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. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
