- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 between the 32 ethernet packets (it is now 8 to 12 bytes). Is there a way to modify this gap, and if so, how? I also want to change the length of the payload of the packets. How?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
HI,
Can you be more specific on which example design that you are referring to here ?
- Do you have the link to the example design ?
- Or if this is example design generated from certain Intel FPGA IP, then pls share with us which IP and using what setting ?
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Dlim,
Thanks for responding to my question.
The example is "Scalable Low Latency Ethernet 10G MAC Intel FPGAIP",
see https://fpgacloud.intel.com/devstore/platform/14.0.0/Standard/scalable-ll-ethernet-10g-mac-with-10g-baser-phy-design-example/?wapkw=LL%20Ethernet%2010G%20MAC,
and see amongst others "ug-20162_LL_MAC_cyclone10GX" manual.
Or the UG-01144, see https://www.intel.com/content/www/us/en/programmable/documentation/bhc1395127830032.html
I am not sure if i changed any settings, a least not intentionally, except for some (irrelevant) timing in the testbench (to make it faster), What i am sure about is that i replaced the INTEL PHY with my own PHY, with some specific features. I got that working.
The configuration I use is 10 Gbps, 1 channel, xgmii 64 + 8 bit.
Now i want to change the testbench (tb_top.sv in the example), such that that there are not exclusively packets of 75 bytes (including preamble, CRC, closing byte "FD")
The packets always end with last2 valid bytes (when the packet starts in hte second half of the 64 bit dataword, or with last6 valid bytes (when the packet starts on the first half of the 64 bit dataword.
I also want to check my PHY on last1, last2...last8 valid byte at the end of packet.
The packets are very tight to each other: 8 byte or 12 idle byte, see examples below (where "07" is an indication of "idle")
time(nsec) data cntr
3789 istin A3208DD2E6FB626E 00000000
3796 istin 0707070707FD2B8F 11111100
3802 istin 555555FB07070707 00011111
3809 istin 00000000D5555555 00000000
3815 istin EEAACC88CCEE0000 00000000
(example 8 byte from MAC), or
3853 istin CCBCF5E2A39F4168
3860 istin 07FD2B8FA320C1C1
3866 istin 0707070707070707
3873 istin 555555FB07070707
3879 istin 00000000D5555555
3885 istin EEAACC88CCEE0000
(example 12 byte from MAC)
I want to be able to change this gap of 8 or 12 byte to any multiple of N * 4 bytes. (exclusive of the 0, 1, 2, 3 last idle byte at the end of a packet)
Now i am building a fifo between eth_generator and the MAC to create those gaps, but that is not a very elegant way ).
I believe the clue is somewhere in:
* "avalon_if_parameter_pkg.sv" : for packet length
* "default_test_params_pkg.sv" : i thought for a moment change "INSERT PAD" from 1 to 5, but this does not result in a visible change anywhere
* "eth_mac_frame" : there is a function "virtual function void insert_payload(ref bit [7:0] frame_data[], input bit [7:0] payload[])" (i am more VHDL then Verilog, what functionality is this virtual void?)
* "eth_register_map_params_pkg.sv" seems to be address map
I attached a part of the transcript, from vlog command onwards.
line 3 - 100 : compiling
line 101 - 314 : elaboration
line 315 - 369 : warnings
line 377 - 443 : starting of testbench
line 446 - 626 : warnings during runtime (not so relevant, those appear in my PHY, not in INTEL's), mainly searching for blocklock and the processing of 'x' s
line 626 -677 : receipt of packets
line 678 - 683 : processing compare
line 688 - 756 : reporting compare.
Looking forward to your advice.
Regards, Pieter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter,
I looked at the LL 10G example design and I can see that the Ethernet traffic generator is controlled by a BFM (avalon_driver.sv) which is then further controlled by Altera Avalon BFM (csr, st Tx and st Rx)
- alt_em10g32_0_EXAMPLE_DESIGN\LL10G_10GBASER\simulation\ed_sim\models\avalon_driver.sv
- /ip/altera/sopc_builder_ip/verification/altera_avalon_mm_master_bfm/altera_avalon_mm_master_bfm.sv
- /ip/altera/sopc_builder_ip/verification/altera_avalon_st_sink_bfm/altera_avalon_st_sink_bfm.sv
- /ip/altera/sopc_builder_ip/verification/altera_avalon_st_source_bfm/altera_avalon_st_source_bfm.sv
To be honest, it's complicated and not easy to decode these BFM. I am sorry. I can point you some direction but I won't be able to do much help for you.
- Perhaps you can also consider to re-write your own test bench as well
Else If you look at the testbench top level file again (tb_top.v), look like from line 640 onwards in function (if (id == 0),
- Looks like user is able to tune some setting provided you spend time to understand the BFM address mapping.
- Feel free to explore it
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter,
Sorry for getting back late to you.
It seems like you are experimenting with different design logic to interact with 10G MAC and you also build your own Ethernet traffic generator/checker ? and you are seeing weird behaviour on your own Ethernet traffic generator/checker or are you trying to feedback there is some issue in Ethernet example design ?
- Did you enable ECC option in 10G MAC so that you can check for potential error bit with ECC error correction signal ?
- There are some timing diagram on both Avalon ST Tx and Rx interface data transfer that you can cross check as expected reference vs your design data transfer
- https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_32b_10g_ethernet_mac.pdf
Thanks for the detail explanation but sorry, I don't think I understand and following your issue here.
- We don't restrict how customer build their user logic to interact with MAC.
- If adding extra buffer/FIFO helps to smooth out the data traffic transfer pipeline then it's not a bad choice either.
- Also always ensure design is able to meet timing closure in Quartus Time Quest Analysis. Sometime weird result behaviour is due to data transfer failure caused by design timing issue.
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter,
I have not hear back from you for sometime.
Hopefully everything goes well at your side.
I am now setting this case to closure.
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter van Leeuwen,
Intel agent support structure goes by IP area and on a case by case support basic.
For instance, I am supporting Ethernet IP while some other Intel agent is supporting PCIe enquiry.
Unfortunately I am not familiar with PCIe and won't be able to help you out.
My suggestion to you is
- We can close this existing case
- while you can file new forum thread mention about the enquiry support on PCIe then this new case will be routed to Intel PCIe support agent that can provide better assist to you.
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter van Leeuwen,
I hope you had file new forum thread for your PCIe enquiry as per my earlier suggestion.
For now, I am setting this case back to closure.
Thanks.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Deshil,
Sorry for not answering earlier. I solved now all my hardware issues with my version of PHY connected to the INTEL MAC. Thanks for that.
I found several UG's and AN documents describing the PCIexpress IP and Examples. At a certain moment in time, i managed to generate a .par file, from which QUARTUS lite 18.0 generated PCIE- IP. However, i cannot find a way to generate the <pcie_a10_hip_0_example_design> as described in ux-dex-a10-pcie-avst.pdf, found at https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug-dex-a10-pcie-avst.pdf.
Can your PCI Express collegue support me in generating this design example. Second question to him: there is a choice between the avalon-st protocol implementation, and a avalon-mm implementation. As the Low Latency MAC interfaces with an Avalon-ST interface, I thought this would be the more easy choice. Is that right, or are there reasons to use the mm version? Regards, Pieter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter,
Np and good to know Ethernet issue is resolved at your end.
Yes, Intel PCIe support agent can support you.
My only request to you if pls file new forum thread and post your PCIe questions there so that your new forum case can be assigned to Intel PCIe support agent to help you up. :)
This is how Intel support structure works. Thanks for your understanding.
Regards,
dlim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Pieter,
I can see that you already filed new forum thread on PCIe enquiry
Hence, I will be setting this case back to closure.
Thanks.
Regards,
dlim

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page