SV: Re: [sdiy] Xilinx 3E webpack and its gotcha's!

[Magnus Danielson]

From: karl dalen <dalenkarl at yahoo.se>
Subject: SV: Re: [sdiy] Xilinx 3E webpack and its gotcha's!
Date: Wed, 14 Jun 2006 02:57:00 +0200 (CEST)
Message-ID: <20060614005700.35437.qmail at web27615.mail.ukl.yahoo.com>

> Yes yes i know your happy, but where is the gotcha's??
> There is **always** such things in every dev software
> package relesed under the sun/moon.

Well OK, I tought you ment gotcha's as in "lookee here, we cripled it!".

> example:
> Im still sitting here completely cluless to get the ARM GCC
> system to work, i have never felt so puzzled in my entire life!!
> It appears to me that i have to be a highely trained educated
> brain surgeon just to get the bloody dev tools working!
> I dont have time for this bullshit!
> 
> There are compilers, giveios, cygwin,GCC's,etc, etc,
> and mr fuck and his unckle! And IARs tools aint easyier!

Ehm, yes... it is indeed a jungle there!

The main gotchas I suspect you would run into (from the top of my head) is:

1) In the beginning VHDL feels like PITA since it is (by design) not as
   forgiving as one might first want. There are few good books on VHDL, but the
   main thing is really the grammar and some good guidance examples. The
   strictness is there to catch errors. This would certainly be the biggest
   cause of anyone being confused like hell. We have already seen pointers to
   some of the usefull online material.

2) There are gazillion options in the tools. Your main concern should be to
   select the right device initially. The GUI will guide you through that
   process pretty up-front.

3) In VHDL, in a entity description you usually define signals as either in or
   out. For a signal being out you cannot internally "sense" that signal. It
   will fail misserably. What you need to do is to create an internal signal
   which value is assigned to the output signal name. You always use the
   internal name for assignments of values.

4) When your simulator gives you red traces and the value of U, then you have
   forgot to initialize it. You want to make sure everything is properly reset
   or initialized as a consequence of reset. Oh, you want signals to be of
   type Std_Logic and buses (such as address or data) being Std_Logic_Vector.

5) You need to declare your library and useage before each entity description.
   They are tightly bound for each entity.

6) You most probably want a bus to be the type Std_Logic_Vector(15 downto 0)
   and not Std_Logic_Vector(0 to 15). It will make a world of difference.

... and the list goes on. Many of these things may seem arbitrary and strange,
but that is just what to expect from an unfamiliar system. When I give people
a hand I usuall just give these "arbitrary" rules as a rule of thumb first.
When followed it gets them some ground to experiment. Down the line one might
elaborate more freely on how and why. There is an inner beuty which can be a
bit hard to apprechiate initially.

Hmm... maybe we should cook up some sort of guide/setofexamples/compendium.

Oh, one thing you really should learn. *NEVER* Expect to use up the full count
of CLBs. You run into routing-issues. Above 80% things are becomming
"interesting". The issue is really a routing issue. It tries to distribute
functionality and move it around in an attempt to acheive connectivity AND
timing. Too full this process takes longer and longer until it can run for
hours without any real progress. When you see that you run into these issues
you need to start looking around in the design and see what you can acheive
more efficiently. What to do really depends on the design.

It is hard to summarize what is really the running experience of a fulltime
professional (I don't even claim to be one, I cheat a little in the corner
compared to the full-time guys).

So, yes... you WILL have stimulated spontaneous emitted swearwords! If you
don't you have an uncunning feeling for it or didn't try too hard. For the most
part it will be the basic stuff.

Cheers,
Magnus