Timothy Miller wrote: > This is making my head hurt. I don't know why. :)
Sorry, shouldn't have elaborated on that. > What's happening here is that the request is being ignored until the > cycle when busy is going low. That is, the logic as I wrote above > doesn't deassert do_read until after it's observed busy==0 for a > cycle. Yes, that how I understood it. > The more complete logic for this, when you have to transfer data with > the request (like an address in this case) is like this: > > always @(posedge clock) begin > if (!busy) do_read <= 0; > if ((!do_read || !busy) && wanttoread) begin > do_read <= 1; > read_addr <= whatever; > end > end I've put this into the test bench for the reads, or as close as I managed to integrate it. >> >> What is the requirement for read_out_valid? You said that it should >> only be asserted in respose to a read request. Does it also need to go >> low a cycle later, or could it remain high until a new request is made? >> > > It would be best to make it go low one cycle later, I think. We have > multiple sources of read data being given to the PCI controller, and I > think it might simplify things if we couldn't have more than one > 'valid' signal asserted at the same time. Technically, the data isn't > valid the instant we change the address to something else anyhow. And the best we shall have :-), it now deasserts read_out_valid after a cycle. I also put `ifdef-`endif around the read-configuration code. For the record I transfer the copyright the Traversal Tech., so that you are free to commit it to the repo.
spi_prom-0.2.tar.bz2
Description: application/bzip
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
