Is there a document that describes the timestamp logic behind the TarmacTrace plugin?
When we get concurrent events from different cores, are the timestamps valid?
Any additional information about the timestamps would be appreciated, thank you.
I've looked at the TarmacTrace chapter, the only related parameter I found was "use_instr_cnt_as_timestamp". Is there a way to ensure in which order the trace events happen across all the cores?
On another note, I get some traces that do not seem to be reported in the document. They also seem to repeat inside the same timestamp, for example:
0 clk cluster0.cpu1 SIGNAL: SIGNAL=POReset STATE=Y0 clk cluster0.cpu1 SIGNAL: SIGNAL=DebugReset STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=ResetHold STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=DebugReset STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=ResetHold STATE=N... (same pattern continues)0 clk cluster0.cpu1 SIGNAL: SIGNAL=DebugReset STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=ResetHold STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=Reset STATE=Y0 clk cluster0.cpu1 SIGNAL: SIGNAL=DebugReset STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=ResetHold STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=DebugReset STATE=N0 clk cluster0.cpu1 SIGNAL: SIGNAL=ResetHold STATE=N...
Hi dvsk,
Note this info relating to the accuracy from the manual Rob mentioned: "If enabled, this trace source generates one record for every instruction started."
What this means is the FVP will report instruction accurate information. This may be sufficient for your needs, but that depends on exactly what you are trying to achieve. Our Cycle Models contain detailed cycle accurate information, these are available separately to FVPs which are based on Fast Models technology.
Responses captured with TARMAC can vary depending on the FVP in use - please confirm the FVP you are using and we'll help with more explanation.
Please also share what you're trying to achieve, FVPs may be the right tool, but let's discuss.
I'm using FVP_Base_RevC-2xAEMv8A (the free Base FVP binary from ARM). I want to use a running model that is usually designed before anything else in the chain of modeling the target system. Precise cycle timing is not my concern (if something takes 10 or 15 cycles is not of importance) but logical order of execution (like a cause and effect, or which core's signal was chosen first for example) is important. Thank you both for taking the time to address my question.
Thanks for confirming, that's a great use case, let us check the details and come back to you.