Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose debug ports as a RISC-V Debug Module #365

Closed
steven-bellock opened this issue Dec 27, 2023 · 6 comments
Closed

Expose debug ports as a RISC-V Debug Module #365

steven-bellock opened this issue Dec 27, 2023 · 6 comments

Comments

@steven-bellock
Copy link
Contributor

Previous issues:

To debug the firmware on Caliptra's RISC-V processor caliptra_top requires

//JTAG Interface
input logic jtag_tck, // JTAG clk
input logic jtag_tms, // JTAG TMS
input logic jtag_tdi, // JTAG tdi
input logic jtag_trst_n, // JTAG Reset
output logic jtag_tdo, // JTAG TDO

and a TAP controller is instantiated within Caliptra. Most (all?) Integrators of Caliptra will already have a top-level TAP controller and so Caliptra's instantiation of one is excessive and unneeded. In particular caliptra_top should be treated as a RISC-V Debug Module and expose the RISC-V DMI ports

input logic dmi_reg_en, // read or write
input logic [6:0] dmi_reg_addr, // address of DM register
input logic dmi_reg_wr_en, // write instruction
input logic [31:0] dmi_reg_wdata, // write data
output logic [31:0] dmi_reg_rdata,

@calebofearth
Copy link
Collaborator

Clarification question:
This feature needs to be implemented by the VeeR team since there is no current mechanism to export just the DMI ports from EL2 VeeR core.
Do you propose waiting until we can discuss this feature within the Caliptra community and reach consensus before filing this request to the VeeR team?

@steven-bellock
Copy link
Contributor Author

Caliptra can either

  1. Instantiate el2_veer instead of el2_veer_wrapper OR
  2. Request an option that the DMI ports be exposed in el2_veer_wrapper instead of the TAP ports as well as removing the TAP controller entirely from el2_veer_wrapper.

But in either case this entire issue should be discussed and approved broadly before implementing.

@bharatpillilli
Copy link
Collaborator

Resolved with this? =-> #415

@steven-bellock ?

@steven-bellock
Copy link
Contributor Author

Resolved with this? =-> #415

No, this is more far-reaching. For security, most folks will just tie Caliptra's JTAG inputs to 0. If Caliptra is being integrated into an SOC and they want the ability to debug the microcontroller, then this enhancement is desirable since it's a cleaner solution. Would like to hear @nstewart-amd's thoughts as well.

@bharatpillilli
Copy link
Collaborator

You can control microcontroller by sending JTAG commands - and the command can be mastered to CLTAP at SoC level. This jtag can be treated as slave TAP controller or a TAP EP under the control of CLTAP. What are we missing?

@bharatpillilli
Copy link
Collaborator

Spoke to few other indusrty experts and my statements match to what other uCs do and how other IPs integrate in their environment on the TAP chain. Closing the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants