【 Verilog 】always@（）的敏感源中为什么不能双边沿触发？为什么不能双时钟触发？

57 阅读 0 评论 38 点赞

我是靠谱客的博主个性大米，最近开发中收集的这篇文章主要介绍【 Verilog 】always@（）的敏感源中为什么不能双边沿触发？为什么不能双时钟触发？，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

最近用Verilog HDL设计了一个小电路，一个3分频的电路，用的是我刚接触FPGA时，别人告诉我的思路，没想到今天才发现有大问题？

如下：

module Freq_divide(
	input clk,
	input rst_n,
	output reg clk_divide

    );
	
	wire clk_reverse;
	assign clk_reverse = ~clk;
	
	reg [3:0] count;
	always @ (posedge clk or posedge clk_reverse or negedge rst_n) begin
		if(!rst_n) begin
			count <= 0;
		end
		else if(count < 2) begin
			count <= count + 1;
		end
		else begin
			count <= 0;
		end
	end
	
	always @ (posedge clk or posedge clk_reverse or negedge rst_n) begin
		if(!rst_n) begin
			clk_divide <= 0;
		end
		else if(count == 2) begin
			clk_divide <= ~clk_divide;
		end
		else begin
			clk_divide <= clk_divide;
		end
	
	end
	
	
	
endmodule

这段代码确实是一个反面教材呀，为了偷懒，只是仿真了一下，觉得功能没有问题，还很满意，但是今天偶然的一次机会，我突然想看下RTL电路图，Vivado却报错了？

报错如下：

意思就是我的这句代码有问题：

always @ (posedge clk or posedge clk_reverse or negedge rst_n)

通过这种方式来实现双时钟采样是不对的。

这是问大神的聊天记录：

由对话可以得出信息，我博文标题中的两种方式都是不对的，一种是：

always@(posedge clk or negedge clk)

另一种是：

always@(posedge clk or posedge clk_reverse)

甚至这种也是不对的：

always@(posedge clk or negedge rst_n) begin

a <= 1'b0;

end

因为你没有用rst_n，Verilog会认为你的rst_n也是一个时钟，这又变成和上面两种情况一样的问题了。

这是在Xilinx官网上找到的解答：

[Synth 8-91] ambiguous clock in event control

https://forums.xilinx.com/t5/Welcome-Join/synth-8-91-ambiguous-clk-in-event-control/m-p/724225#M40235

解读的非常漂亮：

Re: [Synth 8-91] ambiguous clock in event control

You have to always remember that you are using Register Transfer Language (RTL) to have the synthesis infer hardware.

您必须始终记住您正在使用寄存器传输语言（RTL）来合成推断硬件。

Verilog HDL can do pretty much anything - the syntax of the always @(<whatever>) is very flexible. However, when you go to synthesize the design, the code has to map to an available piece of hardware on the FPGA.

Verilog HDL几乎可以做任何事情 - always @（<whatever>）的语法非常灵活。但是，当您进行综合设计时，代码必须映射到FPGA上的可用硬件。

On the FPGA we have combinatorial logic (LUTs, MUXes, etc...). These are inferred a variety of ways, including the always @(*) construct.

在FPGA上我们有组合逻辑（LUT，MUX等）。这些是通过各种方式推断出来的，包括always @（*）构造。

In addition we have flip-flops. A flip-flop on an FPGA (and pretty much anywhere else) is a device that has one clock and is sensitive to only one edge of that clock. So, the synthesis tool can only map to this device when the sensitivity list is always @(posedge clk). We have variants of the flip-flop that can do asynchronous preset/clear, so will map to always @(posedge clk or <posedge/negedge> rst), but that's it.

另外我们有触发器。 FPGA（以及其他任何地方）上的触发器是一个具有一个时钟且仅对该时钟的一个边缘敏感的器件。因此，当灵敏度列表始终为@（posedge clk）时，综合工具只能映射到此设备。我们有触发器的变种，可以进行异步预置/清除，因此将映射到始终@（posedge clk或<posedge / negedge> rst），但就是这样。

There is no real hardware device that can do the equivalent of what you are describing - always @(posedge clk or negedge clk).

没有真正的硬件设备可以完成与你所描述的相同的东西 - 总是@（posedge clk or negedge clk）。

The only exception (sort of) are the IDDR and ODDR, and these need to be instantiated - they cannot be inferred from an HDL description.

唯一的例外（种类）是IDDR和ODDR，这些需要实例化 - 它们不能从HDL描述中推断出来。

So, no, this is not synthesizable Verilog.

因此，这不是可以综合的Verilog。

What exactly do you want to do? You want to clock your design at twice the rate of the incoming clock? If so, then use an MMCM to double your clock, and use that new high speed clock to clock your logic....

As for the GTX example design (and I don't know exactly what you are referring to), you have to realize that a whole bunch of different things are written in Verilog

- synthesizable RTL - this must use only the synthesizable portion of Verilog

- testbench code - this can use the entier Verilog HDL language

- models for library cells (see below)

If you are seeing something like always @(posedge clk or negedge clk) it is pretty much guaranteed that it is going to be in one of the last two (testbench code or library cell models) - these are not synthesizable and hence can use the entire Verilog language.

So, what is a library cell model... When we synthesize an RTL design, we end up with a netlist of Xilinx primitive devices. These primitive devices are really the set of transistors that physically exist on the Xilinx die. However, for simulation purposes, we must have simulation models for these cells.

For some cells (like the LUTs), these are pretty simple - the simulation model of the LUT has to perform the same Boolean operations that will end up happening in the LUT on the die (which is a purely digital thing).

For other cells, like the GTX, the silicon is very highly complex sets of analog and digital functionality. To simulate this, Xilinx provides a GTX simulation model that (at least grossly) describes the functionality of the GTX from a digital point of view - things like the PLLs and clock recovery and other stuff is abstracted so that the result mimics the digital functionality of the underlying silicon. In this model, again, the entire Verilog HDL language can be (and is used) to describe the functionality. However, this description is not (and doesn't need to be/shouldn't be) synthesizable...