|
|
Q: Is core design debug made possible by P1500?
A: Core design debug is not strictly foreseen by P1500 definition, but
P1500 capabilities may be used to ease design debug. Cf. IEEE 1149.1
standard, which is not aimed at debugging, but is often used for that
purpose.
Q: What are the relationships between CTL and STIL?
A: CTL is an extension of STIL.
Q: Does the CTL Environment definition imply a specific operational
mode, e.g. does the 'DataType clock' specification mean that the clock
is activated, not activated, etc.?
A: No, it doesn't.
Q: What is the meaning of 'Coreinternal' and 'Coreexternal' sections: should a
P1500-ready wrapper be defined as 'internal' and a P1500-compliant
one as 'external'?
A: This depends on what is expressed, and by whom it is expressed:
core user or core provider. In general, P1500-ready wrapper signals should be
defined as Coreexternal.
Q: Then, what are these notions used for?
A: They give an idea of the completeness of the wrapper
implementation.
Q: Could the 'Parent mode' in the 'Preamble' definition be modified
for a given application?
A: In such a case, a specific 'Parent mode' should be described in the
Preamble. The 'Parent mode' should be understood as a shortcut,
however the 'Parent mode' information may always be written in
extenso.
Q: Could CTL include floor-planning information, since this could be
useful for TAM definition?
A: The hypothesis is that the core design shouldn't be modified at
this step. However, pointers on design information exists and may be
used for diagnosis and debug.
Q: Core providers would prefer that core users cannot modify the
provided CTL description. Is it possible in this situation to define a
specific syntax allowing core users to make some modifications,
without creating any inconsistency with the already defined CTL?
A: This is an important request, to be taken into account. However,
soft cores or mergeable cores are ignored in the current version of
CTL.
Q: Why is LBIST focused prior to MBIST?
A: This is because people involved in CTL definition have, as for now,
more expertise in LBIST than in MBIST.
Q: How analog core test may be dealt with? To which extend IEEE 1149.4
standard could be combined with P1500? Is this scheduled within P1500
WG activities?
A: CTL may be extended to take into account analog core test. This
problem could be tackled during new CTL version definition, just like
the mergeable core test aspect. Active participants willing to work on
these subject are very welcomed.
Q: What is the scheduling for the ballot process?
A: CTL documentation should be completed by December 2000, so that the
ballot may occur at this time.
The participants were then invited to express specific needs or wishes regarding current CTL definition status. They were also invited to help identifying deficiencies and bugs in the current CTL status definition by trying it on examples.
Note : Some comments/questions raised by people familiar with IEEE 1149.1 but not with P1500 to check if P1500 offers similar capabilities : test modes, etc. May be useful to address this issue in a specific document stating the similarities and differences between 1149.1 and P1500, so as to ease their understanding of P1500.
Then an interesting discussion started on the serial and parallel access mechanisms, which is summarized in the sequel.
A concern was raised about the necessity of the 5-6 signals to implement the parallel control access mechanism: a participant asked if these signals were mandatory, arguing that this could be a bit constraining. It has been answered that the number of the necessary signals is not yet completely fixed, for the parallel access as well as for the serial access.
Regarding the serial access control mechanism, a participant wanted to have more precisions on the controller: is it a TAP? It has been answered that the controller is composed of muxes and signals.
Then the question of deciding whether a TAP at the core level is needed or not has been discussed again, raising the concern of IEEE 1149.1 compliancy at the SoC level in such a case. It has been noted that the 1149.1 compliancy wouldn't be a problem, provided that a hierarchical TAP architecture is considered.
The discussion has shown that there could be some misunderstanding on the role and capabilities of the WIR: does it embed an internal state machine, acting like the IEEE 1149.1 TAP, or does it need additional external signals for the access control? Again, questions and comments on this particular issue have shown that many people have in mind the IEEE 1149.1 definition as a reference. Thus, is the equation 'JTAG = CTAG + TAP' a good summary of the answer?
Another question was raised about the clock mechanism: are the normal and test mode sharing the same clock, or do they have separate, synchronized clocks? A proposal was made to use by default the system clock, and to optionally add a test clock.
Finally, it has been asked whether discussions are running on the possible elimination of one wrapper between two cores, since it would be superfluous that two connected cores have each one its own wrapper. The answer was that this discussion is not running anymore, since it has been solved by the decision to optimize the SoC integration through mergeable cores, whenever possible.
Meryem Marzouki, LIP6