UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Contributor
Contributor
1,221 Views
Registered: ‎05-11-2018

Issues migrating tri-stated bus interface from ZYNQ 7 series to ZYNQ UltraScale+

Hello,

 

I have an existing design I implemented with ZYNQ 7000 devices that has a tri-stated bi-directional bus interface. I used XDC file to push each pin's output register and registered tristate control into IOI resources using "set_property BEL OUTFF ..." and "set_property BEL TFF ...", along with "set_property LOC OLOGIC_X<#>Y<#>...". It worked great.

 

I'm migrating the design to the ZYNQ Ultrascale+ MPSOC and am unable to close timing due to the tri-state control timing. I've been reading through migration guides and UG571 in the hopes of finding a simple solution to my problem. Looking at the device resources I can see the HDIO's have what appear to be local data/tristate FFs via the HDIOLOGIC_S/M_X<#>Y<#> blocks. However, when I attempt to place the relevant signals into these resources I'm getting errors such as the following:

 

[Place 30-1008] Instance i0_foo/i1_blah/i2_fsm/data_oe_reg[10] has an inverted D pin which is unsupported in the UltraScale and UltraScale+ architectures.

 

[Place 30-488] Failed to commit 9 instances:
... <8 other references deleted for clarity>
i0_foo/i1_blah/i2_fsm/data_oe_reg[10] with block Id: 1660 (FF) at SLICE_X85Y16

Looking at the results of synthesis it seems like the corresponding signals are being assigned to the expected cell locations, but during implementation I get the above errors. I think I know what's going on but I can't find any relevant documentation on these HDIOLOGIC cells (UG571 doesn't seem to specifically mention them), to confirm my suspicions (the errors seem to be for signals where the tri-state control resets to a 0, which seems odd as the blocks in question seem to have a reset input...).

 

From various posts it seems like the recommended practice is to push the tristate register into the logic array and try to keep it close to the pin but that isn't proving a workable solution at this point in time and I'd just like to ensure I've looked at the "simple" solutions before going down that route.

 

Take care.

 

Jim

0 Kudos
5 Replies
Xilinx Employee
Xilinx Employee
1,198 Views
Registered: ‎05-08-2012

Re: Issues migrating tri-stated bus interface from ZYNQ 7 series to ZYNQ UltraScale+

Hi jimg@crypto4a.com .From the error, the issue might be an invalid optimization. Can you check to see if the D pin on the FF in the message has the inverting bubble at the post-synthesis stage?

 

If no inversion bubble exists, but an inverting LUT1 is driving the D pin, you can set a DONT_TOUCH property on the FF to avoid the optimization during opt_design. Below is the syntax.

 

set_property DONT_TOUCH TRUE [get_cells {i0_foo/i1_blah/i2_fsm/data_oe_reg[10]}]

 

Since the bel on the HDIO site cannot physically invert the pin, the inversion should be in a driving LUT1, instead of on the FF D pin. A similar issue has been reported, and is being investigated.

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
Contributor
Contributor
1,148 Views
Registered: ‎05-11-2018

Re: Issues migrating tri-stated bus interface from ZYNQ 7 series to ZYNQ UltraScale+

Hello marcb,

 

Thanks for the suggestion as it resolved that part of the issue. Unfortunately, it also helped peel the onion a bit and now I'm seeing additional issues with what I'm trying to do.

 

When I run implementation now I see a number of critical warnings related to it not being able to place the pins in the HDIO logic. I tried two separate approaches to achieve this goal, neither of which succeeded. The first was to attach the IOB TRUE property to the associated registers and that resulted in the critical warnings that look like this:

 

 

CRITICAL WARNING: [Place 30-73] Invalid constraint on register 'i0_foo/i1_blah/i2_fsm/data_oe_reg[0]'. It has the property IOB=TRUE, but it is not driving or driven by any IO element.

 

I then attempted to utilize the LOC and BEL properties to map the registers to their corresponding pad's HDIOLOGIC block's TFF element and that failed with critical warnings that look like this:

 

CRITICAL WARNING: [Vivado 12-2285] Cannot set LOC property of instance 'i0_foo/i1_blah/i2_fsm/data_oe_reg[0]'... Illegal site, cannot place non-IO FF/Latch on IO site [C:/Xilinx/workspace/ultrascale_fun/ultrascale_fun.srcs/hd_pin_test_001/new/floorplan.xdc:77]

 

Diving into the post-synthesis netlist I can see that for some reason the synthesizer has instantiated either FDRE or FDSE registers and then inverted the output of each of them, which isn't allowed for IO logic. I'm not sure why it wasn't smart enough to swap the register type (i.e., FDRE -> FDSE and vice versa) and push the inverter to the logic that feeds the register to avoid this situation, but perhaps there is a way to hand-hold it to get that desired outcome.

 

What's even more confusing to me though is that for some signals (byte enables for the data bus) it didn't create the output inverters, so there were no warnings associated with these pins and they appear to have been valid candidates for mapping to the TFF elements. However, it looks like the placer/mapper still chose to ignore the associated IOB or BEL/LOC properties for these pins and it put those registers into SLICE elements that weren't very close to the associated IO pads. Furthermore, scouring through the implementation logs I see no messages related to these pins and any issues it may have had with my constraints so I have no clue why they were effectively ignored.

 

So at this point of my journey to get back to where I was with the ZYNQ 7000 series I have the following questions:

 

1) Why does Vivado appear to have ignored the BEL/LOC or IOB properties on the bus byte enable registers and mapped them to SLICE elements instead of the IO's TFF elements?

 

2) Is there any way to guide the synthesizer to eliminate the output inverter blocks for the enable registers that are preventing them from being mapped into the IO registers?

 

3) Is there any documentation related to the {OPFF, IPFF, TFF, OPTFF} elements found in the HDIOLOGIC blocks? I can't find anything online and I'd like to be sure these efforts are targeting the appropriate elements to avoid wasting time in an ultimately futile exercise should these elements not do what I think they do.

 

Take care and thanks again for your help so far!

 

Jim

0 Kudos
Xilinx Employee
Xilinx Employee
1,113 Views
Registered: ‎05-08-2012

Re: Issues migrating tri-stated bus interface from ZYNQ 7 series to ZYNQ UltraScale+

Hi jimg@crypto4a.com

 

Is a DCP available to attach? There should be messaging if an IOB constraint is not honored.

 

1) Why does Vivado appear to have ignored the BEL/LOC or IOB properties on the bus byte enable registers and mapped them to SLICE elements instead of the IO's TFF elements?

 

I would expect messaging for an IOB packing failure, but a DCP would help with this analysis.

 

https://www.xilinx.com/support/answers/66668.html 

 

2) Is there any way to guide the synthesizer to eliminate the output inverter blocks for the enable registers that are preventing them from being mapped into the IO registers?

 

This might be a better question for the Synthesis board, but the inversion likely does not have the same conditions associated with it "(if reset)...", so I would not expect the inversion on the output Q within the register. input inversions on specific control signals (D, R, CE, CLK) do get pushed to primitives.

 

3) Is there any documentation related to the {OPFF, IPFF, TFF, OPTFF} elements found in the HDIOLOGIC blocks? I can't find anything online and I'd like to be sure these efforts are targeting the appropriate elements to avoid wasting time in an ultimately futile exercise should these elements not do what I think they do.

 

Chapter 3 of the SelectIO Guide would have the most information on the HDIO resources.

 

http://www.xilinx.com/support/documentation/user_guides/ug571-ultrascale-selectio.pdf

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

 

---------------------------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
---------------------------------------------------------------------------------------------
Contributor
Contributor
1,040 Views
Registered: ‎05-11-2018

Re: Issues migrating tri-stated bus interface from ZYNQ 7 series to ZYNQ UltraScale+

Hi marcb,

 

Thanks for the response, and especially the link to AR6668 as that provided a lot of good information that may help me out in the future. Unfortunately this didn't really resolve things and I ended up rejigging the design and using multi-cycle timing exceptions to deal with it. I would have preferred to just be able to use the design as-is but c'est la vie!

 

One comment in response to item #3 is that I would have thought chapter 3 of the Select IO guide to have that sort of information as well, but it didn't, which is why I posted the question to this forum. I had thought I was missing something here but perhaps it's just not documented anywhere, or the powers that be assume it's all obvious. Regardless, I'm still in the dark with regards to the details of the HDIO logic cells.

 

Take care and thanks again for your assistance.

 

Jim

0 Kudos
Moderator
Moderator
1,027 Views
Registered: ‎01-16-2013

Re: Issues migrating tri-stated bus interface from ZYNQ 7 series to ZYNQ UltraScale+

jimg@crypto4a.com,

 

do you have any more queries for this forum thread? If your query is addressed then please close this thread by marking the helpful post as "Accept as Solution"

 

If you have any architecture related queries then I would suggest you post a new query on ultrascale board under Programmable device section: 

https://forums.xilinx.com/t5/Programmable-Devices/ct-p/SILICON

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos