修改已实施的网表而无需重新合成？

它可以做到，但它很复杂。
注意：对于那些阅读下面的人来说，这是一个危险的领域 - 这不是一个“正常”的事情，只有在真正有充分理由的情况下才能进行，并且没有其他方法可以完成你需要的东西。
。
Vivado中有许多用于修改设计的机制。
一种方法是使用“create_cell”，“connect_net”等命令的整个“ECO（工程变更单）”机制......这些非常复杂，并不是最简单的方法来做你想要的。
更简单的方法是修改现有单元格的属性。
例如，所有触发器都具有INIT值，该值指定在比特流下载之后触发器包含的值。
假设您有一个可以读取的触发器，没有显式复位，那么只要设计打开就可以更改INIT值。
然后将该值置于比特流中，并且将是比特流下载之后的触发器的初始值。
set_property INIT [get_cells]
但更大的问题是“你在流程中做到了这一点”。
这取决于您使用的流量。
在非项目模式下，设计始终保留在内存中。
完成route_design或最终的phys_opt_design后，设计将在内存中并准备生成比特流。
此时（可能是在写入检查点之后），您将运行write_bitstream来生成第一个比特流。
在此之后，您可以更改INIT属性的值，然后您可以简单地使用更改的值写入新的比特流。
这只需要几秒钟。
在项目模式下，它有点复杂 - 没有办法通过项目模式机制这样做。
因此，您需要做的是正常运行实现阶段（和比特流生成阶段） - 这将创建一个比特流。
现在您需要将该设计加载到内存中 - 这可以通过打开实现的设计来完成。
通过内存中的设计，您现在可以更改属性。
但是没有办法“拯救”这个;
从这一点来说，您有责任管理当前在内存中的这种新的修改设计。
据推测，你唯一想做的就是写出第二个比特流，但这必须用非项目模式“write_bitstream”命令完成 - 而不是通过用于生成比特流的GUI机制。
Avrum



以下为原文

It can be done, but it is complicated.
 
NOTE: For those reading below, this is dangerous territory - this is not a "normal" thing to do, and should only be undertaken if there is a really really good reason, and there is no other way of accomplishing what you need...
 
There are a number of mechanisms in Vivado for modifying a design. One way is the whole "ECO (engineering change order)" mechanism using commands like "create_cell", "connect_net", etc... These are very complex and not the easiest way to do what you want.
 
A simpler way is to modify a property of an existing cell. For example, all flip-flops have an INIT value, which specifies what value the flip-flop contains after the bitstream download. Assuming you have a flip-flop that you can read, that has no explicit reset, then you can change the INIT value whenever the design is open. This value will then be placed in the bitstream, and will be the initial value of the flip-flop after bitstream download.
 
set_property INIT [get_cells ]
 
But the bigger question is "where in the flow do you do this". This depends on what flow you use.
 
In non-project mode, the design remains in memory at all times. After you have completed route_design or the final phys_opt_design, the design is in memory and ready to generate a bitstream. At this point (presumably after writing a checkpoint) you would run write_bitstream to generated your first bitstream. After this, you could change the value of the INIT property and then you could simply write a new bitstream with the changed value. This would take only seconds.
 
In project mode it is a little more complicated - there is no way to do this through the project mode mechanism. So what you would have to do is run through the implementation phase (and bitstream generation phase) normally - this would create one bitstream. Now you need to load that design into memory - this is done by opening the implemented design. With the design in memory, you can now change the property. But there is no way to "save" this; from this point it is your responsibility to manage this new modified design that is currently in memory. Presumably the only thing you would want to do is write out the second bitstream, but this will have to be done with the non-project mode "write_bitstream" command - not through the GUI mechanism for generating a bitstream.
 
Avrum

谢谢Avrum！



以下为原文

thanks Avrum!

我们处理这个的方法是使用块ram而不是单个位。
我知道这听起来很浪费。
对我们来说，我们有完全相同的问题 - 但我们有一个4位的版本寄存器，而不是你的一位的情况。
我们想要突破我们的“版本”注册 - 但必须经历一个多小时的重新实现。
（这完全在ISE 10.xx时间范围内）。
我们通过将四位更改为单个BLOCK RAM进行调整。
是4位到18位是相当大的增长。
但通常在FPGA中有一个备用块ram  - 你通常可以慢速计时，以便轻松实现QoR。
通过使用块RAM  -  Xilinx具有跟踪BLOCK RAM内容的方法 - 后期实现。
请注意，ISE中的工具 - 虽然klunky（data2mem / bmm） - 更灵活。
Vivado中的工具不够灵活（updatemem / mmi），但可以使其工作。
我们已经与Xilinx就这个工具进行了很多（仍在进行中）讨论。
您会发现它具有另外的18Kbits（或后者FPGA系列中的36K位）RAM“刮擦”空间的灵活性。
我们最终在这里添加了更多信息 - 除了我们的“版本” - 这非常有帮助。
像修订控制信息，谁建立设计，何时，在什么机器上，以及一些参数化信息的东西。
问候，
标记



以下为原文

 
The way we handle this is to use a block ram instead of a single bit.  I know that sounds wasteful.  For us, we had the EXACT same issues - but we had a version register which was 4 bits, instead of your case of one-bit.
 
We wanted to just bump our "version" register - but had to sit through a many hour reimplemenation. (This was all in the ISE 10.xx timeframe). 
 
We adjusted by changing our four bits to a single BLOCK RAM.  Yes 4 bits to 18 Kbits is quite a growth.  But often there's a spare block ram sitting around in your FPGA - and you can usually clock it slow to allow easy implementation QoR.
 
By using a block RAM - Xilinx has methods of chainging the contents of a BLOCK RAM - post implementation.  Note that the tools in ISE - while klunky (data2mem/bmm) - were much more flexible.  The tools in Vivado aren't as flexible (updatemem/mmi), but can be made to work.  We've had many (still ongoing) discussions with Xilinx on this tool de-featuring....
 
You'll find that it's kind of flexible in having another 18Kbits (or 36Kbits in the latter FPGA families) of RAM "scratch" space to play with.  We ended up adding a lot more information here - in addition to our "version" - that's quite helpful.  Stuff like revision control info, who built the design, when, on what machine, as well as some parameterization info.
 
Regards,
 
Mark

我还想指出它也可以使用分布式RAM来完成，分布式RAM要便宜得多 - 例如16个LUT可以为你提供16x64的存储空间，并且比块RAM便宜得多。
但是，它有点复杂，因为分布式RAM是一位宽 - 所以在分布式RAM中放置一个“字”数据需要你重新分片数据 - 一个LUTRAM的INIT数据是所有的最低有效位
RAM中有64个字;
下一个LUTRAM包含所有64个字的位“1”的64位...
在过去的某个时刻，我想出了一个重新切片的Tcl脚本（所以我知道可以做到）。
Avrum



以下为原文

I also want to point out that it can also be done using distributed RAM, which is far cheaper - for example 16 LUTs can give you a 16x64 space for storing stuff, and is much cheaper than a block RAM. However, it is a bit more complicated since distributed RAMs are one bit wide - so putting a "word" of data in the distributed RAM requires you to re-slice the data - the INIT data for one LUTRAM is the least significant bits of all 64 words in the RAM; the next LUTRAM contains the 64 bits which are bit "1" of all 64 words...
 
At some point in the past I came up with a Tcl script that did the re-slicing (so I know it can be done).
 
Avrum