cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
delomax
Visitor
Visitor
3,208 Views
Registered: ‎02-17-2016

Vivado synthesis doesn't check for width mismatch when assigning an element of an array

 

Usually when assigning vectors (in VHDL) Vivado will check for width mismatch and give error Synth 8-690 if the widths do not match, such as in this code:

architecture rtl of my_entity is
  signal a : std_logic_vector(31 downto 0);
  signal b : std_logic_vector(7 downto 0);
begin
  a <= b; -- Assigning 32 bit vector to 8 bit vector
end rtl;

However, if the vector being assigned is an element of an array type, this width checking doesn't seem to happen. For example, this code does not cause a synthesis error in Vivado 2018.3:

architecture rtl of my_entity is
  type array_t is array (natural range <>) of std_logic_vector(31 downto 0);
  signal a : array_t(3 downto 0); -- Range here is not important...
  signal b : std_logic_vector(7 downto 0);
begin
  a(0) <= b; -- Assigning 32 bit vector to 8 bit vector
end rtl;

Is this a Vivado bug or is there a reason this checking does not occur?

 

Thanks

19 Replies
hemangd
Moderator
Moderator
3,161 Views
Registered: ‎03-16-2017

Hi @delomax , 

 

I have filed CR (Change request) on this issue and development may make necessary changes in upcoming Vivado versions. 

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
alvaro.navarro
Observer
Observer
2,933 Views
Registered: ‎03-22-2010

Hi.

Did this issue get fixed in 2019.1?

I may not be sufficiently familiar with xilinx pages to follow issues, but I see no mention about it in 2018 known issues page, nor can I find a bugfixes list for 2019.

Cheers

 

 

 

 

0 Kudos
hemangd
Moderator
Moderator
2,920 Views
Registered: ‎03-16-2017

Hi @alvaro.navarro ,

Development is still working on it and it is not fixed yet.

Regards,
hemangd

Don't forget to give kudos and mark it as accepted solution if your issue gets resolved.
drjohnsmith
Teacher
Teacher
2,908 Views
Registered: ‎07-09-2009

dont hold your breath

 

this is VHDL, and seems fomr experiance that Xilinx have all but droped support for Xilinx.

Seems they only use SytemVerilog and HLS in house,

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
maps-mpls
Mentor
Mentor
2,872 Views
Registered: ‎06-20-2017

At least he got a response from @hemang .

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
0 Kudos
alvaro.navarro
Observer
Observer
2,307 Views
Registered: ‎03-22-2010

Hi, @hemangd 

Do you know if it got fixed in 2019.2 or will be fixed in 2020.1?

Thanks

Álvaro

0 Kudos
richardhead
Scholar
Scholar
2,298 Views
Registered: ‎08-01-2012

Hi @alvaro.navarro  and @delomax 

I tried the OPs code in 2019.2, and at first it appears that there is a fault.

But then I realised that because it has no ports, it actually just removes everything (and hence does no checking)

If you use the following, you get a range check failure in VHDL and VHDL2008 modes:

library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;


entity my_entity is
  port (
    ip    : in  std_logic_vector(7 downto 0);
    op    : out std_logic_vector(3 downto 0)
  
  );
  
end my_entity;


architecture rtl of my_entity is
  type array_t is array (natural range <>) of std_logic_vector(31 downto 0);
  signal a : array_t(3 downto 0); -- Range here is not important...
  signal b : std_logic_vector(7 downto 0);
begin
  b    <= ip;
  a(0) <= b; -- Assigning 32 bit vector to 8 bit vector
  op   <= a(0);
end rtl;

So I dont know whether it was really ever an issue, as an enaborated design would also likely be empty.

alvaro.navarro
Observer
Observer
2,228 Views
Registered: ‎03-22-2010

It wrote the question because a couple of weeks ago it happened to me again, and my design has ports and is not optimized away etc. The good thing is simulation does catch the error and warns about it. If you don't simulate it and directly implement the code, it goes ahead with synthesis and finishes without error. I don't know what logic it actually implements, haven't looked into it.

I'm still in 2018.3, btw.

0 Kudos
jsammy
Observer
Observer
1,372 Views
Registered: ‎09-19-2014

Can someone from Xilinx provide an update on this CR?

Also, can you provide any insight in what logic is implemented in the case of:

architecture rtl of my_entity is
  type array_t is array (natural range <>) of std_logic_vector(31 downto 0);
  signal a : array_t(3 downto 0); -- Range here is not important...
  signal b : std_logic_vector(7 downto 0);
begin
  a(0) <= b; -- Assigning 32 bit vector to 8 bit vector
end rtl;

 

i.e. does it zero-extend or sign-extend the source signal?

0 Kudos
maps-mpls
Mentor
Mentor
1,355 Views
Registered: ‎06-20-2017

If there is a bug (looks like there might be) synthesize and see. Open synthesized design, then hit the F4 hot key and poke around the generated schematic. You can also first select the module in the netlist before hitting the F4 key to narrow things down a bit.

VHDL is not Verilog.  VHDL is strongly typed.  The width and type in an assignment must match.

If you want to zero extend, you could do this:

a(0) <= X"000000" & b; -- other methods possible

 

If you want to sign extend, you could try:

a(0)(31 downto 8) <= (others => b(b'high)); -- you'll have to test syntax, should work...I have too many languages in my head at the moment
a(0)(b'range) <= b;  -- should work

I would not rely on the default behavior, especially if there is a bug.

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
richardhead
Scholar
Scholar
1,308 Views
Registered: ‎08-01-2012

@jsammy 

Even if this wasnt a bug, it would do neither, as std_logic_vector is not a numeric type.

Go with what @maps-mpls said

0 Kudos
jsammy
Observer
Observer
1,285 Views
Registered: ‎09-19-2014

Perhaps I was unclear.

I was not asking how to zero or sign extend.  My concern is that given the Vivado synthesis bug described in the original post, it clearly will synthesize *something* even with a syntax error in the code.  Imagine a very large design with code that was not all written by you.  It is infeasible to comb through this code to look for the aforementioned bug.  So my question to Xilinx is what exactly is it synthesizing in this case?  This may help direct debugging efforts if we had more knowledge as to what it was actually implementing.

To be clear, this is a critical Vivado synthesis bug that must be fixed.  I am just looking for an update on its progress, and some more background on the behavior of the bug in existing releases.

0 Kudos
drjohnsmith
Teacher
Teacher
1,267 Views
Registered: ‎07-09-2009

do you not sign extend using the resize function of VHDL ?

http://userweb.eng.gla.ac.uk/scott.roy/DCD3/05_Arithmetic.pdf

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
alvaro.navarro
Observer
Observer
1,218 Views
Registered: ‎03-22-2010

To @jsammy : As I mentioned in a previous post, simulation of the design does catch the bug. So if you can, do some simulation. You may not need to do a complete testbench of all the functionality if it's too complicated. I don't remember exactly because it's been a long time, but I think just running the simulation would catch the error during the initial compilation of the files.

To @hemangd or any other Xilinx mod: do we have any news on this severe, 18-month-old bug in Vivado? Seriously, Vivado is (was?) failing to properly detect a syntax error in VHDL, and producing who-knows-what logic instead. It's really dissappointing. We're using Microsemi (Microchip) Polarfire in a different part of the project, and I must say their team has been way more responsive when dealing with problems in Libero that what I have seen in this CR.

About zero/sign-extension: it's not about how to zero-extend or sign-extend. @jsammy was just trying to guess what the Vivado bug does. Anyway, thanks for passing by, and try to help.

 

Cheers

 

richardhead
Scholar
Scholar
1,212 Views
Registered: ‎08-01-2012

@alvaro.navarro 

Unfortunately Xilinx are notoriously unresponsive, particularly when it comes to VHDL bugs. Even when you get notified on the forum a CR is raise, no one gives a ticket number, theres no way to track it, and there are no listed bug fixes in release notes.Any bugs I raise I keep open on the forum and manually check them again on the next release (giving a fix/no fixed in vXXX bump to the post). It is HIGHLY frustrating. It alsoo doesnt help that Xilinx has gone to a 6 monthly release schedule.

If you are some big corp buying a few million dollars of chips every year, you're likely to get better response, and often you can get hotfixes and special versions too.

I suspect with Microsemi having such a smaller market share, it is far more important to them to keep the little guy happy. When I raise a ticket with Aldec, I usually get a response within a day, and I have had a patch sent within 2 days. Its great.

 

drjohnsmith
Teacher
Teacher
1,188 Views
Registered: ‎07-09-2009

Xilinx will probably use this as an example of why HLS is so much better 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
jsammy
Observer
Observer
1,148 Views
Registered: ‎09-19-2014

@alvaro.navarro well said

It seems like this post should not be marked as solved by @delomax until the corresponding fixed version of Vivado has been released and verified :shrug:

 

0 Kudos
maps-mpls
Mentor
Mentor
1,123 Views
Registered: ‎06-20-2017

The price of salt is being impacted by this thread.

*** Destination: Rapid design and development cycles *** Please remember to give internet points to those who help you here. ***
0 Kudos
jsammy
Observer
Observer
513 Views
Registered: ‎09-19-2014

FWIW it seems like this issue has finally been resolved in 2020.1