On 11/28/07, Hamish <[EMAIL PROTECTED]> wrote: > > Who's in? This is really important, so I hope I can get some of the > > more hesitant people involved. > > > > Don't be afraid to take something on if you don't know Verilog coding > > OK. I'm in. I certainly fall in the don't known verilog very well. I'm rustly > on x86 assembler (It's been a while), but certainly current on C, perl and a > few other languages. And learning openGL...
At the moment, we're mostly doing organizational stuff, although I hope that we have all of that worked out before Dec 7. At the moment, that's more important than coding. > But I'm generalky pretty good at troubleshooting (It's what I do for a living > really :) and pointing out the bleeding obvious that people sometimes miss or > don't care about :) Cool. Some people are going to have to get OGD1 boards for this. Also, could I perhaps encourage you to learn how to use Icarus and gtkWave and making Verilog simulation test benches? This kind of Verilog is a lot more like software, and what you need is a good sense of signals and a good ability to keep track of them. Generate inputs for some chunk of logic, watch what the logic does, see where it's not behaving, point out the cause of the problem. Oh, BTW, even for the most experienced chip designers, reading these timing diagrams can be very time-consuming and frustrating. At the very least, it's extremely tedious. It has advantages and disadvantages over, say, gdb, because you can dig down into the logic and in to the past. Also, simulation is one of the most important things you can do. Just because we're doing FPGAs doesn't mean we can just "compile it and try it." The simplest bugs can make something so nonfunctional that you have no hope of finding the problem without access to internal signals. Even when things work okay, but there's some subtle bug, usually only simulation will tell you where the problem is. So the correct approach is to understand the module you're testing, consider typical and corner cases, generate test patterns that cause those cases, and verify directly through simulation that it's correct. -- 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)
