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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
10,106 Views
Registered: ‎04-24-2014

Vivado Synth - Bug in handling physical types

XST is/was a fine tool. In it's last version 14.7 it lerned to handle user defined physical types (UDPT). I tried to use my physical types library in Vivado 2014.4, but found masses of bugs. I investigated physical types in Synth and found that not only user definded physical types are implemented in a false and faulty way, but also the predefined type TIME!

 

This posts concentrates on:

  • decimal literals in physical types
  • attributes of physical types
  • operations with physical types, incl. comparisions
  • value ranges of physical types

1. Synth can't read decimal literals in physical types

 

Here is my example code:

library IEEE;
use     IEEE.STD_LOGIC_1164.ALL;

entity Top_PhysicalTest_Simple is
  Port (
    Clock : in STD_LOGIC;
    Input : in STD_LOGIC;
    Output : out STD_LOGIC
  );
end;

architecture top of Top_PhysicalTest_Simple is
  constant time_1    : TIME     := 1 ns;
  constant time_2    : TIME     := 1.0 ns;

begin
  assert FALSE report "1  - time_1 (1 ns):        " & TIME'image(time_1) severity note;
  assert FALSE report "2  - time_1 (1 ns):        " & INTEGER'image(TIME'pos(time_1)) severity note;
  assert FALSE report "3  - time_2 (1.0 ns):      " & INTEGER'image(TIME'pos(time_2)) severity note;

  Output <= Input when rising_edge(Clock);
end;

Here are the synthesis messages of Synth:

[Synth 8-26] 'image of non-integer, non-enum type not implemented
[Synth 8-63] RTL assertion: "1 - time_1 (1 ns):   <complex-type>"
[Synth 8-63] RTL assertion: "2 - time_1 (1 ns):   1000000"
[Synth 8-63] RTL assertion: "3 - time_2 (1.0 ns): 0"

 

As you can see, decimal literals are converted to zero.

 

2. Attribute 'image(...) is not implemented for physical types:

 

This setion uses the example code from above.

 

XST implemented an attribute 'image(...) to convert physical types to a string reprentation. This feature is gone.

 

3. Arithmetic operations mult(time, real) and div(time, real) produce a false result:

 

Here is my example design:

library IEEE;
use     IEEE.STD_LOGIC_1164.ALL;

entity Top_PhysicalTest_Simple is
  Port (
    Clock : in STD_LOGIC;
    Input : in STD_LOGIC;
    Output : out STD_LOGIC
  );
end;

architecture top of Top_PhysicalTest_Simple is
  constant time_4    : TIME     := 0.1 * 1 ns;
  constant time_5    : TIME     := 1 ns / 10;
  constant time_6    : TIME     := 1 ns / 0.1;
  constant time_7    : TIME     := 1 ns + 2 ps;
  constant time_8    : TIME     := 2 ns - 1 ps;

begin
  assert FALSE report "4 - time_3 (10 * 1 ns):   " & INTEGER'image(TIME'pos(time_3)) severity note;
  assert FALSE report "5 - time_4 (0.1 * 1 ns):  " & INTEGER'image(TIME'pos(time_4)) severity note;
  assert FALSE report "6 - time_5 (1 ns / 10):   " & INTEGER'image(TIME'pos(time_5)) severity note;
  assert FALSE report "7 - time_6 (1 ns / 0.1):  " & INTEGER'image(TIME'pos(time_6)) severity note;
  assert FALSE report "8 - time_7 (1 ns + 2 ps): " & INTEGER'image(TIME'pos(time_7)) severity note;
  assert FALSE report "9 - time_8 (2 ns - 1 ps): " & INTEGER'image(TIME'pos(time_8)) severity note;

  Output <= Input when rising_edge(Clock);
end;

These are the Synth messages:

[Synth 8-63] RTL assertion: "4  - time_3 (10 * 1 ns):   10000000"
[Synth 8-63] RTL assertion: "5  - time_4 (0.1 * 1 ns):  0"
[Synth 8-63] RTL assertion: "6  - time_5 (1 ns / 10):   100000"
[Synth 8-63] RTL assertion: "7  - time_6 (1 ns / 0.1):  0"
[Synth 8-63] RTL assertion: "8  - time_7 (1 ns + 2 ps):  1002000"
[Synth 8-63] RTL assertion: "9  - time_8 (2 ns - 1 ps):  1999000"

 As you can see, every operation with real results in a value of zero.

 

In addition to these operators, the comparision operators are also not correct implemented

 

4. Synth implements no monotone value range for type TIME:

 

This is my example code:

library IEEE;
use     IEEE.STD_LOGIC_1164.ALL;

entity Top_PhysicalTest_Simple is
  Port (
    Clock : in STD_LOGIC;
    Input : in STD_LOGIC;
    Output : out STD_LOGIC
  );
end;

architecture top of Top_PhysicalTest_Simple is
  constant time_00   : TIME     := 1 fs;
  constant time_01   : TIME     := 1 ps;
  constant time_02   : TIME     := 1 ns;
  constant time_03   : TIME     := 1 us;
  constant time_04   : TIME     := 1 ms;
  constant time_05   : TIME     := 1 sec;
  constant time_06   : TIME     := 1 min;
  constant time_07   : TIME     := 1 hr;

begin
  assert FALSE report "10 - time_00 (1 fs):  " & INTEGER'image(TIME'pos(time_00)) severity note;
  assert FALSE report "11 - time_01 (1 ps):  " & INTEGER'image(TIME'pos(time_01)) severity note;
  assert FALSE report "12 - time_02 (1 ns):  " & INTEGER'image(TIME'pos(time_02)) severity note;
  assert FALSE report "13 - time_03 (1 us):  " & INTEGER'image(TIME'pos(time_03)) severity note;
  assert FALSE report "14 - time_04 (1 ms):  " & INTEGER'image(TIME'pos(time_04)) severity note;
  assert FALSE report "15 - time_05 (1 sec): " & INTEGER'image(TIME'pos(time_05)) severity note;
  assert FALSE report "16 - time_06 (1 min): " & INTEGER'image(TIME'pos(time_06)) severity note;
  assert FALSE report "17 - time_07 (1 hr):  " & INTEGER'image(TIME'pos(time_07)) severity note;

  Output <= Input when rising_edge(Clock);
end;

 

These are the Synth messages:

[Synth 8-63] RTL assertion: "10 - time_00 (1 fs):  1"
[Synth 8-63] RTL assertion: "11 - time_01 (1 ps):  1000"
[Synth 8-63] RTL assertion: "12 - time_02 (1 ns):  1000000"
[Synth 8-63] RTL assertion: "13 - time_03 (1 us):  1"
[Synth 8-63] RTL assertion: "14 - time_04 (1 ms):  1000"
[Synth 8-63] RTL assertion: "15 - time_05 (1 sec): 1000000"
[Synth 8-63] RTL assertion: "16 - time_06 (1 min): 60000000"
[Synth 8-63] RTL assertion: "17 - time_07 (1 hr):  1452516352"

 As you can see:

  • TIME seems to a 31 bit value in Synth; XST used 63 bit for internal representation !!
  • 1 us = 1 fs; 1 ms = 1 ps; 1 sec = 1 ns or if you are not convinced: 1000 ps = 1 second
  • Line 17 produces an overflow
    1 hr := 3600 sec = 3.6*10^9
    1452516352 = 3.6E9 AND 0x7FFFFFFF = 3.6E9 mod 2^31

 

I'm not sure if I should ask this:

  1. Why is Synth not compatible to XST?
  2. Why got features lost?
  3. Why is Synth storing physical types in 32 bits?
  4. Why are the operator not correct implemented?
  5. Why is the value range of physical types not monotone?
  6. Does Xilinx know of unit testing or VHDL compliance testing?

 

Tags (3)
0 Kudos
7 Replies
Scholar brimdavis
Scholar
10,030 Views
Registered: ‎04-26-2012

Re: Vivado Synth - Bug in handling physical types

@paebbels   "I tried to use my physical types library in Vivado 2014.4, but found masses of bugs."

As a workaround, you could try rewriting the computations for synthesis to use reals instead.

[Even barring Vivado bugs, there is some occasional weirdness with using VHDL time in calculations, in that it occurs in quantized integer steps of the time resolution]

I generally use reals for computing periods and frequencies in synthesizable code.

I have used this approach in XST for many years, and it seems to work in Vivado (simple example below).

-Brian

--
-- simple fixed baud rate generator (counter based)
-- generates output enable at 16x BAUD_RATE
--
...

entity simple_baud_gen is
  generic
    (
      CLK_FREQ  : real := 50_000_000.0;
      BAUD_RATE : real :=     19_200.0
    );

  port
    (        
      clk       : in  std_logic;
      en_16x    : out std_logic
    );

...

  --
  -- compute required counter length and init value
  --
  constant CLK_DIVIDER  : real     := CLK_FREQ / ( 16.0 * BAUD_RATE ) ;

  constant CNT_BITS     : natural  := natural( ceil( log2(CLK_DIVIDER) ) );
  constant CNT_INIT     : unsigned := to_unsigned( integer(round(CLK_DIVIDER-1.0)), CNT_BITS);

 
Full code here:
  https://code.google.com/p/yard-1/source/browse/trunk/hdl/cores/m_uart/simple_baud_gen.vhd
  https://code.google.com/p/yard-1/source/browse/trunk/hdl/cores/m_uart/test/m_uart_tb.vhd

0 Kudos
Xilinx Employee
Xilinx Employee
9,978 Views
Registered: ‎10-24-2013

Re: Vivado Synth - Bug in handling physical types

Hi @paebbels 

 

We are adding features that are missed in the future versions. I will test your code in internal latest build and getback to you.

Thanks,Vijay
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
Explorer
Explorer
9,969 Views
Registered: ‎04-24-2014

Re: Vivado Synth - Bug in handling physical types

Hello Vijay,

 

Thanks for your reply.

 

Can you offer more details?

- Will you test only type TIME or physical types in general?

- Will you test 64 bit support for physical types?
  I think 64 bit support -- as XST provided -- is essential to fix these issues.

- Will this feature be available in the next Vivado 2015.1?

 

Maybe you could add an '-experimental' switch for Vivado Synth, like the -use_new_parser switch in ISE.

This would allow us to test new or missing features and give a report to Xilinx without infecting the normal Vivado usage.

 

This is the full physical types library for XST and other tools:

https://code.google.com/p/picoblaze-library/source/browse/vhdl/lib_PoC/physical.vhdl?name=release

 

 

Regards

    Patrick

0 Kudos
Xilinx Employee
Xilinx Employee
9,956 Views
Registered: ‎10-24-2013

Re: Vivado Synth - Bug in handling physical types

Hi,

 

This looks to be issue with assert staements. Can you please check the outputs with post synthesis simulation.

Assertions are for debug and from the next version you will see the following message with assertion usage.

WARNING: [Synth 8-312] ignoring unsynthesizable construct: assertion statement

 

Thanks,Vijay
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
Explorer
Explorer
9,944 Views
Registered: ‎04-24-2014

Re: Vivado Synth - Bug in handling physical types

This is not a (post) simulation question. This error can not be compared to the simulator's behavior, because Xilinx uses:

- different tools with

- different parsers,

- different compilers and

- different language support!

 

Did I understand you correctly?:

 

You going to remove general assertion and reporting support from synthesis !?!

 

Assertion statements are not unsynthesizable as XST proofed. These statements are urgent required to write additional errors, warnings and notes into the synthesis log, e.g. if a generic is not well chosen or an implementation of a sub module is missing / not complete, there must be a way to notify the user.

 

As long as the Xilinx synthesis process is as buggy as it is, there must be a way to debug generics in a design. These can only be printed out by assert statements.

 

For example XST has an unfixed bug, that causes vectors in a generic map to be reversed at every generic map parameter handover, if the vector direction is downto. This is very funny if one passes a vector down into the design tree, which has unequal depth leaf nodes: So one module gets the correct vector and the other module a reversed version.

How could one proof that Vivado synthesis is working correct without any reporting mechanism?

 

In my eyes it's not a problem in assertion statements. It's just a simple error in the handling of types and the implementation of some methods / operators on these types.

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

Re: Vivado Synth - Bug in handling physical types

6 month and 2 Vivado versions later:

 

I tested all my accusations with current Vivado 2015.2:

 

  1. Xilinx removed ASSERT statement support in sythesis as Vijay threatened.
  2. Physical types have still unimplemented or false implemented operators like '<' (less than)
  3. The range of physical types is not continuous (see example 1)
  4. This applys also to builtin physical types like TIME

 

Example 1:

 

 

type FREQ is range 0 to INTEGER'high units
	Hz;
	kHz = 1000 Hz;
	MHz = 1000 kHz;
	GHz = 1000 MHz;
--	THz = 1000 GHz;
end units;

FREQ'pos(1 Hz) => 1

FREQ'pos(1 kHz) => 1000

FREQ'pos(1 MHz) => 1000000

FREQ'pos(1 GHz) => 1

 

Example 2:

TIME'pos(1 fs) => 1

TIME'pos(1 ps) => 1000

TIME'pos(1 ns) => 1000000

TIME'pos(1 us) => 1

TIME'pos(1 ms) => 1000

TIME'pos(1 sec) => 1000000

TIME'pos(1 min) => 6000000

TIME'pos(1 hr) => 1452516352 -> this is an integer overflow !!!

 

Although Xilinx removed nearly all possible ways for a VHDL programmer to check intermediat values in constants:

  • no file I/O in synthesis
  • no assert or report statements in synthesis

there is still one ugly way to print them into the synthesis report.

 

Vivado Synth exposes every passed generic to sub-components. So if anyone wants to reproduce my results, you will need to implement a dummy su-component and pass your constants of interesst to that component. Synth will report them all.

 

While searching for these bugs and proofing thats a synthesis fault, I found more bugs:

  • Division by zero is not caught in every situation -> long synthesis time -> I stopped synth after 1 hour
  • Vivado has still memory leaks consuming up to 16 GiB of main memory -> Windows stopped Vivado.exe -> SmartHeap error
  • Sometimes the Vivado GUI closes without any notice

 

When will you fix these fatal issues?

 

 

0 Kudos
Scholar brimdavis
Scholar
8,598 Views
Registered: ‎04-26-2012

Re: Vivado Synth - Bug in handling physical types

@paebbels"Xilinx removed ASSERT statement support in sythesis as Vijay threatened."

 

 

A method using REPORT was discussed in this thread:

http://forums.xilinx.com/t5/Synthesis/Show-information-in-log-file-under-Vivado-2015-1/m-p/596599

 

Also, the Xilinx employee commenting on that thread stated that ASSERT was "on the roadmap"

 

>

> Sometimes the Vivado GUI closes without any notice

>

 

I've found with Windows Vivado that it crashes (slightly) less often if using a short project path or SUBST mapped drive letter:

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

 

-Brian

0 Kudos