Reading 7 series FPGA configuration memory

[greatmaverick]

I have heard reading configuration memory during running causes changing in configuration memory bit. The solution is reading configuration memory when FPGA is not running. How to hold FPGA after it is configured?

Thank you.

[drjohnsmith]

Do you mean internal memory to the FPAG or the external FLASh configuration memory ?

what tools are you looking at to do the reading ?

[greatmaverick]

I mean the FPGA's internal configuration memory. I prepare to develop a read method using slave selectmap method.

[lowearthorbit]

gm,

By design, the CRAM is immune to read disturbs.  Read Type 2 frames all you want.  BRAM readback will disturb BRAM:  it is dual port, not three port, so readback collides with A port usage.  DO NOT read back BRAM unless you do not care about flipping BRAM bits.  Note that LUTRAM, LUTROM, SRL are masked to all 1's during readback.  The .msk file from bitgen tells you which bits are dynamic, and which are static.  But do not read back all frame types if you care about BRAM contents.  Depending on how the BRAM is being used, you may see lots of read disturbs, or none at all.  They are disturbed when the fabric is reading or writing a BRAM word while readback wants to read the word....

If you are looking for a way to guarantee correctness, use the SEM IP core (7th generation, beam tested).Solves all of the problems about frame types, masking, etc.

l.e.o.

[drjohnsmith]

It depends why you want to read back the configuration .

Yes you can read back the curren tstate of the FPGA configuration bits,

     but that WILL not be the same as the orriginal programed file you configured the FPGA with,

           if one could , then piracy would be real easy ..

Once the FPGA is configured, it starts running,

  Part of the configuration is the setting of all the internal registers of the FPGA and the rams.

       thats how you set a counter to start at a given number after configuration , its in the configuration file.

As soo as the configuratoin ha socmpleted, the FPGA will be released fomr reset by the internal global reset line.

       once this happens all the contents is up to be changed as part of the normal FPGA code running.

           i.e. counters start counting...

As all these register initial conditions are part of the FPGA configuration, then the read back file is not the same as the program file.

A lot of the file is the same, but a lot is different.

Its up to your FPGA design to add an external reset if you wan tthe processor not to run after its configured,

Regarding reading BRAMS in th econfigured FPGA via the select map interface.

  you have to consider what happens if you want to read the ram at the sam etime the fpga wants to write to the ram,

      if your FPGA code has controls you have added to hold off the fpga accessing the ram when your reading ,then all should be good,

    if you have generic code, then you can not garuntee what state the dual access ot the ram wil lcause.

[greatmaverick]

Hi lowearthorbit,
Thank you for your reply. What do you mean by "CRAM ", configuration memory? Does SEM IP core is guarunteed to detect any unintentionly configuration memory changes so long as it occurs?

[greatmaverick]

Thank you, drjohnsmith
Can I control the internal global reset line and forbid the FPGA to run after configuration is completed?
Is there any user guide introduce the internal global reset line?

[drjohnsmith]

GSR goes back right to the foundation of Xilinx FPGAs
its an internal signal, that is released after the internal startup block determines the power voltages are with in specification and the device has been configured.

It is tied into the the init_b, program_b etc lines.

If you have look her for instance
https://www.xilinx.com/support/documentation/sw_manuals/xilinx2014_1/ug974-vivado-ultrascale-libraries.pdf

page 7 shows the blocks you have access to to interface with the configuration of a ultra scale part,

Different FPGAs have different configuration blocks made visible

I have not heard of a way of holding off GSR

[lowearthorbit · Accepted solution]

Yes,

100% (every and any number of) upset(s) is/are detected by the RBCRC in the configuration hard logic block (used by SEM IP).  The SEM IP will  classify upsets as fixable (you can fix it, check it was fixed), or it might be a multiple bit upset that is detected, but not corrected.  The replace frame mode in SEM IP fixes 100% of upsets.  The enhanced mode fixes dual adjacent errors.  Single repair and dual adjacent repair use the FRAME_ECC check words (EDAC ECC hamming code per frame).

Note Xilinx devices are the only FPGA device with this feature - beam tested, field tested, 7 generations history, proven and reliable.  Others have tried, and then failed in independent beam tests.  Quite important in safety critical systems, crypto, security, etc.

l.e.o.

[greatmaverick]

Thank you