Why should payload type 0 be standardized?
Closed this issue · 7 comments
0: control packet
Control packets may be used in some applications (for example, the Siemens message infrastructure) for accessing configuration state.
There seems to be insufficient motivation to standardize the type value of 0 when all other type values are source specific. Considering that the only standard definition of control packet is a proprietary protocol all encoding's of type field should be source dependent.
That's a fair comment, and something that had occurred to me also. The type field is currently defined as default length of 2 and must be discoverable if larger. In the spirit of making this as general as possible, how do you feel about the following:
- type field default width is 0 and must be discoverable if larger
- (i.e. all packets from this source are the same type, which will be the most likely case for non-Siemens systems)
- In section 3.3:
- If type field width is 0, only instruction trace is supported
- If type field width is 1, 0 is instruction trace, 1 is data trace
- If type field width is 2, definition is as currently defined
Looks good but the type field width of 2 case can be just dropped as section 3 is about E-trace which only defines Instruction and data trace. The definition for width=2 can be provided by an application of encapsulation that uses such width.
Should type field default width be 1 bit to avoid a header with zero length.
Should type field default width be 1 bit to avoid a header with zero length.
We can say type field can be 0 width. We only need to state that payload must be at least 1 bit.
I'm sorry that I'm giving my comment a bit delayed. But if the document says that the type field width must be detectable if > 0, wouldn't it be better to also define how this detection should work?
I understand where you're coming from, and in an ideal world, yes it would. But this is just one of many attributes of a RISC-V system that have to be discoverable. The Unified Discovery TG is responsible for specifying a standard discovery mechanism for such attributes. It is unfortunate that this is not already in place, but we cannot hold off ratification of all specs that reference discoverable attributes until after this is done, and nor does it make sense for every spec containing a discoverable attribute to define it's own mechanism. As a result, this is out of scope for this spec,
I agree that it does not make sense to wait for the Unified Discovery TG. However, there are several counter-examples in the RISC-V environment where alternative discovery methods are defined.
From my point of view, this is understandable, especially as I understand that Unified Discovery will be optional. Furthermore, the addition of another dependency will make the creation of E-Trace solutions that already reference a number of other documents even more complex.
This will especially be the case if some E-Trace specialties, like the context field, require the presence of the unified discovery structure, which would otherwise be optional. I fear that this will confuse a significant number of chip designers.
In addition, the Common Trace Control Interface already reserves a certain amount of memory (0x0E0--0x0FF) for the sole purpose of recognizing trace encoder specifics. Don't you think this should be utilized somehow?
Do you think it makes sense to move this discussion elsewhere, as this is also relevant for E-Trace discoverable parameters?
Best regards, Michael
Yes, this is really a request to update the E-Trace spec to add register map definitions for the discoverable parameters. The DTPM SIG is the place to raise this.