Forum Discussion
Occasional ContributorAvalon-ST Mux Not Round-Robining
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.
Super ContributorAccording 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
Occasional ContributorI 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.
