Caliptra Subsystem Questions

[jchanga]

Hello,

A few questions arise as the team scopes and prepares for the integration of the Caliptra Subsystem. Your insights on the following questions would be greatly appreciated:

• Will subsystem RTL be wrapped by a top-level module or will each integrator be required to stitch subsystem together? If
  wrapped, will SS top include Caliptra core?
• What features from subsystem are required to support LOCK?
• What FW is provided for MCU? Can it be modified and/or expanded?
• What ROM is provided for MCU? Can it be modified and/or expanded?
• What is the role of the MCU ROM?
  • Subsystem arch spec states: "Support for MCU first fetch vector to direct towards MCU SRAM post reset". Please elaborate
• Is it expected that only MCU perform SOC specific initialization?
  • What does "initialization" include in this context?
• Is it expected that only MCU perform reset control and initial configuration?
  • See previous question on initialization
  • Why must GPIO programming be managed by MCU as mentioned in the spec?
  • Why must non-secret fuses be managed by MCU as mentioned in the spec?
• Is it expected that all FW be loaded from BMC?
• How is boot supported when there is no BMC?
• Is there a BMC model available for verification?
• TTR expectations
• How to handle exceptions?
  • Errors from BMC
  • Errors from Caliptra

Thanks,
Jonathan

[jchanga]

Additional question:
What is the mechanism for integrating user specific eFuse macro with the Fuse Controller (fure_ctrl) hardware module? 

[bharatpillilli]

Will subsystem RTL be wrapped by a top-level module or will each integrator be required to stitch subsystem together? If
wrapped, will SS top include Caliptra core?
- SS Integration spec will provide the specifics. Rather than answering in fragmented way, that might be better. ETA: End of Jan
What features from subsystem are required to support LOCK?
- Not a 2.0 question for now

What FW is provided for MCU? Can it be modified and/or expanded?
As it states here -> https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#caliptra-subsystem-architectural-requirements - this is manufacturer specific code. MCU FW team can provide what is added in the ROM for support

What ROM is provided for MCU? Can it be modified and/or expanded?
Same answer as above

What is the role of the MCU ROM?
Manufacturer specific code. If you can add any SOC HW bring up in pure HW (including non-secret fuse distribution, I3C init, PLL bring up, GPIO impedance programming etc. then you dont have to include a ROM and point the MCU FF to execute from MCI SRAM)

Subsystem arch spec states: "Support for MCU first fetch vector to direct towards MCU SRAM post reset". Please elaborate
Plz see above
Is it expected that only MCU perform SOC specific initialization?
What does "initialization" include in this context?
Is it expected that only MCU perform reset control and initial configuration?
See previous question on initialization
Why must GPIO programming be managed by MCU as mentioned in the spec?
Why must non-secret fuses be managed by MCU as mentioned in the spec?
Plz see above for all these questions.

Is it expected that all FW be loaded from BMC?
Depends on SOC; some FW may come in through OS drivers; anything before it that used to be in local device flash comes over I3C through streaming boot (recovery + PLDM protocol)

How is boot supported when there is no BMC?
This is your architecture/business specific decision. Please see OCP workshop slides for non-streaming boot flow (eg. using device's own SPI).

Is there a BMC model available for verification?
Some companies have published their code but I wld allow our FW team to answer that

TTR expectations

How to handle exceptions?
Errors from BMC
Please see OCP recovery spec and current implementations over i2c

Errors from Caliptra
If the question is Caliptra core, please see the 1.0 spec; there is no change.
If the question is Caliptra SS, that part of spec will be published soon (but MCU FW which is your SOC specific will handle based on the RAS requirements of your market). HW will provide the hooks of various errors (eg. ECC, NMI etc.)