Issue #1373

Cannot write to top-level tristate ports

DESCRIPTION of the bug:
Top level has bidirectional port bus1 and direction bit en1. When
en1==0, bus1 is used as an input port, else it is an output port.
When bus1 is an output it reads an internal id code (13333).
A result port emits the value (bus1+10000).

Then test harness sets en1==1 for five clock cycles, hoping to see
result 23333, which succeeds.

Then test harness sets en1==0 and writes sequential values (1,2,3,4,5) to
bus1, hoping to see result (10001,10002,10003,10004,10005).
This fails, we see only zeroes on bus1 (below).
Why?

History

Verilator doesn't currently support tristate resolution that is a mix of external and internal drivers.

What it should be doing is what it does for internal cell tristate resolution, that is make a bus1, bus1__en, and bus1__out primary signals, your code then needs to drive bus1 and bus1__en appropriately, and Verilator will compute the resolving equation and output bus1__out.

Would you be willing to take a look at fixing this? The code that resolves tristates is in src/V3Tristate.cpp.

Hm I am not currently set up to compile verilator from source, but I suppose I could put it on my to-do list (i.e. may or may not get done in finite time).

FYI our current workaround is to separate each top-level IO pad "pad_i" into two separate pads "pad_i_in" and "pad_i_out" for verilator simulation, similar to your suggestion; then for the actual chip we reunite the pads and use ncsim for the final verification. This tristate bug is the last/only thing that keeps us from using the same verilog code base for both verilator and ncsim...