同时计数倒计时操作的系统设计

编写每种方法的示例并比较合成结果不应该花费很长时间。
我的猜测是，一个好的合成器会提出一个相当优化的解决方案
不管你如何编码。
在FPGA中要记住的一件事是LUT的成本是相同的，无论它是“满”的逻辑还是
用作简单的逆变器，因此不同的编码风格不太可能最终
非常不同的脚印。
事实上，当你试图用门来优化某些东西时，
你最终可以在FPGA中占用更大的空间（更多的LUT，每个LUT的逻辑更少）。
对于像Spartan 6这样的一些较新的架构，LUT也比它更“昂贵”
寄存器，因为片中每个LUT有两个寄存器。
所以使用LUT作为逆变器
避免使用寄存器不是一个很好的权衡。
另一方面，在完整实施中
其中计数器的输出在内部用于FPGA，输出反转可以
进入使用它的逻辑 - 所以“逆变器”实际上消失了。
玩的开心，
的Gabor
-  Gabor



以下为原文

It shouldn't take long to code up examples of each method and compare the synthesis results.
My guess would be that a good synthesizer would come up with a fairly optimum solution
regardless of how you code it.
 
One thing to remember in FPGA's is that a LUT costs the same whether it is "full" of logic or
used as a simple inverter, so it's not likely that the different coding styles will end up with
very different footprints.  In fact often when you try to optimize something in terms of gates,
you can end up with a larger footprint in the FPGA (more LUT's with less logic per LUT).
 
Also for some of the newer architectures like Spartan 6, LUT's are more "expensive" than
registers since there are two registers per LUT in the slice.  So using LUT's as inverters
to avoid using registers is not a good trade-off.  On the other hand, in a full implementation
where the output of counters is used internally to the FPGA, the output inversion can
get rolled into the logic that uses it - so the "inverters" actually disappear.
 
Have fun,
 
Gabor
-- Gabor

嗨，我知道你建议我使用另一个计数器，所以首先，我使用大型系统中的计数器，没有引脚连接到IO焊盘。
因此，计数器（CB8CLED）应该被实例化为virtex II中的宏（我使用原理图条目），包括8个FFD，17个mux，16个xor和8个逆变器，所以你认为这是最佳方式！



以下为原文

Hi,
I understand that you advice me to use another counter, so firstly, I used the counters within a large system and no pin is connected to the IO pads. Hence a counter (CB8CLED) should be instantiated as a macro in virtex II (I use the schematic entry) witch consist to 8 FFD, 17 mux, 16 xor and 8 inverters so do you think that this is the optimal way!

没有使用原理图捕获是最佳的！
------------------------------------------“如果它不起作用
模拟，它不会在板上工作。“



以下为原文

Nothing using schematic capture is optimal!

------------------------------------------
"If it don't work in simulation, it won't work on the board."

基本上，我尝试消耗较少的资源百分比，所以我相信可以在PAR步骤中优化实现，否则原理图捕获和hdl设计之间有什么区别？



以下为原文

Basically, I try to consume the less percentage of resources, so I believe that is possible to optimize the implementation during PAR step, otherwise what’s the difference between the schematic capture and hdl design?

Schematic Capture中使用的库元素已针对独立进行了预优化
使用。
它们由预先放置的基元组成，后端无法进一步优化
工具。
当您使用HDL时，合成器可以看到设计的连通性
它决定使用哪些原语。
这样可以更轻松地提出最佳选择
更高层次的设计。
无论如何，对资源产生最大影响的地方
useage在输入（HDL或原理图），在Map中有一些有限的优化
相。
PAR不会对资源使用进行任何进一步优化。
-  Gabor
-  Gabor



以下为原文

The library elements used in Schematic Capture have been pre-optimised for standalone
use.  They consist of pre-placed primitives that can't be further optimised by the back-end
tools.  When you use HDL, the synthesizer has a view of the connectivity of the design as
it decides which primitives to use.  This makes it easier to come up with an optimal
design at a higher level.  In any case, the place to have the greatest impact on resource
useage is at the input (HDL or schematic), with some limited optimization in the Map
phase.  PAR does not apply any further optimization in resource usage.
 
-- Gabor
-- Gabor

belkacem8086写道：
基本上，我尝试消耗较少的资源百分比，所以我相信可以在PAR步骤中优化实现，否则原理图捕获和hdl设计之间有什么区别？
哦，对于初学者来说，HDL之所以获胜，是因为它易于理解设计，跨设备系列的可移植性，与源代码控制系统的兼容性（与您的原理图分开！）以及每个人的最爱：当原理图格式被弃用时，您不会被击败。
----------------------------是的，我这样做是为了谋生。



以下为原文

belkacem8086 wrote:
Basically, I try to consume the less percentage of resources, so I believe that is possible to optimize the implementation during PAR step, otherwise what’s the difference between the schematic capture and hdl design?

Oh, for starters, HDL wins due to ease of understanding the design, portability across device families, compatibility with source-code control systems (go diff your schematic!) and everyone's favorite: you're not fscked when the schematic format is deprecated.
----------------------------Yes, I do this for a living.