On 10/21/06, Nicholas <[EMAIL PROTECTED]> wrote:
> 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!
It's too early for me to think about why it might work in simulation
either way. But you should pair "negedge reset" with "!reset" and
"posedge reset" with "reset". But you knew that. :)
>
> 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.
Excellent.
> 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.
The idea is to get something we can look at on a scope and also
something simple to see on a monitor.
A good test pattern that we like to use is to put a big boxed X on the screen.
Start with a black screen. If you're on the first or last scanline,
make the pixel white. If you're on the first or last column, make the
pixel white.
The tricky part is the line. I would suggest something vaguely
resembling a bresenham algorithm. For every column, add the height of
the screen to a register. For every row, subtract the width.
Whenever the number is within some range make the pixel white.
Something like that. Fiddle with the math in software first, watching
the numbers and seeing what they look like along the diagonal. The
idea is to get ax+by=c to have c<1 or something like that, but here, c
is scaled up by some denominator that I can't reason through right
now. :)
> >
> > 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)
