08-23-2018 02:46 AM
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.
The same bus type, AXI4LITE, but different signal types...
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?
09-06-2018 09:31 AM
Does this post help?
Don't forget to reply, kudo, and mark the appropriate post as 'accept as solution'.
09-10-2018 08:44 AM
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.
01-10-2019 07:23 AM
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.
01-10-2019 07:31 AM
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.
01-10-2019 07:35 AM
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.
01-14-2019 06:54 AM
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.
01-16-2019 04:56 AM
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.
10-24-2019 02:10 AM
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?
10-24-2019 04:52 AM
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)
10-24-2019 05:15 AM
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.
03-10-2020 07:37 AM
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.