Verilog 中 4 对 1 函数的高效综合
我需要在 Veriog 中实现 4 对 1 函数。 输入为 4 位,即 0-15 之间的数字。 输出是单个位,0 或 1。每个输入给出不同的输出,并且从输入到输出的映射是已知的,但输入和输出本身未知。 我希望 vcs 能够成功优化代码,并使其尽可能短/简洁。 到目前为止我的解决方案:
wire [3:0] a;
wire b;
wire [15:0] c;
assign c = 16'b0100110010111010; //for example but could be any constant
assign b = c[a];
必须声明 c 很丑陋,我不知道 vcs 是否会识别那里的 K-map。 这是否与 case 语句或连接范式的作业一样有效?
I need to implement a 4-to-1 function in Veriog. The input is 4 bits, a number from 0-15. The output is a single bit, 0 or 1. Each input gives a different output and the mapping from inputs to outputs is known, but the inputs and outputs themselves are not. I want vcs to successfully optimizing the code and also have it be as short/neat as possible. My solution so far:
wire [3:0] a;
wire b;
wire [15:0] c;
assign c = 16'b0100110010111010; //for example but could be any constant
assign b = c[a];
Having to declare c is ugly and I don't know if vcs will recognize the K-map there. Will this work as well as a case statement or an assignment in conjunctive normal form?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
显然我使用的是一个糟糕的合成工具。 :-) 我刚刚综合了两个版本(只是使用基于线延迟扇出的模型的模块),问题中的索引版本给出了比 case 语句更好的时序和面积结果。 使用 Synopsys DC Z-2007.03-SP。
Apparently I am using a lousy synthesis tool. :-) I just synthesized both versions (just the module using a model based on fan-outs for wire delays) and the indexing version from the question gave better timing and area results than the case statements. Using Synopsys DC Z-2007.03-SP.
对于这样的事情,RTL 清晰度远远胜过一切。 SystemVerilog 有特殊的always 块指令,以明确该块何时应综合为组合逻辑、锁存器或触发器(如果您编写的 RTL 与该指令相冲突,您的综合工具应抛出错误(例如,不包括另请注意,该工具可能会用最有效的硬件编码(最小化整个设计面积的编码)替换您拥有的任何编码,除非编码本身传播到引脚。 。
这个建议也是一般性的,让你的代码易于人类理解,并且对于综合工具来说也可能更容易理解,这使得它能够更有效地从字面上带来 如果您愿意,您还可以使用三元运算符进行数千人年的算法研究,
但我更喜欢以下内容:
For things like this, RTL clarity trumps all by a wide margin. SystemVerilog has special always block directives to make it clear when the block should synthesize to combinational logic, latches, or flops (and your synthesis tool should throw an error if you've written RTL that conflicts with that (e.g. not including all signals in the sensitivity list of an always block). Also be aware that the tool will probably replace whatever encoding you have with the most hardware-efficient encoding (the one that minimizes the area of your total design), unless the encoding itself propagates out to the pins of your top-level module.
This advice goes in general, as well. Make your code easy to understand by humans, and it will probably be more understandable to the synthesis tool as well, which allows it to more effectively bring literally thousands of man-years of algorithms research to bear on your RTL.
You can also code it using ternary operators if you like, but i'd prefer something like:
我的偏好 - 如果它对您的问题有意义 - 是使用枚举或“定义”的 case 语句。 任何能让代码审查、维护和验证变得更容易的事情。
My preference - if it makes sense for your problem - is for a case statement that makes use of enums or `defines. Anything to make code review, maintenance and verification easier.
我完全同意达拉斯的观点。 使用案例陈述 - 它使您的意图更加清晰。 综合工具会将其构建为查找表(如果它是并行的),并将尽可能优化。
另外,我不会太担心 RTL 代码是否简短。 为了清晰起见,我会先拍摄。 合成工具比你想象的更聪明......
I totally agree with Dallas. Use a case statement - it makes your intent clearer. The synthesis tool will build it as a look-up table (if it's parallel) and will optimise whatever it can.
Also, I wouldn't worry so much about keeping your RTL code short. I'd shoot for clarity first. Synthesis tools are cleverer than you think...
你拥有的很好。 案例陈述也同样有效。 这只是您希望如何表达的问题。
如果选择的编码没有任何特殊含义(例如内存地址选择器),您的解决方案索引可以正常工作。 如果选择的编码对设计者来说确实有一些特殊的语义意义(并且没有太多),那么就使用 case 语句和枚举。
就合成而言,使用哪一种并不重要。 任何像样的综合工具都会产生相同的结果。
What you have is fine. A case statement would also work equally well. It's just a matter of how expressive you wish to be.
Your solution, indexing, works fine if the select encodings don't have any special meaning (a memory address selector for example). If the select encodings do have some special semantic meaning to you the designer (and there aren't too many of them), then go with a case statement and enums.
Synthesis wise, it doesn't matter which one you use. Any decent synthesis tool will produce the same result.