Forum Discussion

NJasa's avatar
NJasa
Icon for New Contributor rankNew Contributor
5 years ago

SGDMA - TSEMAC - SGDMA Loopback problem. TSEMAC internal loopback.

Hi,

I made the program of TSEMAC in internal loopback mode. I use TSEMAC IP in opencore plus. I made the program to transfer frame from Tx_SGDMA to TSEMAC and internal loop back to Rx SGDMA to frame buffer. But it won't work. In the program i used printf for verifying description address allocation, TSEMAC Initailiation register value, etc. For TSEMAC and SGDMA Qsys setting, i have attached snapshot for the same. I have also attached the Nios-II program. I used 8-Bit FIFO with 2048 Depth in TSEMAC.

According to my observation, FIFO in TSEMAC is creating problem, I check and found Tx_SGDMA transfer frame to TSEMAC by checking number of bytes transferred field in descriptor. But TSEMAC is not initiating transmission. I set FIFO in store and forward mode.

Please help to solve this loopback failure.

Thanks and Regards,

Nandish Jasani.

8 Replies

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi Nandish Jasani,

    When you said it won't work - do you mean no return data back to RX or the RX return data is wrong value ?

    I don't see your TSE IP setting screen shot. Can you re-attached the screen shot again ?

    If you suspect is TSE IP internal FIFO issue, then

    • You can increase the FIFO depth to change it to 32 bits FIFO

    Additional debug suggestion to you is

    • You can also disable the TSE MAC internal loopback setting to see if TSE output data to PHY side to isolate it's loopback setting issue or TX data traffic transaction issue
    • Pls signal_tap both Avalon ST Tx transaction and Avalon ST Rx transaction. I expect there will be back pressure status signal from TSE internal FIFO or error signal status explaining why it's failing at your test run

    Thanks.

    Regards,

    dlim

    • NJasa's avatar
      NJasa
      Icon for New Contributor rankNew Contributor
      5 years ago

      Hey Thanks for your reply and sorry for late reply. I have attached TSE IP Qsys settings.

      I had tried 32 bits FIFO, but still problem persist. Actually in my code i am checking TX and Rx status counters. So following is problem i found.

      1) Sometimes TX OK Counter increments but TXOctet transmit value shows less and random from my set value of 1514 bytes. If transmit frame is ok then why its shows TX Octet transmitted value less.

      2) Same frame is received success fully with RXoctetreceived byte is equal to Tx octet byte transmitted. But sometimes rxframecheckerror shows, as this is internal loopback then why framecheck error shows?

      3) Recevied frame is also wrong from what i transmitted. All bytes are shows wrong including MAC Destination and Source address.

      I think you are right, there is something problem with internal FIFO.

      I will try what you suggest. And also check my TSE IP setting, if something wrong, please suggest to correct it. Have you check my C code? is there any thing wrong in it?

      Thanks

      Nandish Jasani.

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    HI,

    I am sorry I am not familiar with C-code, hence I won't be able to help you review your C-code design but I can try my best to provide TSE debug suggestion to you.

    • Your TSE IP setting looks fine except do you use the "align packet to 32 bits boundary" setting ? Certain OS application may need this setting

    In general, I would recommend you to check out Intel TSE user guide doc as usage and debug reference.

    Let me summarize your problem statement to make sure I understand your issue correctly.

    1. You found out some issue with TSE statistic counter
    1. Your TSE MAC loopback Avalon ST RX data is different from TX sent data
    • My concern is maybe your Avalon ST TX data sent to TSE MAC is already corrupted hence the MAC loopback RX data is wrong as well
      • Or maybe TSE internal FIFO is already full but you still continue sent TX data causing packet drop situation
      • Or is there any potential Quartus design timing closure issue ? Have you verified in Quartus timequest ?
      • That's why I asked you to signal_tap both Avalon ST Tx data and Avalon ST Rx data traffic to compare result. Pls trigger on error signal (rx_err[5:0]) to check when failure happen and let me know which error type that it captured
      • If you found out something wrong with TX data transmission then you can back track to check out your TX_SGDMA IP
    1. Sometime you observed aFrameCheckSequenceErrors (CRC error)
    • My first question to you is how do you configure CRC insertion in TSE IP ? (command reg tx_cmd_stat[bit 17])
      • Do you let TSE IP compute the CRC or your software application needs to provide the correct CRC ?
    1. TSE MAC loopback guideline
    • You can find out more about loopback usage in chapter 4.1.9 MAC Local Loopback. It also suggest you to check for other statistic counter as well
    1. Lastly, have you follow user guide doc chapter 5.3.1 guideline to initialize TSE IP correctly during power on ?

    Thanks.

    Regards,

    dlim

  • NJasa's avatar
    NJasa
    Icon for New Contributor rankNew Contributor
    5 years ago

    Hi,

    You correctly summarize TSEMAC Problems. I have Cyclone-IV E device EP4CE55F23I8L and i used Quartus Primer version 16.1.0 SJ Standard Edition. Please let me know if any bug in this software version.

    Yes i am doing signal tap for Avalon Rx and Tx activity. I will try to get what type to error i found. Once i received error i will inform you that which type of error it is.

    TSE IP itself calculate CRC in my case.

    Presently i am trying debug.

    Thanks and Regards,

    Nandish Jasani.

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    Hi Nandish Jasani,

    I screen through the KDB link. Those TSE IP counter known issue mainly affecting earlier Quartus version before v14.

    So, your Quartus version of v16 should be fine.

    Thanks

    Regards,

    dlim

    • NJasa's avatar
      NJasa
      Icon for New Contributor rankNew Contributor
      5 years ago

      Hi,

      I am replying late, busy with another work, I have done signal taping or Debugging TSEMAC. I have attached word file with four images of TSEMAC signal tap.

      1) Image1: TSEMAC Signals before Nios-II Application code.

      2) Image2: TSEMAC Signals with Nios-II Application code running. It seems that TX-SGDMA is not working. It also shown that there no event occurs in eop and sop.

      3) Image4: TSEMAC Signals show event occurs in TXD[3..0] and TX_ENABLE event occurs. But at the same time there is no event occurs in eop and sop. Why TSEMAC sends data as TX SGDMA is not working?

      4) Image3: TSEMAC signals shows tx_ready from TSEMAC is deasserted and TSEMAC now stop working.

      So from above observation, there is something problem of TXSGDMA. Can you please share any code example of SGDMA-TSEMAC-SGDMA which is proven? So I can check with my code.

      Also please share your opinion by seeing attached image, if require letme know if any more information require in signal taping.

      Regards,

      Nandish Jasani.

  • Deshi_Intel's avatar
    Deshi_Intel
    Icon for Regular Contributor rankRegular Contributor
    5 years ago

    HI,


    I am setting this case to closure since I have not hear back from you after my last feedback in early July.


    Hopefully you are doing well with your project development.


    Thanks.


    Regards,

    dlim