Re: [PLUG] verilog AT talk followup

[Neal]

Galen,

Here's a big THANK YOU for all the time and effort you put into the
presentation and followup!

It was great to get a glimpse of what that Verilog thing is all about
from a practical point of view.

NealS
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

[PLUG] verilog AT talk followup

[Galen Seitz]

Here's some followup info regarding my recent AT verilog talk.  Sorry
for the delay.  I hope someone finds it useful.  Michael, please feel
free to forward this as needed.

Thanks to everyone for showing up and asking great questions.  If you
have further questions, you can send them directly to me.
Alternatively, you could use plug-talk, as I'm a subscriber there.
I'm guessing the main list has less interest in verilog discussions.

galen


Here's the source code for verilog demo.  I fixed the bug in the
counter.  My attempt to generate a synchronous carry chain wasn't
appropriate in this situation.  Once I fixed the carry chain, the
counter worked as intended.  I also cleaned up the resets, added
switch debouncing, added a finite state machine that implements a
simple stopwatch, and fixed the testbench.


Here's the development board I used for the demo.  I added 3 L293D
buffers external to the board to boost the LED drive.


Here's a link to the Cliff Cummings papers I mentioned.


In particular, I've found these papers useful:
1. Coding And Scripting Techniques For FSM Designs With
Synthesis-Optimized, Glitch-Free Outputs
2. Nonblocking Assignments in Verilog Synthesis, Coding Styles That Kill!
3. "full_case parallel_case", the Evil Twins of Verilog Synthesis
4. Verilog Nonblocking Assignments With Delays, Myths & Mysteries


The verilog information found at this site seems to be of relatively
high quality.



FWIW, I've yet to see a verilog book that I've thought was worth the
expense.  I wish Cliff would write one, as I think he would do a very
good job.


Finally, here's a few random verilog tips.  You'll probably come
across various forms of these if you do any verilog reading on the net.

1. Limit modules to one per file.
2. Don't try to create tri-states internal to your FPGA/CPLD.
3. Synchronize asynchronous inputs with two flip-flops to avoid
metastable states.
4. Avoid synthesizing latches.  If the synthesis tools warns you about
latches, pay attention.
5. Using the verilog reg type doesn't necessarily mean the synthesis
tool will generate a register.  reg is used for combinatorial logic too.
6. From a timing and verification standpoint, it's often a good idea
to register the outputs of a module.


-- 
Galen Seitz
gal...@seitzassoc.com

___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug