Hi,
As discussed I have attached the API document that describes the design and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) - but questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not limited by this so if I have missed anyone off I apologise.
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Resend of document/email as per action from meeting on 9-Jun-2015.
Regards, Mike.
On 27/05/2015 17:29, "Mike Leach" Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the design and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) - but questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not limited by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1: 1. "Where the source is a core the decoder will be a PE decoder..." : Are we still talking about the "packet trace decoder" or something else?
2. "The protocol block will require..." : Are we talking about the "Protocol decode block"?
3. The reader must assume the "generic trace primitives" are the same as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2: 1. "The trace formatted frame decoder is provided..." : Are we talking about the "trace frame deformatter". Without using the same terms, there is no way to tell.
2. "A decode block can be attached..." : What is a "decode block"? I must assume we are referring to a "Protocol decode block".
Section 2.1.4: 1. "Packet processors and decoders can be...": Are we talking about the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1: 1. Is the "Trace Decode Block" the "Protocol decode block" presented in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2: 1. One must assume the green box labelled "stream protocol decode block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
2. I would add "Perf" in the "formatted trace source" box.
3. Should the "Trace Formatted Frame Decoder" be introduced somewhere in the documentation? Or maybe it was under a different name?
4. "... is the Stream Protocol decode block as previously described". I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the design and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) - but questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not limited by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
Hi Mathieu,
Thanks for the feedback. I'll not comment individually on each section other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
There will be a new version of the document published shortly which will include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
To the C++ question - the answer is yes. The work we are currently undertaking on the infrastructure and packet decoders is implemented in C++.
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 16 June 2015 17:52 To: Mike Leach Cc: coresight@lists.linaro.org Subject: Re: API Document
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1:
- "Where the source is a core the decoder will be a PE decoder..." :
Are we still talking about the "packet trace decoder" or something else?
- "The protocol block will require..." : Are we talking about the
"Protocol decode block"?
- The reader must assume the "generic trace primitives" are the same
as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2:
- "The trace formatted frame decoder is provided..." : Are we talking
about the "trace frame deformatter". Without using the same terms, there is no way to tell.
- "A decode block can be attached..." : What is a "decode block"? I
must assume we are referring to a "Protocol decode block".
Section 2.1.4:
- "Packet processors and decoders can be...": Are we talking about
the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1:
- Is the "Trace Decode Block" the "Protocol decode block" presented
in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2:
- One must assume the green box labelled "stream protocol decode
block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
I would add "Perf" in the "formatted trace source" box.
Should the "Trace Formatted Frame Decoder" be introduced somewhere
in the documentation? Or maybe it was under a different name?
- "... is the Stream Protocol decode block as previously described".
I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the design
and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) - but
questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not limited
by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
On 22 Jun 2015 5:54 pm, "Mike Leach" Mike.Leach@arm.com wrote:
Hi Mathieu,
Thanks for the feedback. I'll not comment individually on each section
other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
There will be a new version of the document published shortly which will
include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
To the C++ question - the answer is yes. The work we are currently
undertaking on the infrastructure and packet decoders is implemented in C++.
Is your current intention to change to C in the future? The discussion in the meetings had been that the library would be C based to maximise deployability. If the external interfaces of the library are C++ based that seems like it might cause problems binding to other languages.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 16 June 2015 17:52 To: Mike Leach Cc: coresight@lists.linaro.org Subject: Re: API Document
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1:
- "Where the source is a core the decoder will be a PE decoder..." :
Are we still talking about the "packet trace decoder" or something else?
- "The protocol block will require..." : Are we talking about the
"Protocol decode block"?
- The reader must assume the "generic trace primitives" are the same
as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2:
- "The trace formatted frame decoder is provided..." : Are we talking
about the "trace frame deformatter". Without using the same terms, there is no way to tell.
- "A decode block can be attached..." : What is a "decode block"? I
must assume we are referring to a "Protocol decode block".
Section 2.1.4:
- "Packet processors and decoders can be...": Are we talking about
the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1:
- Is the "Trace Decode Block" the "Protocol decode block" presented
in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2:
- One must assume the green box labelled "stream protocol decode
block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
I would add "Perf" in the "formatted trace source" box.
Should the "Trace Formatted Frame Decoder" be introduced somewhere
in the documentation? Or maybe it was under a different name?
- "... is the Stream Protocol decode block as previously described".
I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the
design
and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API)
- but
questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not
limited
by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended
recipient,
please notify the sender immediately and do not disclose the contents
to any
other person, use it for any purpose, or store or copy the information
in any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
My understanding with respect to C/C++ was that the library could be implemented in C++, but that there had to be a C callable API to facilitate easy bindings.
Best regards,
Tor Jeremiassen
--- Tor Jeremiassen, Ph.D. Senior Member Technical Staff SDO Foundational Tools Texas Instruments Ph: 832 939 2356 13905 University Lane Fax: 832 939 2015 Sugar Land, TX 77479 Email: tor@ti.commailto:tor@ti.com
From: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Mark Brown Sent: Monday, June 22, 2015 12:04 PM To: Mike Leach Cc: coresight@lists.linaro.org Subject: RE: API Document
On 22 Jun 2015 5:54 pm, "Mike Leach" <Mike.Leach@arm.commailto:Mike.Leach@arm.com> wrote:
Hi Mathieu,
Thanks for the feedback. I'll not comment individually on each section other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
There will be a new version of the document published shortly which will include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
To the C++ question - the answer is yes. The work we are currently undertaking on the infrastructure and packet decoders is implemented in C++.
Is your current intention to change to C in the future? The discussion in the meetings had been that the library would be C based to maximise deployability. If the external interfaces of the library are C++ based that seems like it might cause problems binding to other languages.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.commailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.orgmailto:mathieu.poirier@linaro.org] Sent: 16 June 2015 17:52 To: Mike Leach Cc: coresight@lists.linaro.orgmailto:coresight@lists.linaro.org Subject: Re: API Document
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1:
- "Where the source is a core the decoder will be a PE decoder..." :
Are we still talking about the "packet trace decoder" or something else?
- "The protocol block will require..." : Are we talking about the
"Protocol decode block"?
- The reader must assume the "generic trace primitives" are the same
as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2:
- "The trace formatted frame decoder is provided..." : Are we talking
about the "trace frame deformatter". Without using the same terms, there is no way to tell.
- "A decode block can be attached..." : What is a "decode block"? I
must assume we are referring to a "Protocol decode block".
Section 2.1.4:
- "Packet processors and decoders can be...": Are we talking about
the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1:
- Is the "Trace Decode Block" the "Protocol decode block" presented
in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2:
- One must assume the green box labelled "stream protocol decode
block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
I would add "Perf" in the "formatted trace source" box.
Should the "Trace Formatted Frame Decoder" be introduced somewhere
in the documentation? Or maybe it was under a different name?
- "... is the Stream Protocol decode block as previously described".
I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach <Mike.Leach@arm.commailto:Mike.Leach@arm.com> wrote:
Hi,
As discussed I have attached the API document that describes the design
and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) - but
questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not limited
by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.commailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.orgmailto:CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.orgmailto:CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
Hi,
We are implementing a set of components in C++, with an initial C++ API, which is designed to be then wrapped by a C API for those use cases that require it.
The C++ API will allow apps developers to create and manipulate library objects directly. In addition implementers of custom decode protocols can re-use much of the library base class infrastructure code to create a compatible component by just focussing on their decode algorithm.
The C API will have functions to create/destroy decoder objects along with a set of functions for driving data through the decoder. The these interface signatures will mirror to an extent the interfaces on the C++ objects in the library.
Key datatypes (e.g a decoded ETMv3 packet, an ETMv3 hardware configuration, a generic trace element) are passed through the interface are C structs/enums to ensure that interfacing to a non-C++ environment is easy. (trace is just a stream of bytes, so that is unchanged whatever the API).
For example, the ETMv3 hardware configuration structure - that defines how key registers in the etm are programming is defined in the header file as:-
typedef struct _rctdl_etmv3_cfg { uint32_t reg_idr; /**< ID register */ uint32_t reg_ctrl; /**< Control Register */ uint32_t reg_ccer; /**< CCER register */ uint32_t reg_trc_id; /**< Trace Stream ID register */ rctdl_arch_version_t arch_ver; /**< Architecture version */ rctdl_core_profile_t core_prof; /**< Core Profile */ } rctdl_etmv3_cfg;
The C++ implementation object is defined as:-
class EtmV3Config : public rctdl_etmv3_cfg { <manipulation / state interrogation methods in here> };
So the C++ encapsulation is slightly looser than normal - with some effectively public data members - but it eases the re-use in a C API.
This allows us to easily re-factor some existing C++ packet processors for ETMv3, ETMv4 and PTM, while maintaining the requirement for a C API.
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-----Original Message----- From: Jeremiassen, Tor [mailto:tor@ti.com] Sent: 22 June 2015 22:30 To: Mark Brown; Mike Leach Cc: coresight@lists.linaro.org Subject: RE: API Document
My understanding with respect to C/C++ was that the library could be implemented in C++, but that there had to be a C callable API to facilitate easy bindings.
Best regards,
Tor Jeremiassen
Tor Jeremiassen, Ph.D.
Senior Member Technical Staff SDO Foundational Tools Texas Instruments Ph: 832 939 2356 13905 University Lane Fax: 832 939 2015 Sugar Land, TX 77479 Email: tor@ti.com mailto:tor@ti.com
From: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Mark Brown Sent: Monday, June 22, 2015 12:04 PM To: Mike Leach Cc: coresight@lists.linaro.org Subject: RE: API Document
On 22 Jun 2015 5:54 pm, "Mike Leach" Mike.Leach@arm.com wrote:
Hi Mathieu,
Thanks for the feedback. I'll not comment individually on each section
other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
There will be a new version of the document published shortly which will
include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
To the C++ question - the answer is yes. The work we are currently
undertaking on the infrastructure and packet decoders is implemented in C++.
Is your current intention to change to C in the future? The discussion in the meetings had been that the library would be C based to maximise deployability. If the external interfaces of the library are C++ based that seems like it might cause problems binding to other languages.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 16 June 2015 17:52 To: Mike Leach Cc: coresight@lists.linaro.org Subject: Re: API Document
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1:
- "Where the source is a core the decoder will be a PE decoder..." :
Are we still talking about the "packet trace decoder" or something else?
- "The protocol block will require..." : Are we talking about the
"Protocol decode block"?
- The reader must assume the "generic trace primitives" are the same
as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2:
- "The trace formatted frame decoder is provided..." : Are we talking
about the "trace frame deformatter". Without using the same terms, there is no way to tell.
- "A decode block can be attached..." : What is a "decode block"? I
must assume we are referring to a "Protocol decode block".
Section 2.1.4:
- "Packet processors and decoders can be...": Are we talking about
the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1:
- Is the "Trace Decode Block" the "Protocol decode block" presented
in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2:
- One must assume the green box labelled "stream protocol decode
block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
I would add "Perf" in the "formatted trace source" box.
Should the "Trace Formatted Frame Decoder" be introduced
somewhere
in the documentation? Or maybe it was under a different name?
- "... is the Stream Protocol decode block as previously described".
I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the
design
and current implementation of a CoreSight decoder library framework
that
we have been working on within ARM.
This is very much a work in progress (both the document and the API) -
but
questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not
limited
by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended
recipient,
please notify the sender immediately and do not disclose the contents to
any
other person, use it for any purpose, or store or copy the information in
any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Hi All,
Updated document attached. Contains information on the more comprehensive trace snapshot format which we believe will be useful for exchanging trace captures for decoder testing
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-----Original Message----- From: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Mike Leach Sent: 22 June 2015 17:55 To: Mathieu Poirier Cc: coresight@lists.linaro.org Subject: RE: API Document
Hi Mathieu,
Thanks for the feedback. I'll not comment individually on each section other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
There will be a new version of the document published shortly which will include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
To the C++ question - the answer is yes. The work we are currently undertaking on the infrastructure and packet decoders is implemented in C++.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 16 June 2015 17:52 To: Mike Leach Cc: coresight@lists.linaro.org Subject: Re: API Document
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1:
- "Where the source is a core the decoder will be a PE decoder..." :
Are we still talking about the "packet trace decoder" or something else?
- "The protocol block will require..." : Are we talking about the
"Protocol decode block"?
- The reader must assume the "generic trace primitives" are the same
as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2:
- "The trace formatted frame decoder is provided..." : Are we talking
about the "trace frame deformatter". Without using the same terms, there is no way to tell.
- "A decode block can be attached..." : What is a "decode block"? I
must assume we are referring to a "Protocol decode block".
Section 2.1.4:
- "Packet processors and decoders can be...": Are we talking about
the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1:
- Is the "Trace Decode Block" the "Protocol decode block" presented
in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2:
- One must assume the green box labelled "stream protocol decode
block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
I would add "Perf" in the "formatted trace source" box.
Should the "Trace Formatted Frame Decoder" be introduced somewhere
in the documentation? Or maybe it was under a different name?
- "... is the Stream Protocol decode block as previously described".
I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the design
and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) -
but
questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not
limited
by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended
recipient,
please notify the sender immediately and do not disclose the contents to
any
other person, use it for any purpose, or store or copy the information in
any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
Good morning,
I have reviewed the document and find it much easier to understand now - many thanks for the rectifications.
The shallowness of my knowledge in trace decoding prevents me from doing a detailed analysis of the design but from where I stand things are holding together. Blocks are separated cleanly in accordance with their functionality and interfaces are provided for metadata input.
That being said, in what kind of context do you see this library being used (i.e workflow)? Did you foresee a new user space application that would take trace data and feed it to the openCSD library?
Over the past few weeks I've been working on integrating coresight with Perf on both kernel and user space planes. The Perf user space tool already provides a very rich context that include support for source code analysis. As such integrating coresight trace decoding with Perf is probably a sensitive thing to do.
Before we get too far in the design I think it would be a good idea to look at how code analysis is currently done in Perf, with the goal of fitting the openCSD library with the interfaces needed to integrate with Perf.
Perf is already a well established tool for many things, re-using it can only lessen the amount of work to do and speed up community acceptance for coresight.
Mathieu
On 24 June 2015 at 07:07, Mike Leach Mike.Leach@arm.com wrote:
Hi All,
Updated document attached. Contains information on the more comprehensive trace snapshot format which we believe will be useful for exchanging trace captures for decoder testing
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: CoreSight [mailto:coresight-bounces@lists.linaro.org] On Behalf Of Mike Leach Sent: 22 June 2015 17:55 To: Mathieu Poirier Cc: coresight@lists.linaro.org Subject: RE: API Document
Hi Mathieu,
Thanks for the feedback. I'll not comment individually on each section other than to say I agree that there is inconsistent terminology used and have addressed each element you pointed out.
There will be a new version of the document published shortly which will include the corrections, along with a new section on the updated snapshot format that was discussed at the last phone meeting.
To the C++ question - the answer is yes. The work we are currently undertaking on the infrastructure and packet decoders is implemented in C++.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 16 June 2015 17:52 To: Mike Leach Cc: coresight@lists.linaro.org Subject: Re: API Document
Good day Mike,
I reviewed the document that was submitted and have the following comments - at this time most of them surround the terminology that was used. I may be a little slow to catch on but for someone not familiar with trace decoding engines it is extremely difficult to wrap one's head around new concepts when variations are used.
I read the entire document twice but can't provide comments on section 2.3 and beyond before the following points are clarified.
Section 2.1.1:
- "Where the source is a core the decoder will be a PE decoder..." :
Are we still talking about the "packet trace decoder" or something else?
- "The protocol block will require..." : Are we talking about the
"Protocol decode block"?
- The reader must assume the "generic trace primitives" are the same
as the "generic trace elements" introduced in chapter 2.1.5. If so the latter should be used throughout the document.
Section 2.1.2:
- "The trace formatted frame decoder is provided..." : Are we talking
about the "trace frame deformatter". Without using the same terms, there is no way to tell.
- "A decode block can be attached..." : What is a "decode block"? I
must assume we are referring to a "Protocol decode block".
Section 2.1.4:
- "Packet processors and decoders can be...": Are we talking about
the packet processor and packet "trace decoder" presented in section 2.1.1? If so "trace decoder" needs to be referenced explicitly.
Figure 1:
- Is the "Trace Decode Block" the "Protocol decode block" presented
in section 2.1.1? If so section 2.1.1 needs to be modified to include the "Trace Frame Deformatter". Following the figure I think the latter should be presented first, followed by the "packet processor" and "packet decoder" descriptions.
One of the main provider of trace stream to the "Trace Decode Block" will be the user space Perf tool. I am currently working on how the gap between Perf and the Trace Decode Block will be bridged.
Figure 2:
- One must assume the green box labelled "stream protocol decode
block" is the same as what was presented in Figure 1. If so the same names need to be used in both figures.
I would add "Perf" in the "formatted trace source" box.
Should the "Trace Formatted Frame Decoder" be introduced somewhere
in the documentation? Or maybe it was under a different name?
- "... is the Stream Protocol decode block as previously described".
I must assume this is the "Protocol Decode Block" introduced in section 2.1.1. If so the same terminology has to be use throughout the document.
Section 3.1:
I noticed that C++ syntax was used - is this strictly for documentation purposes or should I deduce that ARM favours using C++ in the implementation?
Best regards, Mathieu
On 27 May 2015 at 10:29, Mike Leach Mike.Leach@arm.com wrote:
Hi,
As discussed I have attached the API document that describes the design
and current implementation of a CoreSight decoder library framework that we have been working on within ARM.
This is very much a work in progress (both the document and the API) -
but
questions / comments etc. are always welcome.
The document does have a distribution list on the front but it is not
limited
by this so if I have missed anyone off I apologise.
Regards
Mike
Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE
-- IMPORTANT NOTICE: The contents of this email and any attachments
are
confidential and may also be privileged. If you are not the intended
recipient,
please notify the sender immediately and do not disclose the contents to
any
other person, use it for any purpose, or store or copy the information in
any
medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-
Jeremiassen, Tor -
Mark Brown -
Mathieu Poirier -
Michael Darling -
Mike Leach