I respectfully disagree; in my opinion, your reasoning is the wrong way around. The standard is VHDL (or Verilog) and it's the job of synthesis tool builders to make sure that sensible generic HDL compiles efficiently to their target hardware.
It's essentially the same choice as you have in software between implementation in assembly and a processor-independent high-level language. That choice was settled a long time ago for almost any application, and for good reason.
I like the ability to simulate using GHDL. Furthermore, I dislike vendor lock-in in the extreme- I always like to keep open the option of switching with a reasonable amount of effort. That pretty much settles it for me.
Having said all that, as a fellow engineer I can see why you like to push the things that you made yourself to the limits.
Well, some people like "chopped up fatty meat", and don't know what they are missing: better taste, more variety, better health, and also lower cost and higher performance (the analogy fails me here). The battle between the FPGA vendors will not be in the direction of greater similarity.. We will never become DRAM-like commodities where ever lower price is the only differentiator. Our pride is in offering superb functionality and extreme performance at a very attractive price. If you decide not to take advantage of our features, maybe your competitor will... (Not meant as a threat, just a friendly reminder) With my apologies to McDonalds and BurgerKing for the analogy. Peter Alfke
I started writing this yesterday, so i apologize if this has already been answered...
First, no VHDL gurus would solve a hardware problem, which is exactly your type of problem. I understand your concern about this FIFO synthesis stuff. This could be a problem in the tool's interpretation, but...!
Think about that BRAM has registered addresses, so maybe when you uncomment the line you specified, Xilinx can synthesize BRAM and not LUT-based RAM. Furthermore, since you do not reset the pointers, you can never know where is the starting point for them. That's why you might get some garbage in the order of the data.
Now I have a question: If you want to synthesize BRAM, why not generate it using CoreGen and ... ?
I'm rather impressed that you were able to turn a comment about increment vs adder speed into a dis on both VHDL generics AND Altera.
Seriously, though, generics (and Verilog parameters) provide a convenient way of configuring your design without modifying the source code. I can think of a couple of recent design I've done where generics/parameters let me, well, genericize the design to support build-time variants.
One example is this solid-state "disk" built with NAND flash devices. Stuffing options included the number of chips to put on the board as well as each chip's capacity. I used both of these options as Verilog parameters, which were used to ensure that addressing and chip selects worked properly.
Another example is a glue logic chip that connected a video digitizer chip to a graphics processor's VIP (video-in port) bus. The glue did two things: one, it muxed two incoming 8-bit buses (Y on one bus, alternating Cr and Cb on the other) into a single 8-bit bus running at twice the pixel clock rate. The second thing was to insert the required SAV and EAV codes into the data stream at the appropriate time. The graphics processor required an exact number of pixels between SAV and EAV for each line (if off by even one pixel, the processor's video capture logic ignored the data). We wanted to support various video formats at build time, so I made the pixel and line active and blanking counter terminal counts all generic. The standard build supported 1024 active pixels in a line. One customer wanted 512 active pixels in a line, so all I had to do was copy my build script, change PIXPERLINE = 1024 to PIXPERLINE = 512 and rebuild.
Another convenient use of generics/parameters is to embed version and other ID info in the design. This stuff appears as a read-only register to whatever host talks to the design. Your build script sets the version and ECO level and whatever.
In all cases, the source code remains unmodified for all versions. All that's needed to do these wonderful things is to put a generic list along with the chip's top-level port list, and override them using the synthesis tool, either in a script or from within the GUI. This makes source-code control a whole lot easier -- you don't have to keep track of 16 different versions of the source if you need to support 16 different builds!
Funny how with XST, you can't set/override a generic from the command line or from within the ISE GUI. Funnier still how you CAN do this with Quartus' synthesis tool. Perhaps a reason for the antipathy towards generics?
I agree that the adder wouold be equally fast, but the routing won't. Also, he's using the sum unregistered. I know, it's not the addition as such. But using registered addresses for RAM access just happens to avoid problems later on (especially in asics).
As for going low level: I tend to disagree as well. Portable code can be re-used (not that it often is) and as synthesis tools get better and better, we can spend more time on verification (or finish faster). Those small areas where performance becomes critical, some fiddling becomes usefull (I remember an integrator, 80 bits wide in a V2-4 at 100MHz, Synplify-XST didn't do this some 3 years ago). I such cases, I prefer to separate the tuned code in a separate block, so that it's implementation can be replaced by the generic code quite easily. Imagine having to re-use a spartan-2 design that uses the fast comparison trick (if I remember this correctly): it wouldn't synthesize as fast for a spartan-3 because there are no OR lines any more. RAMs are also good candidates (I do like dual-port, read before/after/not on write) as there are enough differences between vendors and technologies.
But by no means I would suggest that Xilinx or Altera should stop improving their devices! Faster, bigger and cheaper are always good. Writing generic code for the Proth seive from a few days back that allows SLRs to be inferred (processing the numbers in 8-bit chuncks) would allow for a very small and fast seive. Still, the code could be synthesized for any target. In this case, there is more gain to be made in the algorithm (hint: what if you evaluate r-p instead of r?).
As for generics, they're great for configuring word lengths or some constants. As for doing dramatic configuration changes, I'd say that different architectures are better suited.
Alvin, I do not see why the routing would care about the difference between an incrementer and an adder. But your preference for registering shows the disadvantage of generics: In Xilinx, the address is automatically registered in the BRAM. External registering just adds one unnecessary level of pipelining. Designing WITH the available features achieves better results than ignoring the features and designing generically. As time goes on, the newer chips have more sophisticated features ( DSP blocks, Ethernet controllers), just like they sprouted SRL16s, BRAM read-while-write, and 18 x 18 multipliers before. Unless the synthesizer is ultra-smart, it will ignore such things.
Well, I am obviously biased. But I hate to see our best ideas go to waste because designers don't use them for not being "generic". Peter Alfke
I'll just chip in, although Peter can comment for himself I'm sure - I read his comments on generics to be referring to "code written in a generic manner not to take advantage of one vendors feature set". I don't think he was referring to generics in the VHDL sense...
However, your examples of where VHDL generics can be used are great!
Cheers, Martin
--
martin.j.thompson@trw.com
TRW Conekt, Solihull, UK
http://www.trw.com/conekt
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.