Le Jul 5, 2006 à 5:10 PM, Timothy Miller a écrit :
Many of you who have a software background but haven't had the time to learn hardware should find this to be something you can sink your teeth into. I've written a test harness for the video controller. You can download and run the test, and with the wave viewer, you can watch the output signals. In the test that's in SVN, I've coded a simple loop that walks the video sync signals, so you only need to look at vid_clock and out_signals at the top level to see it working. Check out the code from here: http://svn.suug.ch/repos/opengraphics/main/trunk/rtl/vid_ctl/ If you have Icarus and GTKWave, the "runsim" script will run the simulation and start the wave viewer. Then you can add signals and see the behavior of the video controller. Near the end of video_test.v, you'll find an initial block that makes a bunch of calls to the write_reg task. Hack the bit where I've put in my simple program. Make sure you understand the behavior of the ins_addr signal inside of the video controller before you do too much, because this is how you'll know that the thing is behaving correctly. Some may want to add $display statements to print out specific instructions being executed. Gate those with video_enable (which presently is only a power-consumption device to turn off the video program RAM). When writing new code, keep in mind that the counter values are not intuitive. They're (2049-x), where x is the number of cycles to repeat the instruction before moving on. You'll see that I've put 2048 into the simple test so that each instruction executes only once. Questions?
I finally figured out how to use GTKWave, and it works great! It is SO much easier than how I have debugged previous Verilog with $monitor, $display, etc. I have a few questions about this design: 1) Is there any work going on for a C "compiler"? it is quite difficult to get everything worked out how it is, and seeing how my last program, the SPI module, was already done, I don't want to work on anything if it is finished. I could also try to write a nice interface that outputs assembler from parameters entered, unless that is also in the works. It would be very nice to eventually be able to choose, say, "640x480x32/60Hz", and a binary to be loaded is outputted. 2) What is the status of various Verilog modules, drivers, BIOS, etc? I am willing to help with those, but again, I don't really want to rewrite something that was written by someone else. 3) What should we be doing with this module? It is just some Verilog for us to peruse/correct, or is there other work that needs to be done with it (e.g. interlaced)? (in regards to my previous comment about looping, forget it. I thought this was a higher level than just timing, and actually controlled the video display, where tiling would be useful)
nick_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
