cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
535 Views
Registered: ‎04-08-2015

XC7A50T-cpg236

Hi all,

We have developed  a board using XC7A50T-CPG236 and Micron mt25ql128 memory IC for loading the RTL into FPGA at start-up. It worked well intially, however, after several read-write operations(few thousand atleast), the RTL seemed to have stopped functioning, ie, no response on the data lines. On re-programming it, it starts to work again, but fails after a while. Does anyone have any theory why the hardware would fail? I understand this is a vague question but if anyone has experienced FPGA/Memory system issues similar to what I have described here, your insight would be great.

0 Kudos
6 Replies
Highlighted
Xilinx Employee
Xilinx Employee
476 Views
Registered: ‎03-07-2018

Hello @suvanb1987 

Did you performed any changes in your RTL design recently?

Are you using any evalution license based Xilinx IP? Reason for this query: https://www.xilinx.com/support/answers/42380.html

Regards,
Bhushan

-------------------------------------------------------------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
-------------------------------------------------------------------------------------------------------------------------------------------------
0 Kudos
Highlighted
Moderator
Moderator
466 Views
Registered: ‎01-15-2008

could you let us know about your FPGA system working environment(temperature/automotive/aerospace related)? is the device you are using commercial grade or industrial grade? could you please check on your FPGA power system they remain same throughout the system functioning.

How many boards you see this issue?

0 Kudos
Highlighted
Visitor
Visitor
373 Views
Registered: ‎04-08-2015

The RTL is from a third-party vendor using an .edif core file. Could things like FPGA/oscillator clock drift affect the RTL adversely? The speed grade is -1.

0 Kudos
Highlighted
355 Views
Registered: ‎01-22-2015

@suvanb1987 

...after several read-write operations(few thousand atleast), the RTL seemed to have stopped functioning, ie, no response on the data lines. 
So, the FPGA configures itself from flash correctly, runs for a while, and then stops.  Have I correctly described how things fail?   -or, does the FPGA fail to configure itself from flash?

On re-programming it, it starts to work again, but fails after a while.
Do you mean that if you reprogram the flash then things start working again.  -or, do you mean that when you power-cycle the board then the FPGA configures itself from flash and the FPGA starts working again?

Does anyone have any theory why the hardware would fail?
Which hardware?  The flash hardware or the FPGA hardware?

Could things like FPGA/oscillator clock drift affect the RTL adversely?
Yes.  If the oscillator output frequency drifts too much then CMTs like the MMCM can loose lock.  If you are using the MMCM, then check other MMCM input specifications shown in Table 37 of DS181.

Do you have a constraint like the following in your .xdc file?  If so, what is the value you are using for xxx?

set_property BITSTREAM.CONFIG.CONFIGRATE xxx [current_design]

 

Mark

0 Kudos
Highlighted
Visitor
Visitor
231 Views
Registered: ‎04-08-2015

.after several read-write operations(few thousand atleast), the RTL seemed to have stopped functioning, ie, no response on the data lines. 
So, the FPGA configures itself from flash correctly, runs for a while, and then stops.  Have I correctly described how things fail?   -or, does the FPGA fail to configure itself from flash? The first option is correct.

On re-programming it, it starts to work again, but fails after a while.
Do you mean that if you reprogram the flash then things start working again.  -or, do you mean that when you power-cycle the board then the FPGA configures itself from flash and the FPGA starts working again? The first option is correct.

Does anyone have any theory why the hardware would fail?
Which hardware?  The flash hardware or the FPGA hardware? I think its the FPGA since its doing the computation. The flash just loads the bitstream file at the beginning.

Could things like FPGA/oscillator clock drift affect the RTL adversely?
Yes.  If the oscillator output frequency drifts too much then CMTs like the MMCM can loose lock.  If you are using the MMCM, then check other MMCM input specifications shown in Table 37 of DS181. What is MMCM?

Do you have a constraint like the following in your .xdc file?  If so, what is the value you are using for xxx?

set_property BITSTREAM.CONFIG.CONFIGRATE xxx [current_design]

We dont have this. What does this do?

0 Kudos
Highlighted
217 Views
Registered: ‎01-22-2015

@suvanb1987 

What is MMCM?
Usually, a base-clock is generated outside the FPGA using a crystal-stabilized oscillator.  This base-clock is routed to a clock-capable pin on the FPGA and they (usually) to a MMCM or PLL inside the FPGA.  The MMCM and PLL are used to generated all the clocks used by your design.  See Xilinx Document UG472 for more information on MMCMs and PLLs.

We dont have this. What does this do?
The constraint I showed will set the clock rate at which the FPGA reads the bitstream from flash at power-up.  Try placing the following constraint in the .xdc file for your Vivado project.  It will set the clock rate to 3 MHz for reading the bitstream from flash - and may make reads from flash more reliable.

set_property BITSTREAM.CONFIG.CONFIGRATE 3 [current_design]

 

It sounds like the data stored in flash is being corrupted - possibly by the FPGA.

Please find the figure in UG470 that describes your method of configuring the FPGA from flash - and verify that all the correct connections exist.  Also verify that you have the recommended pullup resistors.

Mark

 

0 Kudos