On Sunday 22 October 2006 00:35, Timothy Miller wrote: > On 10/21/06, Nicholas <[EMAIL PROTECTED]> wrote: > > > > Yes, I recently (as in yesterday, I was going to post it today) > > > > combined them into one, and so the video signals go to the top level. > > > > > > Combined which parts? > > > > gen_head0_signals and test_head0_out. It is now a single module that > > talks to a test case. > > > > > As long as it's mostly working, you can turn off the VCD capture and > > > just use the PPM file as your diagnostic. If you find a bug, then > > > change the timing numbers to something really small and THEN use a > > > waveform viewer. Not only does signal capture take up space, but it > > > slows the simulation. Also, you can select a subset of signals to > > > capture. You can capture only selected interesting signals. > > > > How is it that you only capture certain signals? > > http://www-ee.eng.hawaii.edu/~msmith/ASICs/HTML/Verilog/LRM/HTML/15/ch15.1. >htm > > Read about $dumpvars. > > > This new version is much smaller, close to the 200MB mark, since I > > realized I get 2 pixel/clock now so I only need 1/2 the time length. > > > > > > Again, this should be much nicer later tonight (e.g. no editing > > > > needed)! PS. I attached a version with the 1600 width if people want > > > > it. Also, I need to add the dual licensing stuff to it - for now > > > > there is nothing, but pretend that it has the whole message. > > > > > > I look forward to it. :) > > > > Here it is! > > I still haven't done multi-frame capture, but besides that it works > > great. There are two oddities, however: > > 1) The colors are a little messed up. I don't know why, but I have to > > read them off at the monitor end out of order to get correct values. I > > imagine this means that I have done something wrong somewhere. > > 2) The last line glitches. I think it might have to do with delay > > induced by the lastpixel logic, but I don't really know yet. Whatever > > causes it, the line is the first line of a new frame. In addition, there > > are two pixels right at the beginning (1 clock because 1 master pixel > > and 1 slave pixel) which shouldn't be there. they show up as "x x x\nx x > > x\n" in the scanimage.ppm file. Any ideas on how to fix this? Until > > then, there is still editing :-( just delete the x x x lines, and that > > should product nice images. > > I'll have to have a closer look. > > > Lastly, should I convert the code to work with Simon's module? There was > > some copyright confusion with Xilinx code, and I don't want to convert > > it and not have the new version used. > > The Xilinx bit is timing numbers. Find timing numbers from somewhere > else and recode the `defines. Not a big deal. > > I would like for you and Simon to converge to a single project. We > need (1) a test bench, (2) a monitor simulator, and (3) a > synthesizable test-pattern generator. > > You two can split things up, but feel free to add to each other's work. > > > I am currently working on working on a driver for ODG using > > skeletonfb.c, but if there is more work to be done on this end, I will > > be happy to do that instead (after all, there is no point in having a > > framebuffer driver to a chip that can't display it's framebuffer!) :-) > > At the moment, the most critical thing for ME is to test the OGD1 > prototype board and make sure it's bug-free. That's why I got this > test pattern thing started. We're going to use it next week, after we > have checked out the XP10, and I think we're going to try to do memory > next.
I have done quite a bit of changes to the video controller and also written (using Nicholas' code) two modules acting dac/dvi transmitter and monitor. Awaiting svn access I put it here: http://www.student.luth.se/~simper-2/video_controller.tar.bz2 Now what I've done... It started with me noticing in the dvi spec that the slave transmitter is supposed to get the first pixel in each pair, not the second as I was lead to believe from the naming in Timothy's code (r1,g1,b1 should actually go out before r0,g0,b0). So I changed it to output first part of data on falling edge (which is read a quarter cycle later on rising edge, so for the SiI 178 the assumed mode is EDGE=1 and for the DAC the rising edges of clock and clock_2x need to be aligned). I also added ddr flipflops to delay the syncs and the pixel data is now clocked in on positive edge like everything else. The pattern generator was moved to a separate file to make it easier to switch. The timing numbers were rewritten, local parameters are now used and take into account how many pixels there are per clock. From the simple tests I've run it all seems to work the way I think it should (not necessarily the right way...) I couldn't get Timothy's filename code working with Icarus Verilog version 0.8 ERROR: $fopen parameter must be a constant vvp: vpi_priv.cc:138: PLI_INT32 vpi_free_object(__vpiHandle*): Assertion `ref' failed. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
