[OpenTitan-tool] Bootstrapping should trigger a POR to ensure state is uniform at the start of tests

[drewmacrae]

After bootstrapping if opentitan-tool triggers a POR, tests will always start with just the POR bit set. This allows for simple tests that use the reset_info to determine that they're running the test software for the first time, and could resolve #13096

[a-will]

After bootstrapping if opentitan-tool triggers a POR, tests will always start with just the POR bit set. This allows for simple tests that use the reset_info to determine that they're running the test software for the first time, and could resolve #13096

To be clear, it only helps for the tests as they are run today. On top of the mask ROM, they would fail, since the mask ROM moves the reset reasons to the retention SRAM. 😄

Avoiding a test start with the software reset bit set allows tests that exercise software resets to freely do what they need.

[a-will]

The answer from the chip-level test meeting was "yes"

[drewmacrae]

I'm fairly certain it's currently mapped to a physical switch that we don't have control over. Should we remap it? Who should we ask about allocating an FPGA pin to this?

[a-will]

I'm fairly certain it's currently mapped to a physical switch that we don't have control over. Should we remap it? Who should we ask about allocating an FPGA pin to this?

If it is only mapped to the button right now, I'll take care of adding the GPIO to SAM3X.

[alphan]

I'm not sure if we really need this. Is there a reason why tests can't just check if the POR is set, instead of requiring that only the POR bit is set? Once they start, they clear the reset reasons anyway.

[a-will]

I'm not sure if we really need this. Is there a reason why tests can't just check if the POR is set, instead of requiring that only the POR bit is set? Once they start, they clear the reset reasons anyway.

Because the other reset reasons are reserved for the test to modify, and we do not require bootstrapping to occur as part of the test methodology across all platforms.

Issuing a POR is an extremely simple thing to do, and this expectation has already been baked in to tests. Let's just get it done.

[alphan]

Issuing a POR is an extremely simple thing to do, and this expectation has already been baked in to tests. Let's just get it done.

SGTM but it would be nice to make this optional to be able to verify a bootstrap sequence that ends with RESET.

[a-will]

Issuing a POR is an extremely simple thing to do, and this expectation has already been baked in to tests. Let's just get it done.

SGTM but it would be nice to make this optional to be able to verify a bootstrap sequence that ends with RESET.

Totally agreed 😄

It would merely become associated with a specific test now and be part of its stimulus. (Aside: similarly, we'll also want something for spi_device generic mode, since the bootstrapping changes now have caused it to lose coverage.)

[drewmacrae]

I think there are three unused pins here: https://cs.opensource.google/opentitan/opentitan/+/master:hw/top_earlgrey/data/pins_cw310.xdc;drc=a35f7687666385502591fafed977ab83475d19b6;l=71

[a-will]

I think there are three unused pins here: https://cs.opensource.google/opentitan/opentitan/+/master:hw/top_earlgrey/data/pins_cw310.xdc;drc=a35f7687666385502591fafed977ab83475d19b6;l=71

For the pin, we'll likely be using whatever is the highest unused USB_A* pin, possibly with inverted polarity (so the default is to not be in reset). The section you've got there is for a header, which will be useful for the hyperdebug version later.

Edit: Right... pins probably start high-impedance. So never mind on the inverted polarity part: We'll just attach a pull-up property on the FPGA side. But the principle is the same: Default to not being in reset.

[a-will]

It turns out the POR is already hooked up on CW310 via USB_A14. This pin was pretending to be a JTAG TAP reset, but because it is also used as a power-on reset, we're actually lacking a TAP reset pin. That cleanup will happen with the rest of the JTAG pins, several of which currently are multiplexed on top of the SPI pins.

[alphan]

#13277 should resolve this as a side effect.

[a-will]

Resolved by #13277. Thanks, @alphan!