cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
iobass
Visitor
Visitor
3,014 Views
Registered: ‎08-18-2017

Very slow Vivado synthesis for type conversion

The attached file is a simple single-port RAM model with an initial value.  For portability, it uses a two-dimensional type (RAM_2D_T) to calculate an initial value, then converts the value of that reusable type to a local type.  My target application is to declare the RAM_2D_T in a package along with file reading functions to be shared among multiple entities.

 

On my machine with Vivado 2017.2, I get the following runtimes.  To get the fast runtime, uncomment the "--try:" line and comment out the currently-visible declaration for signal "ram".

 

Direct initial value: 21 seconds

Converted initial value: 42 minutes, 32 seconds

 

I've already found a workaround for my current use, but I hope this test case will be forwarded to the developers to find and fix this serious runtime issue.

 

To reproduce my result, execute the following command.

 

$ vivado -mode batch -source xbug_type_convert.tcl

 

Thanks!

 

0 Kudos
3 Replies
iobass
Visitor
Visitor
2,993 Views
Registered: ‎08-18-2017

Please ignore the first 'xbug_type_convert.tcl' file. I thought I had removed it, and I can't figure out how to get rid of it now.
0 Kudos
hpoetzl
Voyager
Voyager
2,980 Views
Registered: ‎06-24-2013

Hey @iobass,

 

Direct initial value: 21 seconds

Converted initial value: 42 minutes, 32 seconds

Nice ...

 

I've already found a workaround for my current use ...

Care to share that workaround?

 

Thanks in advance,

Herbert

-------------- Yes, I do this for fun!
0 Kudos
iobass
Visitor
Visitor
2,936 Views
Registered: ‎08-18-2017

Care to share that workaround?
I'm happy to, though it may not help much.  

It's a version of the old story, "Doctor, it hurts when I do this. (Doctor) Then don't do that."  I mentioned in my original post that I have a file reading function in a package to return different size/length initial values for RAMs.  In this arrangement, I needed a type flexible in two dimensions (RAM depth and element size).  So I created a two-dimensional type as shown in my example (RAM_2D_T).  The poor Vivado performance comes when I try to loop over the bits in the 2-D type to convert to my component-local array-of-arrays data type.  The easy solution is "don't do that."  I copied the file reading function into the declarative regions of both of my RAM entity/architectures and modified it to populate the array-of-array type directly (RAM_T in my example).  This way I skip the expensive conversion.

 

Another possible workaround springs to mind.  I could have used the 2D type directly for my RAM signal.  It's messier in the read/write logic, so I usually avoid coding my RAMs this way.  I've done this successfully in other synthesis tools, but I haven't tried it with Vivado synthesis.

 

My favorite workaround is to use VHDL-2008 to get the type I need that's flexible in two dimensions.  VHDL-2008 allows declaring arrays where the element type isn't constrained.  I've really enjoyed using VHDL-2008 in the past, but a quick test with Vivado synthesis indicated that it would "poison" my whole design.  For my current design, it would be difficult to rework my code for VHDL-2008.  The cut-and-paste option was too easy to ignore this time.

 

Hope this helps.  Enjoy!

 

- Ryan

0 Kudos