Difference in behaviour with Clock derived from Onboard clock and from CLIP clock

[Intaris]

We are using a PXIE-5693 FPGA card and are using the MGTs.

We have a CLIP which outputs a clock with a nominal frequency of 200MHz, which is an MGT clock output.

When I compile code using this clock, everything seems fine. But I have some code which requires to run at 2x this frequency. I have tested this code at 400MHz (Evena t 500MHz to make sure I had headroom) using on-board clocks before the CLIP had been developed. It compiled every time with onboard clocks, but I get a timing error whenever I try to run it with the 400MHz clock derived from the CLIP clock. The code barely reaches 300MHz in timing, and when I check the timing violation, it only lists two simply "non-diagram component" entries.

I would assume that the issue is not per se with the code (as it will compile at 500MHz) but seems to have something to do with he CLIP clock itself. I was wondering if anyone out there had some inputs as to what might be going on here. I have some ideas what might be different:

• Free-running vs CLIP clock. LV handles free-running clocks differently (including disabling the "implicit enable" functionality)
• Origin of the Clock from which we are deriving: Does the origin of the clock from an MGT make a difference? Is there something special we need to take care of in this instance?
• Could it be a problem with the clock enable and clock valid signals we provide for the CLIP clock?

[Terry_ALE]

---

@Intaris wrote:

We are using a PXIE-5693 FPGA card and are using the MGTs.

We have a CLIP which outputs a clock with a nominal frequency of 200MHz, which is an MGT clock output.

When I compile code using this clock, everything seems fine. But I have some code which requires to run at 2x this frequency. I have tested this code at 400MHz (Evena t 500MHz to make sure I had headroom) using on-board clocks before the CLIP had been developed. It compiled every time with onboard clocks, but I get a timing error whenever I try to run it with the 400MHz clock derived from the CLIP clock. The code barely reaches 300MHz in timing, and when I check the timing violation, it only lists two simply "non-diagram component" entries.

I would assume that the issue is not per se with the code (as it will compile at 500MHz) but seems to have something to do with he CLIP clock itself. I was wondering if anyone out there had some inputs as to what might be going on here. I have some ideas what might be different:

• Free-running vs CLIP clock. LV handles free-running clocks differently (including disabling the "implicit enable" functionality)
• Origin of the Clock from which we are deriving: Does the origin of the clock from an MGT make a difference? Is there something special we need to take care of in this instance?
• Could it be a problem with the clock enable and clock valid signals we provide for the CLIP clock?

---

Can you confirm the product you are using?  5693 is an RF product https://www.ni.com/docs/en-US/bundle/pxie-5693-specs/page/specs.html

Maybe 6593?

[Intaris]

Ah, correct, PXI-E 6593.

I've done another test with the different clock sources.

I added a SCTL with a simple boolean toggle and FP element. When I compile with onboard 400MHz, it compiles absolutely no problem. Estimated is met, end result is met. Unfortunately, Vivavo compiles no longer give the actual clock rate of estimated timings. I suspect it's around 500-600MHz.

When I replace the 400MHz onboard with a 400MHz CLIP derived clock, estimated timing is only 270MHz. And this is for a single flip-flop. This is the same estimated timing as I get for a quite complicated 200MHz bandwidth multifrequency PLL code base. The estimated timing seems to be completely independent of the actual code complexity. In the simple case of a boolean toggle, it can still compile at 400MHz, but anything significant will not. The huge differential between the behaviour of the estimated timings for what is essentially the SAME frequency makes me think something is missing from our implementation of the clock export from our CLIP.

We are basically exporting our TXOUTCLK from our MGTs. All lanes are operated synchronously, they all have the same clock. Are there any specific clock drivers we are maybe missing from our design?

[Terry_ALE]

Which pin are you outputting the clock on?

[Intaris]

It's not being exported via hardware, it's being exported via CLIP interface to our LV code.

We want to run our LV code synchronous to the actual MGT clock. In the CLIP we generate a 200MHz clock which drives an 8b/10b encoder and we are passing this 200MHz clock from the MGT core to our LV code via CLIP.

In LV, we then want to derive a 400MHz clock from this and execute out code in this clock domain. I have been int ouch with some of our other engineers, and they think it might be a missing BUFG connected to the signal when passing it from the MGT core to the CLIP interface.

[JÞB]

OK You said some magic words that got my 8-Ball shaken, "PXIe" and "Difference in behaviour with Clock derived from Onboard clock."

So, let's get straight to the first basic condition which PXIe timing depends on.   TEMPERATURE! Yes, that PXIe chassis must be properly cooled or the clocks overheat and wander.   

Check the following;

• Fan filters
• Air flow around the chassis
• Slot blockers in unused slots
• Blank panels secured

We had this exact problem once and to everyone's surprise BUT MINE we found a half open chassis sitting sideways up against a back corner of the developers cube full of dust and the most sensitive card located next to (just above as positioned) the controller (hottest part in the chassis.)  Of course, with no slot blockers, what little air the fans did move, got sucked through the unpopulated slots (that generate 0 heat and thusly need 0 airflow for cooling)

Why wasn't I surprised when everyone else was?  I read the manual.  It states very clearly that you will likely encounter timing issues if you don't manage the chassis cooling well. 😎 Imagine that!

I'll say the needless to say part too.

Needless to say,  when we positioned the chassis correctly,  left a empty slot (with slot blocker) next to the controller,  cleaned out the dust, and added all needed slot blockers and slot covers. The Timing issue disappeared.   

[Intaris]

---

@JÞB wrote:

OK You said some magic words that got my 8-Ball shaken, "PXIe" and "Difference in behaviour with Clock derived from Onboard clock."

So, let's get straight to the first basic condition which PXIe timing depends on.   TEMPERATURE! Yes, that PXIe chassis must be properly cooled or the clocks overheat and wander.   

Check the following;

• Fan filters
• Air flow around the chassis
• Slot blockers in unused slots
• Blank panels secured

We had this exact problem once and to everyone's surprise BUT MINE we found a half open chassis sitting sideways up against a back corner of the developers cube full of dust and the most sensitive card located next to (just above as positioned) the controller (hottest part in the chassis.)  Of course, with no slot blockers, what little air the fans did move, got sucked through the unpopulated slots (that generate 0 heat and thusly need 0 airflow for cooling)

Why wasn't I surprised when everyone else was?  I read the manual.  It states very clearly that you will likely encounter timing issues if you don't manage the chassis cooling well. 😎 Imagine that!

I'll say the needless to say part too.

Needless to say,  when we positioned the chassis correctly,  left a empty slot (with slot blocker) next to the controller,  cleaned out the dust, and added all needed slot blockers and slot covers. The Timing issue disappeared.   

---

That's all correct and important to note, but not what we're seeing here. I'm referring to compile-time differences in clock behaviour i.e. Vivado reaches much lower compilation speed with one 400MHz clock than a different 400MHz clock with the same jitter and accuracy settings. We currently don't even get to the stage of temperature being able to mess things up. We're stuck much earlier in the process than that. It's a code issue, not a physical one. When I say we don't reach the speeds, I'm referring purely to compilations, not actual hardware performance.

[Intaris]

I attach timing reports from two different compiles, same code but different clocks.

I wonder if someone more knowledgeable than me can give a hint as to what's going wrong? The only thing that seems different to me is the FDCE (register) at the end of the onboard timing report......