为什么JTAG会发生多重启动？

嗨，
理想情况下，JTAG不应该影响FLASH的FPGA多引导编程？
一旦你重新启动FPGA，一切都应该是正常的。
JTAG端口应该影响的唯一情况是，当您加载影响编程FLASH的行的程序时。
你能指出你之前几次发现这个问题的地方吗？
谢谢，AnirudhPS：请将此标记作为答案，以防它有助于解决您的问题。如果帖子引导您找到解决方案，请给予赞誉。



以下为原文

Hi,
 
Ideally, the JTAG should not affect the multiboot programming of the FPGA from the FLASH? Once you power cycle the FPGA, everything should be normal.
 
The only case where the JTAG port should affect, is when you are loading a program which affects the lines which program the FLASH. 
 
Can you please point out where you have found this issue discussed several times before?
Thanks,
Anirudh

PS: Please MARK this as an answer in case it helped resolve your query.Give kudos in case the post guided you to a solution.

您可以使用ICAP读取fpga logi中的状态寄存器（BOOTSTS）寄存器。
--Krishna



以下为原文

you can make use of the ICAP to read the status registers(BOOTSTS) registers in your fpga logi.
 
--Krishna

您使用的是哪种Spartan设备？
如果是Spartan-3A / 3AN，请在以下AR http://www.xilinx.com/support/answers/29416.html上交叉检查您的程序。
_______________________________________________如果有助于解决您的查询，请将此帖子标记为“接受为解决方案”。
因此，它将有助于其他论坛用户直接参考答案。如果您认为该信息有用且面向答复，请给予此帖子称赞。



以下为原文

Which Spartan device are you using?
 
In case of Spartan-3A/3AN please crosscheck your procedures against the following AR  http://www.xilinx.com/support/answers/29416.html
________________________________________________

Please mark this post as an "Accept as solution" in case if it helped to resolve your query. So that it will help to other forum users to directly refer to the answer.

Give kudos to this post in case if you think the information is useful and reply oriented.

谢谢您的回复。
我似乎高估了已经讨论了多少，只是来自一个更有经验的设计师的第一个提示是避免使用JTAG，当快速浏览这些论坛时，同样的提示随便给了其他人（例如http：//
forums.xilinx.com/t5/Spartan-Family-FPGAs/multiboot-using-ICAP-SPARTAN6/mp/417141/）
自然地一直只使用ICAP并实现单独的逻辑来从芯片读取状态寄存器内容将完全避免这个问题。
我对JTAG太固定了，因为这是我目前最容易访问的内容。
实际上已经没有实际问题，但我仍然继续进行调查，仅仅是因为我个人的好奇心。
我写了一个在xc3s50a上运行的简单测试：
模块多引导（ 
输入CLK， 
输出LEDPIX， 
输出LEDBIT， 
输出LEDALIVE 
）; 
reg [29：0] wait_count = 0; 
reg [4：0] addr = 0; 
导线; 
电线[7：0] d; 
wire [7：0] d_swap;  
分配LEDALIVE = wait_count [25]; 
分配LEDPIX = led; 
分配LEDBIT = led; 
赋值d_swap = {d [0]，d [1]，d [2]，d [3]，d [4]，d [5]，d [6]，d [7]}; 
boot_sequence1 bs（ 
.addr（ADDR）， 
.LED（LED） 
.icap_enable（i_ce）， 
.D（d））; 
ICAP_SPARTAN3A icap（ 
.CLK（CLK）， 
.CE（i_ce）， 
.I（d_swap）， 
.WRITE（1'b0））; 
总是@（posedge CLK） 
开始 
wait_count
它具有基本的ICAP多重引导逻辑和两个不同的引导序列，可以提供给ICAP。
还有一个指示器显示正在使用哪个序列（即，加载了哪个bitsteam）。
两者都将引导模式定义为SPI，每个引导模式都具有与引导位置不同的地址。
只需更改boot_sequence实例即可轻松完成两个不同的比特流。
如果我将这两个比特流写入SPI启动闪存并启动FPGA，一切都按预期工作，两个配置轮流加载，并在两者之间等待大约十秒钟。
如果在这十秒钟的等待时间内通过JTAG访问配置，会发生奇怪的事情。
如果我使用Impact读取设备状态寄存器，一切似乎都很顺利，我得到了寄存器内容，fpga继续运行，但是在下一个多引导事件中，根本没有访问SPI闪存，也没有加载新的配置。
如果我再次读取状态寄存器，则会使寄存器内容正常，但状态包含一个标志，表示未找到SYNC字。
随着一些更多的摆弄我也注意到，如果我通过JTAG加载初始比特流而不是允许它来自SPI闪存，同样的情况也会发生。
初始配置运行正常，但SPI闪存永远不会被访问以获得下一个比特流，并且不会进行重新配置。
提供给ICAP的启动顺序将新的启动模式定义为SPI，因此理论上我希望这可以工作并从SPI闪存加载下一个比特流。
在这两种情况下，FPGA的功率循环当然恢复了正常操作，两个比特流再次能够相互加载，但我想知道是否有更“文明”，无中断的方式来进行JTAG访问（或者只是为了阅读
状态寄存器或最佳均匀加载初始比特流）。



以下为原文

Thank you for your replies.
 
It seems I overestimated how much this was discussed already, it was just that the first tip from a more experienced designer was to avoid the JTAG and when quickly browsing these forums the same tip was casually given to other people (for example http://forums.xilinx.com/t5/Spartan-Family-FPGAs/multiboot-using-ICAP-SPARTAN6/m-p/417141/)
 
Naturally using only ICAP all the time and implementing a separate logic to read the status register contents off the chip would completely avoid this issue. I was just too fixed on the JTAG as that the easiest thing I could access at the moment. Actually there is no practical issue any longer, but I still went on to investigate this further just for my personal curiosity.
 
I wrote a simple test that is running on xc3s50a:
module multiboot(    input CLK,    output LEDPIX,    output LEDBIT,    output LEDALIVE    );  reg [29:0] wait_count = 0;  reg [4:0] addr = 0;  wire led;  wire [7:0] d;  wire [7:0] d_swap;    assign LEDALIVE = wait_count[25];  assign LEDPIX = led;  assign LEDBIT = led;  assign d_swap = {d[0],d[1],d[2],d[3],d[4],d[5],d[6],d[7]};  boot_sequence1 bs (    .addr(addr),    .led(led),    .icap_enable(i_ce),    .d(d));   ICAP_SPARTAN3A icap (    .CLK(CLK),    .CE(i_ce),    .I(d_swap),    .WRITE(1'b0));  always @(posedge CLK)  begin    wait_count <= wait_count + 1;    addr <= addr + wait_count[29];  endendmodulemodule boot_sequence0 (    input [4:0] addr,    output led,    output reg icap_enable,    output reg [7:0] d);  assign led = 1'b0;  always @(*)    case (addr)   5'h00: {d,icap_enable} = {8'hFF, 1'b1};   5'h01: {d,icap_enable} = {8'hFF, 1'b1};   5'h02: {d,icap_enable} = {8'hFF, 1'b0};   5'h03: {d,icap_enable} = {8'hFF, 1'b0};   5'h04: {d,icap_enable} = {8'hFF, 1'b0};   5'h05: {d,icap_enable} = {8'hFF, 1'b0};   5'h06: {d,icap_enable} = {8'hAA, 1'b0};   5'h07: {d,icap_enable} = {8'h99, 1'b0};   5'h08: {d,icap_enable} = {8'h32, 1'b0};   5'h09: {d,icap_enable} = {8'h61, 1'b0};   5'h0A: {d,icap_enable} = {8'h00, 1'b0};   5'h0B: {d,icap_enable} = {8'h00, 1'b0};   5'h0C: {d,icap_enable} = {8'h32, 1'b0};   5'h0D: {d,icap_enable} = {8'h81, 1'b0};   5'h0E: {d,icap_enable} = {8'h00, 1'b1};   5'h0F: {d,icap_enable} = {8'h00, 1'b1};   5'h10: {d,icap_enable} = {8'h32, 1'b0};   5'h11: {d,icap_enable} = {8'hA1, 1'b0};   5'h12: {d,icap_enable} = {8'h4F, 1'b0};   5'h13: {d,icap_enable} = {8'h30, 1'b0};   5'h14: {d,icap_enable} = {8'hA1, 1'b0};   5'h15: {d,icap_enable} = {8'h00, 1'b0};   5'h16: {d,icap_enable} = {8'h0E, 1'b0};   5'h17: {d,icap_enable} = {8'h20, 1'b0};   5'h18: {d,icap_enable} = {8'h00, 1'b0};   5'h19: {d,icap_enable} = {8'h20, 1'b0};   5'h1A: {d,icap_enable} = {8'h00, 1'b0};   5'h1B: {d,icap_enable} = {8'h20, 1'b0};   5'h1C: {d,icap_enable} = {8'h00, 1'b0};   5'h1D: {d,icap_enable} = {8'hFF, 1'b1};   5'h1E: {d,icap_enable} = {8'hFF, 1'b1};   5'h1F: {d,icap_enable} = {8'hFF, 1'b1};    endcaseendmodulemodule boot_sequence1 (    input [4:0] addr,    output led,    output reg icap_enable,    output reg [7:0] d);  assign led = 1'b1;  always @(*)    case (addr)   5'h00: {d,icap_enable} = {8'hFF, 1'b1};   5'h01: {d,icap_enable} = {8'hFF, 1'b1};   5'h02: {d,icap_enable} = {8'hFF, 1'b0};   5'h03: {d,icap_enable} = {8'hFF, 1'b0};   5'h04: {d,icap_enable} = {8'hFF, 1'b0};   5'h05: {d,icap_enable} = {8'hFF, 1'b0};   5'h06: {d,icap_enable} = {8'hAA, 1'b0};   5'h07: {d,icap_enable} = {8'h99, 1'b0};   5'h08: {d,icap_enable} = {8'h32, 1'b0};   5'h09: {d,icap_enable} = {8'h61, 1'b0};   5'h0A: {d,icap_enable} = {8'hD6, 1'b0};   5'h0B: {d,icap_enable} = {8'h00, 1'b0};   5'h0C: {d,icap_enable} = {8'h32, 1'b0};   5'h0D: {d,icap_enable} = {8'h81, 1'b0};   5'h0E: {d,icap_enable} = {8'h00, 1'b1};   5'h0F: {d,icap_enable} = {8'h00, 1'b1};   5'h10: {d,icap_enable} = {8'h32, 1'b0};   5'h11: {d,icap_enable} = {8'hA1, 1'b0};   5'h12: {d,icap_enable} = {8'h4F, 1'b0};   5'h13: {d,icap_enable} = {8'h30, 1'b0};   5'h14: {d,icap_enable} = {8'hA1, 1'b0};   5'h15: {d,icap_enable} = {8'h00, 1'b0};   5'h16: {d,icap_enable} = {8'h0E, 1'b0};   5'h17: {d,icap_enable} = {8'h20, 1'b0};   5'h18: {d,icap_enable} = {8'h00, 1'b0};   5'h19: {d,icap_enable} = {8'h20, 1'b0};   5'h1A: {d,icap_enable} = {8'h00, 1'b0};   5'h1B: {d,icap_enable} = {8'h20, 1'b0};   5'h1C: {d,icap_enable} = {8'h00, 1'b0};   5'h1D: {d,icap_enable} = {8'hFF, 1'b1};   5'h1E: {d,icap_enable} = {8'hFF, 1'b1};   5'h1F: {d,icap_enable} = {8'hFF, 1'b1};    endcaseendmoduleIt has the basic ICAP multiboot logic and two different boot sequences to feed to the ICAP. There is also an indicator led to show which sequence is in use (that is, which bitsteam is loaded). Both define the bootmode to be SPI, each has a different address from where to boot. Two different bitstreams can be easily made by just changing the boot_sequence instance.
 
If I write these two bitstreams to a SPI boot flash and boot the FPGA everything works as expected, the two configurations load each other in turns and wait about ten seconds in between. The curious thing happens if during this ten seconds wait time I access the configuration through the JTAG. If I read the device status register using Impact, everything seems to go fine, I get the register contents, the fpga keeps running, but at the next multiboot event the SPI flash does not get accessed at all and no new configuration is loaded. If I read the status register again I get the register contents fine but the status contains a flag indicating that no SYNC word was found.
 
With some more fiddling around I noticed also that if I load the initial bitstream through JTAG instead of allowing it to come from the SPI flash, the same happens. The initial configuration runs fine, but the SPI flash never gets accessed to get the next bitstream and no reconfiguration happens. The boot sequence fed to the ICAP defines the new bootmode to be SPI, so I would have theoretically expected this to work and load the next bitstream from the SPI flash.
 
In both cases power cycling the FPGA of course restores normal operation and the two bitstreams are again able to load each other, but I was wondering is there a more "civilized", non disruptive,  way to make the JTAG access (either just for reading the status register or optimally even for loading the initial bitstream).

抱歉，上面复制粘贴的代码中至少有一个错误。
icap_enable序列之间有一些1'b1。
这些应该自然是1'b0。
无论如何修复这个并没有改变我观察到的行为。
另外我注意到，在JTAG上加载了什么比特流，多引导之后，状态寄存器显示错误标志，因为没有找到SYNC字。
如果我通过JTAG读取状态寄存器，即使非多引导配置正在运行，也是如此。
第一次读取显示SYNC找到，第二次读取始终显示未找到SYNC。
因此，看起来JTAG访问会使配置逻辑处于某种不愉快的状态。
有没有办法清除或重置配置逻辑状态？



以下为原文

Sorry there was still at least one mistake in the code I copy-pasted above. There are some 1'b1 in between the icap_enable sequeces. These should naturally be 1'b0. Anyway fixing this did not change the behaviour I was observing. Additionally I noticed that after loading what ever bitstreams over the JTAG, multibooting or not, the status register shows the error flag for not finding the SYNC word. Same if I read the status register over JTAG even when a non multibooting configuration is running. The first read shows SYNC found, a second read always showed no SYNC found. So it would seem the JTAG access leaves the configuration logic in some unhappy state. Is there a way to clear or reset the configuration logic state?