LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LV FPGA Socketed CLIP workflow w/ NI PXIe-6591R

Solved!
Go to solution

Hello there,

 

I have to develop an application on a NI PXIe-6591R board. My setup also includes a PXIe-1085 chassis w/ a 8135 controller.

Goal: fit a previous VHDL project to the 6591R board. Since the application requires to access the 2 Mini-SAS HD ports and the VHDCI connector on the 6591R front panel (physical front panel) a Socketed CLIP is the only option here, isn't it?

 

I'm quite new to the LV FPGA framework. In order to understand the whole project flow, I'd like to run a trivial VHDL design on the 6591R: a D-FlipFlop Edge Triggered w/ Syncronous Reset. I've attached the VHDL code of the D-FF and of the CLIP wrapper.

I'd like to (1) pass a bit (LV::boolean/VHDL::std_logic) from the VI to the D port of the D-FF (name it DFF/D) and (2) drive the board LEDs according to the outputs signals (DFF/Q and DFF/QB). Also I'd like to (3) read the same outputs (DFF/Q and DFF/QB) back to the VI driving two Boolean indicators.

 

Following the NI white-paper, I've:

  1. Successfully created an XML file from the CLIP Import Wizard interface, importing the 2 VHDL files (the D-FF and its wrapper).
  2. Selected the created CLIP from the Component Level IP Properties window. The LV_DATA_IN (host2fpga) and LV_DATA_OUT (fpga2host) I/O appear into the project tree, under the CLIP icon.
  3. Created a new VI under the FPGA device with an infinite while loop. Inside the loop I've dropped the LV_DATA_IN and LV_DATA_OUT I/O and connected them with a control (to LV_DATA_IN) and two indicators (from LV_DATA_OUT).

 

 

First, why in a simulated execution mode the behaviour of the indicators is totally random? They are not connected to any of the 6591R connectors...

 

Running the VI from the FPGA, it does respond to any change of the LV_DATA_IN control button... Why?

 

The design works as intended in Vivado both in behavioural and post-synthesis simulations.

 

Before asking here, I've tried to figure it out on my own. I've read all the documentation I've found at campus  (I got access to the LV Core1, Core2, Core3 and FPGA course materials) and on the internet.

What am I still missing?

 

TY for your kind assistance!

0 Kudos
Message 1 of 26
(4,035 Views)

Hello,

 

if you are in a simulated mode the output which you will obtain will be totally random, since input data are generated via software and they are random.

If you cannot change your control button during the execution of your vi maybe it is because you leave the controls out of while loop in the block diagram.

Please make sure that the controls are inside the while loop.

 

I hope my answer will help you,

 

Kind regards.

 

Pep

0 Kudos
Message 2 of 26
(3,982 Views)

Thank you for your reply.

 

I've attached a .zip file with screen captures showing the project tree, the 'dff.vi' front-panel and block-diagram. Sorry for haven't done it before, but I've not been able to physically access the system until few hours ago.

 

I can change the 'Data' button status during the run, but neither the board LEDs (real LEDs) or the 'Q' and 'QB' LEDs in the VI FP respond at all:

  • If 'Data' is TRUE, the onboard green  LED should be on and 'Q' LED should be on.
  • If 'Data' is TRUE, the onboard red LED should be on and 'QB' LED should be on.

Concernig the simulation topic, what does not add up to me is which data is randomly generated. I supposed it was the pins coming from the VHDCI and Mini-SAS HD connectors...

0 Kudos
Message 3 of 26
(3,963 Views)

I noticed you're tying the LED signals to 'Z', which I don't think you intend to do.  Let us know if commenting those two lines gives you the behavior you want.

Screen Shot 2016-02-08 at 10.16.06 AM.png

0 Kudos
Message 4 of 26
(3,938 Views)

Surely those lines were left overs from the template I wrote. I'll remove them and try. TY!

 

Today I've tried a new approach using DMA FIFOs. I've attached the block diagrams of the host.vi ("capture_00.JPG") and the dff.vi ("capture_01.JPG").

Will get no chances to let it run until tomorrow morning though...

 

I'm looking forward for your feedbacks, ty all.

0 Kudos
Message 5 of 26
(3,921 Views)

I'm glad you're experimenting with different ways to communicate between the host and FPGA.  A quick look at your screenshot looks like it would work, but I wanted to mention that the first approach you have is the preferred method for small amounts of data (booleans).  The read/write control is lower latency and always provides the latest value.  This is usually used for configuration and status monitoring.   FIFOs are great for data streaming, where you want to move large amounts of data (think waveforms) and also have ability to transfer lossless data.  When troubleshooting this issue, it would probably be best to stick to the first approach.

0 Kudos
Message 6 of 26
(3,907 Views)

Turned out it was a bad connection on the DFF Clock port... Connecting the on-board  clock (through the 'SocketClk40' port) resolved the issue: I was able to run the design using both the VHDL Wrapper + the VHDL design of the DFF and the VHDL Wrapper + EDIF netlist of the DFF.

 

Now I'm moving to implenting a bigger design, with a MicroBlaze core and an AXI-Burst Interconnect using Vivado Block Diagram. I'm receiving a lot of errors like this:

 

ERROR: [Opt 31-30] Blackbox PXIe6591RWindow/theCLIPs/PXIe_dash_6591R_IO_Socket_v1_CLIP0/design_1_i (design_1) is driving pin I of primitive cell aSeGpioOut_n_OBUF[0]_inst. This blackbox cannot be found in the existing library.
Resolution: Please check the input design and ensure that the specific blackbox module is defined. Once the design is modified, then re-run the Vivado flow.

Seems like the LabVIEW cannot build because it cannot find the 'design_1' entity ('design_1_i' is an istance of 'design_1' indeed) and then replace it with a black box...

 

This is the tree of my synthesised design:

 

tree.PNG

 

I've already exported the EDIF netlist of all the cells using these TCL commands:

write_edif {<EXPORT_PATH>/design_1_wrapper.edf }

foreach cell [get_property NAME [get_cells -hier -filter {IS_PRIMITIVE==0}]] {
    puts "Exporting '$cell' netlist..." 
    write_edif -cell $cell { <EXPORT_PATH> } 
}

where <EXPORT_PATH> is a folder local to my LabVIEW project and then I've added all the output files in the Socketed CLIP.

  • The Check Syntax in the CLIP Wizard warns that "design_1 remains a black-box since it has no binding entity".
  • Building (or running) the LV FPGA project fails due to errors like the first reported above.

 

I've tried to refer to the Aurora Pattern example but still I don't understand what I'm doing wrong and different... Also for the Aurora example, the CLIP Wizard's 'Check Syntax ' returns several "remains a black-box since it has no binding entity" warnings, as for 'aurora_64b66b' for example, but the example builds correctly (ofc).

 

I'm using the NI Cloud to compile the project.

0 Kudos
Message 7 of 26
(3,778 Views)

I've fixed the black-box issue wrapping my design again and then specifying for the newly created top level:

ATTRIBUTE SYN_BLACK_BOX : BOOLEAN;
ATTRIBUTE SYN_BLACK_BOX OF design_1_wrapper : COMPONENT IS TRUE;

 

The design compile up to the write_bistream, when the DRC fails:

Running DRC as a precondition to command write_bitstream
INFO: [Drc 23-27] Running DRC with 2 threads
ERROR: [Drc 23-20] Rule violation (UCIO-1) Unconstrained Logical Port - 2 out of 401 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined.  To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1].  NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run.  Problem ports: MgtRefClk0p, MgtRefClk0n.
ERROR: [Vivado 12-1345] Error(s) found during DRC. Bitgen not run.
INFO: [Vivado 12-3199] DRC finished with 1 Errors, 65 Warnings, 1 Advisories
INFO: [Vivado 12-3200] Please refer to the DRC report (report_drc) for more information.
INFO: [Common 17-83] Releasing license: Implementation
write_bitstream: Time (s): cpu = 00:00:56 ; elapsed = 00:00:39 . Memory (MB): peak = 4224.598 ; gain = 11.996
::ERROR: [Common 17-39] 'write_bitstream' failed due to earlier errors.

    while executing
"write_bitstream -force -bin_file -no_binary_bitfile "PXIe6591R_Top_Gen2x8""
    (file "/opt/apps/NIFPGA/jobs/gV251GL_ITH1mFL/bitgen.tcl" line 33)
    invoked from within
"source "/opt/apps/NIFPGA/jobs/gV251GL_ITH1mFL/bitgen.tcl""
# exit
INFO: [Common 17-206] Exiting Vivado at Thu Feb 25 16:21:44 2016...

I've tried to add the set_property LOC constrains or the set_property PACKAGE_PIN constrains:

 ################################ CLOCK CONSTRAINTS ##############################


make_diff_pair_ports MgtRefClk0p MgtRefClk0n

#set_property PACKAGE_PIN E8 [get_ports *MgtRefClk0p*]
#set_property PACKAGE_PIN E7 [get_ports *MgtRefClk0n*]
set_property LOC E8 [get_ports *MgtRefClk0p*]
set_property LOC E7 [get_ports *MgtRefClk0n*]

set_property IOSTANDARD LVDS_25 [get_ports *MgtRefClk0p*]
set_property IOSTANDARD LVDS_25 [get_ports *MgtRefClk0n*]

create_clock -name MgtRefClk0 -period 10.000 [get_pins -hier -filter {DIRECTION==OUT && NAME=~*%ClipInstancePath%*/clk_out1}]

create_clock -period 10.000 [get_pins -hier -filter {NAME=~*clk_in1*}]
set_input_jitter [get_clocks -of_objects [get_pins -hier -filter {NAME=~*clk_in1*}]] 0.1

Also, digging into the XilinxLog I've found:

CRITICAL WARNING: [Vivado 12-1411] Cannot set LOC property of ports, Could not legally place instance PXIe6591RWindow/theCLIPs/PXIe_dash_6591R_IO_Socket_v1_CLIP0/design_1_wrapper_i/design_1_i/clk_wiz_1/U0/clkin1_ibufgds at E8 (IPAD_X1Y106) since it belongs to a shape containing instance MgtRefClk0n. The shape requires relative placement between PXIe6591RWindow/theCLIPs/PXIe_dash_6591R_IO_Socket_v1_CLIP0/design_1_wrapper_i/design_1_i/clk_wiz_1/U0/clkin1_ibufgds and MgtRefClk0n that cannnot be honored because it would result in an invalid location for MgtRefClk0n. [/opt/apps/NIFPGA/jobs/gV251GL_ITH1mFL/PXIe6591R_Top_Gen2x8.xdc:577]

 

 

Any idea?

0 Kudos
Message 8 of 26
(3,756 Views)

You shouldn't have to set any location constraints - that should all be handled by LabVIEW.  It sounds like maybe you didn't visit the clocking and I/O properties of the socketed CLIP?

Screen Shot 2016-02-25 at 4.54.52 PM.png

Screen Shot 2016-02-25 at 4.56.28 PM.png

 

I sent you a PM with my contact info, I think it would be best to have a chat on the phone to understand the bigger picture of the design and give you some advice moving forward.

0 Kudos
Message 9 of 26
(3,737 Views)

Indeed, the type of errors the Compile Cloud was returning looked very suspicious to me: MGTRefClk pins are pre-assigned (E7 and E8 on the xc7k410tffg900) by Xilinx and then it is very odd to be asked to assign a pin location.

 

My "Clocking and IO" settings looks fine to me, exactly as the image you've attached in your last post.

 

Anyway, I was able to compile successfully in LV and the issue has been resolved. It was due to an incorrect buffering of the MGTClkRef0 differential signals. MGT_RefClk*_n and MGT_RefClk*_p cannot be wired directly to the Clock Wizard IP, they have to be buffered (I've used a IBUFDSGTE) and then connected (single ended) to the Clocking Wizard (the IP has a BUFG inside). Implementing the design in Vivado helped put me on the right track to solve the issue.

 

 

Now, I'm stucked again at the moment... Is there a way to easily programming the MicroBlaze in LV2014? Like this example but the v2_2_1 patch won't install for a version incompatibility issue (ofc) and I don't know how to download my .ELF file to the micro processor under the LV environment.

0 Kudos
Message 10 of 26
(3,678 Views)