cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sritchie
Visitor
Visitor
2,604 Views
Registered: ‎03-29-2018

VHDL CONSTANT calculations using TIME are correct in Simulation but not in Synthesis

Jump to solution

I have some code which used to work under ISE but doesn't work under Vivado.

I use INTEGERS and TIME types to calculated the size of a Pulse Width Modulation (PWM) register. The calculations are correct when performed by the Modelsim and the Vivado simulator buy are not correct when performed during Synthesis.

CONSTANT CNTR_FREQ      : NATURAL := 250E6;
CONSTANT PWM_FREQ       : NATURAL := 50E3;
CONSTANT CNTR_PER1      : TIME := 1 SEC / CNTR_FREQ;
CONSTANT PWM_PER1       : TIME := 1 SEC / PWM_FREQ;
CONSTANT CNTR_PER2      : REAL := 1.0 / REAL(CNTR_FREQ);
CONSTANT PWM_PER2       : REAL := 1.0 / REAL(PWM_FREQ);
CONSTANT CNTR_MAX1      : NATURAL := INTEGER((PWM_PER1/(CNTR_PER1*4))*2)/2;
CONSTANT CNTR_MAX2      : NATURAL := INTEGER((PWM_PER2/(CNTR_PER2*4.0))*2.0)/2;

CNTR_MAX1 and CNTR MAX2 should return the same number (1250) but when Synthesised CNTR1_MAX returns 63.

Can anyone please explain why the Simulator works correctly but Synthesis does not. Surely they should give the same answer. Both Modelsim and the Xilinx simulators agree.

I have attached a VHDL file that demonstrates this behaviour.

 

1 Solution

Accepted Solutions
richardhead
Scholar
Scholar
2,597 Views
Registered: ‎08-01-2012
8 Replies
richardhead
Scholar
Scholar
2,598 Views
Registered: ‎08-01-2012
sritchie
Visitor
Visitor
2,580 Views
Registered: ‎03-29-2018

Thanks Richard.

One of the previous posts pointed out that UG901 states TIME is not supported in Vivado so, as someone else said, it would have been preferrable at the very least if Vivado generated a warning to alert the user of the potential Synthesis impact rather than soldier on as if nothing is wrong.

0 Kudos
dpaul24
Scholar
Scholar
2,556 Views
Registered: ‎08-07-2014

@sritchie, @richardhead ,

I have only used TIME in testbench VHDL codes only. Worked correctly.

As far as I know TIME is not synth, ISE/Vivado shouldn't matter.

------------FPGA enthusiast------------
Consider giving "Kudos" if you like my answer. Please mark my post "Accept as solution" if my answer has solved your problem

0 Kudos
drjohnsmith
Teacher
Teacher
2,550 Views
Registered: ‎07-09-2009
the poster is saying i think that time is not supported in synthesis
this is correct, you cant synthesise time
<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
richardhead
Scholar
Scholar
2,523 Views
Registered: ‎08-01-2012

The op is only trying to create constants using type time. If you can use the real type, why not time? Other synth tools had no problem, including ise, so it's odd that vivado struggles. As paebbles mentions in one post, is likely to do with the internal representation of the time type being inadequate. 

0 Kudos
brimdavis
Scholar
Scholar
2,510 Views
Registered: ‎04-26-2012

@sritchie  "UG901 states TIME is not supported in Vivado"

That information in UG901 is incorrect and outdated, as I described a couple of years ago in this post:

  https://forums.xilinx.com/t5/Synthesis/Physical-type-TIME-is-broken-in-synthesis-of-Vivado-2015-4/m-p/741295/highlight/true#M20387

Both XST and Vivado support elaboration-time calculations using TIME, but Vivado uses 32 bits for time[1], vs. 64 bits for XST, which can cause various overflow problems with code that used to work in XST ( although I haven't looked to see whether that's exactly what's gone wrong in your specific example.)

Workaround: I would suggest using reals for time and period calculations (as done for CNTR_MAX2 ), which I've found to work in both Xilinx synthesizers.

-Brian

[1]  IIRC the VHDL LRM says somewhere that TIME integer calculations using TIME should be the same precision as INTEGER; so, for a VHDL synthesizer using 32 bit INTEGERs, this implementation is technically correct; but practically speaking, 32 bit TIME values are rather useless for many computation purposes.

The proper response to this problem would have been for Xilinx either to implement an synthesis error/warning message, or switch over to 64 bit INTEGERs.

Given that they've known about the problem since 2013, it appears they have instead chosen to ignore the issue.

 

richardhead
Scholar
Scholar
2,473 Views
Registered: ‎08-01-2012

@brimdavis 

The VHDL LRM 5.2.4.2 Specifies that type time must be a minimum of 32 bits (as is usual with VHDL, 32 bits doesnt actually include -2^31, but -2^31+1), but is implementation dependent and is not linked in anyway to the integer type.

0 Kudos
brimdavis
Scholar
Scholar
2,448 Views
Registered: ‎04-26-2012

@richardhead   "and is not linked in anyway to the integer type."

My understanding of the VHDL-93 standard is that for expressions involving TIME, a 'link' is established in the sections on type conversion and expressions of type "universal_integer", to wit:

IEEE-STD-1076-1993, Section 7.3.5, lines 534-538, allows that the division of two values of a physical type (such as TIME) is a "convertible universal operand" that can be implicitly converted from a "universal integer" to another integer type.

IEEE-STD-1076-1993, Section 7.5, lines 686-688, states that for a "universal expression" of type "universal integer", the operand and result values are limited to the widest integer range provided by the implementation.

That said, I am a VHDL language user, not a VHDL language specification expert, so my interpretation could be wrong.

I have updated my previous post to read "integer calculations using TIME"

-Brian

 

0 Kudos