InOut in Signature

[tclarke]

I'm creating a signature for a bus with a bidirectional data. With verilog I'd normally mark this as inout and create some comb to set the direction based on the current operation. I know I can use an IoBufferInstance to handle connecting the appropriate lines to the bus with a tristate option. My question is, how do I indicate that it's an inout in the Signature?

[whitequark]

You can't. lib.wiring interfaces are collections of signals, and signals in Amaranth are strictly unidirectional, with a single driver and any number of loads. IOBufferInstance can only be used at the boundary of a device (FPGA or ASIC) and not for communication within the device.

For buses that need to transfer data in both directions, use two members, like i_data and o_data.

[tclarke]

What if I need to communicate with other non-amaranth modules that are using inout? I'll also be connecting the bus signals to external pins on the FPGA to a standard bus with bidirectional lines.

[whitequark]

In those cases you should use IOBufferInstance (for communicating with other modules that use inout), or lib.io.Buffer (for external pins, especially if you are using the Amaranth platform interface).

Note that not all FPGA synthesis toolchains support internal inout signals. In particular Yosys has never had a complete implementation, and I wouldn't recommend using internal inouts. (I realize this may not always be possible, and some cases will work fine, but there is a good chance you will encounter issues).

The reason Amaranth doesn't have first-class support for bidirectional signals within the device is because modern FPGAs don't have them at all, and similarly their use in modern ASICs is quite limited. Rather than complicate the base language with a now-unusual primitive that is not well-supported in all toolchains, we chose to relegate inout signals to be second-class and require explicit buffering.

I hope this clarifies.

[tclarke]

Thanks for the info! I'm building an FPGA based peripheral for debugging a STEbus retrocomputer so I need to follow the bus spec at least on the edges. If I need to, I can use 2 bus lines and just buffer at the edges.

[whitequark]

Ah, retrocomputing would explain it. Yes, buffering at the edges is the most reliable solution by far and is what I will recommend. In this case, I imagine you would want to provide the IOValues to verilog.convert explicitly.