cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
muellera
Adventurer
Adventurer
579 Views
Registered: ‎02-22-2016

How to tristate sysmon i2c interface when using PCIe Tandem Configuration

Hi,

I am working on a design where PCIe Tandem Configuration is used. The IO bank which holds the PERSTN input is part of the PCIe Tandem stage 1. The same IO bank also contains the I2C pins (SCLK, SDA) which go to a sysmon IP.

Therefor, the top level ports for SCLK and SDA need to be tristated in the Tandem stage 1 logic, using the mcap_design_switch signal. How can this be achieved? It appears that the OBUFTs for SCLK and SDA are inside the sysmon IP. I cannot find any IP customization parameter, that would allow to disable these buffers or allow me to access the tristate pin on those OBUFTs.

 

 

[DRC HDTC-19] Stage 1 Tri-state IO buffers should be driven by Stage 1 cell: Tri-state buffer 'top_level/b_sysmon.i_sysmon_0/U0/AXI_SYSMON_CORE_I/i2c_sclk_iobuf/OBUFT' has been added to Tandem stage 1, but the driving logic on the tri-state pin 'top_level/b_sysmon.i_sysmon_0/U0/AXI_SYSMON_CORE_I/inst_sysmon' is part of stage 2. This will result in undefined behavior on the tri-state pin for the stage 1 IO. To correct this condition, the cell driving the tri-state pin for stage 1 IO should also be added to Tandem stage 1 design.

 

 

I did set the property to add the OBUFTs to the stage 1 pblock in my constraint file for all other cells which are in the affected IO bank. I cannot find a way to do the same for SCLK and SDA though.

Your assistance in solving this issue is much appreciated.

Best Regards

0 Kudos
4 Replies
muellera
Adventurer
Adventurer
508 Views
Registered: ‎02-22-2016

I have added the sysmon IP to the PCIe Tandem Configuration example design - using the same IO constraints as in my own design - and can successfully implement the design and generate a bitstream.

However, there are still warnings about IOs that should be tristated using the mcap_design_switch signal. Is it save to ignore these warnings?

[DRC HDTC-11] Non-stage one IO in stage one must be tristated: For Tandem PCIE/PROM flows, the second stage I/O 'sysmon_0_inst/U0/i2c_sclk_iobuf/OBUFT' need to be tri-stated with 'mcap_design_switch' in order to keep them at a known state prior to second stage logic being programmed. The tri-state buffer should be added to a first stage Pblock, and the rest of the driving and load logic should remain in the second stage.
0 Kudos
garethc
Moderator
Moderator
439 Views
Registered: ‎06-29-2011

Hi @muellera 

This is detailed in PG213 in the I/O Behavior section from Page 113 of the latest version PG213 (v1.3)

garethc_2-1612354204029.png

 

Thanks,

Gareth


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

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

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos
muellera
Adventurer
Adventurer
405 Views
Registered: ‎02-22-2016

Thank you @garethc.

The paragraph you quoted describes what I have done for most of the affected IOBs.
However, the OBUFT instances inside the sysmon IP core do not expose the T pins and therefor I see no way how to tri-state the sysmon's SDA and SCLK ports using mcap_design_switch.
Is it save to ignore warnings related to SDA and SCLK not being tri-stated? Does not-tri-stating SDA and SCLK risk disturbances of the I2C bus, while only stage 1 is loaded? Should the sysmon block be moved to stage 1 is a situation like this (which I strongly consider, unless this raises new issues)?

Glad to hear everyones comments and advice.

Kind regards

0 Kudos
garethc
Moderator
Moderator
343 Views
Registered: ‎06-29-2011

Hi @muellera 

Can you clarify some details for me? What part is this? And to confirm is this TandemPCIe or TandemPROM? And what PCIe IP?

What I found is that yes, sysmon intentionally does not allow you to modify the IOBuffer. Ultimately Sysmon doesn’t want you to touch anything with this portion of the design.

I do need you to educate me a little on 1) how the sysmon is intended to work and 2) how you want to use sysmon in your system level operation. The feedback I got about this was that we do expect some unexpected behavior as result of tandem depending on the tandem mode they are using. And there are some concerns that sysmon has some watchdog stuff going on and that it also monitors config-site primitives/use.

Thanks,

Gareth


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

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

If starting with Versal take a look at our Versal Design Process Hub and our
Versal Blogs

------------------------------------------------------------------------------------------------
0 Kudos