01-28-2021 05:02 AM - edited 01-29-2021 02:21 AM
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.
01-29-2021 02:21 AM
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.
02-03-2021 04:10 AM
This is detailed in PG213 in the I/O Behavior section from Page 113 of the latest version PG213 (v1.3)
02-04-2021 12:58 AM
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.
02-08-2021 03:36 AM
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.