FPGA - is there an efficient way of handling a large number of CLIP signals?

[jt_fuw]

Hello.

When I am connecting a CLIP signal into a VI, I need to find it - an easy task when I have about ten signals, and the more signals a CLIP has, the harder is finding the suitable one between them - especially it becomes hard when I have more signals than my computer screen can show. And I need a CLIP (with VHDL code) than will interconnect almost all signals used in a LabVIEW FPGA project, and this means a large number of signals.

Unfortunately, CLIP signals have a flat structure, making dealing with large number of them quite hard. It would be way easier if these signals had a hierarchical structure - were in groups, and I could select a group, than a signal within the group - like it is done e.g. for I/O signals of some C-Modules. But I don't know how to make such a hierarchical structure of CLIP signals, and I don't know if it is at all possible.

Perhaps the CLIP can be replaced with a few smaller CLIP-s... but the code within the CLIP is to interconnect almost all signals, so I would need connections between these CLIP-s, and an efficient way of specifying these connections. Seems there is no way to make CLIP-s containing definitions of connections that would be handled automatically when these CLIP-s were put in a project - every connection needs a line to be drawn in a LabVIEW VI.

I have some idea on how to reduce number of signal lines of the large CLIP: by signal grouping. This means that when the large CLIP has several signals for controlling a group of I/O controls which usually need Boolean, or small numeric signals, these signals can be sent as one wide signal (providing 64-bit width is sufficient) and require one line to a CLIP (or IPIN) that can unpack the wide signal to individual signals for inputs of these controls.

The large CLIP contains a processor with a program serving as "brain"; everything else is to be connected to the "brain".

Any ideas how to do it better, in a more transparent and easier to maintain way?

Thanks in advance, Jerzy Tarasiuk

[jt_fuw]

Hi, just yesterday I noticed that the LabVIEW project file can be modified - it is an XML file, and for a CLIP instance its signals are specified as Item-s:

<Item Name="clip1" Type="FPGA Component Level IP">

  <Property ...>

  ...

  <Item Name="signal10" Type="Elemental IO">

  ...

</Item>

and similarly Chassis signals, with tha excepion that IO Items are sub-items of an <Item Name="Chassis I/O" Type="Folder">. I inserted Folder Items between CLIP Item and IO Items, as follows:

<Item Name="clip1" Type="FPGA Component Level IP">

  <Property ...>

  ...

  <Item Name="IOgroup1" Type="Folder">

    <Item Name="signal10" Type="Elemental IO">

    ...

  </Item>

  <Item Name="IOgroup2" Type="Folder">

    <Item Name="signal20" Type="Elemental IO">

    ...

  </Item>

</Item>

and I have I/O signals of the CLIP in sub-folders (IOgroup1, IOgroup2).

I was editing the project file manually, using plain text editor; this would be better done using e.g. a LabVIEW program. But it is another step to make... now I know the direction.

---

[jt_fuw]

Seems it cannot be done from a LabVIEW program: an attempt to create a virtual folder in a CLIP results in error (bad parameter). I tried AddItem method on the CLIP item (that is in an FPGA target) specifying arguments: Name=<a virtual folder to be created>, Path=<Not a Path>, Type=Folder. When I tried the same on the target instead the CLIP, the folder was created.

From the other side: after modifying the .lvproj file (handling it as an XML) in the way described in my previous post, the project can be loaded by LabVIEW and saved with a different name, and the folders created for CLIP signals are retained, these signals can be used for editing an FPGA VI... I noticed no warning for these folders to be wrong.

Oh, I tried this with LabVIEW 2018 - maybe the behavior is version-dependent.

[jt_fuw]

Here is my test: lvpft-mkft.pdf contains block diagram picture, lvpft-mkft.zip contains a VI for LabVIEW 18.0 (the version I'm using) and saved for LABVIEW 8.0 (the oldest that my LabVIEW allowed).

The test accesses FPGA targets in a LabVIEW project (need select the project file before starting the VI), and attempts to put a virtual folder (need enter the folder name, like NewVirtFolder), in each FPGA target and each project item owned by the target.

The VI doesn't save the modified project - in order to see these changes in addition to information shown on its FP open the project in LabVIEW before running the VI.

I found it adds folders to: target, Chassis I/O, IP Builder, VI-s, Dependencies, Build Specifications; it fails to add a folder to a Base Clock and to a CLIP.

[raphschru]

Hi jt_fuw,

I have never used CLIP signals, but have some experience with scripting FPGA projects.

Could you provide a minimal sample project with an FPGA Target 1 that has the initial situation and an FPGA Target 2 with the final situation, so that I can see clearly the "delta" that the scripting has to do? Please include all files wrapped in a .zip (.lvproj, VIs, subVIs, whatever dependency is required by the CLIP,  even an empty vhdl with no processing, only some signals that can be referenced from LabVIEW, ...).

Regards,

Raphaël.

[jt_fuw]

Hi, Raphaël.

I am still investigating the Scripting. See my topics on another LabVIEW forum:

https://lavag.org/topic/23689-can-the-scripting-add-and-configure-clip-sipin-s/

https://lavag.org/topic/23675-eionode-a-problem-when-getting-data-type-of-a-newly-created-one/

Currently, I can put EIONode-s and most of standard LabVIEW elements in FPGA VI;  when an elements need to be configured, things become complex, as different elements need different operations for configuration (when an alement is created, the creator gets its reference, but it must be converted to more specific class for these operations to be available - and then, each class needs a separate code for the configuration).

Also, I tried making connections, but I'm still at very beginning as it is concerned. My idea is: a text file will list elements that are to be added, and wires for terminals of the element, each wire being named (e.g. wire1, wire2...) - a LabVIEW program will  read this, put elements and make connections - specifying the same wire name many times (usually for different elements) means a connection is to be done.

With kind regards, Jerzy Tarasiuk

[Terry_ALE]

How many CLIP signals are we talking about?  How many bits total?  Are they synchronous?