Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
352 Views

Avalon-ST Mux Not Round-Robining

Jump to solution

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

Accepted Solutions
Highlighted
New Contributor I
14 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
Highlighted
Retired Employee
14 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

 

Highlighted
New Contributor I
14 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.

0 Kudos
Highlighted
New Contributor I
15 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

Highlighted
Employee
14 Views

Thanks a lot James for your answer.

0 Kudos