zachjs
Improperly-handled inout ports
sv2v mishandles a bit-vector inout port where not all bits are headed the same direction
This zip file has all the info to reproduce sv2v_inout.zip
The body of its README is given here:
Short instructions: make succeeds, showing that sv2v processes oscope_top.sv, and the result has no syntax errors according to iverilog, verilator, and yosys. Also, that mmc_mailbox_tb is a valid exercise of the underlying Verilog driver spi_master.v.
make fail fails, showing that using the (sv2v_processed) oscope_top.sv as an interposer between the test bench and spi_master.v causes it to fail.
Even before getting to the failing test, inspection of oscope_top.v should set off alarm bells. The 4-bit inout bus_digitizer_U18, which resolves to an SPI bus controller with 3 outputs and 1 input, hits the Verilog statement assign bus_digitizer_U18 = zif.U18; That won't work for U18[1]. The logic expects that bit to be set by the inout port bus_digitizer_U18[1], and then fed to the sdo input of spi_master.
Complain all you want that this code structure is an abuse of Verilog bit-vectors. But it sure looks like 100% IEEE-compliant code, and some programmers seem to like its driver-encapsulation capability that hides details about the port from intermediate abstraction layers.
I see evidence that occasional people in the Verilog world have been doing this kind of thing since at least 2013.
P.S. In this example, each bit has a well-specified direction. But when encapsulating I2C or 1-Wire busses, one or more of the wires could be an actual 3-state signal. Handling that possibility might be even harder.
Is there any way to model this sort of bidirectional assignment in portable Verilog? If not, I believe this will be fairly difficult to implement for the general case.
Is there any way to model this sort of bidirectional assignment in portable Verilog?
Barely, maybe. See
synthesizable verilog - connecting inout pins (2013) https://adaptivesupport.amd.com/s/question/0D52E00006iHrFnSAK/synthesizable-verilog-connecting-inout-pins?language=en_US works in Vivado and iverilog. But not (yet) verilator or yosys. See
Support feedthroughs/non-ANSI complex ports (IEEE 1800-2017 23.2.2.1) https://github.com/verilator/verilator/issues/2844
Yosys does not accept module port lists with .port_identifier https://github.com/YosysHQ/yosys/issues/4708