Analog/Tri-state I/O is not supported

[armleo]

Description

Imagine we have a macro1, which has inout and it connects it's output to one. Then there is macro2 which is made using OpenLane which has inout and there is macro3 which tries to read the inout wire's value but gets X.

Only reproducible if the macro2 contains submodule that has Hi-Z assigment.

After debugging it seems, that macro2, which has been made using OpenLane connects the inout pin to CONB's LO pin which is tie-hi/low cell and the LO is tie-low pin. Providing minimal build which reproduces this issue.

Environment

Kernel: Linux v5.11.0-49-generic

Distribution: ubuntu 21.04

Python: v3.9.5 (OK)

Container Engine: docker v20.10.10 (OK)

OpenLane Git Version: 2022.01.13_01.51.43

pip:click: INSTALLED

pip:pyyaml: INSTALLED

pip:venv: INSTALLED

---

PDK Version Verification Status: OK

---

Git Log (Last 3 Commits)



8ad16ce 2022-01-20T13:08:19+02:00 Move reading SDC file earlier (#871) - Anton Blanchard -  (HEAD -> master, origin/master, origin/HEAD)

6871aa8 2022-01-20T13:07:26+02:00 Remove manual tech mapping of muxes and get abc to map them (#873) - Anton Blanchard -  ()

c01e53a 2022-01-12T18:40:17-03:00 Fix for make pdk (#861) - Vitor Bandeira -  (tag: 2022.01.13_01.51.43)

Reproduction Material

hiz_bugreport.zip

Expected behavior

Inouts unconditionally connected to Hi-Z or disconnected should be disconnected.

Logs

Not relevant

[armleo]

Hmm... Wait wrong file attached, one moment will reupload

[armleo]

hiz_bugreport.zip

[maliberty]

Same as YosysHQ/yosys#511 which is open since 2018

[armleo]

Workaround idea: Add a cell which has dummy pin, unconnected to anything and force yosys to connect unconnected pins to this instance using the command mentioned in yosys issue. iopadmap and insbuf are candidates for this.

In further stages we may just remove the unstance and all it's nets. Should pass lvs because no transistors are inside the cell in question.

Didnt investigate further. If somebody knows how to do this, it would be great

[maliberty]

Another idea is to manually instantiate a tristate driver and tie its enable to the off state. It would waste a bit of area/power but at least it would be correct.

[armleo]

That does not solve the problem with io_analog and gpio_noesd signals, as this inouts cant be connected to any gates.

This is why I am proposing adding a special cell, which is removed before placement, so not a single wire will go into chip area.

Otherwise your suggestion is a good workaround, until we can come to another solution or implement mine.

Anyway, I will work on this, but this may take a month, with the queue of tasks I am working on. If somebody else could work on this, it would be great.

[maliberty]

Your idea wouldn't be hard to implement. You could manually tie it off with a sky130_fd_sc_hd__conb of a known name in the verilog. Later you can just script an opendb step to delete the instance.

Alternatively you could leave the verilog alone and have a step to delete any instance attached to a port of a known name using opendb.

[armleo]

Only issue: It wont pass lvs.

[maliberty]

What about a cell type that lvs usually ignores like decap? I'm not enough of an LVS expert to know how to work around that.

[maliberty]

@RTimothyEdwards any thoughts on an LVS workaround?

[RTimothyEdwards]

@maliberty : That's a case similar to doing a metal mask fix. My usual approach is to hand-edit (or script-edit) both the netlist and the layout. This adds a certain amount of risk, but as long as you carefully check both netlists before you run LVS, you should be able to confirm that the substitution was made correctly and so the LVS result can be trusted.

[armleo]

I will work on this later, but currently I am thinking about following:

1. iopadmap yosys to tristate buffer with enable tied to zero. (should be easy), and can be used to implement tristate in/outs from top level.
2. Find from netlist buffers connected to io that have enables tied to zero and remove them (Some python and opendb magic ✨)
3. maybe have a list of block terminals (ports) that has to be disconnected from everything. And add a check to make sure that these ports are disconnected from anything (for noesd/io_analog). Alternatively remove the pin from def, add blockages, do the flow and then add back the pin.

Millions of other solution should be possible. Will work on this when done with def pin issue.

[d-m-bailey]

@donn This is also the case when io is unconnected. For example, in https://efabless.com/projects/474

The rtl for user_proj_example uses 16 bits of la_data_out.

    assign la_data_out[10:3] = codeout ;
    assign la_data_out[18:11] = epochrx ;

The other 112 unused bits are synthesized as connected to ground in the gl netlist.

 sky130_fd_sc_hd__conb_1 _60754_ (.LO(la_data_out[0]),...);
 sky130_fd_sc_hd__conb_1 _60755_ (.LO(la_data_out[1]),...);
 sky130_fd_sc_hd__conb_1 _60756_ (.LO(la_data_out[2]),...);
 sky130_fd_sc_hd__conb_1 _60757_ (.LO(la_data_out[19]),...);
...

This may be a bit more that simply tri-state I/O not being supported.

[d-m-bailey]

@armleo Is it necessary to connect macro1's output to macro2's unconnected output? Maybe the simplest solution would be not to connect to unused outputs. At least until yosys is fixed.

[armleo]

What I am trying to do is create a wrapper like caravan. It uses faster IO and is called carrack. It is placed inside Caravan.

I wanted to place pins in the wrapper that were analog, but unfortunately they were tied low with conb as they were left unconnected.

For temporary workaround I removed all analog connections and left only digital ones.

The macro1 and 2 was just an example that showed the issue and this macro case is not important for me to bother.

[RTimothyEdwards]

@armleo : Please keep in touch with me about this, because my intention for the next-generation Caravan chip is to be able to directly swap I/O pads through a user-level configuration file. Currently, as you know, the drawbacks of the Caravan layout is that the analog pads have no ESD, and user-created ESD structures can't be placed close enough to the pad for optimal performance, because nothing that the user creates can get closer to the pad than the edge of the wrapper.

[armleo]

@RTimothyEdwards "directly swap I/O pads through a user-level configuration file". So you want to use OpenLane for that, correct? If possible could also Caravan connect the VDDIO/VSSIO to user area? I want to keep the power pins free for my own wrapper.

For that purpose, I have three proposals.

1. Add pre-post hooks for each flow step. This will allow modifying the DEF with custom power/analog routing and pin locations with custom scripts from tcl/python without keeping custom "interactive tcl". It will also allow to modify the DEF to mark power as USE POWER/GROUND and analog as USE ANALOG.

For Caravan/Caravel, you will be able to split the chip into two pieces and one of the pieces can be the mgmt SOC and one being the Chip IO + User Logic. Chip IO + User Logic can be modified as the user wants from config or if the user wants, he can just modify the scripts to put custom GPIOs and run the openlane.

2. Assuming the first one is implemented, this allows marking the analog pads from the pre-post hooks.
   Then add a pass to OpenLane to remove all "USE ANALOG" pads and add obstructions and save the pads to some file/DEF. Then at a later stage, all USE ANALOG pads are placed back into DEF.

This will allow to put Analog Pads and merge caravel/caravan.

This assumes the PADs are located right on top of the GPIOs, so they will always be routed by default OR the user scripts in pre-post hooks can modify the DEF with predefined routing.

Only one thing to check: Make sure that if blackbox is connected to pad, yosys wont add CONB. If it does, we will need to fix this.

In a later version we can even allow to add custom LEF for analog routing. Assuming current routers handle custom LEFs, this will allow analog routing done by router in automatic mode. This is very low priority for me.

3. iopadmap for tristate buffers. This pass from yosys maps top-level tristate logic. This is low priority for me too.

@maliberty I am open to discuss all of the above. If anybody has better idea on how to do this, please let me know.

Keep in mind: I am doing this for fun, as I am not employed by anybody. Dont expect any level of commitment.

UPD: It seems yosys scripts can be used to connect, disconnect, add components, wires, etc. I will be trying this.

[armleo]

Update. I am no longer able to work on this.

My current implementation was using a Tcl list to describe all pins that are analog, then it was supposed to route them using custom DEF rules however there were two issues.

1. Magic VLSI didn't respect the LEF custom rules, so the rules were moved to DEF. See [Feature request] Magic VLSI does not handle non default rules RTimothyEdwards/magic#151.
2. That I was unable to force the router to route the nets, due to the lack of routing of specific nets in OpenRoad: [Feature request] Routing only specific nets OpenROAD#1747. Keep in mind that this feature is easy to implement.

After it's done I was supposed to fix nets and their connections and then pass it to the next stages. I was afraid that despite it being fixed, the flow would try to buffer it. It didn't happen, which is good.

Regarding the fact that Hi-Z was not supported, I just removed tristate to pull down logic from Yosys script. However, this is a backward compatability-breaking change.