I looked a bit on this in the weekend, but since have no experience I
didn't want volunteer to lead it. You can see what I have got this far
on
http://85.235.225.158/~petter/ogp/spi_prom/
I have, however, made an assumption that, after reading your post, I
think is wrong. If you'll excuse the elementary question:
When reading some Verilog tutorial, I drew the conclusion that there is
an underlying assumption about flip-flops and timing. Namely, that
there is a delay from when the data is sampled at the rising clock until
the data appears on the output. Furthermore, this delay is longer than
the variance in sampling times due to propagation and finite rise-time
of the clock signal. Thus, the same clock can drive serially connected
flip-flops, and the data is sampled at the end of the duration of their
valid value.
This is not the case for the PROM, right? I can think of some reasons
why not:
* It uses different tech. than the FPGA, and thus sample that data
at different points on the rising clock edge.
* It may drain more charge than is available at the end of the valid
cycle.
(Since the PROM inputs on posedge and outputs on negedge, we could force
the assumption by shifting the clock of the PROM by pi/2 before that of
the controller. This should work for reading to, since the PROM outputs
on falling clock:
clk: ++++----++++----++++----++++----++ + high
sck: ++----++++----++++----++++----++++ - low
SI: XDDDDDSDXDDDDDSDzzzzzzzzzz X indefinite
SO: zzzzzzzzzzzzzzzzzzXDDDDDSDXDDDDDSD D data, S sampled data
Or is it's critical to hit the middle of the valid data?)
But, the timing-assumption holds within the FPGA, right? So, we don't
have to deal with such detailed timing considerations for most of the
work?
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?
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.)
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
