??? 09/21/07 15:58 Read: times |
#144888 - for purpose of understanding ... YES Responding to: ???'s previous message |
Russ Cooper said:
Hi Richard,
Thanks for your thoughtful response. All that makes sense. However, it doesn't actually answer the question that I asked. All I was looking for was a simple "yes" or "no". For ease of reference, here's the question again: Russ said:
Before I go charging down the wrong path completely, are you suggesting here that I construct my little clock divider starting with the gate-level primitives provided by Verilog? Thanks, -- Russ Yes, I'd suggest you do it in a number of ways, just to see how the differences in expression affect resource utilization. One thing I found in designing CPLD-based hardware with schematics was that the hardware seems to translate very efficiently from schematic to CPLD, while it doesn't work as well in FPGA. In part, of course, this is because FPGA's are register-rich and logic poor, while CPLD's register-poor and logic-rich. You'll find that, as you move from monolithic to modular circuit description, which favors module reuse, the way in which you concatenate modules will affect resource allocation. It will also affect timing. One example I'd offer is that if you design multi-bit counter stages with a synchronous carry output rather than a ripple carry, as is often used in library components, you use more registers but save a bit of time. I've found that I can get a 20-bit counter to operate at 200 MHz in a Spartan-II FPGA using 4-bit counter modules with a synchronous carry output, yet can only get that same counter length to operate at 78 MHz using a ripple carry output. Even though it uses more registers, the synchronous-carry counter module is faster and requires less of the FPGA's routing resources than does a fully synchronous expression of the same counter. In terms of "thinking hardware," it's likely you'll want to consider whether you want to build synchronous or ripple counters (which use much less logic) for some things. Ripple counters use much less logic and fewer routes. A ripple counter counts fast though it doesn't allow glitch-free decoding. Its individual outputs aren't synchronized with the clock that drives the lsb, but they are glitch-free. If all you want is a divided-down clock, they can work very well. RE |