open-source-silicon.dev

is there a particular reason the openlane yosys script avoids `tribuf` for tristate inference?

looks like we can do a manual techmapping to ebuf

Problem with tristate signals is that they can't be buffered and digital P&amp;R tools depend on being able to insert buffers in heavily loaded signals.

that's not a reason to not support them in the flow. our design needs tri-state signals.

i also dont understand why "tristate signals" can't be buffered. that seems like a limitation of the tooling; if you're driving a bus with multiple tri-states you should be able to buffer it as if it was high or low.

The output of a buffer is always hard 0 or 1 as it does not know when input is high impedance. So it will have drive conflict with other drivers on the bus that are not in tristate.

FYI, most FPGAs don't support tri-state signals either on signal level so they transform RTL using tri-state to something without tri-states on a higher level. Implementing this is in Yosys is non-trivial.

i think you think i'm writing RTL to implement on an FPGA?

so, yeah. you can insert buffer cells where needed by assuming any multi-driven bus is in a particular state (1 or 0). you are then able to design the bus so that it is always driven by exactly one driver. our FPGA logic won't support tri-state signals, but the FPGA fabric itself will be built with them. all yosys has to do is synthesise a tri-state buffer from the verilog, which it does just fine :slightly_smiling_face:

You then need to make sure the P&amp;R tools don't touch the net connected to the output of the tri-state buffers. OK, if you do P&amp;R manually, likely not OK if you want to use OpenLANE flow for P&amp;R.

i'm concerned by the suggestion that the P&amp;R tools would change net connectivity, though. buffer insertion is fine, that won't change correctness. any logic simplification should be restricted to the synthesis tool and thus controlled

P&amp;R tools assume no tri-state logic so buffer insertion may be put it in the wrong place on a tri-state bus when tri-state buffers are allowed. The tool will most likely also not be able to do proper sizing of the tri-state buffers for the capacitive load of the bus.
Reason P&amp;R tools are allowed to do also logic optimization is that the synthesis tool can't take the placement and routing impact on timing into account. You can compare it to peephole optimization in classic compilers.

tri-state buffer sizing doesn't matter since we have to map it to a cell manually anyway. i understand why p&amp;r might do logic optimisation around our cells but i'm more interested in how to turn it off, since we have a legitimate design goal in using these tri-states

Just to be sure that we are on the same page. You also have to avoid that the P&amp;R tool wants to do the following which is a problem:
```TRIBUF → BUS ← TRIFUB```
into

```TRIBUF → BUF → BUS ← TRIBUF```
which is a problem.
Remember that bus may a long net where P&amp;R wants to insert buffers.

but
```TRIBUF -&gt; 
          \
           BUS -&gt; BUF -&gt; MORE BUS
          /
TRIBUF -&gt;```
is not a problem