LabVIEW FPGA: Multiple SCTL versus one SCTL (same clock domain)

Question

Hello NI forums,
Question:
See the attached picture from a modified version of the LabVIEW DRAM FIFO example. It probably explains my question more effectively than the paragraphs below.
What is the difference to the LabVIEW / Xilinx compiliers, if any, between placing two independent branches of code in the same SCTL, versus placing them in individual SCTLs (in the same clock domain)?
Misc. comments:
I have briefly experimented with this concept using the included LabVIEW DRAM FIFO example (example finder >> Hardware Input and Output >> FlexRIO >> External Memory >> Simple External Memory FIFO.lvproj).
I compiled the default example (the read and write interfaces are in separate 40MHz SCTLs) five separate times. Then I put the read and write interfaces in the same 40MHz SCTL and compiled another five times. The result (when both read and write interfaces were in the same SCTL) was a reduction in resource usage (according to the compilation summary).
However, due to my lack of knowledge I'm hesitant to conclude that placing everything in one SCTL is always the best option. For example, I do not know what is created 'behind the scenes' with each SCTL. Perhaps putting independent branches of code in separate SCTLs makes it possible to route clock, reset, implicit enable, etc. signals more effectively.
Background information:
My task involves acquiring 2 channels of analog data using the NI 5772 and PXIe-7966. Data acquisition takes place in a 200MHz SCTL, and downstream processing is performed in a 100MHz SCTL.
During a vast majority of the 100MHz SCTL processing stages of the FPGA VI, the 2 channels of data do not interact with eachother. So it would be easy for me to place them in separate 100MHz loops if doing so would somehow help the design (timing, resource usage, etc.).
Thanks!
Attachments:
question.png ‏76 KB

Answer 1

Intaris
Trusted Enthusiast
Posts: 3,264
Re: LabVIEW FPGA: Multiple SCTL versus one SCTL (same clock domain)
‎10-28-2014 12:11 PM
Just out of interest, what is the resource usage differential between the two versions?
In response to the above comment,
This is a little embarrassing, but it seems like the resource usage is similar than I initially thought for this particular example. I think the previous compilations that I based my assumption on coincidentally used more resources in the 2-SCTL loop case. I just compiled each version two additional times (see below).
Here's the version with everything in one loop:
Device Utilization
Total Slices: 17.6% (2587 out of 14720)
Slice Registers: 9.5% (5583 out of 58880)
Slice LUTs: 8.2% (4855 out of 58880)
DSP48s: 0.0% (0 out of 640)
Block RAMs: 2.5% (6 out of 244)
Device Utilization
Total Slices: 16.9% (2493 out of 14720)
Slice Registers: 9.5% (5583 out of 58880)
Slice LUTs: 8.3% (4858 out of 58880)
DSP48s: 0.0% (0 out of 640)
Block RAMs: 2.5% (6 out of 244)
Here's the version with the read and write in separate loops:
Device Utilization
Total Slices: 16.4% (2407 out of 14720)
Slice Registers: 9.5% (5583 out of 58880)
Slice LUTs: 8.2% (4852 out of 58880)
DSP48s: 0.0% (0 out of 640)
Block RAMs: 2.5% (6 out of 244)
Device Utilization
Total Slices: 19.4% (2859 out of 14720)
Slice Registers: 9.5% (5583 out of 58880)
Slice LUTs: 8.3% (4859 out of 58880)
DSP48s: 0.0% (0 out of 640)
Block RAMs: 2.5% (6 out of 244)