You are not logged in.
Hi
I have been using Chipscope recently (which is really cool by the way) to see what is happening to some of the internal signals in the 802.11 ref design. Specifically in the rx phy.
In wlan_phy_rx_pmd > Sync & Antenna Sel > Resets, there is a comment noting that the logic handles the rare case of a valid SIGNAL being received then getting reset before the packet is processed. This turns into the RX_ENDED_UNEXPECTEDLY sink block which then goes to wlan_phy_rx_pmd > MAC IO through some ORs until eventually triggering PHY_RX_END.IND.
In Chipscope this can be seen, when the rx block is unexpectedly reset, PHY_RX_END.IND also goes high one cycle later. It returns low after the reset signal is removed. But there is also a second rising edge of PHY_RX_END.IND after a variable number of cycles.
After a bit of rooting around this seems to come from wlan_phy_rx_pmd > Sync & Antenna Sel > PHY CCA > Rate*Length BUSY. This block generates the goto called RX_END_OFDM_LAST_SAMP which in turn is used in wlan_phy_rx_pmd > MAC IO and routes to the signal PHY_RX_END.IND.
I guess the sub block 'Rate*Length BUSY' is used to determine the length of the actual transmission and indicate it has ended via the RX_END signal? This causes a second 'blip' of RX_END since it has not been reset with the rest of the system. The variable length delay makes sense, as this is how long the reception *should* have taken.
This is a very niche problem but could I solve it by adding the GLOBAL_RESET source block to the reset pins in Rate*Length BUSY?
Thanks for any advice.
Offline
Interesting... Having RX_ENDED_UNEXPECTEDLY reset the Rate*Length logic should be fine.
That logic (and its associated quirks) is a bit...historical. The early versions of the PHY only supported BPSK/QPSK. But it was necessary to defer to receptions at the higher, not-yet-supported rates. Hence the Rate*Length block that keeps CS asserted independent of the operation of the actual Rx PHY pipeline. This block pre-dates the MAC hardware; I built it when the MAC was software-only and still under development.
The RX_ENDED_UNEXPECTEDLY logic is much newer, designed to handle the very rare sequence of:
-Valid SIGNAL arrives, asserting RX_START to MAC hardware
-Something external resets the Rx PHY
-MAC hardware gets stuck, since no RX_END followed the previous RX_START
The PHY must always generate an RX_END for every RX_START to keep state in the MAC hardware sane. However there may be RX_END events that don't have RX_START (bad SIGNAL, for example).
Offline