怎么改进使用过多多路复用器的设计

对于基于结构的寄存器，常见的优化是具有“影子RAM” - 通常是块RAM  -
它包含最近写入的寄存器值的副本。
然后阅读寄存器，你的
多路复用器默认为这个“影子RAM”，除非读回可以在外部改变的数据
只读位或寄存器位，否则可以在处理器范围之外进行更改。
在大多数系统中，这会相当多地减少多路复用器输入的数量。
将寄存器分组
只读或有其他原因不使用影子RAM有帮助。
另一件需要考虑的事情是Block RAM和分布式RAM都有更长的Q时序
比织物人字拖鞋。
如果您能负担得起，在这些RAM之后添加管道阶段会有很大帮助
额外的延迟周期。
在许多情况下，你将一些不真实的东西多路复用
每个周期都会发生变化（如寄存器），因此额外的延迟几乎没有问题。
-  Gabor
-  Gabor



以下为原文

For fabric-based registers, a common optimization is to have a "shadow RAM" - usually a block RAM -
that holds a copy of the most recently written value of the registers.  Then to read the registers, your
multiplexer defaults to this "shadow RAM' unless reading back data that can change externally like
read-only bits, or register bits that can otherwise be changed outside the scope of the processor.
In most systems, this reduces the number of mux inputs by quite a bit.  Grouping together registers
that are read-only or have other reasons not to use shadow RAM helps.
 
Another thing to consider is that block RAM and distributed RAM both have longer clock to Q timing
than fabric flip-flops.  Adding a pipeline stage after these RAMs helps immensely if you can afford
the extra cycle of latency.  In many cases you are multiplexing together some things that don't really
change on every cycle (like registers) so the extra latency is of little or no concern.
 
-- Gabor
-- Gabor

谢谢Gabor，这给了我很多思考。
我做了一些非常有用的改进
- 使可写硬件寄存器只写。
（换句话说，保持可写寄存器值的记录工作是软件问题而不是硬件问题，从而减小了读取端多路复用器树的大小）
- 将所有可写寄存器的更新流水线化到CPU写入之后的循环（在CPU写入后将可写寄存器多路复用器树移动到时钟周期）
- 维护所有传入硬件信号的本地寄存器副本（在CPU读取之前将传入路由延迟移至时钟周期）
您是否知道将单独的SRAM块有效组合到单个地址空间的技巧？
我使用CORE向导配置SRAM块。
当向导将多个SRAM块连接到更大的存储器时，它似乎使用专用的路由资源而不是通用多路复用器，因此结果几乎与单个块一样快。
但有时我需要配置单独的块块（可能是因为端口B侧的连接不同），然后将它们连接在一起，形成端口A侧的单个地址空间。
当我在VDHL中执行此操作时，会与多路复用器建立连接，这会引入时序延迟。
无论如何使用端口A侧的专用资源将SRAM块链接在一起，但是能够为端口B侧的不同块指定不同的连接，以及为不同的块使用不同的COE初始化文件？



以下为原文

Thanks Gabor, this has given me much food for thought.
 
I made some quite helpful improvements by
 
-- making writable hardware registers write only.  (In other words the job of record keeping the values of the writable registers is made a software problem rather than a hardware problem, thus reducing the size of the multiplexer tree on the read side)
 
-- pipelining the update of all writable registers to the cycle following the CPU write (moves the writable register multiplexer tree to the clock cycle after the CPU write)
 
-- maintaining local register copies of all incoming hardware signals (moves the incoming routing delays to the clock cycle before the CPU read)
 
Do you know any trick for combining separate SRAM blocks into a single address space efficiently?  I configure my SRAM blocks with the CORE wizard.  When the wizard connects multiple SRAM blocks into larger piece of memory it seems to use dedicated routing resources rather than general purpose multiplexers so that the result is almost as fast as if it were a single block.   However sometimes I need to configure separate chunks of SRAM (perhaps because of different connections on the port B side) and then connect them together into a single address space on the port A side.  When I do this in VDHL the connections are made with multiplexers and this introduces timing delays.
 
Is there anyway to link SRAM blocks together using the dedicated resources on the port A side, yet be able to speicify different connections for different block on the port B side as well as use different COE initialization files for different blocks?