Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

priority on two asynch triggered events

Status
Not open for further replies.

stanford

Full Member level 2
Joined
Feb 16, 2014
Messages
132
Helped
4
Reputation
8
Reaction score
6
Trophy points
1,298
Activity points
2,223
If we write verilog like this with async set/reset, does the synthesis tool use FF with this priority? (reset has higher priority than enable)

Code:
always @(posedge clk or posedge reset or posedge enable)
begin
    if (reset)
        out <= 1'b0;
    else if (enable)
        out <= 1'b1;
    else
        out <=a & b;
end

================================================================================================

If we were to write the code like this, will the tool use a different FF with enable being the higher priority?

Code:
always @(posedge clk or posedge reset or posedge enable)
begin
    if (enable)
        out <= 1'b0;
    else if (reset)
        out <= 1'b1;
    else
        out <=a & b;
end
 

With if else you are adding a priority code. It does not matter if it is reset or any other signal, with if else you are coding priority.
 

I am a VHDL person, but this looks like bad code that can cause a mismatch between simulation and synthesized hardware.
If you activate both reset and enable, and then release one of them, the simulator will not do anything at the release.
The hardware for the first design (if accepted by the synthesis tool) will change the output from '0' to '1' if both reset and enable are '1', and reset then changes to '0'.
 

I am a VHDL person, but this looks like bad code that can cause a mismatch between simulation and synthesized hardware.
If you activate both reset and enable, and then release one of them, the simulator will not do anything at the release.
The hardware for the first design (if accepted by the synthesis tool) will change the output from '0' to '1' if both reset and enable are '1', and reset then changes to '0'.

I don't think there is any ambiguity here with the code. I was just wondering if we actually do have different libs for FF to take care of multiple async inputs with different priority.

Releasing async set/reset does not trigger the FF anyway.
 

I agree with std_match, there's a potential simulation mismatch with this code, as discussed in previous Edaboard threads, e.g. https://www.edaboard.com/showthread.php?321110-Sensitivity-lists-syntax-in-VHDL-and-Verilog

Hardware synthesis can be expected to follow the known register template and creates asynchronous set and reset function with priority. Deasserting the reset will allow the lower priority set input to take effect if it's already asserted. However in simulation, there's no event created when the reset input is deasserted, due to the fact that the register template doesn't literally correspond to the intended function. (Correct functional simulation would require level sensitive events, but they are accepted by synthesis tools…)

I assume so far that your ASIC synthesis tool can implement the priority of asynchronous inputs correctly. Newer FPGA hardware is often lacking an asynchronous set input and needs to emulate the described logic with latches.
 

I agree with std_match, there's a potential simulation mismatch with this code, as discussed in previous Edaboard threads, e.g. https://www.edaboard.com/showthread.php?321110-Sensitivity-lists-syntax-in-VHDL-and-Verilog

Hardware synthesis can be expected to follow the known register template and creates asynchronous set and reset function with priority. Deasserting the reset will allow the lower priority set input to take effect if it's already asserted. However in simulation, there's no event created when the reset input is deasserted, due to the fact that the register template doesn't literally correspond to the intended function. (Correct functional simulation would require level sensitive events, but they are accepted by synthesis tools…)

I assume so far that your ASIC synthesis tool can implement the priority of asynchronous inputs correctly. Newer FPGA hardware is often lacking an asynchronous set input and needs to emulate the described logic with latches.

Ah I get what you are saying. The FF in the sim will not get triggered because it did not see a posedge on async set.

Then how can we write the code such that this unintended mismatch does not occur? i.e how can we write verilog to have async set/reset input without sim mismatch?
 

You need an internal signal to trigger the process when reset is released while enable is already active. This should work for simulation and also for synthesis:

Code:
assign enable_int = ~reset & enable;

always @(posedge clk or posedge reset or posedge [B]enable_int[/B])
begin
    if (reset)
        out <= 1'b0;
    else if (enable)
        out <= 1'b1;
    else
        out <=a & b;
end
 

Your suggested construct doesn't comply with the synthesizable register template, I doubt that it will be accepted by synthesis tools.

I don't yet recognize a way to avoid the simulation mismatch.
 

I have tried similar code in system verilog (always_ff) with synopsys DC (we have only active low S, R) and the result is S-R FF with correct priority. If it does not work for you, only way I know is to use ifdef on sensitivity list to distinguish between synthesis and simulation.
 

I have tried similar code in system verilog (always_ff) with synopsys DC (we have only active low S, R) and the result is S-R FF with correct priority.
I guess there's a typo in post #7. This construct complies with the register template and should work in functional simulation as well:


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
assign enable_int = ~reset & enable;
 
always @(posedge clk or posedge reset or posedge enable_int)
begin
    if (reset)
        out <= 1'b0;
    else if (enable_int)
        out <= 1'b1;
    else
        out <=a & b;
end

 

No, it is not the typo. I really used it as I wrote in #7.
Originally I wrote it as model and wanted to replace it with cell from the library during the synthesis. But after the synthesis I saw, that DC recognized it properly (no warnings, internal signal removed and enable connected to the set).

I am not sure wether enable_int will be removed during optimization or not when it is used in the condition itself.

I know that it is not in line with the register template, but Verilog/System Verliog don't have an alternative to clock event as VHDL and so I use this as workaround. I also don't know if it will work properly with other tools. It needs to be tested.

As I mentioned, another way might be:
  • You can use `ifdef for sensitivity list to distinguish between synthesis and simulation.
  • Write it into a separate module and replace it with library cell during the synthesis.
 

I agree, that #10 is OK for simulation.
Just for my curiosity, what is the result of synthesis in Quartus? Is the enable directly connected to the Set, or is there also a logic related to enable_int?
 

I checked with Quartus integrated synthesis, as expected the #7 code causes an error:
cannot match operand(s) in the condition to the corresponding edges in the enclosing event control of the always construct

The modified code according to post #10 can be compiled with reasonable gate level implementation, and as far as I understand, won't cause simulation mismatch. In so far it looks like a suitable workaround that strictly keeps the register template.

Another point is, if DC accepts the code in post #7, the behavior should be documented, like the expected register template is described in documentation of other Verilog tools.

- - - Updated - - -

You get this RTL netlist

rtl.png

and post mapping netlist

post-mapping.png

Implementation works only on old FPGA series that have separate asynchronous reset and set, respectively asynchronous load function, e.g. Cyclone I
 

No, it is not the typo. I really used it as I wrote in #7.
Originally I wrote it as model and wanted to replace it with cell from the library during the synthesis. But after the synthesis I saw, that DC recognized it properly (no warnings, internal signal removed and enable connected to the set).

I am not sure wether enable_int will be removed during optimization or not when it is used in the condition itself.

I know that it is not in line with the register template, but Verilog/System Verliog don't have an alternative to clock event as VHDL and so I use this as workaround. I also don't know if it will work properly with other tools. It needs to be tested.

As I mentioned, another way might be:
  • You can use `ifdef for sensitivity list to distinguish between synthesis and simulation.
  • Write it into a separate module and replace it with library cell during the synthesis.

I would consider what is in #7 to be a typo for async
Code:
else if (enable)
as opposed to what is shown in #10
Code:
else if (enable_int)

As I recall back when I worked on ASIC designs we ended up instantiating the SR FF from the library in the design directly (inside a wrapper file, in case we migrated to a different process). We didn't try any tricks with the coding of the reset or set to make both the simulation and the synthesis work the same.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top