After working through a few logic bugs :o , I recently discovered that there is a potential timing problem (hold violation) with the buffered pipe modules and this could also apply to the unbuffered pipe modules as well.
I am using the most recent installation of the OK software release v1.3.0.
A portion of my design implements two independent SERDES blocks. The SERDES blocks are instantiations of one design which includes a bufPipeIn and bufPipeOut set of modules along with status and control registers.
- I would generate traffic on one SERDES channel and the results were identical to the expected results verified in simulation. I would use the exact same sequence on the other SERDES channel and it would fail. Looking at the data in the status/control registers, it became apparent to me that the data was not transferring properly between the fifo and my logic.
- The symptom above would appear intermittently depending on the image file that was generated. In other words, I would make a tweak and have to generate a new programming file for the FPGA which would introduce this failure. Other images would not. This is a first clue that it was more dependent on place and route.
- Some of the status/control registers are direct copies of the fifo data getting pulled from the bufPipeOut module. These values are corrupted when the symptoms appear. I connected a logic analyzer and brought out the fifo data and read signal. Indeed the read strobe, data out is as described in Xilinx XAPP131. However, the data coming out was already corrupted.
- I then brought out the ti_control and ti_data lines to see what could be happening. Again, the waveforms resemble the ones in the XAPP131 doc.
- I deduced that the data is actually latched on the falling edge of the WRITE strobe (ti_control). In some instances I saw that the data started to change prior to the WRITE strobe’s falling edge as it transitioned back to the idle state (0xFF). This is of course dependent on the placement and routing of the logic within the FPGA which changes everytime one generates a new programming image.
- Reducing the clock frequency does not alleviate the problem. This is another strong indicator that we are dealing with a hold time violation.
- I have attached a sample waveform of what I use in my design. I am essentially transitioning the data on the falling edge of the clock and generate the WRITE strobe as spec’d in the XAPP131 note. As shown in the diagram, the yellow marker shows a write strobe will latch 0xef into the bufPipeIn module. Likewise, I sample the bufPipeOut data on the falling edge of the clock cycle. In the diagram, you can see the data presented by the pipe (0xc3) and the data appears in the shift register (serdesOut) on the next half cycle. This makes my part of the design robust, but what about the Opal Kelly side? I created a 1/2 cycle delay off of ti_data and feed this into the bufPipeOut module. I am able to run the clock in my portion of the design at 32MHz with plenty of margin. I am borrowing from the setup time to do this, so higher frequency designs may not benefit from this technique.
- I am not an FPGA design expert, so it may take me a while to figure out how to specify constraints in the Xilinx suite. Could Opal Kelly provide a constraint file to help the Xilinx tool place and route the Opal Kelly portions to meet timing? With a set of constraints, we may not have to resort to these techniques. Given my relative slow frequency operation, it is faster for me to code verilog for a robust design than to deal with timing problems.
- Any other suggestions???
If this problem can happen between the okHostInterface and okBufPipeOut modules (things that should be black boxes), what about the other modules? Has anyone seen this problem on the other interfaces? Jake, could you evaluate the other interfaces as well? It is critical for the data to transfer properly even between wire and trigger blocks on the first attempt. Other than this issue, I think the kit offers everything we need for the moment.
bufPipeTiming.gif (10.4 KB)