Xilinx BRAM Primitives

[Intaris]

I've always wondered.....

LabVIEW ships with IPCores for BRAM instances and FIFO instances which I have never been able to get running.

I just revert to using the LV-intern BRAM and FIFO Primitives.  But once in a while, I miss the full functionality of the Xilinx primitives. Things like asynchronous dual-clock BRAM and asynchronous dual clock FIFOs.

Has anyone ever been able to successfully use such primitives in LabVIEW?  If so, could someone give me an idea how to accomplish that? I have some design decisions which are kind of awkward which could be solved very elegantly be simply having access to asynchronous read and write ports for dual-clock BRAM.

Shane

[GatorChomp · Accepted solution]

Out of curiosity, have you tried integrating the dual-clock BRAM through a CLIP rather than the IP Cores? While the Xilinx IP Cores and the LabVIEW Xilinx Palette are very useful for quickly integrating various Xilinx IP, it doesn't quite meet the use case for dual-clock BRAM. 

Disclaimer: I haven't actually gone through this completely and tried it, so your mileage may vary. 

Anything dropped from the Xilinx IP palette in LabVIEW is actually just implemented using an IP Integration Node, as called out here:

Integrating Xilinx IP into FPGA VIs (FPGA Module)

IP Integration Nodes (IPIN) are for synchronous, in-lined, local instances of IP that serves more of a functional purpose. The clock rate is also directly controlled by the clock of the SCTL that the IPIN lives in. This makes it very not ideal for items that need to be accessed from separate clocks. 

Instead Component-Level IP would likely be the best bet since it lets you specify more than one clock signal and access IP asynchronously. If you have access to the Xilinx IDE to configure the IP and a .vhd top-level then I would highly recommend that route. For ISE, I believe you would need a separate installation of the IDE. For Vivado, that's as simple as having the LabVIEW local compile tools installed as you can launch the IDE by running the following batch file:

C:\NIFPGA\programs\<Vivado version>\bin\vivado.bat

Otherwise, you *could* cheat a bit by using the IP core file (eg, .xci) in a folder next to your FPGA VI when you configure the Xilinx IP from LabVIEW and reuse that. CLIP does require a top-level vhd module, so you would need to properly instantiate the IP core as well (hence why I recommend using the IDE if it's available). 

[Intaris]

OK, so I haven't overseen anything, it simply doesn't work in "typical" LabVIEW fashion.  Shame. Although I can't think how it could realistically be made to work, it would be cool to have access to BRAM primitives with different write and read widths.....

I'm off to the FPGA Idea exchange.

[GatorChomp]

One thing I forgot to mention is that you could also configure LabVIEW Project Memory items as dual clock. I may have gotten too caught up in how you could use the IP Core instead, but this option is definitely easier for the more typical LabVIEW user who doesn't need all the extra options offered by the IP Core. The main disadvantage that I can think of right now is that it's a "simple" dual-clock BRAM implementation rather than the "full" option. That is, it allows read from one clock domain and write from another but does not seem to have any option to read and write from both domains. 

[Intaris]

Thanks. The dual-clock option I already have used a lot.  It's mostly the combination between that and different width read / write which I could have used recently.  Instead, I needed some hoop jumping in order to overclock a producer loop on FPGA x2 in order to support a function which would have been more elegantly (and with less resources) solved with different width read / write ports.