On 6/14/06, Tom Cook <[EMAIL PROTECTED]> wrote:
Thanks a lot for providing these lessons. I learned VHDL at uni a few years
ago, so I'm finding this easy to follow but very informative of the
differences between VHDL and Verilog.
However, one thing we never talked about at uni was synthesis (more because
I didn't take that subject than because no-one talked about it). Can you
spend some time talking about synthesis issues? For instance, how would a
synthesis tool go about implementing the code you have presented in this
lesson? Does it just "know" about adders and multipliers and how to
implement them at gate level? I guess some targets provide adders and the
like - do you need to use a specific synthesis tool to make it use them? Or
can you tell the synthesizer what blocks are available and make it use them?
There are a lot of common functional units like adders, multipliers,
memories, multiplexers, decoders, etc. that synthesizers are designed
to recognize straight from the RTL. The back-end (map, place, and
route) also applies some heuristics to further optimize for the
available hardware, but things generally work best when you code
things in a way (they call them 'templates', but they're just coding
styles) that the synthesizer is going to recognize as the thing you
want. That's why we code resets the same way all the time, for
instance.
In modern FPGAs, it's important to do the RTL inference, because there
is hardware that is generally accessible only when a block is
recognized correctly. For instance, there are carry chains that go
between slices in Xilinx and Lattice FPGAs. Those carry chains may be
manually instantiable by name as a module in RTL, but for the most
part, they're used only for adders, subtractors, and similar things.
So, if you were to manually code an adder, ripple-carry or
look-ahead-carry, the synthesizer's heuristics probably wouldn't
recognize it as an adder, you wouldn't get the carry-chain logic, and
the result would be a larger, slower design.
As for random logic, it's relatively straightforward to map arbitrary
combinatorial logic to the gate technology in FPGAs and ASICs.
Especially with FPGAs which are just 4-input 16-entry memory blocks
which can implement ANY function of 4 bits. You may recall in logic
design, they taught how to convert two-level logic (where the first
level is AND, and the second level is OR) into all NAND or all NOR.
For an ASIC with simpler gates, there's this sort of translation going
on. But also, there's still a heck of a lot of RTL-level inference
being done. Chip vendors have large libraries of pre-optimized logic
blocks that are dropped in where appropriate. And given the special
hardware, they're almost always a win, even when they theoretically
might not be the most optimal way to implement exactly what you had in
mind.
BTW, a lot of what I know about synthesis has been gleaned through
observation of how synthesizers behave, what kinds of information
messages come out of them ("INFERRED INSTANCE OF 4X6 RAM CELL"), and
what I've seen of post-synthesis netlists. I'm sure someone like
Howard would find inaccuracies in my explanation. Just like learning
to get gcc to spit out assembly code from your C program can teach you
assembly, it can be helpful to experiment with very simple Verilog
designs and see what the synthesizer produces. Most of them can show
you block schematics, and there's some small value in looking at the
final EDIF netlist.
What if part of my design is a specific gate-level ALU implementation? How
do I then make the synthesizer use *my* ALU to implement all the
arithmetic/logic operators? Some detail on these issues would be
interesting, although perhaps others might find it more helpful if this was
deferred until a later time.
I'm eventually going to code an ALU in a lesson, so it's important.
When you're in a hardware design class, learning to design an ALU,
they tend to design this small functional unit that takes three data
bits in (two operands and a carry) plus a operator, and this
efficiently block implements add, sub, and, or, xor, etc., and then
they stick a shifter on in the next stage. While this is nice in
theory, and it's okay for some technologies, it's horrible for an
FPGA, because you don't take advantage of specialized hardware.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
