On 5/30/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> module DDRIOFF(clock_p, clock_n, in_p, in_n, out); > input clock_p, clock_n, in_p, in_n; > output out; > reg out; > always @(posedge clock_p) out <= in_p; > always @(posedge clock_n) out <= in_n; > endmodule > > We have positive and negative clocks and two data inputs, one for the > high cycle and one for the low cycle. > > Instantiating it will look like this: > > DDRIOFF ddrbuf (.clock_p(clock), .clock_n(!clock), .in_p(...), > .in_n(...), .out(...)); > > In our case, with the phasing and all that, I think it would look like this: > > DDRIOFF ddrbuf (.clock_p(!clock), .clock_n(clock), .in_p(sck_enable), > .in_n(0), .out(...)); I couldn't find a good ref on DDR (dual data rate?) at the moment, so I might not get this, but: What I think this does, is deliver a clock on 'out' which is shifted by pi plus maybe a small amount caused by loading it into a register.
Typically, a DDR I/O buffer is designed to send/receive two bits per clock, one on the rising edge, and one on the falling edge. But they're also useful for generating clock signals.
How about passing an inverted clock on write, then a double-length clock-high continuing into a non-inverted clock for read? SCK = ((reading? clock : !clock) || switching_write_to_read) && clock_enable;
You don't want to do this for a few reasons. First, it's generally frowned-upon to use clocks in logic. Secondly, we want to guarantee the timing of all of the I/O's which means we want all I/O to be registered, including the clock. Using logic like what you're doing can work when you carefully constrain the path, but when you register things, you don't have to worry about it.
Or is it better not to "upset" the PROM by putting out "weird" clocking and instead sample SO on 'negedge clock' in the FPGA?
I'm betting duty cycle matters because of the fact that the prom uses both edges of the clock. We also want to run it at the fastest rate.
> I might not have that exactly right. > > > > >Reading your previous post, it seems that you only intend to support > >byte writes, i.e. only one bit in write_bytes is set for each write. > >Is that right? (My sketch takes any value of write_bytes, but this > >conflicts with configuration.) > > > > Right. The basic problem is that it's evil to cause unnecessary wait > states on the PCI bus. When you do, you starve other devices. Since > it's milliseconds between writes (required by the SPI), we can just > let software time the delay. But we couldn't we write 32 bits simultaneously? In any case, byte-only writes simplifies the RTL, and I guess programming the PROM is kind of an exceptional activity, anyway.
We could design it so that we post 32 bits and then wait four times as long. But that means the state machine has to count down the time delay between writes (or poll the status register). It's just not worth the logic for what should be a rare event. And we can't even speed it up much!
Another thing, will the bitmask of this code itself be on a protected part of the PROM on delivery?
I'm not sure what you're asking about. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
