LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

CPU accessible registers in LabView FlexRIO FPGA

Solved!
Go to solution

Howdy folks, I am wondering if it's possible to get the following behaviors out of Labview.  I'm thinking it's not.

 

System description:  CVI application that communicates with PXIe FlexRIO via controls and indicators.

Problem: Designing to a CPU-FPGA interface specification which lists "registers" as a combination of read and read/write bit-fields.

 

Example:

 

According to the spec, there should be a 32-bit register.  Bits 31:16 are read-only, and bits 15:0 are read/write, from the perspective of the CPU.  In the labview world, I would just make a uint16 control, and a uint16 indicator and be done with it.

However, to meet the spec (written for traditional microprocessor buses), a 32-bit read to an address should read back the full contents of the 32-bitregister at that location (implemented as flops on the FPGA, with appropriate memory mapping within the FPGA device).  Similarly a 32-bit write to an address should store values to that register (appropriately masking writes to bits 31:16 within the FPGA device).

Is there a way for me to have a single address (basically, a single labview block diagram component) that will let me accomplish this behavior?  It looks to me like the only solution is to pack my registers with bit fields that are all read, or all read/write in order to fit in with the labview paradigm.  That means the spec will have to go back and be re-written and re-approved.

 

Thanks in advance,

-J

0 Kudos
Message 1 of 7
(2,801 Views)

Would you count a cluster as a single element? You could read the whole cluster, or just R/W the parts you need.

 

Cheers!

TJ G
0 Kudos
Message 2 of 7
(2,787 Views)

I'll have to check with my software folks and see if they can/will handle reading and writing of a cluster via CVI.  

 

But how would that work?  Suppose I have:

 

Cluster "testCluster" is:

{uint16 counter

uint8 config

uint8 status}

 

Is it true that if I make that cluster an indicator, the CPU cannot write to that cluster when referencing the handle "testCluster"?

 

Is it true that if I make that cluster a control, the FPGA cannot write to that cluster when referencing the control "testCluster"?

It seems like I would need to make the cluster a control, but that would only work if the cluster was allowed to have the FPGA write sections of it.  Ie: testCluster.status was an indicator.  I thought that clusters only described the data type within them, but when aggragated together enforced all of their component datatypes to be either indicators or controls, depending on how the cluster defined at the top level.

 

-J

 

0 Kudos
Message 3 of 7
(2,782 Views)

Maybe I'm not properly understanding what you're trying to do; can't you just add some logic in the FPGA code that masks off the upper 16 bits when you attempt to write to an address?

0 Kudos
Message 4 of 7
(2,763 Views)

Nathand,

 

Here is the standard paradigm (some simplification):

 

1)  C helper file that contains #defines that describe the memory map.  things like BASE_ADDRESS, DEV1_OFFSET, DEV2_OFFSET, REGISTER_1_OFFSET.  To get to a 

 

2)  C procedure which calls things like void setRegister(uint32 *memory, int device_offset, int register, uint32 new_data, uint32 write_mask).  and uint32 getRegister(int base_address, int device_offset, int register).

 

3)  If I want to write the value 0xABCD the upper 16 bits of a 32-bit register (register 5), to device #1, I would code:

 

main(){

   setRegister( ptrMemory, 1, 5, 0xABCD0000, 0x11110000)

}

 

This would compute the PCIe address based on some equation like BASE_ADDRESS + DEV1_OFFSET+register_offset<<2 (byte addressed).

 

Suppose this gives us a 32-bit address of 0xC000_4000.  We would issue a write across PCIe to address 0xC000_4000.  The memory map in the FPGA is programmed such that a set of flops will latch the data in the PCIe write when write_enable = 1, and address 0xC000_4000 are both true. That completes the register write to the FPGA.

 

A similar thing occurs for a register read.  In this case however, when read_enable = 1 and address = 0xC000_4000, the values held in that same set of flip flops is now written onto the PCIe as a transaction.  The software application recieves the value and returns that value from the getRegister function.

 

In my example above, you notice that the same address on the PCIe is used for reading and writing. I am trying to understand if I can have software read AND write from the same address.

 

When you compile an FPGA, labview creates a (seemingly) arbitrary address translation for all CPU accessible structures, meaning FIFOs, controls and indicators.  It assigns different addresses for every single item, and it may or may not keep the same address depending on whether any modifications were done to controls/indicators/fifos since last compile.

 

I am trying to understand how labview works, so that I can assess whether or not I can read/write from the same address.  This matters, because if I can pack bit fields into registers more efficiently in the FPGA, that reduces the amount of functional tests to write and execute to verify the FPGA functionality.  

 

So, a restatement of my original question:  is there some mechanism with using controls indicators where both the FPGA AND the CPU can write to the same set of flipflops in the FPGA?   If I use an indicator, the FPGA can write to the indicator but the CPU cannot.  If I use a control, the CPU can write to the control, but the FPGA cannot.  Is this correct?   

 

-J

0 Kudos
Message 5 of 7
(2,748 Views)
Solution
Accepted by topic author JJMontante

Thank you for the detailed explanation. I'm familiar with reading and writing to FPGA registers - I've been doing a lot of non-LabVIEW work recently with an Altera FPGA. I have not, however, used the CVI interface to LabVIEW FPGA, I've only used the LabVIEW interface. I'm not quite sure if your question is about LabVIEW FPGA, the CVI interface, or both.


JJMontante wrote: 

So, a restatement of my original question:  is there some mechanism with using controls indicators where both the FPGA AND the CPU can write to the same set of flipflops in the FPGA?   If I use an indicator, the FPGA can write to the indicator but the CPU cannot.  If I use a control, the CPU can write to the control, but the FPGA cannot.  Is this correct?  


On LabVIEW FPGA, a control and an indicator are essentially identical. You can write to a control, or read from an indicator, using a local variable in the FPGA code. It's common to use a single front-panel item to transfer data in both directions, and it doesn't matter whether that's a control or an indicator. For example, a common strategy uses a boolean front-panel item for handshaking. The CPU writes a value to a numeric control, then sets the boolean to true to indicate that new data is available. The FPGA reads that numeric value, then sets the boolean to false, indicating to the CPU that the value has been read. The LabVIEW FPGA interface (on the CPU side) likewise treats all front-panel items on the FPGA identically regardless of whether they are controls or indicators - they can be both read and written.

 

Does that answer your question at all?

Message 6 of 7
(2,738 Views)

I didn't realize that FPGA Front panel items (controls and indicators) were both writeable by the FPGA.  I guess I'll have to make some test applications to try it out.

0 Kudos
Message 7 of 7
(2,733 Views)