Sunday, December 16, 2012
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.
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
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).
Sunday, November 11, 2012
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.
Sunday, October 14, 2012
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!
Saturday, September 1, 2012
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.
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!
Friday, August 3, 2012
Saturday, July 7, 2012
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.
Saturday, February 4, 2012
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.
Saturday, January 21, 2012
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