RE: [ethmac] Burst Writes/Reads on the Wishbone

["Lake, Matt A @ PWC" <matt.a.lake@l-3com.com>]

Nick,

The simplest explanation i can give you is that you need to set up all the
RX buffer pointers in the MAC to the address mapping you want the mac to use
in your memory.  The mac will keep track of where it is when it recives Data
and write it to the next availible BD.  As for TX you will buffer a packet
into memroy and write the TX pointer to the next availible Tx BD that you
are keeping track of.  Essentially just remeber YOU control the TX pointers
and after you initilize the RX pointers the MAC will keep track of where it
is, and you also keep track of where it is as far as the RX buffer pointers
go. When you get an interupt saying there is a packet you read the control
register of the RX register next in line to make sure this is the pointer
with data, then read the pointer to know where in memory to grab it.  That
is the basic overview.  There are thousands of games you can play to
optimise your memory space but that is the basic overview.

Matt Lake

-----Original Message-----
From: NICHOLAS DAVID LINDBERG [mailto:ndlindberg@students.wisc.edu]
Sent: Thursday, October 24, 2002 3:34 PM
To: ethmac@opencores.org
Subject: Re: [ethmac] Burst Writes/Reads on the Wishbone


Matt,

Do you have verilog code written for reading and writing buffer 
descriptors?  I'm trying to basically do the same thing you are for a 
class project but I can't figure out how the MAC is supposed to know 
what address to write the memory to once it gets data from the PHY.  
Does the mac keep track of memory mapping?  And how does it know which 
buffer descriptors (or how do I konw which buffer descriptors to 
read/write when I want to transmit/send data in the 0x800-0xfff memory 
space?)  

One last thing: let me know if this sounds right as far as operation 
goes:
1) write to all the appropriate status registers to initialize the MAC
2) turn on the Rx and Tx by setting RxEnable bit and TxEnable bit to 1.
3) now it's ready to go (I can start writing Tx buffer descriptors and 
reading Rx buffer descriptors when an interrupt is issued)

Thanks,
Nick

----- Original Message -----
From: "Lake, Matt A @ PWC" <matt.a.lake@l-3com.com>
Date: Thursday, October 24, 2002 3:15 pm
Subject: [ethmac] Burst Writes/Reads on the Wishbone

> While testing the design of the ethmac i noticed something that 
> troubled me.
> After i have buffered a packet into off-chip SRAM i do a write the 
> MAC BD to
> tell it there is a Packet in memory for it to transmit.  Then the 
> MAC comes
> out to memory using it's wishbone compatible interface and begins 
> to do a
> "burst" read from the memory to fill it's internal fifo with the 
> data to be
> transmited.  Well that is fine execpt it doesn't look to me like 
> the MAC
> memory wishbone signals are really wishbone compatible.  It asserts
> m_wb_cyc_o and m_wb_stb_o as well as the address it wants to read 
> from.  I
> then give the MAC it's data and the apropriate acknowlege.  This 
> is where
> the problem occurs.  According to the wishbone spec on page 51 (Block
> Read/Write Cycles) it says that m_wb_cyc_o will stay high during 
> the entire
> block read/write, which it does in simulation, and then it says that
> m_wb_stb_o will cycle with each access in a block read/write, i.e. 
> it should
> be asserted high then deassert when an acknowlege is given then it 
> willreassert m_wb_stb_o with each subsequent access in the block 
> read/write.Well in simulation the m_wb_stb_o signal stays high 
> during the entire block
> read/write.  The MAC will put out a new address when it recieves the
> acknowledge but it leaves both m_wb_stb_o and m_wb_cyc_o high the 
> entiretime.  I dont think this is the correct operation.  Can 
> anyone tell me if im
> correct in beliveing that what i am seeing in simulation is not 
> correct for
> a wishbone compliant block read/write.  Thank you all for your time.
> 
> _____________________________________________
> Matt Lake
> 
> --
> To unsubscribe from ethmac mailing list please visit 
> http://www.opencores.org/mailinglists.shtml

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