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

Reply to
Tom
Loading thread data ...

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

formatting link
?

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

Reply to
Allan Herriman

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

Reply to
DerekSimmons

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.

Reply to
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:

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

Reply to
austin

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

Reply to
Phil Hays

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

Reply to
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

Reply to
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:

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

Reply to
austin

not

the

constraints

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

Reply to
Marc Randolph

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

Did you look at the ABEL code flows ?

ABEL is more direct, and uses dot extensions [.CK, .D, .T, .AR ...] so is very like creating a NET LIST. More like assember vs Visual basic :) If your task is simple, and the learning curve will dominate, you could try that.

Last time I looked, ABEL was still supported (actually improving) in the Xilinx tools. [.. and also Lattice, and Altera have a similar flow called AHDL ]

I presume it is still there, in Webpack, and will support S3 and BRAMs - Austin ?

-jg

Reply to
Jim Granville

Guys,

many thanks for your input.

I've seen the writing on the wall and will dive into HDL.

BTW the fpga editor looks promising - even I can understand it at some level.

Cheers, Tom

Reply to
tom

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.

A damn good start into HDL: Peter Ashenden's "The VHDL Cookbook" downloadable from

formatting link
and it won't take long to read.

His dead tree book "Designer's Guide" is pretty good too...

- Brian

Reply to
Brian Drummond

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

One more thing: You can use the Xilinx/Altera primitives to instantiate your logic exactly. I end up having to include MUXCY or MUXF5 primitives manually often enough to meet my speeds even with an advanced 3rd party synthesizer. Arrays of instances and generate statements allow me to do wider operations easier without sacrificing too much in the way of readability. There are spots I've even resorted to manually instantiating LUTs to have something I can always RLOC to keep my critical timing close.

Often, however, just knowing the silicon will allow you to code in a form that the synthesizer has a better chance of doing the right thing from the start. I find myself coding in Verilog to get the full data flow in a concise form then checking the timing and iteratively constraining or infusing primitives to get my timing. If you need 2.5 or fewer logic levels to run at 250 MHz, it's easier to code with Verilog to get the paths that automatically fall to 1 or 2 levels of logic and spend time getting the other paths chopped down through redesign, pipelining, or primitives.

Schematics wre fun until I had to start sitting through 180 page design reviews. I am soooo glad I have Verilog.

Reply to
John_H

May I suggest that you do not use the FPGA editor to build your whole design. Create some building blocks (datapath components) and hook them up via HDL and place them with the floorplanner.

In this case you usually can trust the tools to map any external control logic with less then four inputs into a single LUT and automated placement of a few LUTs between hand placed macros shouldn't be too bad either.

Kolja Sulimma

Reply to
Kolja Sulimma

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.