使用SPI闪存配置Spartan 3A FPGA

csholikowski写道：
虽然系统之间的故障不同，但我们只是为了简单起见：
我有一个时钟，每当有一个上升沿时，计数器增加1.一旦达到5000计数，我想重新编程FPGA。
我将I / O连接到PROGRAM_B引脚将其驱动为低电平，配置过程将开始。
但是，如果配置启动时它是相同的FPGA（控制PROGRAM_B线），fpga会使PROGRAM_B引脚置为无效，从而违反信号保持低电平的时间量？
那么你需要一个外部部件来控制PROGRAM_B线路吗？
数据表说PROGRAM_B需要断言仅500 ns，我的猜测是你基本上需要保持它直到配置开始。
并且您知道当释放保持PROGRAM_B的引脚时配置已经开始。
所以我认为你不需要任何额外的东西。
例如：我在一个系统中有两个FPGA：
FPGA A工作正常，但FPGA B检测到故障。
FPGA B通过共享通信接口向FPGA A发送有关FAULT的消息。
然后FPGA A将FPGA B的PROGRAM_B线驱动为低电平所需的时间。
然后它将释放引脚。
这将重新配置FPGA B.
这是怎么回事？
那应该没问题。
您可能希望FPGA监视FPGA B的INIT_B和DONE信号。
如果配置期间出现CRC故障，则前者被拉低;当配置完成且FPGA准备好使用时，后者显然会变高。
----------------------------是的，我这样做是为了谋生。
在原帖中查看解决方案



以下为原文

csholikowski wrote:
While a fault is different from system to system, lets just say for simplicity:
 
I have a clock and everytime there is a rising edge the counter increases by 1.  Once it hits 5000 counts I want to reprogram the FPGA.  I connect a I/O to the PROGRAM_B pin drive it low and the configuration process will start.  But if it is the same FPGA(controlling the PROGRAM_B line) when the configuration starts the fpga will deassert the PROGRAM_B pin and therefore violating the amount of time the signal is held low?
 
So you need an external part to control the PROGRAM_B line? 

The data sheet says that PROGRAM_B needs to be asserted for only 500 ns, and my guess is that you basically need to hold it until configuration starts. And you know configuration has started when the pin holding PROGRAM_B low is released. So I don't think you need anything extra.

For example:  I have TWO FPGA's in a system:

FPGA A is working fine, but FPGA B detects a fault.  FPGA B sends FPGA A a message about the FAULT over a shared communication interface.  FPGA A will then Drive the PROGRAM_B line of FPGA B low for a required amount of time.  Then it will release the pin.   This will reconfigure FPGA B.
 
Is this how it would work?

 That should be fine. You might wish to have FPGA monitor FPGA B's INIT_B and DONE signals. The former is pulled low if there's a CRC fail during configuration, and the latter obviously goes high when configuration is done and the FPGA is ready for use.
----------------------------Yes, I do this for a living.View solution in original post

csholikowski写道：
早安Xilinx用户，
我最近一直在研究如何使用SPI串行闪存配置Spartan 3a（400a，700a或1400A）。
我知道如何使用平台u***电缆等将SPI闪存加载到适当的位文件中......上电时SPI闪存将配置FPGA。
我的问题是：
如果在我的系统中检测到故障（测量不良，硬件故障或其他一些噪声导致故障等等），我想用SPI闪存中的比特流重新配置FPGA。
我不完全理解Program_B和Init_B的时间。
我是否需要另一个FPGA来控制这些线路以重新配置FPGA？
是否有文档说明如何在通电阶段重新配置FPGA？
一旦在FPGA中发生某个事件，我基本上需要一个如何将比特流重新编程到FPGA中。
首先，问题在于弄清楚如何检测故障。
我想这一切都取决于你试图检测的故障类型。
这是一个留给读者的练习。
因此，例如，如果FPGA能够检测到故障，您可以将任何FPGA引脚连接到PROGRAM_B。
将该引脚开漏。
每当检测到故障时，该检测逻辑在PROGRAM_B上下降。
当配置逻辑将PROGRAM_B识别为低电平时，将启动配置过程。
重新配置过程中的一个步骤是释放所有用户I / O（拉高或拉高-Z），因此PROGRAM_B将自动解除置位。
如果您有外部逻辑来检测故障，比如使用微控制器，那么您需要做的就是确保将PROGRAM_B保持为足够长的时间。
多久？
RTFDS。
----------------------------是的，我这样做是为了谋生。



以下为原文

csholikowski wrote:
Good Morning Xilinx Users,
 
I have recently been researching on how to configure a Spartan 3a (400a, 700a, or 1400A) with a SPI serial flash. 
 
I know how to load the SPI flash with the appropriate bit file using a platform u*** cable etc...  The SPI flash on power up will configure the FPGA.
 
My question is:
 
If in my system a fault is detected( bad measurement, hardware fault, or some other noise caused a fault etc...)  I would like to reconfigure the FPGA  with the bitstream in the SPI flash.  I don't fully understand the timing of the Program_B and Init_B.  Do I need another FPGA to control these lines to reconfigure the FPGA?  Is there a Document explaining how to reconfigure an FPGA while past the power up stage?
 
I basically need a How to reprogram the bitstream into the FPGA once a certain event has happened in an FPGA.
 

The issue, first and foremost, is figuring out how to detect a fault. And I suppose that all depends on the type of faults you're trying to detect. That's an exercise left to the reader.
 
So for example, if the FPGA is capable of detecting a fault, you can take any FPGA pin and connect it to PROGRAM_B. Make that pin open-drain. Whenever the fault is detected, that detection logic yanks down on PROGRAM_B. When the configuration logic recognizes PROGRAM_B low, the configuration process will start. One of the steps in the reconfiguration process is to release all user I/O (either pull high or go hi-Z), so PROGRAM_B will automatically be deasserted.
 
If you have external logic that detects the fault, say with a microcontroller, all you need to do is ensure that you hold PROGRAM_B low long enough. How long? RTFDS.
----------------------------Yes, I do this for a living.

虽然系统之间的故障不同，但我们只是为了简单起见：
我有一个时钟，每当有一个上升沿时，计数器增加1.一旦达到5000计数，我想重新编程FPGA。
我将I / O连接到PROGRAM_B引脚将其驱动为低电平，配置过程将开始。
但是，如果配置启动时它是相同的FPGA（控制PROGRAM_B线），fpga会使PROGRAM_B引脚置为无效，从而违反信号保持低电平的时间量？
那么你需要一个外部部件来控制PROGRAM_B线路吗？
例如：我在一个系统中有两个FPGA：
FPGA A工作正常，但FPGA B检测到故障。
FPGA B通过共享通信接口向FPGA A发送有关FAULT的消息。
然后FPGA A将FPGA B的PROGRAM_B线驱动为低电平所需的时间。
然后它将释放引脚。
这将重新配置FPGA B.
这是怎么回事？
谢谢



以下为原文

While a fault is different from system to system, lets just say for simplicity:
 
I have a clock and everytime there is a rising edge the counter increases by 1.  Once it hits 5000 counts I want to reprogram the FPGA.  I connect a I/O to the PROGRAM_B pin drive it low and the configuration process will start.  But if it is the same FPGA(controlling the PROGRAM_B line) when the configuration starts the fpga will deassert the PROGRAM_B pin and therefore violating the amount of time the signal is held low?
 
So you need an external part to control the PROGRAM_B line? 
 
For example:  I have TWO FPGA's in a system:


FPGA A is working fine, but FPGA B detects a fault.  FPGA B sends FPGA A a message about the FAULT over a shared communication interface.  FPGA A will then Drive the PROGRAM_B line of FPGA B low for a required amount of time.  Then it will release the pin.   This will reconfigure FPGA B.
 
Is this how it would work?
 
Thanks

csholikowski写道：
虽然系统之间的故障不同，但我们只是为了简单起见：
我有一个时钟，每当有一个上升沿时，计数器增加1.一旦达到5000计数，我想重新编程FPGA。
我将I / O连接到PROGRAM_B引脚将其驱动为低电平，配置过程将开始。
但是，如果配置启动时它是相同的FPGA（控制PROGRAM_B线），fpga会使PROGRAM_B引脚置为无效，从而违反信号保持低电平的时间量？
那么你需要一个外部部件来控制PROGRAM_B线路吗？
数据表说PROGRAM_B需要断言仅500 ns，我的猜测是你基本上需要保持它直到配置开始。
并且您知道当释放保持PROGRAM_B的引脚时配置已经开始。
所以我认为你不需要任何额外的东西。
例如：我在一个系统中有两个FPGA：
FPGA A工作正常，但FPGA B检测到故障。
FPGA B通过共享通信接口向FPGA A发送有关FAULT的消息。
然后FPGA A将FPGA B的PROGRAM_B线驱动为低电平所需的时间。
然后它将释放引脚。
这将重新配置FPGA B.
这是怎么回事？
那应该没问题。
您可能希望FPGA监视FPGA B的INIT_B和DONE信号。
如果配置期间出现CRC故障，则前者被拉低;当配置完成且FPGA准备好使用时，后者显然会变高。
----------------------------是的，我这样做是为了谋生。



以下为原文

csholikowski wrote:
While a fault is different from system to system, lets just say for simplicity:
 
I have a clock and everytime there is a rising edge the counter increases by 1.  Once it hits 5000 counts I want to reprogram the FPGA.  I connect a I/O to the PROGRAM_B pin drive it low and the configuration process will start.  But if it is the same FPGA(controlling the PROGRAM_B line) when the configuration starts the fpga will deassert the PROGRAM_B pin and therefore violating the amount of time the signal is held low?
 
So you need an external part to control the PROGRAM_B line? 

The data sheet says that PROGRAM_B needs to be asserted for only 500 ns, and my guess is that you basically need to hold it until configuration starts. And you know configuration has started when the pin holding PROGRAM_B low is released. So I don't think you need anything extra.

For example:  I have TWO FPGA's in a system:

FPGA A is working fine, but FPGA B detects a fault.  FPGA B sends FPGA A a message about the FAULT over a shared communication interface.  FPGA A will then Drive the PROGRAM_B line of FPGA B low for a required amount of time.  Then it will release the pin.   This will reconfigure FPGA B.
 
Is this how it would work?

 That should be fine. You might wish to have FPGA monitor FPGA B's INIT_B and DONE signals. The former is pulled low if there's a CRC fail during configuration, and the latter obviously goes high when configuration is done and the FPGA is ready for use.
----------------------------Yes, I do this for a living.

谢谢，我只是想仔细检查一下，看看我是否理解了一切。



以下为原文

Thanks, I just wanted to double check to see if I understood everything properly.
 
 

csholikowski写道：
谢谢，我只是想仔细检查一下，看看我是否理解了一切。
现在我考虑一下 - 我希望其中一位Xilinx人员介入并确认我的想法是否可靠。
----------------------------是的，我这样做是为了谋生。



以下为原文

csholikowski wrote:
Thanks, I just wanted to double check to see if I understood everything properly.
 

Now that I think about it -- I wish one of the Xilinx folks would step in and confirm whether my idea is reliable.
----------------------------Yes, I do this for a living.

嗨！

Do you use some sort of power monitor for brown-out detection? If FPGA not held in reset state during possible temporary power faults, its config RAM corrupts and lead to undefined state or even burn FPGA. So the best practice is to use Reset manager (Power On Reset Circuit) like LP3470IM5-2.93. Why i writing this? Just because in case of using this stuff, it looks to be easy to implement what you want, i.e. prolong Reset pulse to guaranteed time. For LP3470, i bias it via resistive network, and in case of alarm, tie 2nd resistor to GND with FPGA alarm out pin to emulate power fault spike. You may use more espensive parts like  TPS3828 which have dedicated 'watchdog' input. In any case, you get the benefit of proper Reset all the time just for few USD.

nposozvezdie写道：
嗨！如果某个事件发生，如何将比特流重新编程到FPGA中你是否使用某种功率监视器进行欠压检测？
如果FPGA在可能的临时电源故障期间未处于复位状态，则其配置RAM会破坏并导致未定义状态甚至烧毁FPGA。
因此，最佳做法是使用复位管理器（上电复位电路），如LP3470IM5-2.93。
我为什么写这个？
仅仅因为在使用这些东西的情况下，它看起来很容易实现你想要的，即延长复位脉冲到保证时间。
对于LP3470，我通过电阻网络对其进行偏置，并且在发生报警时，将第二个电阻连接到GND，并使用FPGA报警输出引脚来模拟电源故障尖峰。
您可以使用更加昂贵的部件，如TPS3828，它们具有专用的“看门狗”输入。
在任何情况下，只需几美元即可获得正确重置的好处。
我的猜测是他的“特定事件”比简单的电源监控所处理的要复杂得多。
----------------------------是的，我这样做是为了谋生。



以下为原文

nposozvezdie wrote:
Hi!
How to reprogram the bitstream into the FPGA once a certain event has happened
Do you use some sort of power monitor for brown-out detection? If FPGA not held in reset state during possible temporary power faults, its config RAM corrupts and lead to undefined state or even burn FPGA. So the best practice is to use Reset manager (Power On Reset Circuit) like LP3470IM5-2.93. Why i writing this? Just because in case of using this stuff, it looks to be easy to implement what you want, i.e. prolong Reset pulse to guaranteed time. For LP3470, i bias it via resistive network, and in case of alarm, tie 2nd resistor to GND with FPGA alarm out pin to emulate power fault spike. You may use more espensive parts like  TPS3828 which have dedicated 'watchdog' input. In any case, you get the benefit of proper Reset all the time just for few USD.

My guess is his "certain event" is a lot more sophisticated than what can be dealt with by simple power-supply monitoring.
----------------------------Yes, I do this for a living.

嗨！
我的意思是使用现有的POR管理器（如果有的话）有意地从FPGA触发，而不是（仅）由于电源轨事件而自行触发;
或添加此设备，如果它仍然不存在。
TPS3823A-33具有专用的“看门狗”和“手动复位”输入。
当FPGA中的WDT /特定事件触发时，POR保证正确的复位脉冲。
所以对于有问题的任务，它看起来像是最佳解决方案。
或者我错了或在某处误读了？



以下为原文

Hi! I mean using existing POR manager (if any) for triggering intentionally from FPGA, not (only) itself due to power rail event; or add this device, if it still not exist. TPS3823A-33 have dedicated 'watchdog' and 'manual reset' inputs. PORs guarantee proper Reset pulse when WDT/specific event in FPGA fires. So for task in question, it looks like best solution. Or i am wrong or misread somewhere?..

nposozvezdie写道：
嗨！
我的意思是使用现有的POR管理器（如果有的话）有意地从FPGA触发，而不是（仅）由于电源轨事件而自行触发;
或添加此设备，如果它仍然不存在。
TPS3823A-33具有专用的“看门狗”和“手动复位”输入。
当FPGA中的WDT /特定事件触发时，POR保证正确的复位脉冲。
所以对于有问题的任务，它看起来像是最佳解决方案。
或者我错了或在某处误读了？
啊，我的道歉，现在我理解你在说什么。
我们使用复位管理器在所有设计上驱动PROGRAM_B。
我们从来没有需要强制重新配置，但你的建议很有意义！
----------------------------是的，我这样做是为了谋生。



以下为原文

nposozvezdie wrote:
Hi! I mean using existing POR manager (if any) for triggering intentionally from FPGA, not (only) itself due to power rail event; or add this device, if it still not exist. TPS3823A-33 have dedicated 'watchdog' and 'manual reset' inputs. PORs guarantee proper Reset pulse when WDT/specific event in FPGA fires. So for task in question, it looks like best solution. Or i am wrong or misread somewhere?..

Ah, my apologies, now I understand what you're saying. 
 
We use a reset supervisor to drive PROGRAM_B on all of our designs. We've never had a need to force reconfiguration but your suggestion makes a lot of sense!
----------------------------Yes, I do this for a living.