Alex Williams

Use the pinmux pad controls to set pull ups. See https://opentitan.org/book/hw/ip/pinmux/doc/registers.html#dio_pad_attr--pull_select

I'm mostly making this available so others might take it further (or possibly direct me to the flow that needs modification). It seems like DV's OTP generation is doing its...

I'm not reproducing the issue here. I made just this change to `//sw/device/tests:pwrmgr_deep_sleep_all_wake_ups_silicon_owner_sival_rom_ext`: ```diff diff --git a/sw/device/tests/sim_dv/pwrmgr_sleep_all_wake_ups_impl.c b/sw/device/tests/sim_dv/pwrmgr_sleep_all_wake_ups_impl.c index 65afc74b00..060574aca3 100644 --- a/sw/device/tests/sim_dv/pwrmgr_sleep_all_wake_ups_impl.c +++ b/sw/device/tests/sim_dv/pwrmgr_sleep_all_wake_ups_impl.c @@ -38,15 +38,23 @@ dif_usbdev_t...

No, that means it showed a value of 0x1 (i.e. bit 0, for sysrst_ctrl)). It would fail if it woke up for some other reason. At least, that is what...

@GregAC @marnovandermaas @moidx for triage / discussion on the `ac_present` detector front. Jes suggests using KEY_INVERT_CTL is problematic because they intend to lock it. @jesultra Is the REGWEN story similar...

I'll just note that the pad attributes originate rather directly from CSRs: https://github.com/lowRISC/opentitan/blob/90f79898a7aef54110511d8a9c54eb54720aa233/hw/ip/pinmux/rtl/pinmux.sv#L213-L218 The CSR values get masked through a technology-specific prim_pad_attr: https://github.com/lowRISC/opentitan/blob/90f79898a7aef54110511d8a9c54eb54720aa233/hw/ip/pinmux/rtl/pinmux.sv#L265-L273 And they are then passed directly to...

> Related to this, in Earlgrey's SDC we restrict STA to the case where `od_en` is disabled: > > https://github.com/lowRISC/opentitan/blob/ab878b5d3578939a04db72d4ed966a56a869b2ed/hw/top_earlgrey/syn/chip_earlgrey_asic.sdc#L1073-L1078 > > I understand that we don't need to close...

`prim_generic_pad_wrapper` is for simulation only. But the point about hazards with mixing open-drain and signal level inversion is an interesting one. The original code is correct here, though. I think...

This reminds me... We have IPs that do virtual open-drain internally, and the logic connecting it to a pad in either open-drain mode would need to understand that. This can...

The issue is primarily with UartConsole::wait_for(). https://github.com/lowRISC/opentitan/issues/20580#issuecomment-1862107661 The UartConsole wants to search a buffer for matches, and when the search "reads" from the underlying UART buffer, the read is destructive...