cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
jorisvr
Visitor
Visitor
381 Views
Registered: ‎05-03-2019

Vivado segfault on VHDL array type declaration

Hello,

It seems that Vivado 2020.2 synthesis consistently crashes while processing a specific kind of type declaration.

The architecture of my entity contains the following declaration:

  type table_type is array(std_logic) of std_logic;

When I try to synthesize the entity, Vivado fails with an "abnormal program termination" of the synthesizer:

--------------------------------------------------------------------------------
Starting Synthesize : Time (s): cpu = 00:00:03 ; elapsed = 00:00:04 . Memory (MB): peak = 2295.770 ; gain = 0.000 ; free physical = 641 ; free virtual = 18567
---------------------------------------------------------------------------------
Abnormal program termination (11)
Please check '/home/joris/vivado/crashtest/crashtest.runs/synth_1/hs_err_pid4706.log' for details
segfault in /opt/Xilinx/Vivado/2020.2/bin/unwrapped/lnx64.o/vivado -exec vivado -log crash.vds -m64 -product Vivado -mode batch -messageDb vivado.pb -notrace -source crash.tcl, exiting...
Parent process (pid 4706) has died. This helper process will now exit

I'm running Vivado 2020.2 on Linux. My target is Zynq-7000 xc7z010clg400-1.
The error log file contains a stack trace and is attached here.
The error occurs when my source file type is "VHDL" and also when it is "VHDL 2008".
The error goes away when I write "array(std_ulogic)" instead of "array(std_logic)".

I understand that people may have varying opinions on the usefulness of my type declaration, whether or not this array type should ever be used for synthesis, and whether the declaration is even allowed in VHDL. However I hope we can agree that a segmentation fault is not the best way to handle it in Vivado.

This array type is not absolutely necessary for my design, so I can work around the problem easily. But it would be great if the segfault can be fixed in some future version of Vivado.

0 Kudos
5 Replies
surajc
Xilinx Employee
Xilinx Employee
377 Views
Registered: ‎01-30-2019

hi @jorisvr 
Could you please share a test case which can be used to reproduce the issue at our end? 

Also what OS are you using to run Vivado 2020.2 ? 

0 Kudos
pulim
Xilinx Employee
Xilinx Employee
349 Views
Registered: ‎02-16-2014

HI @jorisvr 

Able to reproduce this crash.

I will report this issue to get it fixed.

 

Thanks,

Manusha

richardhead
Scholar
Scholar
342 Views
Registered: ‎08-01-2012

A segfault is always a tool problem, not a code problem and should always be reported, regardless of code "usefulness".

On another note, if you literally are writing:

type table_type is array(std_logic) of std_logic;

This is a syntax error. You should have to write the full range symantics:

type table_type is array(std_logic range <>) of std_logic;

 

I think VHDL 2019 removes the need to add range <>, because ranges can be infered from types and returned as objects in their own right. But dont expect support this decade.

 

0 Kudos
jorisvr
Visitor
Visitor
312 Views
Registered: ‎05-03-2019

Thanks for handling this. It could make a nice test case for the regression suite.

0 Kudos
jorisvr
Visitor
Visitor
308 Views
Registered: ‎05-03-2019

Yes, I was literally using that type definition. I think I disagree with your assessment.

In VHDL 2002, std_ulogic is an enumerated type, which implies that it is also a discrete type.
There are two kinds of array type definitions: constrained and unconstrained.
You seem to be proposing an unconstrained array definition (which requires that the actual range is specified when the type is used). My intention was to define a constrained array type, with an index range corresponding to the complete discrete range of std_logic values.

By the way, it looks like my type definition is in fact invalid in VHDL 2002: The standard explicitly forbids the use of a resolved subtype as the discrete range specification of an array. So indeed std_logic is not allowed, but std_ulogic should be fine.

0 Kudos