Replace RISC-V specific Vendor ID in mvendorid with JEDEC manufacturer ID

[kasanovic]

This would avoid duplication of effort, given that chip makers already need/have a JEDEC code. It would also free Foundation from managing the vendor ID list. Registering a JEDEC code costs $500, and can be used for all chips from a manufacturer. mvendorid can always return 0 if no code available.

[kasanovic]

For soft cores, the vendor ID would be that of the softcore provider, who I guess might not otherwise need a JEDEC code, though this is still useful for debug port interrogation.

[kasanovic]

Updated spec.

[asb]

The specification should really indicate the mapping of JEDEC ids to a 32-bit register. JEDEC's encoding is very inefficient (assigned in "banks" of 7-bits, with a "continuation code"). They are beyond 9 banks now, so JEDEC's encoding wouldn't fit in a 64-bit register. Specifying the continuation bits be concatenated with the manufacturer code would be the logical encoding.

EDIT: and this is used by e.g. by ARM, though they've made the mistake of having multiple alternative encodings. We should decide upon one, so if ARM were to make a RISC-V core, we should document it so people can expect to read 0x23B rather than 0x7F 0x7F 0x7F 0x7F 0x3B or any of the alternatives.

[aswaterman]

Good point @asb; I believe the debug spec already writes up how it maps to 32 bits, so we can crib that text.

[aswaterman]

mvendorid[6:0] = JEDEC[6:0]
mvendorid[XLEN-1:7] = number of 0x7f continuation codes

[asb]

Fixed by 2447f7421b0f4

[kasanovic]

This representation is standardized in section 11.2.1 (Manufacturer Identity code) of JTAG 1149.1 standard and is what I intended.