cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Participant
Participant
2,399 Views
Registered: ‎12-04-2017

Inconsistent port type when using Block Design

Hi,

 

I'm using Block Design to manage a large AXI Interconnect tree. Most of the AXI slaves are connected in RTL code via the Block design wrapper code generated by Vivado. However, when making multiple AXI connections external, there seem to be inconsistencies whether single-bit signals should be created as std_logic_vector(0 downto 0) or just a simple std_logic.

 

Skjermbilde.PNG

Skjermbilde2.PNG

The same bus type, AXI4LITE, but different signal types...

Skjermbilde3.PNG

 

Also, whenever I update the Block Design with something, there seems to be a chance that these signals may change to the other type. This is very annoying since I then have to change my instantiation code as well.

 

Is there some way to make Vivado choose a signal type?

Tags (1)
13 Replies
Highlighted
Moderator
Moderator
2,336 Views
Registered: ‎09-15-2016

Hi @olagrottvik,

 

Does this post help?

https://forums.xilinx.com/t5/Welcome-Join/Getting-std-logic-vector-0-to-0-instead-of-std-logic-in-vivado/td-p/657959

 

Thanks

Prathik

-----------------------------------------------------------------------------------

Don't forget to reply, kudo, and mark the appropriate post as 'accept as solution'.

-----------------------------------------------------------------------------------

 

0 Kudos
Highlighted
Participant
Participant
2,304 Views
Registered: ‎12-04-2017

Hi,

 

Thanks for your reply, but my question is not how to connect a std_logic to a std_logic_vector(0 downto 0).

 

The problem is that Vivado is not consistent, and whenever I make a change in the block design I need to update several hundred lines of code. Why would Vivado, or the AXI Interconnect have the option to randomize which signal it uses...

 

After some experiments, it looks like that if I connect an XBAR after the AXI interconnect, the signals are consistent (all stay std_logic_vector(0 downto 0). This is extremely annoying as well, and not an acceptable workaround if you ask me.

0 Kudos
Highlighted
Adventurer
Adventurer
2,041 Views
Registered: ‎06-25-2012

Did you ever find another solution to this issue?

It has been very frustrating to me as well. It seems like Vivado randomly decides if AXI ports leaving the block diagram have signals (like arready, arvalid, etc) are a std_logic_vector of 0 downto 0 or simply std_logic.

I have had this issue for Vivado versions ranging from 2015.x - 2017.4.

 

I can make small changes to my block design and it "randomly" swaps back and forth breaking the top level that I place my block design in.  Even two AXI-MM ports connected to the same AXI Interconnect can have different representations.

 

0 Kudos
Highlighted
Participant
Participant
2,035 Views
Registered: ‎12-04-2017

Sadly, I have not, and it does not seem like Xilinx care about this, even though it is extremely time-consuming to fix for changes. Maybe the type of workflow where you export the signals out of block diagram is unprioritized.

I'm using 2018.2 now, and I still see this behavior. I've unsuccessfully tried to modify things and look for patterns for a choice of signal type.

0 Kudos
Highlighted
Adventurer
Adventurer
2,033 Views
Registered: ‎06-25-2012

Have you tried to make a support ticket?

From my past support experience I am guessing that it could take quite some effort to arrive at point of mutual understanding and replicating the problem.

0 Kudos
Highlighted
Adventurer
Adventurer
1,937 Views
Registered: ‎06-25-2012

I created a support request.

Support indicated: This looks to be a bug as scalar ports should always be std_logic type. I am not sure why the tool is giving inconsistent result and changing it to wrong type “std_logic_vector (0 down to 0)”

Support suggested a wrapper could be made in verilog instead, or the wrapper could be manually maintained.

I will update if bug gets confirmed and CR gets filed.

0 Kudos
Highlighted
Participant
Participant
1,935 Views
Registered: ‎12-04-2017

Thanks for the update!

I have not had the time to post support yet, so thanks for the help with that!

0 Kudos
Highlighted
Adventurer
Adventurer
1,897 Views
Registered: ‎06-25-2012

The bug was confirmed by Xilinx and CR-1020027 was opened.

Additionally Xilinx confirmed that this issue was still present in the internal build of 2019.1.

0 Kudos
Highlighted
Adventurer
Adventurer
1,627 Views
Registered: ‎06-25-2012

I recently got an update from Xilinx.

They indicated the Change Request (CR-1020027) is now "Closed (Never Fix)"

 

0 Kudos
Highlighted
Adventurer
Adventurer
951 Views
Registered: ‎02-22-2016


@jsmithsrc wrote:

I recently got an update from Xilinx.

They indicated the Change Request (CR-1020027) is now "Closed (Never Fix)"

 


Good luck then. Do I get to be disappointed, even if Xilinx met my expectations?

0 Kudos
Highlighted
Adventurer
Adventurer
933 Views
Registered: ‎06-25-2012

This bug is very annoying. Probably the bug I most frequently encounter and results in code change back and forth as Vivado spins the random number generator wheel to decide the type (std_logic or std_logic_vector) of scalar ports.

It is even more annoying when formal conversion via function is not supported either, yet (https://forums.xilinx.com/t5/Synthesis/Any-plans-to-implement-formal-function-conversion-in-VHDL-2008/td-p/750492)

 

0 Kudos
Highlighted
Adventurer
Adventurer
925 Views
Registered: ‎02-22-2016

I fully agree, working with Vivado is just very anoying at times and doesn't seem to get any better with time. It is only thanks to the fact that users do not have any feasible alternatives to Vivado, when working with Xilinx FPGAs, that people are still putting up with this.

The issue described in this post certainly isn't a new Millenium Problem. Still it got rejected and won't be fixed. Instead another new IDE will be pushed, were everything is supposed to be better... same old story.

0 Kudos
Highlighted
533 Views
Registered: ‎11-01-2019

I have also experienced frustration with this behaviour in Vivado.

What I have noticed is that what determines the type of the port (std_logic/std_logic_vector(0 downto 0) is what the immediately next element that the external interface of the BD connects to. For instance, if your interconnect has an slave AXI interface that immediately goes into an AXI register slice (before the AXI crossbar), then you will get std_logic for your AxValid/AxReady ports. Same thing holds for master interfaces; if the very last element on the path to the master AXI interface of the interconnect is a register slice then you get std_logic and not std_logic_vector(0 downto 0).

So if you want deterministic behaviour (i.e. always std_logic), a good rule of thumb is to always enable reg slices on your slave/master AXI interface on the interconnect. It's anyway helpful for better timing isolation and it is not a massive resource overhead.

0 Kudos