You are not logged in.
I had a query to make regarding the transmission.
Since, no queue is being maintained on the transmitter side and only one frame is present in txBuffer, so what happens to the frames sent by the higher layers when the ethernet interrupt is disabled (warpmac_disableEthernetInterrupt()). Do such frames never make their way to the warpmac board?
Offline
That's correct. If the the rate of Ethernet traffic exceeds what the wireless MAC can keep up with, packets will be dropped at the emac.
Keep in mind that this is a property of our reference design, not the platform itself. You can certainly add queueing to handle cases like this.
Offline
Hi,
I just found this post from Chris and was wondering if somebody can give me some advice on how to implement a packet queue for the ethernet interface. Has somebody already implemented this or could give me some hints or ideas on how to do it?
Thanks!
Offline
Hi.
You could transfer the packets coming from eth to several TX PHY buffer locations. You need some kind of circular buffer scheme to keep track of the buffers which are used and aren't . When you need to send the packets(PHY->AIR) then transmit according to your scheme from physical buffers.
Study the chain between ETH buffer and the PHY buffer (located in warpmac.c) and you will get the hang of it. Also remember that packet has header and payload, so also copy the header to the TX PHY buffer.
Offline
Hannu's suggestion is a good one. The OFDM PHY has a large (64KB) packet buffer which is divided into 32 2KB "sub-buffers". The OFDM reference design only uses three of these sub-buffers- one for receiving packets, one for sending data packets and one for sending ACKs. You could implement a queue in the remaining sub-buffers without adding any hardware (i.e. just by modifying C code to track more packets in buffers).
Offline
Thanks, that sounds really good.
But how does the board handle the parallel execution of code, meaning does it call the emac handlers while it is still processing the previous packet or even while it is processing the goodHeaderCallback handler? I know that when a timer is active, the board reacts to incoming emac packets and executes the respective handlers but how does that look like when it is still executing other functions?
Offline
When using the standalone board-support-package (like the OFDM reference design does), the PPC core runs everything in a single thread, so there is no parallel execution of code. But everything in the FPGA fabric (like the PHY and Ethernet MAC) do run in parallel. We exploit this in the reference design. For example, consider the flow of events during a wireless packet reception. The packet detector triggers the AGC and OFDM transceiver cores (all in the FPGA fabric). The transceiver begins processing the incoming packet, but doesn't notify the PowerPC until either a good or bad header is received. Until this time, the PPC can do other things (like handle Ethernet stuff, or manage a packet queue).
Offline