[ethmac] Bug in internal DMA interface with zero-wait state slave?

[janick@opencores.org]

The following MAC frame was injected through the system (wishbone) 
side:

dst=48'hda838741157f, src=48'h833c831fdb9f, len/typ=16'h0000
tag=16'h8100 pri=3'd1 cfi=1 vlan=12'h01c
dsap=8'h4c, ssap=8'hfc, ctl=16'hd255
length=0, data=
pad=38, data= 0xe9 0xc1 0xb9 0x78 0x82 0x2e .. 0x90 0x96
fcs=32'h6052a574 (good)


And the following frame was received on the MII side:

dst=48'hda838741da83, src=48'h8741157f833c, len/typ=16'h831f
length=54, data= 0xdb 0x9f 0x81 0x00 0x30 0x1c .. 0x87 0x41
fcs=32'h8e01eea8 (good)


Notice how the first 4 bytes (of the dst MAC address) are repeated
in the frame that was received on the MII interface.

http://members.rogers.com/janick/virsim.pdf shows the waveform on the 
wishbone interface to the DMA RAM. The first read cycle is sampled 
twice, at the location of each cursors.

Subsequent read cycles are fine.

If I increase the number of wait state in my wishbone RAM slave model 
to >0, then everything is fine.

My reading of the wishbone interface spec says that a zero-wait-state
answer is perfectly valid.



--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml