Issue with ii_deframer

[plewj]

We are attempting to use the Deframer IP for processing packets as they exit the PCIE Core, and have come across an issue. As we are using both the X5-210M and the X5-TX, and furthermore have multiple X5-210M designs, trying to keep the IP separate from one another proved unwieldy, and we consolidated as much of the Innovative IP as possible. Thus, all of our FPGAs use the following from the X5-TX R0 release: clock, alerts, packetizer, deframer, temp_control, and reg_slaves (and underlying support blocks). We have not previously had any issues so far in either simulation or implementation, but have now come across an issue with the ii_deframer module - while we currently are using it in the X5-210M, given that the X5-210M R3 PCIE Sim. Model and the model from the X5-TX R0 appear to be the same in regards to the RX Data IF (both directly interface to a FIFO), I'm thinking we will see the same problem when we use it with the X5-TX.



In simulation, everything was working fine, though I was streaming the data into the FPGA with no breaks in an individual packet (and we have significant dead time between packets). However, in the lab, we noticed that there could be significant breaks in the data stream ( assume this is normal). Furthermore, the 1st packet appeared to be detected and processed, but subsequent packets would not. Upon further investigation with Chipscope, I noticed that the Read Strobe to the FIFO would remain asserted two cycles after data stopped arriving from the FIFO - apparently due to the latency in determining from the FIFO RD Count that the FIFO was empty. As a result, the Deframer's count of received words would not be accurate, resulting in it thinking that the packet was finished to early, and processing yet another data word as a Packet Header (which would not match anything in the PDN table). It would therefore not be able to process any further packets. I verified this by modifying my simulation to introduce large breaks (up to 50 cycles) in the data stream at random - and was able to observe the same result there.



I did note that there is a new deframer module in the R4 release for the X5-210M. Would updating our Deframer module to this code fix this issue for the X5-210M? If so, as it would no longer work with the PCIE Core for the X5-TX R0, is there a forthcoming X5-TX release that contains an updated PCIE core that also uses this Interface? Or is there by chance some other way to fix this issue?



Thanks.

[Pat Carr]

Hi Jason,

There are numerous changes from the releases you are using, to our latest ones. X5 210M r4.1 was released days ago, while TX r1 was released in June.
Both products include various fixes, mainly in the PCIE core, but also in most of the datapath flow control logic in & out of the PCIE. Deframer and packetizer were re-written using empty & almost empty FIFO flags, that prove to be less timing critical than routing counters back & forth.
There is also a common components directory in the library now, that reuses the modules that you mention.
I would recommend taking a look at them. The porting would not be without some pain, but we believe is worth doing. Enumeration issues are gone, timing is more consistent, runtime is a bit shorter (20% faster under ISE 11.x), and PCIE throughput has been substantially improved.
You can find the latest TX release here:
http://www.innovative-dsp.com/cgi-bin/dlWindowsBeta.cgi?product=X5-TX

[plewj]

Thanks for the quick response.

I've been able to download R4.1 for the X5-210M, but I have not been able to find R1 for the X5-TX, in either the Standard or Beta Release - both contain only the R0 firmware logic. I've tried both InstallFromWeb, and the website itself.

[plewj]

Furthermore, in regards to using the new IP in the R4.1 release - as you said, the Packetizer Input Interfaces now use "empty" and "almost empty" flags - we have several FIFOs that are connected to the channels of this module, that have been providing their read counts, and we now need to modify them to provide the empty and aempty signals instead.

I would have just connected the Packetizer "almost empty" signal to the almost empty flag that is normally sent by a Xilinx FIFO (and that is asserted when only 1 sample is left in a FIFO), However, in looking at the example design (especially in ii_alerts and your configuration of the VFIFO), it would appear that instead we should connect this Packetizer signal to the "programmable empty" flag from the FIFO, and set the empty threshold to eight. Is this correct?

Thanks

[Pat Carr]

[quote]I would have just connected the Packetizer "almost empty" signal to the almost empty flag that is normally sent by a Xilinx FIFO (and that is asserted when only 1 sample is left in a FIFO), However, in looking at the example design (especially in ii_alerts and your configuration of the VFIFO), it would appear that instead we should connect this Packetizer signal to the "programmable empty" flag from the FIFO, and set the empty threshold to eight. Is this correct?
[/quote]

That is correct. We use a programmable empty set to 8 to account for latency in cases where the FIFO read strobe, data output and/or empty flags are registered in the source component.

[Pat Carr]