On 6/1/06, Petter Urkedal <[EMAIL PROTECTED]> wrote:
On 2006-05-31, howard parkin wrote: > 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]}};Is it needed? I assumed the software could arrange so that the source data is stored in the upper byte, independent of target address, thus saving the multiplexer gates. (I was also woundering why not specify the full address instead of write_bytes, but I assume that has something to do with the PCI standard.)
This is because we're using a PCI interface, and that's how PCI puts bytes on the data lines. The lower two address bits are always zero (well, there are exceptions, but don't worry about those right now). Bytes are placed on their corresponding signal lines on the bus, and the corresponding byte enables are asserted. (A write combiner will even combine things such that you get odd combinations, like '0100 [assertion low], and that's perfectly valid.)
Another thing. The files that I used to produce the simulation output can be found at http://85.235.225.158/~petter/ogp/spi_prom/: spi_prom_sim.v clipped from Tim's second post on this thread spi_test.v clipped from Tim's same post, with a few tweaks Makefile if you care They may should still be applicable, unless the inferface is changed.
I'll pull them down today and add my own comments. _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
