Start a new topic

VC707+FMC110 - how do CID, FW, SW versions get set?


We have a Xilinx VC707 with FMC110, and we are using the 4DSP reference design CD243.

Using the original reference design files, we can generate the .XISE project using the 4FM GUI Control App, and we can synthesize, implement, and generate the programming .BIT file in Xilinx ISE 14.2.  Then, we are able to run the provided Fmc110App.exe, and we see the correct CID 243.

We made some changes to some of the reference design files (no updates to the top-level constellation, star, nor wormhole files, though), and after generating the .XISE project and the programming .BIT file using the same tools, when we run the provided Fmc110App.exe, we get a CID of 63 now.

We modified the Fmc110App.exe test program to "accept" a CID of 63, but then we receive several errors when the Fmc110App.exe test program tries to read star offsets, temperatures, voltages, etc. and detect the FMC110 hardware (it cannot).

It looks like cid_package.vhd contains constant values for CID, SW/FW build versions, etc., which seems to explain the CID 63 that the Fmc110App.exe test program is reading back, but this is also the original, unedited cid_package.vhd file, so it is identical to the file in the original reference design.

When we look at vc707_fmc110.h (in output\vc707_fmc110), I do see the CID defined as 0xF3=243, and the SW build verison as non-zero.  How is this file generated?  By the 4FM GUI Control App?

Thus, it looks like the test program reads back CID 63 with the changed design .BIT file and CID 243 with the reference design .BIT file.  Both cid_package.vhd and vc707_fmc110.h are the same in these constants, so it seems like there is something else causing the different behavior.

Please help.  Do you have any ideas/suggestions on what/why this might be?  How do the CID and FW/SW versions get set when the cid_package.vhd file contains fixed constants?

Thank you!

This topic is being closed because the issue is considered as resolved by 4DSP. Feel free to create a new topic for any further inquiries.
Dear Sir,
This is almost correct; StellarIP is copying over cid_package.vhd from the star library to the output folder (because part of the sip_cid .lst file) and then cid_package.vhd is completely created from scratch and overwrites the original copy.
On the new StellarIP the scheme will be slighty different and there is an option to not copy source file bute create an ISE/Vivado project refering to the original location instead.
We were planning on release the new StellarIP mid January but we are behind schedule unfortunately. Would you be interested to be beta tester for the new StellarIP?
Best Regards,

Thank you, Arnaud.

It turns out that the cid_package.vhd file in star_lib\sip_cid\vhdl was read-only when we used the 4FM GUI Control App to generate the .XISE project.  As a result, cid_package.vhd was simply copied to output\vc707_fmc110\Src\sip_cid.  However, once we made sure cid_package.vhd in star_lib\sip_cid\vhdl was no longer read-only, but writeable, the cid_package.vhd generated in output\vc707_fmc110\Src\sip_cid was indeed different, not just simply copied.

Of course, the cid_package.vhd file in star_lib\sip_cid\vhdl still remained unchanged, as expected.

Thus, it looks like the 4FM GUI Control App makes some changes to cid_package.vhd in star_lib\sip_cid\vhdl and then "saves as" the new cid_package.vhd to output\vc707_fmc110\Src\sip_cid, leaving the cid_package.vhd file in star_lib\sip_cid\vhdl unchanged; is this correct?

Thanks again!
Dear Sir,
You might want to add a chipscope in your design in order to "debug" the stellarIP read operation on address 0x2000. This will help you to understand what is actually provided to the host (63 or 243). You could also tackle the software side using Wireshark and look at which ethernet packet is returned by the firmware when step tracing cid_init().
cid_package.vhd, firmwarename.h and the toplevel are created by StellarIP in 4FM GUI Control when the "Generate" button is pressed. FW build code is not used, always set to 0 and the SW build code is a random number also written from StellarIP. StellarIP is indeed mapping all stars to a given addresses.
Note that we never had/heard about this issue.
Keep me updated.
Best Regards,