Restricted use of inout ports

[thack123]

Hi Sephan,

would it be possible to restrict the use of InOut ports to the design top level? At least in the EFINIX development environment, top-level InOut ports are only permitted via an explicit description, IN / OUT / OUT_EN. Therefore, whenever I want to use a new version of your core, I have to patch several files. It is easy to derive the additional 'Z' state in the top module from the necessary signals for e.g. TWI. Unfortunately it doesn't work the other way around.

Greetings
Thomas

[stnolting]

Hey @thack123,

I think this is a really good idea! I also had some issues with "deeply burried" tri-state drivers when playing with Xilinx block designs.

[stnolting]

So, do you propose to move all tri-state drivers out of the NEORV32 design (i.e. just having uni-directional data an enable signals inside the top's interface)?

[thack123]

Yes, I think that would be the best solution.
Perhaps TWI can then be implemented as an example within the test setups.

[stnolting]

Right now the test setups do not require any of the tri-state interfaces (TWI & NEOLED). I would like to keep them as simple as possible. But we could add some VHDL and Verilog snippets to the according sections of the documentation to illustrate how to implement suitable tri-state drivers? 🤔

[thack123]

yes, that would be ok too!

[vhdlnerd]

As a current user of the core, I'm not a fan of needing to redo my top level with an "I/O-ring" around the core.
How about leaving the current core top as is (in regards to the ports), but the core top is now the I/O ring (creating the tri-state buffers) around a lower level core top that has all the I/O unidirectional. Then the user can choose which top level to use.
Does that make sense?

[thack123]

I understand your point. However, adding another intermediate layer would complicate the design (and maintenance) since the package module also needs to be changed. Changing your design toplevel, on the other hand, is straightforward.
Copy the relevant part from the current top module once and you're done.
copied from neorv32_top.vhd
-- Tri-state driver --
twi_sda_io <= '0' when (twi_sda_o = '0') else 'Z'; -- The module can only actively pull the line low
twi_scl_io <= '0' when (twi_scl_o = '0') else 'Z';
twi_sda_i <= to_stdulogic(to_bit(twi_sda_io)); -- "to_bit" to avoid a discrepancy between hardware and simulation
twi_scl_i <= to_stdulogic(to_bit(twi_scl_io));

[stnolting]

As a current user of the core, I'm not a fan of needing to redo my top level with an "I/O-ring" around the core.

I don't like that either 😅 But I think that would be the "cleanest" way. Especially because the tri-state signals are of type std_logic and I don't really like having different signal types in the same entity.

How about leaving the current core top as is (in regards to the ports), but the core top is now the I/O ring (creating the tri-state buffers) around a lower level core top that has all the I/O unidirectional. Then the user can choose which top level to use.
Does that make sense?

I also thought about this, but that would mean adding another top level to the design that requires maintaining 🙈 But on a second thought, we already have this kind of "integration" wrappers in rtl/system_integration... So maybe it would not hurt to add another wrapper there that provides tri-state ports.

I'm not sure... What do you think?

[vhdlnerd]

Also considering GideonZ comments, add an integration wrapper (at most) and leave the core work only in and out ports. That's my vote now.

I'm not sure why I was complaining anyway, I don't think I'm even using any of the bi ports. 😃

[GideonZ]

I hope you still appreciate my 2 cents on this topic, but in my opinion there should be no tristate pins on any IP block. NeoRV32 is an IP block, not a top-level. Therefore, there should be an I/O ring. In 99% of the cases you will need an I/O ring anyway, whether it is for instantiating a PLL, a memory controller, or whatever. The NeoRV32 is a very complete system (my compliments!), but if you just need a SoC, you better buy a SoC-like device, instead of an FPGA. In my opinion there is always something "of your own" in the FPGA, something that is not part of the NeoRV32 SoC. The benefit of I/O rings is also that they can be vendor specific, while the NeoRV32 is fully vendor agnostic. In my IP, I usually use the _i, _o, _t postfixes for signals that -together- make a tristate I/O.

[stnolting]

I agree! 👍

In my IP, I usually use the _i, _o, _t postfixes for signals that -together- make a tristate I/O.

Looks good! But I think two signals for each tri-state signal should be enough in this case, as all those signals (TWI SDA & SCL, NEOLED data) can only be driven low (actively) by the processor.

As an example, the signals for the TWI module could look like this:

twi_sda_i : in  std_ulogic;
twi_sda_o : out std_ulogic;
twi_scl_i : in  std_ulogic;
twi_scl_o : out std_ulogic;

[stnolting]

I made a first proposal for implementing this in #543.

[GideonZ]

In my IP, I usually use the _i, _o, _t postfixes for signals that -together- make a tristate I/O. Looks good! But I think two signals for each tri-state signal should be enough in this case, as all those signals (TWI SDA & SCL, NEOLED data) can only be driven low (actively) by the processor.

Ah yes, bu then it's not tri-state, but bi-state, in particular "open drain". ;-) Yeah, the _o and _i are then enough. Super! 👍👍

…

Message ID: <stnolting/neorv32/repo-discussions/538/comments/5257655@ github.com>

[stnolting]

Haha, good point! 😅

[thack123]

Thank you, that saves a lot of time!