On Tuesday 27 December 2005 17:08, Timothy Miller wrote: > Ok, I'm looking at it. Care to paste it inline and explain how it's > different, better, etc?
Hmm, I think it's easier just to list differences rather than putting it inline. Otherwise I'd have to list them both side by side. 1. Naming conventions; they help in identifying which signal is used for which purpose. 2. Synchronous resets, for obvious reasons. :) 3. Keep code that works together combined within one always part. I'm not familiar with tools having issues with the code as I wrote it, but of course code may sometimes need to be adapted accordingly. We've had enough experience in the past with other syntax problems by tools. :) 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. 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. 6. Due to the above mentioned points, the code is a bit more compact, which makes it easier to read, understand, and maintain. Regards, Pieter Hulshoff -- The last good thing written in C was Franz Schubert's Symphony number 9. When your hammer is C++, everything begins to look like a thumb. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
