Multi top clock, for main VI ... Multi partition FPGA code ...

[manu.NET]

Hello,

For the moment, there is only one clock assigned with the FPGA main VI. "The top level clock"

This clock is used by the code created on the main block diagram. (Outside SCTL)

Today, if you need an other clock ... you have to use SCTL's ... but using SCTL generates many problems, because not all instructions are allowed in SCTL's ! 

I think that XILINX can handle a kind of partition ! 

My need would be, for example, to have one partition running at 40MHz ... and an other at 80MHz ... without having necessary to use SCTL's.

This is only an idea ... i think that behind my idea something heavy must be done !

The Top would be, to be able to share data between the different partitions (using FIFO for example) ... but i think this is one more difficulty !

The partition mechanism could be created in Labview FPGA as follow  ...

• With multiple top VI's : On per partition
• Or, with a special structure in the main vi block diagram : Partition structure, with a clock as input : Like a mega SCTL, without SCTL limitations.
• Or, by adding a clock input to the while loops
• ...

Thanks for reading.

[Dragis]

i think this is a great idea. this is certainly a feature many people have asked for in the past. one reason the feature probably hasn't been implemented yet is because many people use the single-cycle loop as the only way to get the rates they desire. do you have a significant amount of code outside the single-cycle loop?

[manu.NET]

Hello asco,

I have no real need yet ... it's only an idea !

For the moment i managed to do what i wanted using SCTL's ... sometimes whith many efforts ...

But i think this could be very usefull !

Instead of having to create a state machine in a SCTL, i would prefer to use a simple loop running in an other clock domain !

I think sometimes it could be mode 'readable', 'maintainable' to view code in a simple loop as in a state machine.

And also, SCTL's have limitations ...

I think the actual way of programming is good ... but it could be improved with this idea.

I know that my idea is certainly not easy to develop ... it's only an idea ... thats why ni.com/ideas exists !

To bring Labview to be better.

Manu.net

[ErnieH]

The ability to run everything at a lower clock speed also would be useful. Would make routing much easier and still be much faster than than programmable hardware. Maybe options of 10MHZ, 20MHZ, 25MHZ, 33MHZ, but at least 20MHZ.

[Pie566942.0]

@Dragis

I program with the SCTL structure exclusively until I need to do otherwise. In my experience, otherwise is oftentimes. My high(er) speed designs have been winding up with the acquisition and little else in the SCTL. Other code is going into the top-level clock domain. Here’s an RF example I see often: PRBS randomization. PRBS = For Loop + Feedback Nodes + XORs. I’m aware that I could implement a handshaking protocol around the randomizer, but why should I have to do that when LabVIEW has built-in auto-indexing?  Personally, I’d rather see “enable chained” loops implemented as structures rather than buried in the VI properties. It would make the code more readable.

-Steve K