Xilinx KC705 PCI Express on Ivy Bridge (i7 3rd Gen)

I am doing work on a KC705 evaluation board from Xilinx. This chip (Kintex 7) uses the 7 Series Integrated Block for PCI Express. I am running this on a Gigabyte GA-Z77X-UP5 TH board. I have run into a brick wall trying to get this Xilinx board to work on this Gigabyte motherboard. Luckily, there is a note from Xilinx about this:
http://www.xilinx.com/support/answers/51135.htm

In short, there is a workaround. Check out this page, which tells you to set the TX_RXDETECT_REF signal to 3'b011 instead of the default. The Answer Record also explains that this is due to an errata on Ivy Bridge cores. It points to a web page by Intel and indicates that it is errata BV56.
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/3rd-gen-core-desktop-specification-update.pdf

I don't understand the errata, but I can attest to the fact that this fixes the problem. The KC705 is now successfully detected on this motherboard.

UPDATE: If you take a look at
http://www.xilinx.com/support/documentation/boards_and_kits/kc705_PCIe_pdf_xtp197_14.2.pdf
you can see that by setting the Bitstream Configuration, and by adding an emcclk you can accomplish a PCIe compliant FPGA load-time. This method doesn't need a soft-reboot to properly enumerate the bus.

See note above, kept for accuracy:
Even with this success, there are still some failures... For example, the load time for the FPGA configuration is too long. This means that I have to do a soft-reboot after a hard reboot to get the PCIe link to work. Xilinx has created a method to solve this, but I have yet to figure it out. It is called Tandem PROM and Tandem PCIe. It is supposed to quickly load the PCIe portion, negotiate the link, and then load the rest.

For now, I'm just doing a soft-reboot (ctrl-alt-del).

finding combinational loops in ncsim

There may be better ways of doing this... but here was my way:

You are running gate level or rtl simulations, and the simulation gets stuck. Yup, what do you do?

Simple answer is not to have combinational loops. If you do, perhaps you've done something wrong. If you must have combinational loops, or you are debugging someone else's code, then here's the way I found the loop path. This is especially useful when you are unfamiliar with the code, and the code spans many files and many processes.

Use NCSIM's built in "Create Force" option. I just debugged a combinational loop, and this worked like clockwork. I could follow the whole loop, and figure out which branches were being taken by selectively forcing signals. When a force caused the simulation to continue, that signal is part of the loop. If the force had no effect, that signal is not part of the loop. This worked well for me as it didn't take too long to get the simulator stuck. If it takes a long time before it gets stuck this may not work well as it requires continuously restarting the simulation to test each sequential branch.

VS 2005 convert to VS 2010 - property pages

A client sent me their Visual Studio 2005 project. I have Visual Studio 2010 Express. I opened the project, and it offered to convert it. It failed miserably. First thing is, it couldn't handle the x64 configurations. So I opened the VS 2005 vcproj file, and I removed the x64 configurations. Yay!

It now opens the project, (reporting that conversion passed without errors). Except that it is lying. The property pages have converted as pretty much empty files. It has the XML header, but all of the property pages are empty.

Long story short, go to the command line, and use vcupdate on the original vcproj file. One problem I noticed was the SolutionDir wasn't available as you can't run vcupdate on an sln file. So in the command prompt, type:

set SolutionDir=(path of the project)

Then run vcupgrade on the vcproj file. Make sure the path is a fixed path and not relative to the vcproj file.

That does it, the property pages get converted properly!

Xilinx Zynq - harder to implement than one would hope

So I get a new Zynq ZC702 development board, and I'm tasked with making it work. I got the new ISE 14.2 development tools from Xilinx. Here are some things you might want to know if you encounter the same board.

The FPGA logic is the PL (Programming Logic), and the A9 subsystem is the PS (Processor System). Don't attempt to use Impact to burn anything! The burning is all done through an application called zynq_flash.exe.

Do not use Project Navigator to build this FPGA bitstream! Even if you wanted to, which I did, you will find that ngdbuild crashes most of the time (when using the embedded A9) in this flow. Use PlanAhead. It is the new recommended flow from Xilinx. Its also a surprisingly good flow.

The flow I'm using is:
Create a project in XPS. Set up everything that you need for interfacing to the PL there.
Export the project for the SDK, it's an option in XPS. Don't generate the bitstream. Don't launch the SDK.
Create a new project in PlanAhead. Import the .xmp project that you created in XPS. Right click on the embedded processor to create a stub file. Add your source files, and build the rest of the project there.
Generate a bitstream.
Open SDK. Create a new hardware platform specification. Browse for the .XML file under the XPS project in the SDK export folder. Choose the bitstream that was built by PlanAhead. If you have a .bmm file, then use it.
Create a new BSP based on this platform.
Create a new C project and choose Zynq FSBL. You need the FSBL (First Stage Bootloader) to burn the FPGA. It is also needed by the A9 to boot up. Select the platform that you created for the FSBL.
Create a project for your application based on the platform you created.

To burn, right click on the application, and choose to create image. It will automatically add the FSBL, bitstream, and application. To burn the new .mcs file, use the Xilinx tools menu, and burn flash. This is using the zynq_flah applicaion.

Some caveats, I have seen zynq_flash claim to burn even when it doesn't. If the erase step doesn't take at least a few seconds (more like 30+), then it's not working. I have never seen the verify option work at all. If it isn't burning, then turn off the board for a few minutes, and try again.

That's about it.

Libero SOC and IO constraints

A rule that I have always kept to is : Keep design source files as text! A  while back I had the misfortune of using ATEasy. Back then all ATEasy projects were binary, and the sources were stored in the project. This made it very hard to compare versions or to store the sources in revision control. This was bad back then. Even then, ATEasy became aware of the problem and added an option to store project files as text.
Getting back to Microsemi / Actel... The newest version of the tool no longer allows out to use a PDC file to store IO constraints. You must maintain the constraints from within Designer. This is unpleasant to say the least. The constraints are held in the Designer project file. The project file is not only binary, but it is updated on every run.
You can of course import a PDC file, but don't try and change the IOs around without first opening the tool to unassign all IOs from the Designer database. Otherwise you'll get errors about conflicting IO assignments.
Please fix this!

SystemVerilog variable argument display (printf)

Ah, the joy of perfection.

Any C / C++ programmers now programming in SystemVerilog must feel pretty constrained by language limitations. One of the frustrations that I felt today was the lack of variable argument (varargs) support. I wanted to be able to overload a print function (ie write my own $display) and selectively print or not print based on debug levels or the like. Actually... what I wanted was to store all the debug prints between runs, and only print them in the case of an error, but that's besides the point. I needed a way to overload the $display function.

Here is what I've finally come up with: (be ready, it's wild)

$display("Print with no arguments");

$display("Print with 1 argument %t", $time());

$display("Print with 2 arguments %t, %d", $time(), 5);

$display("Print with 3 arguments %t, %d, %s", $time(), 5, "debug");

etc...

I wanted this to become:

DEBUG_PRINT("Print with no arguments");

DEBUG_PRINT("Print with 1 argument %t", $time());

DEBUG_PRINT("Print with 2 arguments %t, %d", $time(), 5);

DEBUG_PRINT("Print with 3 arguments %t, %d, %s", $time(), 5, "debug");

etc...

Is it possible??

Yes! (at least until someone points out a flaw)

The solution is based on macros that can have variable number of arguments, and the preprocessor allowing ifdef on substituted strings

function void my_debug(string s);

...

endfunction

`define DELIM

`define DEBUG_PRINT(p0, p1=ELIM, p2=ELIM, p3=ELIM, p4=ELIM, p5=ELIM) \

`ifdef D``p1 \

my_debug($psprintf(p0)); \

`else \

`ifdef D``p2 \

my_debug($psprintf(p0, p1)); \

`else \

`ifdef D``p3 \

my_debug($psprintf(p0, p1, p2)); \

`else \

`ifdef D``p4 \

my_debug($psprintf(p0, p1, p2, p3)); \

`else \

`ifdef D``p5 \

my_debug($psprintf(p0, p1, p2, p3, p4)); \

`else \

my_debug($psprintf(p0, p1, p2, p3, p4, p5)); \

`endif \

`endif \

`endif \

`endif \

`endif

This solution works on Cadence Incisive 12.1

Tell me what you think of this solution,

Nachum

ncsim and ReInvoke

If you are a chip designer, and you use Cadence's tools, you might get some advantage by reading this post. Cadence Incisive is a complete package for simulating digital designs (perhaps more than just digital...). Incisive includes such tools as ncvlog, ncvhdl, ncelab, ncupdate, ncsim, and others. ncvlog and ncvhdl compile Verilog/SV and VHDL respectively. ncelab elaborates the design from the top level module. ncupdate re-compiles all changed source files in an elaborated design and re-elaborates. ncsim loads an elaborated design, and can display it with the SimVision GUI.

A sorely underused feature is SimVision's ReInvoke. Using ReInvoke from the simulation menu will cause SimVision to call ncupdate and reload the elaborated design. What is most pleasant about re-invoking the design is that most of the GUI stuff is saved and restored once the re-invoke is done. This includes signals in waveform windows, and I assume it includes watch variables and breakpoints, etc...


The problems with ReInvoke revolve around ncupdate. ncupdate does not properly update source files when packages are involved. This includes VHDL or SystemVerilog packages. Cadence has already informed me that ncupdate will NOT be fixed when it comes to updating SystemVerilog files (and I assume it will not fix VHDL package updates either). This has forced me to look for a way around the ncupdate from ReInvoke issue.

My first attempts to resolve this was to perform a re-compilation and re-elaboration outside of SimVision. Then call ReInvoke. This DOES NOT work. The reasoning is that SimVision will call ncupdate, and ncupdate will once again see which files have been updated (assume the packages), and then it will re-compile the packages (again), and re-elaborate. The re-elaborate will fail since the package has been compiled after the modules that use the packages!

To resolve this issue you can pass ncsim the "update" with "nosource" option. What this means is that SimVision on ReInvoke will NOT check for timestamps or perform any re-compilation of source files. ReInvoke will no only re-elaborate.

Using these options, you can recompile outside of SimVision, and let ReInvoke perform the re-elaboration. Voila! No more errors.

Side note: ReInvoke adds the "update" option automatically even if you didn't call ncsim with the "update" option to begin with. But ncsim will not allow you to pass the "nosource" option with the "update" option. Make sure to add the "update" option on the call to ncsim to avoid any issues.

SystemVerilog Classes and Parameters

I recently attempted to use an SV class with parameters. Simple parameters seem to work fine. You can templatize a class based on type or size. But that's about all you can do.

The limitations of how parameters work within a class are disappointing. As you may be aware, a parameter in a module or interface allows you the flexibility of generating different code for different parameter values. But as another example of the lack of uniformity throughout SystemVerilog they chose to not allow generate statements in a class. So the paramters look the same, but they can't be used the same way.

Another disappointment.

SystemVerilog, Cadence, Exporting a module task

I have recently been writing a lot of verification code with Cadence's tools. I use Incisive for RTL simulations. After using the tools for a while there are definitely limitations that are frustrating. But overall, the tools are very stable and support a large portion of SV, and support it really well. Kudos to Cadence for giving decent error messages on most occasions. That is really a huge plus even if the error is SV legal, but not yet supported.

Tip for calling tasks from a module using SV with Cadence's Incisive:
There are 2 ways, without using Verilog standard probing, to access tasks from within a module.
1. Create an interface. Declare a modport for the module with an exported task. Let the module define the exported task.
Cadence doesn't support this yet.
2. Create a class with the desired task declaration. Extend that class from within the module. Output an instance of the extended class for use elsewhere.
This method works fine with Cadence's tools.

Most people are satisfied with probing. In a small testbench, probing works OK. But when creating a large testbench with many identical modules (or modules with similar functionality), it is much nicer to have an array of class instances to work with. They lend themselves to more modular test designs.

About: System Verilog, Cadence Incisive, ncsim, ncvlog, export task, extends, exported tasks, extended classes, inherited classes, inheritance