hdl:lament

A HW-designer's lament: I'm new to FPGA's, but not to HW design in general. Xilinx/Altera et al all characterize their FPGA's in terms of (very nice) HW features. Great, you buy an ev-kit, fire up the SW, only to discover that the SW, i.e, HDL, hides the HW from you. A design that could have been hand-wired in a matter of hours (using imaginary discrete chips having the function-blocks of the FPGA) now turns into an aggravated struggle against the SW (others have described it as pushing a rope, or searching for an incantation which will magically make the synthesis tool behave). Isn't there some way to do direct design instead of the tedious imposing of constraints upon an excruciatingly stupid piece of SW? Thoughts? Cheers, Tom

On Sat, 19 Feb 2005 18:01:21 -0800, Tom <tagerbaek@epo.org> wrote:

>A HW-designer's lament: I'm new to FPGA's, but not to HW design in general. Xilinx/Altera et al all characterize their FPGA's in terms of (very nice) HW features. Great, you buy an ev-kit, fire up the SW, only to discover that the SW, i.e, HDL, hides the HW from you. A design that could have been hand-wired in a matter of hours (using imaginary discrete chips having the function-blocks of the FPGA) now turns into an aggravated struggle against the SW (others have described it as pushing a rope, or searching for an incantation which will magically make the synthesis tool behave). Isn't there some way to do direct design instead of the tedious imposing of constraints upon an excruciatingly stupid piece of SW? Thoughts? Cheers, Tom


That's so hard to read all on one line without wrapping.

When are Xilinx going to fix the software on www.xtra.xilinx.com ? 

Surely it's not hard; newsgroups have been around for a couple of
decades now.

(I know that some readers will wrap long lines, but not all of them
do.)

Allan

When I first got involved with embedded development I had a similar
first reaction. With Altera's Quartus II software there is a graphic
editor, MAX+plusII compatibility mode that and 74xx series library that
once you learn how to use the tools would allow you to design,
implement and test a system in a fraction of the time it would take to
breadboard or wire wrap the same design.

My suggestion to you is to down load Quartus II wepack and try the
online tutorials. Especially the MAX+plusII tutorial. If you don't mind
spending the money on a textbook or the time looking it up at a local
technical university library, try "Digital Electronics with VHDL" by
William Kleitz, ISBN 0-13-110080-7, TK7868.D5K555 2004. The author
blends HDL design methods with skills like you have.

Derek

Derek, thanks for the input, alas, I shall obviously have to acquire the finer points of teaching an exceedingly stupid apprentice (the HDL SW) how to do the job for me, when I could have done it myself in a fraction of the time. BTW, I got a Spartan-3 ev-kit. Cheers, Tom.

Tom,

Initially, FPGA design was done in schematic form.  In fact, schematic 
support is still available for development. (Some designs were done 
using our FPGA Editor initially -- extremely crude, and impossible to 
understand -- like having a wirewrap netlist as your only documentation).

Why has it been all but abandoned? (Schematics are often still used at 
the top level of hierarchy, however by some designers)

The complexity of the designs grew from being some glue logic, to being 
"super" glue logic, to being the whole system (or, perhaps more 
accurately, the heart of the system, and sometimes the heart, lungs, 
brains, and kidneys).

When designs get to these large dimensions (million gate), a schematic 
is no longer an effective way to document the design, and allow it to be 
verified.  50 pages of schematic for the FPGA is just impossible to deal 
with.

HDL initially started out as a means to verify the behavior of a digital 
system.  It was soon adopted as a way to describe the system.

A single language that allows for functional, and behavioral simulation, 
as well as creating test benches to verify the design, was just too 
powerful to ignore.

All serious design is now done in either VHDL, or verilog, as these two 
languages have the necessary features to be effective tools for 
specifying, creating, verifying, and documenting digital systems.

They have their faults, and there are some jobs that are poorly dealt 
with by HDLs, and there are plenty of extensions, improvements, and 
competitors out there working on this.

Take the time to learn VHDL, or verilog.  Or be relegated to the fringes.

Austin


Tom wrote:
> A HW-designer's lament: I'm new to FPGA's, but not to HW design in general. Xilinx/Altera et al all characterize their FPGA's in terms of (very nice) HW features. Great, you buy an ev-kit, fire up the SW, only to discover that the SW, i.e, HDL, hides the HW from you. A design that could have been hand-wired in a matter of hours (using imaginary discrete chips having the function-blocks of the FPGA) now turns into an aggravated struggle against the SW (others have described it as pushing a rope, or searching for an incantation which will magically make the synthesis tool behave). Isn't there some way to do direct design instead of the tedious imposing of constraints upon an excruciatingly stupid piece of SW? Thoughts? Cheers, Tom

On Sat, 19 Feb 2005 18:01:21 -0800, Tom <tagerbaek@epo.org> wrote:

> A HW-designer's lament: I'm new to FPGA's, but not to HW design in general. 
> Xilinx/Altera et al all characterize their FPGA's in terms of (very nice) HW 
> features. Great, you buy an ev-kit, fire up the SW, only to discover that 
> the SW, i.e, HDL, hides the HW from you. A design that could have been 
> hand-wired in a matter of hours (using imaginary discrete chips having the 
> function-blocks of the FPGA) now turns into an aggravated struggle against 
> the SW (others have described it as pushing a rope, or searching for an 
> incantation which will magically make the synthesis tool behave). Isn't 
> there some way to do direct design instead of the tedious imposing of 
> constraints upon an excruciatingly stupid piece of SW? 

If you really want to control exactly what goes into an FPGA, you can.

For starters, you can bring up FPGA_Editor (not in the free webpack,
but is in both the full and the evaluation versions of the software),
and put exactly what you want exactly where you want it.  This is
sometimes the only way to do something, but is hardly a good way to do
most designs.  I mostly use this to see what was built by the tools,
and to see what I want the tools to build.  I suggest that novice
designers should spend some time with FPGA_Editor to learn what is
there and how it can be connected.

There is XDL, a very low level language that allows for full control.
This displays some information that FPGA_Editor does not for some of
the older parts.  This was very useful to me once, I have not used
this for a while, but it is still around.

At fairly widely useful level, look in the Xilinx Install Directory
for:

\vhdl\src\unisims\unisim_VCOMP.vhd

This file has the component declarations for the real primitive
elements that are in the parts.  You properly include this library,
and then you can write your design with a netlist of elements, each of
which you can position in a fixed or a relative location.  This is
worth knowing how to do for a speed critical section of a design.  For
putting multiple items of the same type down learn about the VHDL
"Generate" statement.  

Finally, spend enough time on the learning curve so that you
understand what about logic will be built from a given source.  If you
are pushing the speed hard, you may want to use lots of primitives
will full placement information.  If you are pushing the speed
somewhat, you may need to use some, and learn a little about
floorplanning.  My impression is that most designs are done with VHDL
(or with Verilog) this way because:
1) The code is faster to write
2) The code easier to maintain
3) Performance is high enough for most uses.


--
Phil Hays
Phil-hays at posting domain (- .net + .com) should work for email

Austin, thanks, I got the message regarding HDL (still I find 50 pages of hierarchical schematics a lot more readable than 50k lines of code, though). But look: the purpose is to use Spartan-3/400s as front-ends for 200Msps DACs and ADCs. I'll be using only the BRAMs and maybe 3-5% of the CLBs, so the logic is simple, but the required speed is critically close to the published S3 limits. Things like ensuring nice, parallel data-flows spring to mind; for example, one could shuffle the bit order in the RAM to prevent needlessly crossed lines. However, I haven't been able to find any pertinent information in the S3 documentation. There's a 1000 tricks and considerations like the above, which every HW-designer knows, but they all reside in that very boundary where HDL-synthesis takes over. I have nothing against HDL, I just wanna get this thing flying, fast. Cheers, Tom

Phil, thanks for the valuable info. I will try it before my 60-day SW evaluation period expires. As it were, my design is indeed very simple and very fast. Cheers, Tom

Tom,

Well, as for fast, HDL is the way to go (as in get it done quickly).

Time saved by simulating, etc. will pay off later.

Fast (as in performance) is tougher.  Even in a schematic, you can not 
tell the place and route software how to route everything.

In fact, constraints with or without a schematic are required to get the 
best performance.

Or, as one suggested, open up FPGA Editor, and see what is happening. 
(May do that in any event).

The tradeoff is a difficult one:  become an HDL expert and a constraints 
expert, or stick with schematics and hack constraints...

I prefer the first, as it will serve you better as you do other 
projects.  It will start slower, and finish faster, though.

Austin


tom wrote:
> Austin, thanks, I got the message regarding HDL (still I find 50 pages of hierarchical schematics a lot more readable than 50k lines of code, though). But look: the purpose is to use Spartan-3/400s as front-ends for 200Msps DACs and ADCs. I'll be using only the BRAMs and maybe 3-5% of the CLBs, so the logic is simple, but the required speed is critically close to the published S3 limits. Things like ensuring nice, parallel data-flows spring to mind; for example, one could shuffle the bit order in the RAM to prevent needlessly crossed lines. However, I haven't been able to find any pertinent information in the S3 documentation. There's a 1000 tricks and considerations like the above, which every HW-designer knows, but they all reside in that very boundary where HDL-synthesis takes over. I have nothing against HDL, I just wanna get this thing flying, fast. Cheers, Tom

austin wrote:
> Tom,
>
> Well, as for fast, HDL is the way to go (as in get it done quickly).
>
> Time saved by simulating, etc. will pay off later.
>
> Fast (as in performance) is tougher.  Even in a schematic, you can
not
> tell the place and route software how to route everything.
>
> In fact, constraints with or without a schematic are required to get
the
> best performance.
>
> Or, as one suggested, open up FPGA Editor, and see what is happening.

> (May do that in any event).
>
> The tradeoff is a difficult one:  become an HDL expert and a
constraints
> expert, or stick with schematics and hack constraints...
>
> I prefer the first, as it will serve you better as you do other
> projects.  It will start slower, and finish faster, though.
>

Howdy Tom,

  From your description of schematics, it seems like you aren't
referring to modern schematic tools... most that I've heard of
translate your schematic into an HDL.

Overall, I have to admit that I'm a fan of schematics - mainly because
I think in more graphical terms, and I think it is somewhat easier for
others to pick up and understand the *overall* functionality and flow
of the design.  But when you get down to doing the details of the
functions, it ends up taking quite a bit of time and effort to do it,
and you WILL end up finding times where you have to battle with the
schematic tool to get it to do what you want.

I was going to suggest going HDL for the same reasons as Austin, but
had one additional reason:  what better time to start learning an HDL
than with a small, straight forward project like this?  In reality, it
isn't hard to find examples (either from the vendors or other example
online code) of enough stuff that I'd be surprised if it really slowed
you down by more than a day or two.

BTW, a schematic entry doesn't force routing internal to the FPGA to be
any different than HDL, so I don't see that as being a deciding factor.

Have fun,

   Marc