[ROM] Enable Schmitt trigger in pads (via pinmux) where beneficial

[andreaskurth]

Earlgrey's pads feature a Schmitt trigger, which can be enabled per DIO and MIO in pinmux and which can improve signal integrity for certain use cases / protocols.

We should go through our ROM code and check

• which DIOs and MIOs ROM uses
• for which DIOs and MIOs ROM locks the PAD_ATTR register (by setting the corresponding REGWEN)

and investigate if any of the uses / locks would benefit from having Schmitt trigger enabled. (One example that was mentioned might be SPI Clock.) Where it is beneficial, we should enable the Schmitt trigger.

We should check the timing tables in the datasheets of the relevant target devices and compare them to the characteristics of the Schmitt trigger in Earlgrey before we commit to this change. If the FPGA pads feature a comparable Schmitt trigger (to be checked), we should additionally test this with the relevant target devices connected to Earlgrey on an FPGA.

For DIOs and MIOs not used or locked by ROM, we can later enable the Schmitt trigger in mutable code if we find that the need arises.

[andreaskurth]

To be resolved before ROM release --> assigned to M5.

[cfrantz]

I think we should make the enabling of Schmitt triggers by ROM an OTP configuration option.

This means we don't have to decide now exactly which pads would benefit from Schmitt triggers and allows the sku_creator to decide what is appropriate for their environment.

[a-will]

and investigate if any of the uses / locks would benefit from having Schmitt trigger enabled. (One example that was mentioned might be SPI Clock.) Where it is beneficial, we should enable the Schmitt trigger.

SPI_DEV_CLK almost certainly should not have the schmitt trigger enabled, not unless they have only a very short delay. This is a high-performance input in many cases, and delays are deleterious to transfer rates. Instead, the board design should handle signal integrity so the channel performs as desired.

Edit: I might be confusing the effect of the I2C pad's 50 ns glitch filter and the schmitt triggers, though!

[cfrantz]

and investigate if any of the uses / locks would benefit from having Schmitt trigger enabled. (One example that was mentioned might be SPI Clock.) Where it is beneficial, we should enable the Schmitt trigger.

... Instead, the board design should handle signal integrity so the channel performs as desired.

Are there any pads then that would benefit from schmitt triggers?

• The strapping pins don't seem like they'd have much benefit - they're effectively const-value apart from the pull-up/down probing we do to determine the 64 combinations in 3 inputs.
• The UART seems like its a low-speed peripheral and the ROM never uses the UART input.
• The SPI device pins should have their SI handled by board design.

I'd be happy to forego adding this to the ROM if it really isn't going to be useful.

[a-will]

and investigate if any of the uses / locks would benefit from having Schmitt trigger enabled. (One example that was mentioned might be SPI Clock.) Where it is beneficial, we should enable the Schmitt trigger.

... Instead, the board design should handle signal integrity so the channel performs as desired.

Are there any pads then that would benefit from schmitt triggers?

• The strapping pins don't seem like they'd have much benefit - they're effectively const-value apart from the pull-up/down probing we do to determine the 64 combinations in 3 inputs.
• The UART seems like its a low-speed peripheral and the ROM never uses the UART input.
• The SPI device pins should have their SI handled by board design.

I'd be happy to forego adding this to the ROM if it really isn't going to be useful.

I might've jumped to conclusions: Data sheets suggest the effect of the schmitt triggers for intrinsic delay is small, and the model for extra propagation delay likely relies on slew rate vs. the augmented Vih / Vil for hysteresis.

I thought the 50 ns glitch filter was provided by the schmitt triggers, but it looks to be a separate feature of the I2C pads. Incidentally, this means that I2C wouldn't be spec-compliant on the ordinary pads, since we don't have a digital glitch filter in the IP.

[a-will]

If the FPGA pads feature a comparable Schmitt trigger (to be checked), we should additionally test this with the relevant target devices connected to Earlgrey on an FPGA.

The FPGAs do not have an option for schmitt triggers. :smile:

[cfrantz]

We declined to submit the change that would enable Schmitt triggers; we believe signal integrity issues should be handled by board design.

Re-evaluate if we need to do a metal-layer ROM update in the future.