On 2006-05-30, Timothy Miller wrote: > It's simply more convenient to hit it in the middle. So, the SCK is > 180 degrees (PI) out of phase from our internal clock. Or at least > that's how we're generating it, but the I/O buffers will add some > nanoseconds here and there.
I see, and since we don't divide the freq, maybe it isn't even possible. > >Some more specific questions: > > > >Is clock_1x the full FPGA clock or the PROM clock? FPGA is 200 MHz, > >right? So, maybe 1:16 for the PROM? Or go with fast read only and use > >1:8? > > clock_1x is sortof a typo from copy/paste from other code. We'll use > only one clock and generate SCK using a DDR flipflop. We are on the small FPGA, of course... > Here's a quick and dirty simulation model (won't synthesize) of a DDR > I/O buffer: > > 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. 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; 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 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. Another thing, will the bitmask of this code itself be on a protected part of the PROM on delivery? _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
