Multiple SCTLs vs single SCTL

[ramyasree]

I have some large code on in  single 40MHz SCTL.

Total slices I am using around  92%.

Block RAM-77%

Slice LUTs-54%

DSP slices-80%.

I am getting timing errors while compiling the whole code.

Splitting the between 2 SCTLs will solve the issue?

what happens If use 2 SCTLs in terms of resources & timing?

thanks in advance.

[GerdW]

Hi ramyasree,

---

@ramyasree wrote:

I have some large code on in  single 40MHz SCTL.

I am getting timing errors while compiling the whole code.

Splitting the between 2 SCTLs will solve the issue?

what happens If use 2 SCTLs in terms of resources & timing?

---

IMHO it should help to split your large SCTL into 2 (or more) smaller ones as it gets easier to comply to timing restrictions…

Why don't you attach your code (and maybe the whole project)?

[crossrulz]

---

@ramyasree wrote:

I am getting timing errors while compiling the whole code.

Splitting the between 2 SCTLs will solve the issue?

---

Not likely.  Two things I have seen to fix timing errors:

1. Reduce FIFO and/or memory sizes.  In my specific case, it was a DMA FIFO I reduced in size and that fixed all of my compile issues.

2. Use  pipeline.  This could be something as simple as adding a Feedback Node inline with data flow paths or use Shift Registers.  The idea here is to use multiple iterations to get a single job done, but you will still get a result each iteration.  This does add delay based on the depth of your pipeline.  For more information: Optimizing your LabVIEW FPGA VIs: Parallel Execution and Pipelining

[Terry_ALE]

If you move code from one SCTL to two SCTLs of the same clock domain, LabVIEW FPGA will not optimize and it is as if the code is in the same loops.

If you split into two SCTLs you may be forced to create FIFOs and stuff which is very similar to pipelining as mentioned above.  So better to pipeline in the same SCTL so you do not have to add things that may not optimize.

There are various LabVIEW FPGA help articles on optimizing such as https://www.ni.com/en/support/documentation/supplemental/18/labview-fpga-code-optimization.html.  Internet searches for “LabVIEW FPGA optimization” should find other similar articles.

[ramyasree]

DMA usage I reduced.

Memory sizes also I reduced. In my code, more memories are needed.

Pipelining also added at every module.

Alone that code  is supporting up to 150M. 

In the streaming compilation , I placed that code in 40M.

I am attaching my timing error report.

[ramyasree]

I am attaching my module here.

After adding this to previous code in PXI-5840, I am getting timing errors.

[Intaris]

Depends on your code.

I re-wrote our code into multiple SCTLs starting a few years back and routing was massively improved. You only need one wire linking lots of nodes to run into trouble with the routing.

OTOH, if your code portions are completely independent, moving to two loops will probably do nothing for your compilation.

Again, depends greatly on the current code base.

[ramyasree]

Thanks for your reply.

But In my case, Code is dependent.

need to use some target scoped FIFO to transfer data between them.

Is that fine?

Will It cause any issue in timing again?

Anyway , I will try with 2 SCTLs. 

" You only need one wire linking lots of nodes to run into trouble with the routing."

That means , If we connect one output wire to many nodes, it will affect the timing.

Am I correct?

[Intaris]

---

@ramyasree wrote:

Thanks for your reply.

But In my case, Code is dependent.

need to use some target scoped FIFO to transfer data between them.

Is that fine?

Will It cause any issue in timing again?

Anyway , I will try with 2 SCTLs. 

" You only need one wire linking lots of nodes to run into trouble with the routing."

That means , If we connect one output wire to many nodes, it will affect the timing.

Am I correct?

---

Nit will, but it can. If you have any one signal with a huge fanout on the FPGA chip, it can cause headaches.