[padctrl] Additional Pinmux Features

[msfschaffner]

This issue came up during our recent silicon meeting, and deals with the question whether additional features such as hardware selection signals and custom design-time default mappings are needed for our basic v0.5 target.

Some background first:

• The current pinmux implementation just uses a global default value for all periph and pad mux-select signals when coming out of reset, which basically causes all peripheral inputs to be tied to constant 0, and all MIO pad outputs to be set to high-Z.
• All mux select signals are connected to SW controllable CSRs in the pinmux, and there is no way to use other signals coming from hardware to steer the muxes.
• Available peripheral IOs can either go through the full pinmux (MIOs), or they bypass the pinmux and become dedicated IOs (DIOs). There is no other way at the moment to specify the partial mux connectivity in the top-level .hjson (i.e., we cannot specify the full connectivity matrix).
• See pinmux spec for more info.

Open points (feel free to add more if you come across them): 1) Do we need custom default mappings at reset for our current boot sequence (e.g., for UART TX, or some GPIO pin that needs to be sampled), or can we rely on the bootrom to program the pinmux before anything is transmitted through MIO? 2) How shall we deal with the SPI / JTAG ports that are currently muxed using a DIP switch input signal?

In both cases we could just work around using DIOs at the moment, and wire the signals up by hand in top_earlgrey. I.e., UART could be directly connected to DIOs instead of going through the pinmux, and SPI / JTAG could be muxed using a dedicated mux steered by a DIP switch signal that is mapped to DIO. This may however lead to a target-dependent code section in top_earlgrey, and we may have to use an 'ifdef for that.

Is that acceptable, or should we expedite some of the features such that they can make it into the v0.5 code-base in time?

[tjaychen]

thanks for the detailed issue @msfschaffner !

regarding open points IMO, at the moment, the only signals we need to have hardware mapped is in fact JTAG. All other functions can wait until boot ROM has done some level of checking and sanity validation. This could change in the future if we want some kind of power up debug mode, but we'll probably get to that later.

For JTAG , it will eventually be muxed onto SOME functional pins (may be SPI, may be something else), so it would be good to have a generic / scaleable way to change that (these are probably the extra features you're talking about). My opinion is that we should probably gauge how much work it is to do that, and if feasible (meaning it does not impact other items that are already green-lit for 0.5), we should try to get it into 0.5. I don't see it as something we urgently need though.

[sjgitty]

A note from minimum-perturbation land: we could have UART_TX be a DIO to start with, to reduce changes to existing hello_world type programs.

A note from proof-of-concept land: SPI device pins do not need to be DIOs at this time, but we could leave them as such to show the difference between DIO and MIO (if we don't do UART_TX as above). Also would reduce programming by spiflash and boot ROM where those pins are needed for code loading.

[asb]

I don't think we need to expedite any of this prior to 0.5 (other than making a decision as to whether at least initially UART is DIO or MIO). I think it will be useful to add support for default pinmux setup that would allow e.g. zero-config UART while still allowing it to be modified later using the pinmux IP.

But if someone wants to propose that instead we rely solely on the boot ROM for setting "default" config, I'd be interested in discussing the trade-offs.

[tjaychen]

@msfschaffner i think everyone described here has been implemented in some way. What do you think? Feel free to close the issue.

[msfschaffner]

Indeed, this one can be closed down. Thanks!