Forum Discussion

PVanL's avatar
PVanL
Icon for Occasional Contributor rankOccasional Contributor
5 years ago

Low latency Ethernet 10R Reference Design. How to modify the behaviour of the testbench?

I understand the "avalon_if_param_pkg" is used to configure the behaviour of the Avalon Interfaces. Eth_register_map_params_pkg to configure the inside of the packet. I want to change the gaps betwee...
Deshi_Intel's avatar
Deshi_Intel
Icon for Regular Contributor rankRegular Contributor
5 years ago

Hi,

I am sorry. Indeed a painful process for you.

There is one thing that I would like to clarify on your option 3 - regarding tx_ready signal.

  • May I know are you referring to "avalon_st_tx_ready" as mentioned in user guide doc (page 101, table 40) ?
  • https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_32b_10g_ethernet_mac.pdf
  • the tx_ready is actually a output status signal from MAC to user indicating condition of MAC. If MAC is busy then it will back pressure user data traffic by de-asserting tx_ready else if tx_ready is high, that's mean MAC is ok to accept user data.
  • I believed if you want to stall user traffic, then the input control signal should be "avalon_st_tx_valid"

Thanks.

Regards,

dlim

PVanL's avatar
PVanL
Icon for Occasional Contributor rankOccasional Contributor
5 years ago
Hi Deshil, Thanks, that is indeed the parameter I am using. However, there is something odd. I first built in altera_eth_10g_mac_base_r a nice fifo buffer between Avalon_st_adapter and the MAC (in the altera_eth_10g_mac_r_wrap ). SC_FIFO => AVALON_ST_ADAPTER => MAC was modified into: SC_FIFO => AVALON_ST_ADAPTER => FIFO => MAC Then I ran the testbench: passed! Below you will see the signal from end of packet 1, packet 2, and start of packet 3 Val = valid, sop = start of packet, eop = end of packet, mty = empty, dav = the ready signal. You see that the signal is nicely hold during dav = 0, and continues again after dav is made 1 again (by the MAC). So far, so good. val 1 sop 0 eop 0 mty 0 dav 1 E6FB626E 6E62FBE6 val 1 sop 0 eop 1 mty 2 dav 1 00008DD2 D28D0000 val 1 sop 1 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 01003000 00300001 val 1 sop 0 eop 0 mty 0 dav 1 D138F5BA BAF538D1 val 1 sop 0 eop 0 mty 0 dav 1 D8D2FF84 84FFD2D8 val 1 sop 0 eop 0 mty 0 dav 1 8A497C15 157C498A val 1 sop 0 eop 0 mty 0 dav 1 2716DDDA DADD1627 val 1 sop 0 eop 0 mty 0 dav 1 F3B7CD8C 8CCDB7F3 val 1 sop 0 eop 0 mty 0 dav 0 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 0 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 0 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 0 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 0 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 1 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 1 1F34C835 35C8341F val 1 sop 0 eop 0 mty 0 dav 1 DF6B7265 65726BDF val 1 sop 0 eop 0 mty 0 dav 1 523E4CBC BC4C3E52 val 1 sop 0 eop 0 mty 0 dav 1 A39F4168 68419FA3 val 1 sop 0 eop 0 mty 0 dav 1 CCBCF5E2 E2F5BCCC val 1 sop 0 eop 1 mty 2 dav 1 0000C1C1 C1C10000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 1 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 1 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 02003000 00300002 Then I built, without using this extra buffer, based on your suggestion, a simple statemachine, generating idles by making ‘avalon_st_tx_ready = ‘0’ back to the Avalon_st_adapter to indicate ‘hold your signal’. So, without using the extra fifo. After some iterations it worked. Simulation passed. SC_FIFO => AVALON_ST_ADAPTER => IDLE_GENERATOR => MAC (the idle generator has no fifo, it just holds tx_ready towards the Avalon st adapter, when a idle should be made, and forwards tx_ready from the MAC when not) val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 01003000 00300001 val 1 sop 0 eop 0 mty 0 dav 1 D138F5BA BAF538D1 val 1 sop 0 eop 0 mty 0 dav 1 D8D2FF84 84FFD2D8 val 1 sop 0 eop 0 mty 0 dav 1 8A497C15 157C498A val 1 sop 0 eop 0 mty 0 dav 1 2716DDDA DADD1627 val 1 sop 0 eop 0 mty 0 dav 1 F3B7CD8C 8CCDB7F3 val 1 sop 0 eop 0 mty 0 dav 0 3010BFC8 C8BF1030 val 1 sop 0 eop 0 mty 0 dav 0 1F34C835 35C8341F val 1 sop 0 eop 0 mty 0 dav 1 DF6B7265 65726BDF val 1 sop 0 eop 0 mty 0 dav 1 DF6B7265 65726BDF val 1 sop 0 eop 0 mty 0 dav 1 DF6B7265 65726BDF val 1 sop 0 eop 0 mty 0 dav 1 523E4CBC BC4C3E52 val 1 sop 0 eop 0 mty 0 dav 1 A39F4168 68419FA3 val 1 sop 0 eop 0 mty 0 dav 1 CCBCF5E2 E2F5BCCC val 1 sop 0 eop 1 mty 2 dav 1 0000C1C1 C1C10000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 1 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 02003000 00300002 val 1 sop 0 eop 0 mty 0 dav 1 3856DA8B 8BDA5638 val 1 sop 0 eop 0 mty 0 dav 1 4E1D101E 1E101D4E val 1 sop 0 eop 0 mty 0 dav 1 9544372D 2D374495 val 1 sop 0 eop 0 mty 0 dav 1 0A9CE36B 6BE39C0A val 1 sop 0 eop 0 mty 0 dav 1 D21E53C7 C7531ED2 val 1 sop 0 eop 0 mty 0 dav 0 5256C93A 3AC95652 val 1 sop 0 eop 0 mty 0 dav 0 E14279C8 C87942E1 val 1 sop 0 eop 0 mty 0 dav 1 409E1A9D 9D1A9E40 val 1 sop 0 eop 0 mty 0 dav 1 409E1A9D 9D1A9E40 val 1 sop 0 eop 0 mty 0 dav 1 409E1A9D 9D1A9E40 val 1 sop 0 eop 0 mty 0 dav 1 644ED592 92D54E64 val 1 sop 0 eop 0 mty 0 dav 1 864EF32D 2DF34E86 val 1 sop 0 eop 0 mty 0 dav 1 CAE46D7F 7F6DE4CA val 1 sop 0 eop 1 mty 2 dav 1 0000107C 7C100000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 0 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 1 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 00000000 00000000 val 1 sop 0 eop 0 mty 0 dav 1 03003000 00300003 val 1 sop 0 eop 0 mty 0 dav 1 AE9F6EC5 C56E9FAE However, if you look closer, you will see that the relation between ‘dav’ (= tx_ready as generated by the MAC) is set to ‘0’, while the inputs keep coming, and after ‘dav’ turns to ‘1’, it repeats the signal two more clocks. So, the signal is delayed with 2 clocks compared to the ‘dav’ (which makes perfectly sense if you look at the logic of the ‘idle generator’: the ‘dav’ signal from the MAC needs 1 clock to propagate back to the adapter, and the signal from the adapter needs 1 clock to propagate to the MAC. Together 2 clocks (so, the idle generator makes an erroneous signal). So far so good. But how then can the test pass?????? Let us look at the signal coming from the TX side of the MAC into the PHY, did it indeed take out correctly the signals that are invalid? ( that is: 2 of the 3 DF6B7265’s?). Of course not, it took out 3010BFC8 and 1F34C835, as it should, as indicated by the ‘dav’ signal. Yet, the test passed! So, the evaluation gives a false positive! (a sort of corona test that gives a false negative, although the person tested is positive). Can you explain / elucidate? Do I have some misunderstanding somewhere? Or does someone @ intel has to do some homework? Regards, Pieter