2003/09/11 San Jose Minutes taken by Duaine Pryor Attendees: Kevin Kranen - Synopsys Damien Denault - Zaiq Andy Eliopolis - Cadence Brian Bailey - Mentor Mitch Dale - Mentor Jan Johnson - Mentor Duaine Pryor - Mentor John Stickley - Mentor Andrea Castelnuovo - ST Micro Todd Massey - Verisity Lauro Rizzatti - Eve Bernard Gilbert - Zaiq (CEO) Richard Newel - Aptix Per Bojsen - Zaiq Shabtay Matalon - Cadence Steve Wang - Axis Ching Ping Chou- Axis James Wang - Axis Jason Andrew - Axis The group was polled for the current scemi implementations and clients. There are currently 3 implementations of SCE-MI, Mentor, EVE and Aptix. There are currently 2 SCE-MI 1.0 clients Verisity and Zaiq. Summary notes: This meeting had two main foci. The first focus was setting a baseline understanding of the current SCE-MI 1.0 standard and the various proposed donations and how they fit with the existing standard. The second focus was the collection, abstraction and development of consensus around requirements for the next set of changes to the SCE-API. Duaine Pryor presented an overview of the SCE-MI standard and its capabilities. This was largely understood by the audience and useful for the newer members of the group. It was agreed that this presentation would be useful in future training sessions for the "modelers" that we wanted to bring into the group. Per Bojsen from Zaiq presented their proposed donation. This proposal included variable transaction size, elimination of uncontrolled clock and a number of clarifications to the standards document. These should be easily handled through the "errata" process. In addition, a threading system and control interface were proposed. Finally, the Zaiq proposal includes an application layer which standardizes the transaction messages. Shabtay Matalon from Cadence presented their proposed donation. This proposal also included variable transaction size and elimination of uncontrolled clock. There was no proposal to standardize threading or control and debug, although there was discussion of technology in that area that Cadence could decide to donate. Ching-Ping Chou from Axis presented their proposed donation in detail. This proposal includes variable transaction length, elimination of uncontrolled clock. It includes a standardized threading system. It also includes some control functions. Finally it includes an application layer and miscellaneous functions. Andrea Castelnuovo presented an overview of ST Microelectronics requirements for SCE-MI. The main requirements were in the area of support for a software based TLM environment and rationalization of the various TLM standards that are under development. In addition he stated that uncontrolled clock was "not so scary". There was a strong need for backwards compatibility as well as memory access functions. Duaine Pryor presented a list of high level requirements which were derived from Mentor Graphics customers and the requirements which were either implicitly or explicitly stated in the proposed donations. The basic requirements were SCE-MI 1.0 requirements, strong backwards compatibility to SCE-MI 1.0 environments plus variable length transactions and some type of use mode which eliminates uncontrolled clock. This could be handled through the errata process or an appendix to the existing specification, creating a 1.1 version. The group was polled as to whether the characterizations of the donations and their requirements were accurate. It was agreed that all were accurate. Finally, potential activity was partitioned into four areas which could be pursued at least somewhat in parallel. These were: addition of variable length transactions and uncontrolled clock free communication to the modeling interface, application layer standards for transaction functions, control and debug, interaction with application layer thread systems The first should be well underway before the other three could get started, but otherwise, these could proceed in parallel. Detailed notes and actions: Action: John S. - Need to correct names in CoModelSeminar slides if it is to be used in future training presentations - Brian asked if Verisity can share transactor modeling guidelines - Brian suggested that it would be good to post a programming guidelines of some sort for transactor design - Todd Massey asked if it would make sense to provide some sort of SCE-MI compliancy suite - The group agreed that the only current "compliancy suite" per se is the Routed example - Per Bojsen then presented the Zaiq proposal - Zaiq's main new requirements for SCE-MI II: - Automate transaction segmentation/reassembly in infrastructure - Get rid of exposure of uncontrolled clock to user - Zaiq also made a good point that we need to be careful that vendor C models don't make incorrect assumptions about calling ServiceLoop() - [Not sure exactly what they meant by this but it may have to do with clarifying semantics about synchronization requirements between C side and HDL side] - Current Zaiq implementation of wide transactions does not support fragment streaming - i.e. early processing of partial fragments even before remaining fragments of complete transaction arrive - Duaine raised the point that this early fragment processing feature is possible in MCT and should not be sacrified - Zaiq's proposal raised the point that we need to have a clear distinction of what are fixed fields (commonly defined transaction attributes across all applications) and what is loosely defined in a transaction on an application by application basis - Duaine raised the point that requiring opcodes essentially forces the concept of 2-stage de-muxing upon the user as opposed to the current SCE-MI in which the simple channel concept only requies 1-stage de-muxing - Zaiq raised the point that the SCE-MI header file itself needs to have a standard name (like SV DPI) - Zaiq also said that the current SCE-MI version discovery system needs better defining - Shabtay Matalon then presented the Cadence proposal - Duly clarified by Brian Bailey for the record: Despite the words "confidential" appearing on Cadence's slides, Shabtay did state that the material presented was *not* confidential - Cadence basically had the same additional requirements over SCE-MI I that Zaiq did: - Variable transaction width (and builtin frag/defrag) - Get rid of uncontrolled time, allow message communication to occur in 0-time - Ching Ping then presented the Axis proposal - Duly clarified by Brian Bailey for the record: Despite the words "confidential" appearing on Axis' slides, Ching Ping and Jason Andrews did state that the material presented was *not* confidential - In the Axis proposal, knowledge of threads was embedded in the CTI messaging API but they said it could be adapted to other threading systems if necessary though at some potential cost in performance - There was a lot of discussion about the rigid definition of fixed transaction fields in the Axis and Zaiq proposal and whether that is really what we want. Some concern existed about trying to pre-categorize transactor use models at the API level as opposed to keeping the transaction API general and letting applications define data fields for their specific use models. - Andrea Castelnuovo then presented the "token" non-vendor point of view from ST Micro - Andrea made some interesting points: - Need a good software environment for transaction based modeling to compliment the communications API - Andrea made good suggestions for backward compatiblity - define two levels of SCE-MI: - SCE-MI level 1: exact compatiblity with current SCE-MI - SCE-MI level 2: enhanced capability offered by next SCE-MI - Level 1 models will run on level 2 implementations - Level 2 models will not necessarily run on level 1 implementations - Vendor IP models and user applications can query the support level from the API - we may want to integrate this with the improved version discovery mechanism - Andrea said something else interesting: Though there was a lot of discussion on the topic of removal of uncontrolled time, this discussion was driven largely by the vendors and that from his "user" point of view, uclock was "not such a scary thing" - Andrea does not care so much about precise simulation time display - he's more concerned with keeping track of cycle counts as the current CycleStamp mechanism allows - Andrea would like support for memory read/write access (memory transactor concept ?) - Andrea really would like a transaction recording mechanism in the API - He said that support for SystemC TLM API would be nice - He also said that having the concept of a "function call as monitor" would be nice - i.e. the equivalent of Verilog $display() - There was also a large concensus in the group that we need to be closely monitoring the activities of the SystemC TLM Working Group - In fact, it might behoove us to have someone from that committee give a talk to the SCE-MI group