https://open-source-silicon.dev logo
#openlane
Title
# openlane
a

aryap

11/18/2020, 11:28 PM
is there a particular reason the openlane yosys script avoids
tribuf
for tristate inference?
looks like we can do a manual techmapping to ebuf
f

FatsieFS

11/19/2020, 12:14 PM
Problem with tristate signals is that they can't be buffered and digital P&R tools depend on being able to insert buffers in heavily loaded signals.
a

aryap

11/19/2020, 6:58 PM
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.
f

FatsieFS

11/19/2020, 8:48 PM
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.
a

aryap

11/20/2020, 9:04 PM
i think you think i'm writing RTL to implement on an FPGA?
i'm RTL to implement an FPGA.
writing*
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 🙂
f

FatsieFS

11/21/2020, 2:04 PM
You then need to make sure the P&R tools don't touch the net connected to the output of the tri-state buffers. OK, if you do P&R manually, likely not OK if you want to use OpenLANE flow for P&R.
a

aryap

11/24/2020, 4:16 AM
correct
i'm concerned by the suggestion that the P&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
f

FatsieFS

11/24/2020, 11:57 AM
P&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&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.
a

aryap

11/25/2020, 7:15 AM
tri-state buffer sizing doesn't matter since we have to map it to a cell manually anyway. i understand why p&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
f

FatsieFS

11/25/2020, 9:36 AM
Just to be sure that we are on the same page. You also have to avoid that the P&R tool wants to do the following which is a problem:
Copy code
TRIBUF → BUS ← TRIFUB
into
Copy code
TRIBUF → BUF → BUS ← TRIBUF
which is a problem. Remember that bus may a long net where P&R wants to insert buffers.
a

aryap

11/25/2020, 7:24 PM
yes i'd like that to be turned off
but
Copy code
TRIBUF -> 
          \
           BUS -> BUF -> MORE BUS
          /
TRIBUF ->
is not a problem
3 Views