> Read about $dumpvars.

I have combined the code with your new version of Simon's code, so this
is no longer required because that code does not use state variables.
Either way, that is some nice information to keep around, as it really
helps making everything go smoothly on an old machine.

Strangely enough, the code that I was using had reset used opposite that
of simon's code:
wire reset;
always @(posedge clock or negedge reset) //his code had posedge reset
begin
      if (!reset) begin //his code had if (reset)
         ...
      end else begin
... 
      end
end

It works either way, just wanted to warn you!

> 
> The Xilinx bit is timing numbers.  Find timing numbers from somewhere
> else and recode the `defines.  Not a big deal.
> 

Ok, I have used gtf for the current numbers. I am now using parameter
instead. For ease of use, we could also get it to parse a gtf modeline,
but that is for another day when there is not so much time pressure.

> 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.
> 

(1) and (2) are currently working in the merged code (with the exception
of the same two offset pixels showing up). Should the test-pattern
generator have hardcoded patterns? If so, that is basically done right
now also (in theory; I haven't actually made sure the code is
synthesizable and written the test pattern Verilog yet). I can get
working on that later tonight.

> >
> > 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.

Ok, that is fine with me. After all, I don't want to be programming a
buggy board :-)


I have not posted the new code as you expressed interest in using SVN
instead. I am fine with this, so I'll just wait to check it in until we
sort out how that will work.

Nicholas

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

Reply via email to