Hi, Attatched is a variation of Petter's code in the form of a state machine, with the fixes to problems I've previously highlighted. I've not simulated it yet, but it may give you an idea or two.
Regards, Howard 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));
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]}};
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.
Regards,
Howard
On 5/30/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
> On 2006-05-30, Timothy Miller wrote:
> > 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.
>
> I see the point.
>
> > >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.
>
> Ok.
>
> > >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.
>
> Never mind. This goes right on the small FPGA, of course.
>
> I see that this is a bit more tricky than software, and maybe I should
> leave it to EEs. But I attach a new implementation, which incorporates
> many of the hints and fragments you posted in this thread. Only
> read/write ATM. Also, a dump to show timing.
>
>
> _______________________________________________
> Open-graphics mailing list
> [email protected]
> http://lists.duskglow.com/mailman/listinfo/open-graphics
> List service provided by Duskglow Consulting, LLC (www.duskglow.com)
>
>
>
spi.v
Description: Binary data
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
