Following last week's motion, I will try and collect here my proposal for a definition of the data access protocol.
To start with the basis, I recopy once more one of our high-level visualisations of SJTAG:
The point of discussion is: how would the "Algorithms and Routines" in the top left-hand corner would communicate with the System Model and ultimately with the System Under Test ?
I would propose to follow the same protocol and semantics of 1687 and 1149.1-2013, so that we can maintain backward compatibility. In practice this would involve using the same 3-step protocol:
- data can be pushed from an Algorithm to the System Model using an iWrite command. The effect is a only a modification of the System Model State Ssm, and no transaction are triggered with the SUT;
- data can be brought to an Algorithm from the System Model using an iGet command. The effect is only a data retrieval from the System Model State Ssm, and no transaction are triggered with the SUT;
- all synchronisation between the Ssm and Ssut must be explicitly requested by an iApply command. This might trigger multiple execution cycles if the target of "iApply" is not on the active part of the system.
NB: "iGet" is just ashort name for all iGet-like commands in both standards, where the only difference is the type and format of the data returned.
I my view, this is just a software constraint and it puts no limitation on the hardware: of course it is modelled on the Capture-Shift-Update sequence, but this is just about the implementation of the iApply command, not about its semantics.
Once we get this base settled, we might of course then extend on the subject, for instance to add primitives for efficient concurrent execution
(along the lines of Test And Set or joint iApplys, etc..)
Discussion and feedback on the SJTAG Initiative Group weekly meetings.
1 post • Page 1 of 1