On 12/27/05, Pieter Hulshoff <[EMAIL PROTECTED]> wrote: > 4. Don't use extra FFs for logic that's already small/fast. Consider what kind > of hardware each function will become, and decide accordingly if it needs to > be clocked or can be used combinatorial.
In FPGAs, they're generally free at the ends of combinatorial logic, and this is also true for some ASICs. Could you point out a specific example of where you made this change and how it was an improvement? > 5. I actually prefer repetition of code rather than placing it outside the > always part to keep the code better readable. Within VHDL you can use a > variable for this purpose to keep that code in one place while still within > the process, but I'm not sure if this can be done in Verilog as well. RAMs do > indeed require some special attention. Yeah, you can have a variable inside of an always block. First, you have to name the block, and then you can declare reg's inside of it. I don't like to do that because the synthesizers always end up warning about a signal that's assigned but never used. Plus, it becomes easier to screw up and have a useless latch or ff inferred. Here's how you do the in-block variable: always @(whatever) begin: block_name reg [something:something] varname; .... end > 6. Due to the above mentioned points, the code is a bit more compact, which > makes it easier to read, understand, and maintain. I don't know why, but there are times when I find code that's more spread-out to be easier to read. But this is a matter of personal taste and not very important. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
