LabVIEW
LabVIEW FPGA timing error in compilation
312MHz is extremely high even for FlexRIO. You can't have much of sequential logic in the loop that runs at this speed. The fact that increasing the latency of the memory read doesn't seem to change much should give you a hint that the bottle neck is likely not at the memory read but some other function in there. A harmless looking multiplication node certainly would have more impact than a memory read for instance.
Also note that you usually can't just go and change the read (or write) latency of nodes without also adding extra pipeline stages and/or changing the surrounding logic to account for that extra delay without causing functional differences in the code.
@ramya850 wrote:
I added extra pipelining after increase the latency of memory read.
I am using complex multiplication in 10 different places of code.
The first time, I used high throughput complex multiplication in the FPGA palette.
I haven't worked with PCI FPGA, only cRIO/sbRIO hardware, which has lower performance limits than FlexRIO. But even a single high throughput multiplication does prevent me from getting an SCTL loop faster than 100MHz if there is anything else in the same code path, so if you have such a node in the 312 MHz loop, I'm not surprised about your timing constraint at all.
If the multiplication (or division) happens to be a power of two then you can try to do it with a rotate or shift instead. That is more efficient than any form of multiplication but otherwise you will need to rethink your approach.
Your approach of splitting the uint32 into 2 uint16 and doing the multiplication on each of them seperate won't really give you a lot of speed gain. The problem is the multiplication itself, if it is operating on 16 or 32 bit is just peanuts in comparison to the actual multiplication. I also kind of doubt that it would be really faster than the high throughput multiplication, because I would suppose that the high throughput node actually implements your approach depending on the configured latency, splitting the incoming values once for every latency step you allow.
In fact even less complex nodes than multiplications easily add several ns to the timing delays and even a few boolean operators quickly can add up. Since your only constraint is the 312 MHz clock you also only have to concentrate on that for now. What do you have in the SCTL that runs on this clock? At 312 MHz you really can't put much in there, 3ns delay time is so eaten up. Your code path in there seems to eat up a little over 4ns, that is not much even for FPGA hardware!
