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

Remove (or make optional) the JTAG IDCODE command #146

Open
calebofearth opened this issue Dec 11, 2023 · 6 comments
Open

Remove (or make optional) the JTAG IDCODE command #146

calebofearth opened this issue Dec 11, 2023 · 6 comments

Comments

@calebofearth
Copy link
Contributor

Similar to what was done here: chipsalliance/caliptra-rtl#298, we request that the VeeR core implement configurability that allows integrators to remove support for the JTAG IDCODE command. This IP block is expected to be integrated into a larger system with it's own JTAG IDCODE defined, so keeping a block-level IDCODE is not necessary.

See also the discussion here: chipsalliance/caliptra-rtl#289

@algrobman
Copy link

the jtag_id input can be tied to any value, including 0, not sure why the change is needed. ..

@calebofearth
Copy link
Contributor Author

The discussion in 289 elaborates on why we decided to remove the command entirely.

@algrobman
Copy link

a) I don't see enough justification of this change in the discussion. There is no many gates will be saved
b) SOC with multiple different RISCV cores may need a way for identification them separately by the debugging tools like OpenOCD to take appropriate actions.
c) what will be reaction of the tools like OpenOCD if it can't read JTAGID?
d) Veer needs different JTAGID setting as it's not WDC part anymore

@calebofearth
Copy link
Contributor Author

From IEEE Std 1149.1™-2013 (section 12.1.1), IDCODE bit 0 is required to be 1, so using a 0 value would not be a legal solution.

The impetus is not about saving gates, but about removing erroneous manufacturer information. Leaving the IDCODE instruction as optional will allow integrators to identify the RV core in their chips, as necessary. I don't see a ChipsAlliance (or other relevant manufacturer) ID defined in JEP106, so this fix just resolves the ambiguity.

@algrobman
Copy link

From IEEE Std 1149.1™-2013 (section 12.1.1), IDCODE bit 0 is required to be 1, so using a 0 value would not be a legal solution.
Exactly - this may cause some JTAG tools to malfunction and complain.
Besides RISCV debug spec requires:

6.1.2 JTAG DTM Registers
JTAG TAPs used as a DTM must have an IR of at least 5 bits. When the TAP is reset, IR must
default to 00001, selecting the IDCODE instruction
. A full list of JTAG registers along with their
encoding is in Table 6.1. If the IR actually has more than 5 bits, then the encodings in Table 6.1
should be extended with 0's in their most signi cant bits. The only regular JTAG registers a
debugger might use are BYPASS and IDCODE, but this speci cation leaves IR space for many
other standard JTAG instructions. Unimplemented instructions must select the BYPASS register.

@steven-bellock
Copy link

I filed riscv/riscv-debug-spec#924 so we'll see what the RISC-V Debug folks have to say about this case.

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