UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply

Synthesis-simulation mismatch due to type inference

Accepted Solution Solved
Highlighted
Visitor
Posts: 4
Registered: ‎08-11-2017
Accepted Solution

Synthesis-simulation mismatch due to type inference

I have a D flip-flop defined as:

interface Dff#(type T = bit, T init_val = '0)(input wire clk, rst);
T q, d;
bit we;
...
endinterface

init_val is the value the flip-flop should store when reset is asserted.

 

When I instantiate a 36-bit flip-flop as:

Dff#(bit[35:0], 1 << 34) count(CLK, RST);

init_val gets the correct value in simulation (34th bit as 1 and the rest 0). But with synthesis, init_val is 0. (I checked on an LED on an KCU105).

 

If I instead do:

Dff#(bit[35:0], 36'd1 << 34) count(CLK, RST);

Both synthesis and simulation get the correct value. I suspect that synthesis takes the literal value "1" as a 32-bit number and so "1 << 34" ends up being 0. On the other hand, simulation is smart enough to take "1" as a 36-bit number based on its context.

 

I'm not sure whether the bug is in synthesis or simulation. I found a statement in the SystemVerilog standard IEEE Std 1800-2012: "Simple decimal numbers without the size and the base format shall be treated as signed integers". But I don't know what "signed integers" means here.


Accepted Solutions
Scholar
Posts: 908
Registered: ‎09-16-2009

Re: Synthesis-simulation mismatch due to type inference

 

The declarative "integer" never appears in the OP's example.  The type of init_val is bit [35:0], which is NOT an integer.

 

I believe his example could be boiled down to:

 

bit [ 35 : 0 ] init_val_failing = 1 << 34;

bit [ 35 : 0 ] init_val_working = 36'd1 << 34;

 

This gets down to some rather low-level details within (basically) the original verilog language with respect to (unsized) integer literals and operations on them.  I think section 11.8.2 "Steps for evaluating an expression" covers this.

 

I tend to avoid coding like this just to avoid these sorts of questions.  But I believe the standard actually is clear here, and the same value (34th bit as 1 and the rest 0) should be assigned in both cases.

 

I believe this is a Vivado bug, and should be fixed.

 

--Mark

 

View solution in original post


All Replies
Voyager
Posts: 1,636
Registered: ‎06-24-2013

Re: Synthesis-simulation mismatch due to type inference

Hey mehul.tikekar@analog.com

 

You basically did all the work and answered your question already ...

 

In (System) Verilog an integer is 32bit (IIRC), a longint is 64bit and a shortint 16bit.

 

Hope that helps,

Herbert

-------------- Yes, I do this for fun!
Visitor
Posts: 4
Registered: ‎08-11-2017

Re: Synthesis-simulation mismatch due to type inference

But there is still the mismatch with simulation. The two need to be consistent on this (unless the standard has actually left it ambiguous).

Voyager
Posts: 1,636
Registered: ‎06-24-2013

Re: Synthesis-simulation mismatch due to type inference

mehul.tikekar@analog.com,

 

But there is still the mismatch with simulation.

The two need to be consistent on this (unless the standard has actually left it ambiguous).

There are many differences between reality and simulation ...

 

Best,

Herbert

-------------- Yes, I do this for fun!
Scholar
Posts: 908
Registered: ‎09-16-2009

Re: Synthesis-simulation mismatch due to type inference

 

The declarative "integer" never appears in the OP's example.  The type of init_val is bit [35:0], which is NOT an integer.

 

I believe his example could be boiled down to:

 

bit [ 35 : 0 ] init_val_failing = 1 << 34;

bit [ 35 : 0 ] init_val_working = 36'd1 << 34;

 

This gets down to some rather low-level details within (basically) the original verilog language with respect to (unsized) integer literals and operations on them.  I think section 11.8.2 "Steps for evaluating an expression" covers this.

 

I tend to avoid coding like this just to avoid these sorts of questions.  But I believe the standard actually is clear here, and the same value (34th bit as 1 and the rest 0) should be assigned in both cases.

 

I believe this is a Vivado bug, and should be fixed.

 

--Mark