On 5/31/06, howard parkin <[EMAIL PROTECTED]> wrote:
Hi Peter,Tim
Some things I noticed about the code.
1) The clock output is generated from a DDR register, modelled
by two 'always' blocks, one clocked off positive edge, the other
negative. Most logic synthesizers would have a hard time with this
representation. When it comes to DDR registers, I think the only
way the Synplicity or Precision synthesis tools would generate the
correct logic is to instantiate the register by hand. In the Lattice case,
the two 'always' blocks doing clock generation need to be replaced with :-
ODDRXB sck_buf (.DA(1'b0), .DB(!CE_) , .LSR (1'b0), .CLK (clock), .Q (SCK));
This is why I had written a separate module for this as an abstract
representation of the DDR FF. But this is more specific and what
should end up in the final code.
Note that CE_ needs to be managed separately from the clock. The
diagrams show it going active a cycle before the first rising edge of
SCK. For anything but a read, CE_ can go away after the last clock
pulse.
For a read, the documentation isn't clear. We need to be sure to have
the right number of clock pulses (63 -> 32 rising edges followed by 32
falling edges). We take the data on the next rising edge, and I think
it would be appropriate for CE to go away at the same time as that
rising edge (which will be delayed somewhat due to I/O buffers, so it
won't really be simultaneous).
All of the commands seem to a falling edge of CE_ before the first rising edge.
2) The next thing I noticed is probably something missed
out of the initial specification. For the 32 bit data input, only
a byte is written to the PROM. The byte that is written depends
on which one of the 4 byte enables is active. You can fix this
by adding the code :-
wire [7:0] wr_data = (write_data[7:0] & {8{write_bytes[0]}}) |
(write_data[15:7] & {8{write_bytes[1]}}) |
(write_data[23:16] & {8{write_bytes[2]}}) |
(write_data[31:24] & {8{write_bytes[3]}};
This is better than how I would have done it. :)
The 'wr_data' register is the one that gets put in the 'ck_out_data'
register when a write is requested.
3) The 'read_out_valid' signal has not been generated. Not sure
yet how you would fix this. What should happes is that the 'do_read'
input is set active and remains active until the 'read_out_valid' signal
is generated for one clock cycle. Immediately after the 'read_out_valid''
signal is activated, the 'do_read' signal gets de-asserted or remains
high if another read request is made.
I think with the PCI target logic we have, the 'do_read' signal can
dissapear mid-request, because the PCI bus will time-out. After this,
the PCI bus will re-request the data and the 'do_read' signal will
become active again. I do not think this behavior will affect your
design, as the 'do_read' signal is ignored while the logic is fetching
data from the PROM, but it might be something to bear in mind.
I would store the 32-bit data in one holding register and the address
in another. If a read request comes in that is at the same address,
then one cycle later, we assert the valid signal. Otherwise, the
state machine goes off and fetches.
If anything other than a read happens, that buffer should be invalidated.
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
