brentms

@Michael Simmons - thank you for the feedback. responses below: General question on Multiple IPs: Is it correct that each IP provider will contribute their own SWKB databases to be compiled with others? Will the SWKBs be inspectable for completeness or correctness? How would conflicting entries be handled? Are there checks for tampering? [brent] - The SWKB can be proprietary however the entries that are applicable to the IP must be shared with the Integrator. The relationship between the IP Supplier and Integrator is trusted therefore tampering should not be a concern. The Integrator has the capability to verify all created data objects for correctness and completeness. page 7, line 14: Is it an eventual goal for the EDA tools to generate the Element objects? Does “created manually” mean tools can be internally developed or open-sourced? [brent] - Yes. page 7, line 20-22: Does tool used for verifying data objects need to be the same tool used to generate data objects? [brent] - It doesn't have to be the same tool however it must follow the standard. To expand, given the same input, the tools must produce the same output. Figure 4, Asset Definitions? [brent] - There may be more than one however the standard refers to data objects as singular. Section 7.4: Can more examples be given regarding "Elements"? Are these like waveforms or lint-checker results? [brent] - Examples are provided in section Annex B. They are JSON data objects. The workgroup is developing some demos to help illustrate the workflow using tools. The demos will be showcased in the security embedded track at DAC'21. page 11, line 19: There is no "Ports" attribute in the APSO in Figure 5 but clarified in Table 6 four pages later. You should make this clarification sooner like done for "Name" and "Asset Name" on line 20. [brent] - Good feedback. I've updated the standard to reflect your suggestion.

@Bas Arts - yes, we had several discussions about xml vs json. we chose json for its simplicity and ease of use. since there are online converters, a tool could support both if need be.

@Darren Galpin - Thank you for the feedback. I updated the standard to reflect your suggestions.

Hi Anupam - Thank you for the feedback. Responses below: #1 - It seems the addressable register configuration is better categorized as an asset or part of the attack surface, not a type of IP Family. If this doesn't address your concern, please let me know. #2 - The scope is in reference to the Condition which may be different from the Asset's scope (e.g. the Condition could be located in another module). In the next release, we will clarify this. Thank you for bringing this to our attention. #3 - Oversight. Will include in the next release. Thanks, Brent

hi sergio, thank you for the feedback! good recommendation. it is somewhat called out in table 3 in the insertion section of the "Mitigations" field. to see examples, refer to table 7. however i agree with you, we need better language around this. thanks, brent