Issues with 7813R in a part Verilog part LV FPGA programmed project

[mgerceker]

I wrote an extention to a Verilog FPGA project using LV8.6 and odd things like loosing IO signals started to happen. The Verilog project alone compiles and syntesizes and runs fine (using the CLIP) function. However when I add my LV extension to the project some of the IOs stop functioning. The extention is programmed to be independent from the original Verilog project. i.e. the two modules do not share any IO lines.

When I compile the top level VI everything looks OK and the code downloads and runs, but not as it was intended. I was wondering, if anyone encountered something similar to my problem before.

Thank you,

Mehmet

[hagedornj]

Hello Mehmet,

in most cases the problems were located in a wrong name inside of the xml file. How did you setup the flow.

I have done the following steps:

     1. generate a ngc file from the verilog source

     2. write a vhdl wrapper which instantiates the verilog/ngc macro

     3. add all sources (vhdl and ngc) inside of the xml file

          -> in case of wrong names you will got no error

     4. to find errors it is helpful to search for the word "resolve" inside of the xilinx log. In this case some macros are not resolved -> maybe the reason for unexpected bahaviour

Kind regards

Joerg

[mgerceker]

Hi Joerg,

I have gone through my log filed and even though there were several warnings. I have not been able to located any unresolved signals. Yet in my top.vhd file I have found the following line

csn_o : out STD_LOGIC;  (csn_o is the signal in question)

I have changed the line to:

csn_o : out STD_LOGIC := 'X'; and rebuilt my bit file and the IO started to work again, but my state machine is acting very oddly now. I am not sure what I should be looking into and would appreciate any pointers. I am planing to repeat steps 1-3 in your message using a more recent version of the Xilinx tools.

Thank you,

Mehmet

[BrowningG]

Hi Mehmet,

In addition to Joerg's comments, it is also important to review your Xilinx log to ensure that none of your signals are being accidently trimmed during the compile process.  Make sure that your Verilog signal names map correctly to your VHDL wrapper and that the VHDL wrapper signals match the names you use in the CLIP XML file.  This helps ensure that your signals are completely connected to the LabVIEW diagram.  In some cases the trimming of these signals will not result in a compile failure (resolved signal issues typically result in compile failures) but can make your code behave strangely if parts of the code are optimized out without error.  This can also happen sometimes if you do not have some of your important CLIP signals attached to your VI.  Make sure to attach any critical top level CLIP signals to logic in your block diagram to ensure that the compiler does not accidently remove anything important.

Also, you may consider posting this and future support questions on the Real Time Measurement and Control Forum.  There is a large network of NI forum users that actively monitor this board and may have some additional suggestions.  Typically the community is used to share examples, tutorials, and other information while support requests are usually best for the forums.

Regards,

Browning G

FlexRIO Product Support Engineer

[mgerceker]

Thank you for your response. I have looked into the VHDL wrapper and the CLIP XML file and everything looked ok. Then I finally upgraded to LabVIEW 2009 Evaluation version and compiled my code using the timing oriented Xilinx options. Now everything seems to be working fine. There's still more to be tested. I can't quite explain how the same code may or may not run when successfully compiled using 2 different versions of LabVIEW/Xilinx toolchain. Is there anything documented on this subject?

Thanks again,

Mehmet Gerceker

[BrowningG]

Hi Mehmet,

LabVIEW FPGA implements designs by converting the FPGA block diagram to VHDL and then sending this VHDL hierarchy to a Xilinx compiler for bitfile generation.  As a result, when you use Verilog in CLIP, this creates a mixed HDL design in the overall HDL hierarchy.  To help reduce possible issues with this type of design, I will typically convert the Verilog portion to a netlist to remove the syntax dependencies (this helps with the signal mapping).  There is not much documentation on how to use Verilog in CLIP (other than a document I wrote http://decibel.ni.com/content/docs/DOC-8218 that highlights this netlist process).  I think that the Xilinx log can provide some useful clues in seeing if there are any critical warnings that caused signals to be lost or if other components went missing.  Do you know if any CLIP signals were being trimmed or if there were any other surprising errors in the log file?

Regards,

Browning G

FlexRIO Product Support Engineer

[mgerceker]

Hi Browning,

Unfortunately the document you wrote seems to be indeed the only piece of documentation that is available on the topic. I have gone through the log files and were not able to find any warnings relating to my signals on the IO level. Due to the large size of the file all I could do was search for non-functional signals by name. I also tried to use the directives to remove sync registers around the CLIP module (verilog) LabVIEW fpga places to guarantee syncronization, but I was unable to do so. (Compiler error while trying to use requiredclockdomain.) The documentation on the directive is about 2 lines long. I'll start looking for more clues int the Real Time Measurement and Control Forum as soon as I have my project up and running as 2009 seems to be working for me at the moment.

Best,

Mehmet Gerceker

[BrowningG]

Hi Mehmet,

I am glad you are able to get it working in 2009.  I am going to be away for a few weeks, so I will have to dig more into this when I get back.  The forums will be a good place to ask questions when you get some time.  Good luck with your application!

Regards,

Browning G