On 11/9/07, Josephblack <[EMAIL PROTECTED]> wrote: > http://wiki.opengraphics.org/tiki-index.php?page=HDL_Resources
It looks good, although I have one concern. I'm very experienced with designing chips in Verilog, yet I had to take a moment to figure out how the Verilog code for the 138 matched the truth table. It's far from obvious. As I have said before, playing tricks with the language syntax buys you nothing, except perhaps lousy synthesis. In this case, it also buys you a poor teaching tool. There are only disadvantages to being overly terse. If this is to be an educational tool, we should show off how readable we can make the examples, not how cleverly we can compress how we express the logic. Besides, the example on the page is not only NOT maximally terse but it's also less readable than what IS maximally terse. Now, I'll admit that sometimes, when _optimizing_ to meet timing or area constraints, a designer is forced to do some things that hide the true semantics behind what's going on. Just compare the simulation and synthesis models of the PCI controller. But when you're _designing_ something in the first place, you should strive to make your code as explicit and readable as possible. More code in Verilog does not necessarily translate to more gates. In fact, quite the opposite is true in many cases. Sorry for the rant. I really appreciate the work that everyone's doing on this. I just want to inject some wisdom I have learned from making these mistakes early in my career as a chip designer. You wouldn't believe some of the crap I've written (and how the synthesizers puked when faced with it). Here's what _I_ think makes a more readable model and one that synthesizes well too! First, of all, I'm getting signal names from here: http://focus.ti.com/lit/ds/symlink/sn74ls138.pdf I don't like them, so I think we should either change them or insert comments. I have inserted comments. I think it would be just great to change the names. Also, module SN74138( // 3-to-8 demultiplexer input [2:0] CBA, // Select which output to pull low output [7:0] Y, // Output input Gbar2A, // Pull low to enable input Gbar2B, // Pull low to enable input G1, // Pull high to enable ); // First, combine the enables together. When the disable signal is high, // all outputs are forced high. wire disable = Gbar2A || Gbar2B || !G1; // Now, compute each of the outputs assign Y[0] = (CBA != 0) || disable; assign Y[1] = (CBA != 1) || disable; assign Y[2] = (CBA != 2) || disable; assign Y[3] = (CBA != 3) || disable; assign Y[4] = (CBA != 4) || disable; assign Y[5] = (CBA != 5) || disable; assign Y[6] = (CBA != 6) || disable; assign Y[7] = (CBA != 7) || disable; endmodule You MIGHT be able to come up with a form of this that uses less logic or is faster, but I don't see much value in optimizing too early. Maintainability is more important than confusing yourself. However, it is also the case that repeating yourself a lot in code can cause you to make errors. What if I'd changed all the Y subscripts but forgot to change one or more of what CBA is being compared to? That can be a problem. So here's a more terse representation that, for an experienced designer, can have some readability and error-proneness advantages: module SN74138( // 3-to-8 demultiplexer input [2:0] CBA, // Select which output to pull low output reg [7:0] Y, // Output (marked reg for behavioral block) input Gbar2A, // Pull low to enable input Gbar2B, // Pull low to enable input G1, // Pull high to enable ); // First, combine the enables together. When the disable signal is high, // all outputs are forced high. wire disable = Gbar2A || Gbar2B || !G1; // Now, compute each of the outputs integer i; // Loop variable always @(CBA or disable) begin for (i=0; i<8; i=i+1) begin Y[i] = (CBA != i) || disable; end end endmodule Note that I would suggest supplying both forms. It's educational to see both the straightforward case and the loop case. -- Timothy Normand Miller http://www.cse.ohio-state.edu/~millerti Open Graphics Project _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
