request to improve the generality of STF LIB #3
Description
I'm promoting a case for more generality in STF LIB records. I believe more generality improves likelihood of broader adoption of the lib.
The STF specification makes assumptions about record formats etc, which precludes using an unmodified STF_LIB, and associated tools outside a range of ISAs. Addition of USER defined settings would help.
ATM the library is strongly organized around the assumptions of RISC-V. There are enums for the others but attempting to implement tracing for the unsupported variants of known ISAs, implement tracing for user defined ISAs, or a custom extensions, can not be done without forking the library.
I believe in some cases these restrictions could be relaxed, with little impact. In other cases these changes would be visible, but I believe these can be handled programmatically through modification to header information.
STF_INST_MEM_ACCESS: as I understand recent comments, this will be documented to require a byte based sizing. bits is more general, particularly in accelerators, not directly related but this is in the same spirit as STF_BUS_MASTER_ACCESS with understands the concept of user created ACCEL (accelerators I presume). Changing to bits allows more generality in particular accelerators with bit addressable memory.
STF_VLEN_CONFIG: VLEN is a RISC-V only naming convention, there are other vector implementations outside RISC-V
STF_PROTOCOL_ID would benefit from a USER enum
STF_ISA would benefit from a USER enum, or much wider support for other ISAs. There is a long list.
STF_INST_REG: limits scalar results to 64 bits, also bakes in VLEN which is a RISC-V only naming convention
STF_INST_MICROOP: this assumes fracture, 1:N where N>= 1, request that a new record type be created for the fusion case, or modify this record type to not assume 1:N
STF_INST_32/16: this bakes in support for only two instruction sizes. Request a more general approach, or some mechanism that supports a variety of encoding sizes.
ProtocolIdRecord would benefit from an explicit USER protocol. We will not always be using TileLink.