cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mzabel
Visitor
Visitor
14,033 Views
Registered: ‎03-01-2016

Physical type TIME is broken in synthesis of Vivado 2015.4

Hi all!

 

I have coded a lot of VHDL components which synthesize properly with ISE 14.7 for a Kintex-7 FPGA. But now, I'm migrating to Vivado, and synthesis failes even for simple implementations which use the physical type TIME. I'm using the newest Vivado version 2015.4 up to now.

 

For example, this is the code for a delay line which delays an input X by the generic time DELAY. The design is fully synchronous, and the clock period is specified by the generic CLOCK_PERIOD.

 

library ieee;
use ieee.std_logic_1164.all;

entity delay_line is
  
  generic (
    CLOCK_PERIOD : time := 10 ns;
    DELAY	 : time := 3 us);

  port (
    clock : in	std_logic;
    x	  : in	std_logic;
    q	  : out std_logic);

end entity delay_line;

architecture rtl of delay_line is
  -- With the default values of the generics, this should evaluate to 300.
  constant STEPS : natural := DELAY / CLOCK_PERIOD;

  -- Delay input with shift register.
  signal shift_reg : std_logic_vector(STEPS-1 downto 0) := (others => '0'); -- THIS IS LINE 22
  
begin  -- architecture rtl
  process (clock) is
  begin
    if rising_edge(clock) then
      -- shift from left to right, delayed value will be in top-most bit
      shift_reg <= shift_reg(STEPS-2 downto 0) & x; -- THIS IS LINE 29
    end if;
  end process;

  q <= shift_reg(STEPS-1);
end architecture rtl;

The above synthesizes without error and warnings in ISE 14.7: a shift register with 300 flip-flops is detected. But, when using Vivado 2015.4, synthesis reports the following errors:

 

WARNING: [Synth 8-3919] null assignment ignored [/home/zabel/delay_line/delay_line.vhdl:22]
ERROR: [Synth 8-421] mismatched array sizes in rhs and lhs of assignment [/home/zabel/delay_line.vhdl:29]

 

I have annoted the line numbers in the code above. The error messages make no sense because STEPS should be evaluated to 300.

 

To track the error down, I have splitted the entity into two entities: "delay_line2" and "shift_reg". The first calculates the number of steps required, the second implements the shift register part. Here is the code:

 

library ieee;
use ieee.std_logic_1164.all;

entity delay_line2 is
  
  generic (
    CLOCK_PERIOD : time := 10 ns;
    DELAY	 : time := 3 us);

  port (
    clock : in	std_logic;
    x	  : in	std_logic;
    q	  : out std_logic);

end entity delay_line2;

architecture rtl of delay_line2 is
  -- With the default values of the generics, this should evaluate to 300.
  constant STEPS : natural := DELAY / CLOCK_PERIOD;

begin
  -- instantiate shift register for debugging
  shift_register_1: entity work.shift_register
    generic map (
      STEPS => STEPS)
    port map (
      clock => clock,
      x	    => x,
      q	    => q);
  
end architecture rtl;
library ieee;
use ieee.std_logic_1164.all;

entity shift_register is
  
  generic (
    STEPS : integer);

  port (
    clock : in    std_logic;
    x      : in    std_logic;
    q      : out std_logic);

end entity shift_register;

architecture rtl of shift_register is
  -- Delay input with shift register.
  signal shift_reg : std_logic_vector(STEPS-1 downto 0) := (others => '0');
  
begin  -- architecture rtl
  process (clock) is
  begin
    if rising_edge(clock) then
      -- shift from left to right, delayed value will be in top-most bit
      shift_reg <= shift_reg(STEPS-2 downto 0) & x;
    end if;
  end process;

  q <= shift_reg(STEPS-1);
end architecture rtl;

Again, this code is synthesized properly with ISE 14.7 but fails on Vivado 2015.4 with the same error as above. But, what we can see now from the Vivado synthesis report is, that the calculation of STEPS is broken:

 

Parameter STEPS bound to: 0 - type: integer

 

It seems that the internal representation of the time literals is broken, because both synthesis reports (for "delay_line" and "delay_line") list:

 

Parameter CLOCK_PERIOD bound to: 32'b00000000100110001001011010000000
Parameter DELAY bound to: 32'b00000000000000000000000000000011

 

The binary value of CLOCK_PERIOD represents the decimal number 10'000'000 which equals the position number of 10 ns with the primary unit of 1 fs for the physical type time.

 

The binary value of DELAY represents the decimal number 3 which is just wrong! If I change the generic DELAY to 30000 ns (= 30 us), then synthesis reports:

 

    Parameter DELAY bound to: 32'b11111100001000111010110000000000
WARNING: [Synth 8-3512] assigned value '-6' out of range [/home/zabel/delay_line/delay_line2.vhdl:19]

 

The binary value of DELAY now corresponds to an unsigned decimal 4230196224 or a signed decimal -64771072. Boths are wrong! The parameter STEPS is bound to -6 which is wrong too!

 

Be warned: if you set, DELAY to 30000 ns, then synthesis requires 16 GB of memory.

 

Can someone confirm this bug?

Tags (3)
28 Replies
mzabel
Visitor
Visitor
14,024 Views
Registered: ‎03-01-2016

Addendum: If I set DELAY to 3000 ns which would match the original setup, then I had to cancel synthesis after 5 mins because it consumed up to 35 GB (!) of virtual memory. The partial synthesis log contains the lines:

 

INFO: [Synth 8-638] synthesizing module 'delay_line2' [/home/zabel/delay_line/delay_line2.vhdl:17]
    Parameter CLOCK_PERIOD bound to: 32'b00000000100110001001011010000000
    Parameter DELAY bound to: 32'b10110010110100000101111000000000
WARNING: [Synth 8-3512] assigned value '-129' out of range [/home/zabel/delay_line/delay_line2.vhdl:19]
INFO: [Synth 8-638] synthesizing module 'shift_register' [/home/zabel/delay_line/shift_reg.vhdl:16]
    Parameter STEPS bound to: 2147483519 - type: integer
tcmalloc: large alloc 17179869184 bytes == 0x11174000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed86bf7ba
tcmalloc: large alloc 17179869184 bytes == 0x442da8000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed7de84f7
tcmalloc: large alloc 17179869184 bytes == 0x442da8000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed7de84f7
tcmalloc: large alloc 17179869184 bytes == 0x442da8000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed7de84f7
tcmalloc: large alloc 2147483648 bytes == 0x2bbc30000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed87c38de
tcmalloc: large alloc 2147483648 bytes == 0xd423c000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed87c38de
tcmalloc: large alloc 8589934592 bytes == 0x197304000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed878a9d4 0x7f6f027e9700
tcmalloc: large alloc 8589934592 bytes == 0x442da8000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed87816cc
tcmalloc: large alloc 8589934592 bytes == 0x642da8000 @  0x7f6f03c0c456 0x7f6f03c30399 0x7f6ed8780e62 0x17fffff7f 0x7f6f027e9700
./ISEWrap.sh: line 51:  4543 Killed                  $ISE_STEP "$@" >> $HD_LOG 2>&1

 

As you see, the parameter STEPS was bound to a very high integer value (2147483519) and, thus, synthesis tried generate a very large shift register instead of just 300 flip-flops as expected.

achutha
Xilinx Employee
Xilinx Employee
12,537 Views
Registered: ‎07-01-2010

@mzabel

 

I appreciate your effort in giving the detailed explanation on the issue. Both the issues discussed are bugs in Vivado Synthesis.

 

I will verify this  and will update you on the change request details.

 

Regards,

Achutha

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful and reply oriented.
----------------------------------------------------------------------------------------
0 Kudos
paebbels
Explorer
Explorer
10,663 Views
Registered: ‎04-24-2014

Are there any updates on this bug?

0 Kudos
muzaffer
Teacher
Teacher
10,644 Views
Registered: ‎03-31-2012

did you try it with 2016.1 ?
- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
paebbels
Explorer
Explorer
10,644 Views
Registered: ‎04-24-2014

No still the same ...

 

The bug was accepted circa 1 week before the 2016.1 release. And of cause its not fixed in that version, yet.

0 Kudos
luca.cremona
Visitor
Visitor
10,219 Views
Registered: ‎06-07-2016

I've got the same problem, trying to syntesize the OpenRISC on a Sakura board with a Spartan 6.

I'm using Vivado 2016.1

The final part of the log is that:

 

Start Technology Mapping
---------------------------------------------------------------------------------
tcmalloc: large alloc 3145121792 bytes == 0x379708000 @  0x7f3fac3f6456 0x7f3fac41a399 0x7f3f7d752583 0xf3a4d80
tcmalloc: large alloc 2282119168 bytes == 0x25b2a6000 @  0x7f3fac3f6456 0x7f3fac41a399 0x7f3f7d77419f
tcmalloc: large alloc 3423174656 bytes == 0x379708000 @  0x7f3fac3f6456 0x7f3fac41a399 0x7f3f7d78c460
/home/luca/Xilinx/Vivado/2016.1/bin/loader: riga 164:  2779 Ucciso                  "$RDI_PROG" "$@"
Parent process (pid 2779) has died. This helper process will now exit

0 Kudos
paebbels
Explorer
Explorer
10,208 Views
Registered: ‎04-24-2014

You cannot synthesize for Spartan-6 with Vivado. It supports only 7-Series devices and newer. You need to use ISE 14.7, which supports physical types.

0 Kudos
luca.cremona
Visitor
Visitor
10,203 Views
Registered: ‎06-07-2016

I tried to do it with ISE 14.7 but I got the same result.

The RAM of my laptop (16 GB) gets filled by ISE synthesis process.

I'm trying to synthesize the basic version of the OpenRISC OrpSoC v2

 

Any idea about that?

 

Luca 

0 Kudos
paebbels
Explorer
Explorer
10,198 Views
Registered: ‎04-24-2014

No, sorry. You should contact the OpenRISC community.

0 Kudos
mzabel
Visitor
Visitor
9,834 Views
Registered: ‎03-01-2016

Just to know, the corresponding answer record can be found here:

http://www.xilinx.com/support/answers/57964.html

 

 

0 Kudos
paebbels
Explorer
Explorer
8,727 Views
Registered: ‎04-24-2014

Dear Xilinx,

 

are there any news on the issue?

4 months have passed by and Vivado got 2 new versions without a bugfix, since we reported this bug....

0 Kudos
muzaffer
Teacher
Teacher
8,717 Views
Registered: ‎03-31-2012

do you have a verified SR (service request) with a CR (change request) attached to it for this bug? If yes, you might have some expectation of when this might be addressed. If not, you are out of luck.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
paebbels
Explorer
Explorer
8,712 Views
Registered: ‎04-24-2014

If Xilinx would offer an interface to submit service requests, I would submit all my bug report in this form rather then writing posts in a forum... buying full licenses for Xilinx tools does not seam to be enough to get support except from this forum.

 

As I wrote in my last posts here in the forum, I can create many issues in the Vivado tool chain. If you can grant me better access to the support, I willing to provide lots of test cases and narrowed down explanations what's going wrong in the tools.

paebbels
Explorer
Explorer
6,874 Views
Registered: ‎04-24-2014

Does Vivado 2016.3 fix this issue?
The new release note don't contain detailed bugfix notes anymore ...

0 Kudos
brouhaha
Explorer
Explorer
6,561 Views
Registered: ‎08-14-2007

It's still broken in Vivado 2016.4.  Spent about two hours trying to figure out why I was getting the null assignment warnings and logic optimized out.  Ugh.

paebbels
Explorer
Explorer
6,550 Views
Registered: ‎04-24-2014

Thank you brouhaha. I don't believe in Xilinx bug fixing since years. I have supplied a long list of bugs but they are not interested in a good product.
0 Kudos
anusheel
Moderator
Moderator
6,485 Views
Registered: ‎07-21-2014

@brouhaha

 

As mentioned in UG901, TIME data type will be ignored in synthesis phase.

UG901.PNG

I am checking internally if Vivado can generate a warning message for the same and I will update this thread.

 

@paebbels

I have sent you an email regarding old synthesis issues and service requests.

 

Thanks,
Anusheel
-----------------------------------------------------------------------------------------------
Search for documents/answer records related to your device and tool before posting query on forums.
Search related forums and make sure your query is not repeated.

Please mark the post as an answer "Accept as solution" in case it helps to resolve your query.
Helpful answer -> Give Kudos
-----------------------------------------------------------------------------------------------

 

 

 

brimdavis
Scholar
Scholar
6,459 Views
Registered: ‎04-26-2012

@anusheel  "As mentioned in UG901, TIME data type will be ignored in synthesis phase."

 

The information in UG901, copied [1] from the XST manual, is inaccurate and outdated for both XST 14.7 and current Vivado synthesis.

 

Both synthesizers support calculations using TIME, but Vivado uses a 32 bit integer type instead of a 64 bit integer as did XST 14.7.

 

So TIME is not ignored as you claim above, but is in fact silently synthesized incorrectly in Vivado due to this change in precision!

 

Although Xilinx was notified of this problem  two years  ago, Xilinx has done nothing to fix the synthesizer or the documentation, other than the publication of AR57964

 

EDIT 1 (CORRECTION): The creation date of AR57964 is 10/15/2013, so Xilinx has known about this issue, and done nothing to fix it, for over three years.

 

EDIT 2 : clarified XST version (14.7) supporting TIME calculations

-Brian

 

[1] XST => Vivado manual copying

time_xst_vs_vivado.png

0 Kudos
paebbels
Explorer
Explorer
6,429 Views
Registered: ‎04-24-2014

@brimdavis

It's correct that XST 14.5 doesn't support type time, but it was fixed in the latest XST release 14.7 to work correctly.

 

@anusheel

It's no good policy of Xilinx to removed features or edit documentation afterwards and then claim that users are requesting a new feature. I new 2 cases where Xilinx did this:

1. The report and assert statements got removed in Vivado 2014 and reintroduced as a brand new feature in 2016.

2. After a Xilinx ship was shipped for months, Xilinx altered the switching guide because the FPGA had timing issues.

 

I also want to remember that Xilinx noted several years ago, that the physical type bug is related to a false implementation of assert statements (that why they got removed from the feature set). But after reintroducing assert statements, I can reproduce the same synthesis bugs as with the old assert statement implementation. So we can summarize the bug was not related to assert statements.

 

Sometimes Xilinx writes that physical types or type time is not synthesizable, that correct, but it does not mean not usable in synthesis. Type REAL is also not synthesizable, but usable in synthesis to calculate constants. Btw. all your competitors support physical types in synthesis!

 

Kind regards

    Patrick

0 Kudos
brimdavis
Scholar
Scholar
4,385 Views
Registered: ‎04-26-2012

@paebbels "It's correct that XST 14.5 doesn't support type time, but it was fixed in the latest XST release 14.7 to work correctly."

 

 I've updated my post to clarify that XST version 14.7 supported TIME calculations.

 

 My point was that Xilinx never updated the XST manual to reflect this late addition to XST, so when they 'documented' Vivado language support by copying the XST manual , the documentation error persisted, and is now being erroneously quoted by Xilinx employees.

 

 Also, since TIME was a late addition to XST, there should have been new testcases added to the XST synthesis regression suite to validate the TIME support; one would expect that Xilinx would then run these same XST tests against Vivado, which should have exposed this synthesis regression early on in Vivado development.

 

"Xilinx noted several years ago, that the physical type bug is related to a false implementation of assert statements"

 

  I think the 01-19-2015 post, on this thread, to which you are referring to might simply have been noting your use of INTEGER'image in the assert printing the TIME result.

 

-Brian

paebbels
Explorer
Explorer
1,688 Views
Registered: ‎04-24-2014

Seems like Vivado 2019.2 is going to fix that bug that was working in Xilinx ISE until 2013 ...

From Xilinx Vivado 2019.2 release notes:

brimdavis
Scholar
Scholar
1,650 Views
Registered: ‎04-26-2012

@paebbels   "Seems like Vivado 2019.2 is going to fix that bug that was working in Xilinx ISE until 2013"

At a quick look, TIME calculations in Vivado 2019.2 now appear to match ISE 14.7 XST, other than the <still annoying> omission of TIME'IMAGE

Below are my summary of the synthesis logs [results.txt] , and the test case code [test_time_calc.vhd]:

-Brian

[results.txt]

 

===============================================================
ISE 14.7 XST  : passes all tests *AND* TIME'IMAGE works

Elaborating entity <test_time_calc> (architecture <synth1>) from library <work>.
Note: "TIME calculation tests: "
Note: "  tc1 = 1000"
Note: "  tc2 = 10000"
Note: "  tc3 = 40000"
Note: "  tc4 = 12500000 fs"
Note: "  tc5 = 12500000 fs"
Note: "  tc6 = 2147483"
Note: "  tc7 = 2147484"
Note: "  tc8 = 9223372"


===============================================================
Vivado 2019.2 : TIME'IMAGE is still broken, but TIME calculations now appear to match ISE 14.7

---------------------------------------------------------------------------------
Starting Synthesize : Time (s): cpu = 00:00:05 ; elapsed = 00:00:05 . Memory (MB): peak = 684.512 ; gain = 247.113
---------------------------------------------------------------------------------
INFO: [Synth 8-638] synthesizing module 'test_time_calc' [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:50]
INFO: [Synth 8-63] RTL assertion: "TIME calculation tests: " [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:108]
INFO: [Synth 8-63] RTL assertion: "  tc1 = 1000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:110]
INFO: [Synth 8-63] RTL assertion: "  tc2 = 10000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:113]
INFO: [Synth 8-63] RTL assertion: "  tc3 = 40000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:116]
WARNING: [Synth 8-26] 'image of non-integer, non-enum type not implemented [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:119]
INFO: [Synth 8-63] RTL assertion: "  tc4 = <complex-type>" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:119]
INFO: [Synth 8-63] RTL assertion: "  tc4 = 12500000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:120]
WARNING: [Synth 8-26] 'image of non-integer, non-enum type not implemented [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:123]
INFO: [Synth 8-63] RTL assertion: "  tc5 = <complex-type>" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:123]
INFO: [Synth 8-63] RTL assertion: "  tc5 = 12500000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:124]
INFO: [Synth 8-63] RTL assertion: "  tc6 = 2147483" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:127]
INFO: [Synth 8-63] RTL assertion: "  tc7 = 2147484" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:130]
INFO: [Synth 8-63] RTL assertion: "  tc8 = 9223372" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:133]
INFO: [Synth 8-256] done synthesizing module 'test_time_calc' (1#1) [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:50]


===============================================================
Vivado 2016.4 : fails tests 2,3,7,8; TIME'IMAGE not supported

INFO: [Synth 8-638] synthesizing module 'test_time_calc' [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:50]
WARNING: [Synth 8-3512] assigned value '-29' out of range [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:66]

INFO: [Synth 8-63] RTL assertion: "TIME calculation tests: " [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:108]

INFO: [Synth 8-63] RTL assertion: "  tc1 = 1000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:110]

INFO: [Synth 8-63] RTL assertion: "  tc2 = 0" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:113]
WARNING: [Synth 8-63] RTL assertion: "  tc2 calculation error!" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:114]

INFO: [Synth 8-63] RTL assertion: "  tc3 = 2147483619" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:116]
WARNING: [Synth 8-63] RTL assertion: "  tc3 calculation error!" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:117]

WARNING: [Synth 8-26] 'image of non-integer, non-enum type not implemented [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:119]
INFO: [Synth 8-63] RTL assertion: "  tc4 = <complex-type>" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:119]

INFO: [Synth 8-63] RTL assertion: "  tc4 = 12500000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:120]
WARNING: [Synth 8-26] 'image of non-integer, non-enum type not implemented [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:123]
INFO: [Synth 8-63] RTL assertion: "  tc5 = <complex-type>" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:123]
INFO: [Synth 8-63] RTL assertion: "  tc5 = 12500000" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:124]

INFO: [Synth 8-63] RTL assertion: "  tc6 = 2147483" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:127]

INFO: [Synth 8-63] RTL assertion: "  tc7 = -2147483" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:130]
WARNING: [Synth 8-63] RTL assertion: "  tc7 calculation error!" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:131]

INFO: [Synth 8-63] RTL assertion: "  tc8 = 633437" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:133]
WARNING: [Synth 8-63] RTL assertion: "  tc8 calculation error!" [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:134]

INFO: [Synth 8-256] done synthesizing module 'test_time_calc' (1#1) [C:/Projects/vivado_tests/test_time_calc/test_time_calc.vhd:50]

[test_time_calc.vhd]

--
-- test_time_calc.vhd
--
--
--  Example to illustrate TIME synthesis regressions going from XST 14.7 to Vivado Synthesis 2016.4
--
--    - TIME'IMAGE not supported by Vivado (useful for assertions to check calculation results)
--
--    - TIME calculations in XST 14.7 use a 64 bit signed integer type
--    - TIME calculations in Vivado 2016.4 use a 32 bit signed integer type
--
--    => this causes TIME calculations that worked in XST to fail (often silently) in Vivado
--
--
-- Rationale for the use of TIME in synthesis:
--
--   TIME calculations can be used for various elaboration-time computations, such as
--  initializing a watchdog timer or baudrate generator; the counter length and counter 
--  preload value can be computed from the clock period and desired time interval.
--
--
-- Workaround:
--
--   Vivado supports elaboration-time computations using the REAL datatype; expressions
--   using REAL periods or frequencies can be used as a substitute for TIME calculations.
--
--
-- Related AR and forum threads:
--    https://www.xilinx.com/support/answers/57964.html
--    https://forums.xilinx.com/t5/Synthesis/Vivado-Synth-Bug-in-handling-physical-types/m-p/557049
--    https://forums.xilinx.com/t5/Synthesis/More-bugs-in-Vivado-s-VHDL-synthesizer/m-p/644045
--    https://forums.xilinx.com/t5/Synthesis/Physical-type-TIME-is-broken-in-synthesis-of-Vivado-2015-4/td-p/684711
--    https://forums.xilinx.com/t5/Synthesis/Vivado-incorrect-time-calculation/td-p/740073
--

library ieee;
  use ieee.std_logic_1164.all;
  use ieee.numeric_std.all;
 
  
entity test_time_calc is
  port 
  (
    in1  : in  std_logic;
    out1 : out std_logic
  );

end;

architecture synth1 of test_time_calc is

  --
  -- tc1,2 test examples are from this forum thread:
  --  https://forums.xilinx.com/t5/Synthesis/Vivado-incorrect-time-calculation/td-p/740073
  --
  constant tc1          : natural := 1 ms /  1 us;
  constant tc1_expected : natural := 1000;

  constant tc2          : natural := 100 us / 10 ns;
  constant tc2_expected : natural := 10000;


  --
  -- tc3: test from AR57964
  --
  constant tc3          : natural := 1000000 ns / 25 ns ;
  constant tc3_expected : natural := 40000;

  --
  -- tc4,5: test real operations on time 
  --   https://forums.xilinx.com/t5/Synthesis/Vivado-Synth-Bug-in-handling-physical-types/m-p/557049
  --
  constant tc4          : time := 25000 ps / 2.0 ;
  constant tc4_expected : time := 12500 ps;

  constant tc5          : time := 25000 ps * 0.5 ;
  constant tc5_expected : time := 12500 ps;


  --
  -- The following tests check for 32 bit or 64 bit math as described by paebbels on this thread:
  --    https://forums.xilinx.com/t5/Synthesis/Vivado-Synth-Bug-in-handling-physical-types/m-p/557049
  --

  --
  -- tc6: test intermediate value just below 2^31 (when expressed in fs units)
  --
  constant tc6          : integer := 2147483 ps / 1 ps ;
  constant tc6_expected : integer := 2147483;


  --
  -- tc7: test intermediate value just above 2^31 (when expressed in fs units)
  --
  constant tc7          : integer := 2147484 ps / 1 ps ;
  constant tc7_expected : integer := 2147484;


  --
  -- tc8: test intermediate value just below 2^63 (when expressed in fs units)
  --
  constant tc8          : integer := 9223372 ms / 1 ms ;
  constant tc8_expected : integer := 9223372;


begin

  assert FALSE report "TIME calculation tests: " severity note;

  assert FALSE report "  tc1 = " & natural'image(tc1) severity note;
  assert tc1 = tc1_expected report "  tc1 calculation error!"  severity warning;

  assert FALSE report "  tc2 = " & natural'image(tc2) severity note;
  assert tc2 = tc2_expected report "  tc2 calculation error!" severity warning;

  assert FALSE report "  tc3 = " & natural'image(tc3) severity note;
  assert tc3 = tc3_expected report "  tc3 calculation error!" severity warning;

  assert FALSE report "  tc4 = " & time'image(tc4) severity note;
  assert FALSE report "  tc4 = " & integer'image(integer(time'pos(tc4))) severity note;
  assert tc4 = tc4_expected report "  tc4 calculation error!" severity warning;

  assert FALSE report "  tc5 = " & time'image(tc5) severity note;
  assert FALSE report "  tc5 = " & integer'image(integer(time'pos(tc5))) severity note;
  assert tc5 = tc5_expected report "  tc5 calculation error!" severity warning;

  assert FALSE report "  tc6 = " & integer'image(tc6) severity note;
  assert tc6 = tc6_expected report "  tc6 calculation error!" severity warning;

  assert FALSE report "  tc7 = " & integer'image(tc7) severity note;
  assert tc7 = tc7_expected report "  tc7 calculation error!" severity warning;

  assert FALSE report "  tc8 = " & integer'image(tc8) severity note;
  assert tc8 = tc8_expected report "  tc8 calculation error!" severity warning;
                                         

  out1  <= in1;

end;

 

0 Kudos
pulim
Xilinx Employee
Xilinx Employee
1,614 Views
Registered: ‎02-16-2014

Hi @brimdavis 

I tested TIME'image usecase at my end and reported this to development team to get it fixed.

 

Thanks,

Manusha

paebbels
Explorer
Explorer
1,594 Views
Registered: ‎04-24-2014

@pulim Has only type TIME be changed to 64 bits or has Vivado changed all integer values to 64 bits as defined by VHDL-2019?

I know that Vivado already supports some VHDL-2019 features. This this change for TIME another new feature?

Is there any list of VHDL-2019 features?

 

0 Kudos
richardhead
Scholar
Scholar
1,580 Views
Registered: ‎08-01-2012

I know that Vivado already supports some VHDL-2019 features

Really? Can you elaborate which ones you know about? struggling for 2008 support!

0 Kudos
paebbels
Explorer
Explorer
1,558 Views
Registered: ‎04-24-2014

Hi,

the feature is described in LCS-2016-019. It allows the user to infere constraints of constrained types from initial values. Such values can also be generated by functions. This feature is already of VHDL-2008, but only for constants. Now it's allowed for signals and variables too.

Kind regards

   Patrick Lehmann

 

0 Kudos
pulim
Xilinx Employee
Xilinx Employee
1,491 Views
Registered: ‎02-16-2014

Hi @paebbels 

 

Only TIME datatype is changed to 64-bits

 

Thanks,

Manusha

0 Kudos
paebbels
Explorer
Explorer
1,468 Views
Registered: ‎04-24-2014

@pulim 

I did further tests ...

  • to_string(10 ns) gives an error.
    In general to_string(...) seems to have problems. In many cases to_string is just an alternative for type'image(...).
  • time'image(...) is not displayed correctly.
0 Kudos