Virtex-5中的Microblaze和Capture-Restore过程出现问题

米克尔，
我宁愿使用BUGFMUX或BUFGCE来停止MicroBlaze时钟。
在重置期间或重启期间，重置DCM可能会导致未知的时钟行为。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mikel,
 
I would rather use the BUGFMUX or BUFGCE to stop the MicroBlaze clock.
 
Resetting the DCM may be causing unknown clock behavior either during the reset, or during the restart.
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

谢谢Lesea先生的建议。
我已经在DCM之后放置了一个BUFGCE缓冲区，现在我停止使用此缓冲区向设计输入。
（我不得不降低设计频率，因为DCM和BUFGCE之间的距离在我的主板Virtex-5板上有很长的松弛）
无论如何，在捕获 - 恢复过程之后，停止的设计（包括微型激光）仍然被破坏。
我对任何其他建议持开放态度，我真的不知道哪个可能是失败的根源。
谢谢。
米克尔A-a



以下为原文

Thank you Mr. Lesea for your advice.
 
I've placed a BUFGCE buffer after the DCM and now I stop the feeding to the design with this buffer.
(I had to reduce the frequency of the design because the distance between the DCMs and the BUFGCE had a long slack in my board Virtex-5 board)
 
Anyway the stopped design (including a microblaze) is still corrupted after the capture-restore process.
 
I'm open to any other suggestion, I really don't know which can be the source of the failure.
 
Thanks.
Mikel A-a

麦克风，
你如何控制BUFCE？
CE信号必须与时钟同步。
另外，如何控制捕获和后续恢复？
你在捕获和恢复之间做了什么？
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mike,
 
How do you control the BUFCE?  The CE signal must be synchronous with the clock.
 
Also, how to you control the capture, and the subsequent restore?
 
What do you do inbetween the capture, and the restore?
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

我通过另一个具有自定义外设的Microblaze生成的信号控制BUFGCE的CE（使用另一个时钟，并且在复位时默认停止BUFGCE）。
我已经证实它实际上停止了设计。
第二个Microblaze在同一个FPGA中，但我认为它在恢复后会被破坏（我在恢复后将其重置在外部）。
我有第二个FPGA：（1）产生捕获信号，（2）产生恢复信号，（3）重置第二个Microblaze以使其恢复到已知状态。
在捕获和恢复之间我使用第二个Microblaze进行一些处理，我可以私下给你更多细节。
再次感谢，
米克尔A-a



以下为原文

I control the CE of the BUFGCE with a signal generated through another Microblaze with a custom peripheral (with another clock and it stops the BUFGCE by default at reset). I had verified that it actually stops the design. The second Microblaze is in the same FPGA, but I assume that it get corrupted after the restore (I reset it externally after the restore).
 
I have a second FPGA that: (1) generates the capture signal, (2) generates the restore signal, and (3) resets the second Microblaze to bring it back to a known state.
 
Between the capture and the restore I do some processing with the second Microblaze, I can give you more details privately.
 
Thanks again,
Mikel A-a

一个，
这里的关键点是CE的控制必须是同步的，并在正确的时间到达（并在正确的时间离开）。
从另一个Microblaze控制它意味着CE信号从gpio路由到控制点，我怀疑这条路径没有足够的约束。
如果CE信号的保持时间不足，并且稍晚到达，则BUFGCE会出现毛刺，从而提供额外的小边缘。
有些元素会看到这个故障和切换，而有些则不会。
我认为这是“轮子脱落”的地方，也是问题的原因：第一次捕获捕获垃圾。
要测试这个理论，不要进行捕获和恢复，而只是启动和停止时钟。
如果Microbalze将停止，并且干​​净地启动，那么CE的时间不是问题（将问题切换成较小的东西来验证）。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

a,
 
The key point here is that the control of the CE must be synchronous, and arrive at the right time (and leave at the right time).
 
Controlling it from another Microblaze means that the CE signal is routed from the gpio to the control point, and I suspect that this path is not constrained well enough.

If the CE signal has insufficient hold time, and arrives just a little late, the BUFGCE will glitch, providing small extra edges.  Some elements will see this glitch and switch, while others won't.  I think this is where the "wheels fall off" and is the cause of the probolem:  the first capture captures garbage.

To test this theoory, do not do the capture and restore, but just start and stop the clocks.  If the Microbalze(s) will stop, and start, cleanly, then the timing of the CE is not the problem (cut the problem into smaller things to verify).
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

我做了你提到的检查：
测试a）如果我没有产生捕获信号，则设计在每次恢复时复位（FF捕获值是比特流的原点 - >复位）。
但经过一些恢复后它仍然失败。
测试b）如果我没有生成存储信号，则没有问题。
我认为可能的失败来源是：
1）当我捕获时，设计（或设计的一部分）尚未停止。
2）在捕获和恢复之间，设计（或设计的一部分）改变它们的状态。
但是在观察测试中的行为（a）之后我会丢弃失败源（1）和（2），因为在这个测试中捕获值与捕获瞬间和捕获与恢复之间的状态变化无关。
所以我想我必须调试depper，你的意思是通过切割问题？
你会建议我采取哪种策略？
谢谢，
米克尔A-a



以下为原文

I have done the check you mentioned:
 
test a) If I do not generate the capture signal, the design resets at every restore (FF capture values are the originals of the bitstream -> reset). But it still fails after some restores.
 
test b) If I do not generate the restore signal, there is no problem.
 
I think the possible failure sources are:
 
1) When I do capture, the design (or parts of the design) is not stopped yet.
 
2) Between the capture and the restore the design (or parts of the design) change their state.
 
But after watching the behavior in test (a) I would discard failure sources (1) and (2), becase in this test the capture values are independant of the capture instant and the state change between the capture and the restore.
 
So I guess I will have to debug depper, what you mean by cutting the problem?
Which strategy would you suggest me?
 
Thanks,
 
 
Mikel A-a

米克尔，
我建议我们寻找未存储在CLB DFF中的内容（这是唯一被捕获和恢复的内容）。
例如，如果LUT用作LUTRAM或SRL（它可能在MicroBlaze中），那么捕获不会将LUT内容捕获到某个安全的地方。
如果在捕获和恢复之间更改LUT，则所有投注都将关闭。
BRAM也是如此：捕获无法将BRAM内容恢复到原来的状态。
你想要完成什么？
您是否尝试过捕获，然后进行验证（对文件impact.bin，impact.rbd进行回读）？
在捕获时钟停止验证之前，时钟停止后和捕获后验证，...恢复后验证？
在每个步骤检查部件正在对其所有位执行的操作可能会向您显示问题的根源。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mikel,
 
I propose we look for what isn't stored in the CLB DFF (which is the only thing that is captured, and restored).

For example, if the LUT is used as a LUTRAM, or SRL (which it probably is in MicroBlaze), then capture does nothing to capture the LUT contents to someplace safe.  If the LUT is changed between the capture and restore, then all bets are off.
 
The same is true of BRAM:  capture does nothing to restore BRAM contents to what they were.
 
What is it you are trying to accomplish?  Have you tried a capture, and then a verify (which does a readback to the file impact.bin, impact.rbd)?  Before capture clock stoped verify, after clock stopped and after capture verify, ... after restore verify?
 
Checking what the part is doing with all of its bits at each step may show you the source of the problem.
 
Austin Lesea
Principal Engineer
Xilinx San Jose

当你说要进行验证时，你的意思是与使用影响的执行并行执行，我是对的吗？
我不知道这是可能的，但这是个好主意。
然后比较之前和之后的“verifygenerated”回读文件并查看差异。
听起来非常好。
谢谢！
米克尔A-a



以下为原文

When you say to do a verify, you mean to do it in parallel to the execution using impact, am I right? I didn't know this was possible, but it is a great idea. Then compare the "verify generated" readback files before and after and look for the differences. It sounds very nice.
 
Thank you!
Mikel A-a

米克尔，
是的，我建议使用带有Impact的JTAG电缆。
验证会检查内存，您可以忽略它。
它还将回读数据放在名为impact.bin（二进制）和impact.rbd（ASCII 1和0）的文件中。
您可以在设备运行时随时验证（回读），并了解如果正在写入BRAM，则JTAG读取将发生干扰（如果两者发生冲突，可能会损坏值）。
由于在回读处理该字的同一时刻读取或写入BRAM的极不可能，因此失败的概率很小，但不是零。
您可能需要三次回读才能确保没有碰撞。
验证将报告配置中不应该改变（静态）的位，这些位实际上已经从初始编程改变了它们的值。
有一个.msk文件，用于屏蔽这些动态位（LUTRAM，SRL，BRAM）。
因此，您无法使用验证报告来发现这些动态位，但您可以观察包含所有数据的impack.bin文件。
.msk文件还会告诉您有多少“允许更改”位。
这种逆向工程有时非常痛苦，因为我们不容易做到（比特流格式，映射是专有的）但在尝试解决问题时完全“合法”（通过合法，我的意思是我们可能不支持
或鼓励使用它，但它不是限制使用工具，每个人都这样做，以发现他们的设计正在发生的事情，当然）。
“diff”命令和二进制文件编辑器（以十六进制或二进制显示）是用于查找更改位的有用工具，然后发现它们发生变化的原因（它们是什么）。
例如，使用LUTRAM或SRL的测试设计将显示它们在比特流中的外观。
并且，如果您将SRL 101010 ..移入其中，则在移位后很容易观察到010101 ..等等。
这些测试设计必须完全相同，因此FPGA_editor用于修改设计的第一个版本，更改那一个，然后创建一个新的bistream进行测试。
上述技能被称为“比特流黑客”，对于那些奇怪的，无法解释的行为很有用。
同样，比特流黑客攻击不是Xilinx支持的流程，所以不要费心向Xilinx寻求任何帮助：我已经说过的是我们所做的全部工作（帮助人们调试奇怪的问题）。
了解，你正在做什么设计，非常奇怪，不寻常，并接近FPGA设计的“极限运动”类别......即使你看起来很简单。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mikel,

Yes, I was suggesting the use of the JTAG cable with Impact.  A verify does a check of the memory, which you chould ignore.  It also places the readback data in a file called impact.bin (binary) and impact.rbd (ASCII 1 and 0).
 
You may verify (readback) at any time while the device is running, with the understanding that if the BRAM is being written to, the JTAG read will interfere (could corrupt a value if the two collide).  Since it is extremely unlikely that a value is being read, or written in the BRAM at the same moment that word is being addressed by the readback, the probability of failure is small, but not zero.  You may have to readback three times to be sure nothing collided.
 
The verify will report bits in the configuration that are not supposed the change (static) that have in fact changed their values from the initial programming.  There is a .msk file which is used to mask out these dynamic bits (LUTRAM, SRL, BRAM).  So you can't use the verify report to discover these dynamic bits, but you can observe the impack.bin file which has all the data.  The .msk file also tells you how many of these "allowed to change" bits there are.
 
This sort of reverse engineering is sometimes quite painful, as we do not make it easy to do (the bitstream format, mapping is proprietary) but is perfectly 'legal' when trying to fix a problem (by legal, I mean we may not support or encourage its use, but it is not a restricted use of the tools, and everyone does this to discover what is going on in their designs, as a matter of course).
 
The "diff" command, and a binary file editor (that displays things in hex or binary) are useful tools for finding the bits that change, and then discovering why they change (what they are).  For example, a test design with a LUTRAM or SRL will show you what they look like in the bitstream.  And, if you shift the SRL once with 101010.. in it, it is easily observed after the shift to be 010101.. and so on.  These test designs have to be identical, so FPGA_editor is used to modify the first version of the design, to change that one thing, and then create a new bistream to test.
 
The skill described above is known as "bitstream hacking" and is useful for those odd, unexplained behaviors.  Again, bitstream hacking is not a Xilinx supported flow, so do not bother to ask Xilinx for any help:  what I have already said is the full extent of what we do (to help folks debug odd issues).
 
Understand, what you are doing with your design, is quite odd, and unusual, and borders on the "extreme sport" category of FPGA designs...even though it may seem like somethign very simple to you.
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

再次感谢您，特别是有关如何调试问题的所有细节以及您的热情！
:)
我无法在我的Virtex-5 LX110T芯片上找到影响的“验证”选项（对于其他板都没有尝试）。
无论如何，我认为问题不是对LUTRAM或SRL原始值的破坏：只有在存储信号被置位时才会出现故障，因此，我认为，它必须与IOB或CLB寄存器相关。
我意识到了一件大事：改变我停止设计的方式DCM到BUFGCE设计失败的方式也发生了变化。
使用DCM时，只有Microblaze因BUFGCE而损坏，其他硬件也会损坏。
米克尔A-a



以下为原文

Thank you again, specially for all the details about how to debug the problem and your passion doing so! :)
 
I'm not able to find a "Verify" option on impact for my Virtex-5 LX110T chip (neither for other boards are tryed).
 
Anyway I believe that the problem is not a corruption on LUTRAM or SRL primitive values: failures only come up when the restore signal is asserted, therefore, I think, it must be related to IOB or CLB registers.
 
I realized about a wierd thing: changing the way I stop the design DCM to BUFGCE the way the design fails also changes. With the DCM only the Microblaze went corrupted with the BUFGCE also other hardware pieces go corrupted.
Mikel A-a

设置需要设置的环境变量以启用验证。
如果你想获得所有东西，那么忽略掩码文件是个好主意。
如果你不想涉及数千个无关紧要的位，那么掩码文件最好保持启用状态。
设置XIL_IMPACT_VIRTEX_DUMPBIN = 1set XIL_IMPACT_IGNORE_MASK_FILE = 1
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Set the enviroment variables that needs to be set to enable the verify.
 
If you wish to get everything, then ignoring the mask file is a good idea.  If you don't wish to wade through thousands of bits that do not matter, then the mask file is a good idea to leave enabled.
 
set XIL_IMPACT_VIRTEX_DUMPBIN=1
set XIL_IMPACT_IGNORE_MASK_FILE=1
Austin Lesea
Principal Engineer
Xilinx San Jose

在恢复之前和之后，我没有看到使用冲击中的验证功能在停止的设计区域中有任何差异。
但是从冲击中获得的回读文件中有一些奇怪的东西：验证是正确完成的，但是这些位的结构是8位，具有相同的值。
整个回读文件由“00000000”和“11111111”系列构成。
这是正常的吗？我担心我会因此而失去解决方案......
米克尔A-a



以下为原文

I don't see any difference in the stopped design area before and after the restore using the verify feature in impact.
 
But there is something bizarre in the readback file obtained from impact: the verify is done correctly but the bits are structured in sets of 8 bits with the same value. The whole readback file is built by series of "00000000"s and "11111111"s. Is this normal? I'm afraid I'm loosing resolution with this effect...
Mikel A-a

我想我发现了这个问题：
当连续执行两次捕获时（设计中的时钟停止），每个回读都会显示设计区域的一些差异。
似乎捕获本身改变了停止设计的状态。
捕获信号在外部生成，不会跨越任何逻辑或寄存器从输入缓冲区到CAMTURE_VIRTEX5原语（我已经用FPGA编辑器对此进行了验证）。
为什么捕获信号的断言会改变停止设计的状态？
任何想法？
我假设第一次捕获后回读文件发生了变化：捕获使用新的寄存器值内容更新比特流内容。
但为什么第二次不同呢？
寄存器值相同，因为设计已停止。
我已经验证了没有捕获的双读数，并且回读文件是等于的;
我可以保证设计实际上已停止。
米克尔A-a



以下为原文

I think I found the problem:
 
When performing two captures in a row (with the clock in the design stopped) the readback of each of them show some differences on the design area. It seems that the capture itself changes the state of the stopped design.  The capture signal is generated externally, and do not cross any logic or register from the input buffer to the CAPTURE_VIRTEX5 primitive (I've verified this with FPGA editor).
 
Why the assertion of the capture signal changes the state of the stopped design? any idea?
 
I assume that the readback file changed after the first capture: the capture updates the bitstream content with new register value contents. But why the second time is it different? The register values are the same because the design is stopped.
 
I've verified the double reading without a capture and the readback files are equals; I can assure that the design is actually stopped.
Mikel A-a

米克尔，
Capture获取DFF的内容，并将其写回配置存储单元（位），该单元包含DFF的起始值（默认情况下通常为0）。
这个是正常的。
如果回读捕获时钟停止的每个DFF的状态，然后当重新启动时钟时，事情应运行正常。
如果时钟停止，则执行捕获，然后执行恢复，重新启动时钟，然后事情也应该起作用。
每次在捕获后停止时钟时，回读文件可能会有所不同，因为状态可能会在时钟滴答时不断变化。
最后一个想法：你使用DCM吗？
如果这样做，则无法停止DCM的时钟。
时钟丢失后，必须重置DCM，并且必须等待锁定，然后才能恢复。
如果您的设计中有DCM，请将其取出。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mikel,

Capture takes the contents of the DFF, and writesd it back into a configuration memory cell (bit) that contains the starting value for the DFF (usually a 0 by default).
 
This is normal.
 
If a readback captures the sate of each DFF whiel the clock is stopped, and then when the clock is restarted, things should run fine.
 
If the clock is stopped, a capture is performed, and then a restore is performed, clock restarted, then things should also work.

The readback files may be different each time you stop the clock after a capture, as the state may be constantly changing while the clock is ticking.

One final thought:  do you use a DCM?  If you do, you can not stop the clock to the DCM.  Once the clock is lost, the DCM must be reset, and you must wait for lock, before resuming.
 
If there is a DCM in your design, take it out.
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

我按照你的建议，但使用DCM或BUFGCE（同步命令信号）同样失败。
我在上一篇文章中的含义是，在同一状态内的两个连续捕获事件（时钟提醒已停止）会产生两个不同的回读文件。
我无法找到更改背后的特定组件，因为回读文件是“11111111”和“00000000”的系列，没有单个位更改是整个比特流而是8位的块。
你以前见过这样的吗？
我的影响验证功能是否正常？
米克尔A-a



以下为原文

I followed your piece of advice, but with DCM or with BUFGCE (with syncronous command signal) fails similarly.
 
What I meant in the previous post is that two consecutive capture event within the same state (clock remining stopped) produce two different readback files. I'm not able to locate the specific component behind the change because the readback file is a serie of "11111111"s and "00000000"s, there is not a single bit change is the whole bitstream but blocks of 8 bits. Did you seen anything like this before? Is my impact-verify feature working fine?
 
 
 
Mikel A-a

米克尔，
您可以在停止时钟时在回读文件之间执行“diff”，在某些事件（如捕获）之后执行另一次回读，然后在其他事件（如还原）之后再执行一次“diff”。
差异将识别那些改变的位。
我停止了时钟，唯一应该改变的位是用于预测捕获的位。
因此，文件1 readback =时钟停止，然后捕获
文件2 =捕获后
文件3 =恢复后（仍然没有时钟）
预期结果：文件1文件2（它们应该相差几百个DFF捕获状态或更少）。
文件2 =文件3（恢复后捕获的数据应自行匹配）。
是的，我认为验证（回读）工作得很好。
.rbd文件是回读的ascii版本（impact.rbd），可能更容易可视化（ascii 30hex = 0，ascii 31hex = 1）。
每次停止时钟时，回读都会有所不同（因为它运行的机器正在改变用作SRL和LUTRAM的所有查找表）。
在时钟停止后，第一次捕获后，在您再次启动时钟之前不会发生任何变化。
哦，当时钟运行时，BRAM内容也可能会发生变化。
没有掩码文件，您会看到每一位，动态和静态。
使用掩码文件，您将看不到BRAM，LUTRAM，SRL或捕获位！
（无论如何，所有比特流回读都是相同的）。
如果在时钟停止时事情发生变化，那么在第一次捕获之后，就会有一些你认为可以控制的时钟：去寻找它（你错过了控制一堆东西的BUFG ......）。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mikel,
 
You can do a "diff" between the readback file when you stop the clock, and the other readback after some event (like capture), and then again after some other event (like restore).
 
The diff will identify those bits that change.

I expet with the clock stopped, the only bits that should change are the bits that are used to stpre the capture.
 
So, file 1 readback = clock stopped, before capture
file 2 = after capture
file 3 = after restore (still no clock)
 
Expected results: file 1 <> file 2 (they should differ by a few hundred DFF captured states or less).
 
File 2 = file 3 (the captured data should then match itself after a restore).
 
Yes, I think the verify (readback) is working just fine.
 
The .rbd file is the ascii version of the readback (impact.rbd), which might be easier to visualize (ascii 30hex = 0, ascii 31hex =1).
 
Each time you stop the clock, the readback will be different (as the machine whern it runs is changing all the look up tables used as SRL and LUTRAM).  With the clock stopped, after the first capture, nothing should change until you start the clock again.
 
Oh, and while the clock is running BRAM contents may be changing as well.  Without the mask file, you see every bit, dynamic and static.  With the mask file, you won't see BRAM, LUTRAM, SRL or capture bits! (all bitstreams readback will be the same, regardless).
 
If things change when the clock is stopped, after the first capture, then something is being clocked that you thought you had control over:  go find it (you missed a BUFG controlling a bunch of stuff...).
 
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose

你好，
时钟停止时，我执行以下2个过程：
1）捕获 - （验证） - 恢复 - 捕获（验证）。
2）捕获 - （验证） - 捕获 - （验证）。
在两个进程中的捕获事件之后生成的两个回读文件之间，我完全看到了差异，并且仅在BRAM互连列的最后一帧中看到了差异。
这有什么意义吗？
在“.msd”文件中，我看到这些帧中的一些动态内容，但“.ll”文件没有显示任何相关逻辑。
任何想法？
顺便说一句，谢谢Lesea先生，你是非常有帮助的！
米克尔A-a



以下为原文

Hello,
 
I do the following 2 processes while the clock is stopped:
1) capture - (verify) - restore - capture (verify). 
2) capture - (verify) - capture - (verify).
 
Between the two readback files generated after the capture events in the two processes, I see some differences exactly and only in the last frame of the BRAM interconnect columns. Makes this any sense? in the ".msd" file I see some dynamic contents in those frames but the ".ll" file does not show any related logic. Any idea?
 
By the way thank you Mr. Lesea you are being extremelly helpful!
Mikel A-a

米克尔，
通过我的电子邮件将之前和之后的回读文件发送给我：austin@xilinx.com
首先拉上它们
发送.bin文件
我将直接回复您发送电子邮件的内容，这些内容已发生变化。
支持研究人员和客户，当他们想知道“那是做什么的？”时，我没有任何问题。
我总是学到一些我不知道的东西，最终在设计下一个产品系列时帮助我们。
我只需要知道完整的部件号和两个.bin回读文件。
Austin Lesea主要工程师Xilinx San Jose



以下为原文

Mikel,
 
Send the before, and after readback files to me at my email:  austin@xilinx.com

zip them first
 
send the .bin files
 
I will answer you direct to your sending email what those bits are that changed.
 
I have no problem supporting researchers, and customers, when they want to know "what does that bit do?'  I always learn something I did not know, which ends up helping us when we design the next product family.
 
I just need to know the full part number, and the two .bin readback files.
 
 
 
 
Austin Lesea
Principal Engineer
Xilinx San Jose