Timing violation when adding code blocks parallel to each other in a FPGA SCTL

[Winko]

Hey guys!

I've got a problem with my code inside a SCTL of a VI running on a FPGA and was hoping somebody could help me.

I'm working with an 120 MS/s ADC and write the data to the FPGA's block memory in a 120 MHz SCTL. Since the data has to be "shuffled" there is also some code to get the right adress (for example first data to adress 0, second to adress 20, then 40 and so on until 2000, then i start again with 1, 21...).

I have a second block of code that later, when writing is done, reads from the block memory to perform some calculation (interpolation of a linear slope of the signal)

Both parts are implemented using pipelining (I'm telling because I think that would be the first answer of the community), so that if I compile just one of them, each one needs about 7 to 8 ns to run, which means they meet the requirements to run in my 120 MHz SCTL (8,33 ns).

But when both blocks of code are in the same clock domain (either in one SCTL ore in two SCTLs using the same clock) of the FPGA VI I get a timing violation, saying that the code in the SCTL needs 17 ns (logic and routing delay) to run. It also doesn't show me the critcal path, just the SCTL. Since the code runs parallel, I see no reason why the logic delay should increase (to 12 ns). The only way the 2 code blocks are communicating to each other are the block memory and some shift registers so the combinatorial path is not increased.

I already checked if the SubVIs (I use one per code block to prevent lack of clarity, but they are different) cause the problem. If the code in the SubVIs directly implemented in the FPGA Main VI it doesn't change the logic delay.

50% of the FPGA's Registers and LUTs are used, 5% of the DSP48s and 50% of block RAM, so I don't think the problem is something like the compiler finds not enough free Slices to create fast paths.

The main problem is not that the routing delay increases, but the logic delay.

Does somebody have an idea what could cause this tremendous increase in delay time?

I'm using labview 2011 and Xilinx 12.4.

[Winko]

OK, I gave it a new try.

first "code block" could be executed in a 125 MHz SCTL. Its results are that data is written into the block memory and that a boolean shift register is set to T when writing is finished.

instead of second code block i inserted (outside of code block 1 of course but inside the same 120 MHz SCTL) just a case-structure with a memory-read method in its true-case. The value of address i (an index shift register value) is written to a local variable. The true-case is executed when the shift register boolean value of code block 1 is TRUE.
Now, this SCTL can only be executed with a 60 MHz SCTL... did really nobody ever experience something like that?

I really don't understand how the memory read method, that is parallel to the memory write method and never executes in the same clock cycle can increase the combinatorial path.

[nathand]

It will be a lot easier to help you if you can share your code, both the version that works and the version that does not.

[MelanieE]

Hi Winko,

I guess we can better help you, when you post your code or an example code that shows the same behavior.

So far, as you said, you have some processing code in the SCTL, maybe the solution in the following link may help you:

Optimizing your LabVIEW FPGA VIs: Parallel Execution and Pipelining - National Instruments
http://www.ni.com/white-paper/3749/en/

Regards,

Melanie

[david1147 · Accepted solution]

Try not putting memory read node inside a case structure. Instead, you can always read from a fixed address, say 0, when the data is not all ready. Reading from a memory will not corrupt your data unlike pushing from a FIFO. If your memory read node is inside a case structure, there will be a mux when the data is passed outside that case structure, which will increase the logic delay.

Besides, I would also recommend that you do not use the index loop "i" if you are running at high clock rate. That counter is having 32 bits and you probably do not have a memory that deep. LV FPGA is having address range checking logic inside the memory read node, so invalid address width may still matter. You can instead implement your code counter with proper bit width.

[Winko]

thank you.