08-04-2015 03:22 AM
I am performing readback on xc7vx485t xilinx fpga. For this I need to know the following:
1. Total Configuration Frames
2. Words per Frame
3. Overhead Word Count(Pipeline Word Count)
I searched for documents but could not find this detail in any of the doc.
Any help will be really very very helpful for me
08-04-2015 07:26 AM
We generally do not support this sort of detail. We have developed the SEM IP to handle all readback/mitigation/configuration error management.
What are you trying to do?
In the past it was just too time consuming to deal with these sorts of questions. Most of them come from academics and researchers, and we are happy to support them, but only to the extent that it doesn't become a huge time sink. For that reason (and others) we recommend the use of the SEM IP core (fully documented, fullyu supported).
08-04-2015 07:58 AM
I need this information to extract design signal values from the readback file(.rbd). I was going through the document:
To read the deisgn value from readback file, we need to find the line number using words per frame, configuration overead etc.
If there is any other simple way to perform the readback and extract design signal values, I would be happy to do it in that way.
I want to read the design signal values cycle by cycle by enabling disabling clocks at every cycle or eveyr few cycles. Is there any document which can help me with this? How do we enable/freeze clock every cycle?
% create_hw_bitstream -hw_device [current_hw_device] -mask fpga.msk fpga.bit
% verify_hw_devices [current_hw_device]
% readback_hw_device [current_hw_device] -readback_file <filename.rbd> -bin_file <filename.bin>
I just executed the above commands and it gace me the readback file. I was wondering if the execution of commands in sequence before readback capture is needed or not.
08-04-2015 08:41 AM
That is what you need.
Why is it you require the configuration memory image after each cycle. The static bits will remain unchanged cycle to cycle. The SRL, LUTRAM will change.
Note that the state of the DFF in the CLB is captured by the global state capture controls (either load the intial value, or write the current state to that init value configuraion bit).
The state of the DSP48 is not in the bitstream.
An incredible amount of effort to record hundreds of millions of bits that will be identical from cycle to cycle.
If this is proprietary (and you do not wish to discuss in the forums), then email me at firstname.lastname@example.org