cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
18,485 Views
Registered: ‎11-02-2015

[Synth 8-91] ambiguous clock in event control

Jump to solution

Behavioral simulation works without error. 

 

What is this error means?

 

If I am not allowed to use both pos edge and neg edge, How can I perform or build a logic for maximum data rate on hardware? Because GTX example design uses both pos and neg edge to transmit data. 

 

Thank you.

vivado4.PNG
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Guide
Guide
28,805 Views
Registered: ‎01-23-2009

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

 

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.

 

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

 

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.

 

There is no real hardware device that can do the equivalent of what you are describing - always @(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.

 

So, no, this is not synthesizable 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...

 

Avrum

View solution in original post

1 Reply
Highlighted
Guide
Guide
28,806 Views
Registered: ‎01-23-2009

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

 

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.

 

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

 

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.

 

There is no real hardware device that can do the equivalent of what you are describing - always @(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.

 

So, no, this is not synthesizable 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...

 

Avrum

View solution in original post