chipsalliance / Cores-VeeR-EL2

VeeR EL2 Core
https://chipsalliance.github.io/Cores-VeeR-EL2/html/
Apache License 2.0
247 stars 74 forks source link

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

Open calebofearth opened 9 months ago

calebofearth commented 9 months ago

Similar to what was done here: https://github.com/chipsalliance/caliptra-rtl/pull/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: https://github.com/chipsalliance/caliptra-rtl/issues/289

algrobman commented 9 months ago

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

calebofearth commented 9 months ago

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

algrobman commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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 commented 9 months ago

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