Hi Caliptra Team,
Regarding the JTAG connection described in the following document:
https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#tap-pin-muxing
The current diagram shows a TAP MUX being used to select the JTAG path. However, we would like to implement a daisy-chain approach instead.
Our current implementation blocks DMI transactions at the lower-level DMI wrappers (css_mcu0_dmi_wrapper and dmi_wrapper) by masking rd_data and reg_en_o, as shown below:
assign rd_data_i = (debug_intent | soc_hw_debug_en) ? rd_data : 32'b0;
assign reg_en = (debug_intent | soc_hw_debug_en) ? reg_en_o : 1'b0;
From a functional perspective, this prevents DMI access unless debug_intent or soc_hw_debug_en is asserted.
Would this modification be considered compliant with the Caliptra trademark requirements, or would replacing/modifying this logic impact trademark compliance?
Thanks for your guidance.
Best regards,
Hi Caliptra Team,
Regarding the JTAG connection described in the following document:
https://github.com/chipsalliance/caliptra-ss/blob/main/docs/CaliptraSSHardwareSpecification.md#tap-pin-muxing
The current diagram shows a TAP MUX being used to select the JTAG path. However, we would like to implement a daisy-chain approach instead.
Our current implementation blocks DMI transactions at the lower-level DMI wrappers (css_mcu0_dmi_wrapper and dmi_wrapper) by masking rd_data and reg_en_o, as shown below:
assign rd_data_i = (debug_intent | soc_hw_debug_en) ? rd_data : 32'b0;
assign reg_en = (debug_intent | soc_hw_debug_en) ? reg_en_o : 1'b0;
From a functional perspective, this prevents DMI access unless debug_intent or soc_hw_debug_en is asserted.
Would this modification be considered compliant with the Caliptra trademark requirements, or would replacing/modifying this logic impact trademark compliance?
Thanks for your guidance.
Best regards,