-
Notifications
You must be signed in to change notification settings - Fork 75
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
Comments
the jtag_id input can be tied to any value, including 0, not sure why the change is needed. .. |
The discussion in 289 elaborates on why we decided to remove the command entirely. |
a) I don't see enough justification of this change in the discussion. There is no many gates will be saved |
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. |
|
I filed riscv/riscv-debug-spec#924 so we'll see what the RISC-V Debug folks have to say about this case. |
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
The text was updated successfully, but these errors were encountered: