FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5990 Discussions

Avalon-ST Mux Not Round-Robining

JHaye4
New Contributor I
535 Views

I am trying to share my TSEC between a hardware data path and some simple DHCP/ARP from NIOS, I have connected both streams up to the mux but only am seeing traffic from nios leaving the device. I put a signal tap in and can see my data plane traffic arriving at the mux but never leaving it. Does the simple round-robin scheduler need anything to work? My understanding from the data sheet is that it should function independently.

0 Kudos
1 Solution
JHaye4
New Contributor I
197 Views

My setup for this was two Avalon-ST interfaces wishing to use a single TSEC for egress from my FPGA. One of the streams was 32b@100MHz originating within QSYS, the other 8b@125MHz from external data plane. What I was originally seeing in QSYS with the Avalon-ST MUX set up to operate at 32b@100MHz was only my traffic from QSYS passing through the mux. When data arrived at the mux from my external data plane (via a width and clock adapter) the valid signal was choppy and I originally thought this might be causing issues even though it was within the avalon spec.

 

To solve the problem I changed the setup of my MUX to be 8b@125MHz (this required adding in an extra clock interface for my QSYS block). I used a DC FIFO to cross the clock domain within QSYS, and then let the width adaption take care of itself and fed this interface into port 0 of the MUX. I was then simply able to import my data plane traffic into QSYS to take advantage of the MUX. The output of the MUX was exported out of QSYS and into my ethernet wrapper block. This solved the issues I was having that the MUX would not detect packets arriving at both interfaces.

 

View solution in original post

4 Replies
sstrell
Honored Contributor III
197 Views

According to the user guide, the scheduler switches inputs in the following scenarios:

     

  • The specified number of cycles have elapsed.
  • The input interface has no more data to send and valid is deasserted on a ready cycle.
  • When packets are supported, endofpacket is asserted. 

 

Which method are you relying on for the switch?

 

#iwork4intel

 

JHaye4
New Contributor I
197 Views

I am using the packet scheduling setting with two interfaces, and I can see that my input on port 0 is working properly as the packets are making it through the mux to the TSEC and out to a receiver PC. However, no packets from the second interface are ever seen on the TSEC and I have seen when they arrive at the MUX uncontested, they are not passed through.

JHaye4
New Contributor I
198 Views

My setup for this was two Avalon-ST interfaces wishing to use a single TSEC for egress from my FPGA. One of the streams was 32b@100MHz originating within QSYS, the other 8b@125MHz from external data plane. What I was originally seeing in QSYS with the Avalon-ST MUX set up to operate at 32b@100MHz was only my traffic from QSYS passing through the mux. When data arrived at the mux from my external data plane (via a width and clock adapter) the valid signal was choppy and I originally thought this might be causing issues even though it was within the avalon spec.

 

To solve the problem I changed the setup of my MUX to be 8b@125MHz (this required adding in an extra clock interface for my QSYS block). I used a DC FIFO to cross the clock domain within QSYS, and then let the width adaption take care of itself and fed this interface into port 0 of the MUX. I was then simply able to import my data plane traffic into QSYS to take advantage of the MUX. The output of the MUX was exported out of QSYS and into my ethernet wrapper block. This solved the issues I was having that the MUX would not detect packets arriving at both interfaces.

 

Ahmed_H_Intel1
Employee
196 Views

Thanks a lot James for your answer.

Reply