CPU accessible registers in LabView FlexRIO FPGA

Question

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
Solved!
Go to Solution.

Answer 1

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