reponse to Zaiq's and Broadcom's presentations last week

------------------------------------------------------------------

Intro
- We want an opportunity to address a few points in Russ's
   and Per's presentations last week

Russ's Presentation - Mentioned no provision for clock definition in our 
proposal

   - Important ! We did not change anything regarding clocks

   - The fact that it was not there means we don't want to change it not
     that we're taking it away.

   - We should have made this a bit more clear in the proposal

   - Although we propose no changes to *clock ports* for definitions of 
clocks,
     we do recognize that with the DPI approach no *clock control* is 
needed.

     -> i.e. clock ports for flexible definition of multiple clocks with
        specific relationships are nice, need to control them is removed

   - Russ did mention that there were some weaknesses in SCE-MI 1.1
     clock port definition - particularly with regard to time-base control
     -> We don't disagree and would be open to improvements to SCE-MI 1.1
        clock port macros such as allowing period/frequency specification
        to establish time base

   - Again:
     - We *are not* proposing doing away with clock port macros
     - We *are* open to improvements

------------------------------------------------------------------
Per's Presentation - Mentioned users and IP Providers must
    "throw out transactors and start all over"

   - Let's be careful not to frame this issue as a deficiency of only
     the Mentor proposal.

     - It is partly true - for both proposals
     - And partly false - for both proposals

   - Important ! We did not change anything regarding setup environment

     - You still call SceMi::Init(), ::RegisterErrorHandler(), etc.

     - As mentioned above, you still use clock ports if you wish.

     - Again we should have made this a bit more clear in the proposal:
       *none of this changes*

     - That is why it was not mentioned

   - A key point to be made: Although we don't change the infrastructure
      environment (SceMi::Init(), clock ports, etc.) these constructs are
      generally external to transactor models anyway.

      - Think about it: Clocks are typically outside the HDL transactor
      - Think about it: Initialization, error handler registration
                        typically outside the C proxies

      - So: A model that uses DPI will not only run in a SCE-MI 
infrastructure
            but also an any DPI compliant simulator

      - This allows for a very nice feature of reusability of DPI models 
among
        both native SystemVerilog environments and SCE-MI environments

- Other key point regarging "throwing away transactors
   and starting all over"

    - What is being thrown away ?

     - 1.1 models ? Why ? Let them keep running if necessary
       - Is not SCE-MI 1.1 compatibility a fundamental requirement ?
       - 1.1 models can continue to run alongside DPI models if this is 
desired

     - This is true of both the Mentor and Cadence proposal. Why are
       we singling out the Mentor proposal ?

   - Or, is it being thrown away because user wants to clean up and
     rewrite without uncontrolled time ?

     - No problem, but again, why are we singling this out to be
       a problem with the Mentor proposal ?

     - Removal of uncontrolled time has to be done identically with both
       proposals. DPI itself does not add more or less complexity to this
       task from the Cadence proposal

     - Straining out uncontrolled time from legacy models  is by far the 
most
       complex part of conversion but this process is identical for both 
proposals

     - And for DPI, conversion of messaging code in general becomes
       a "very satisfying" act of code deletion - no more handshake
       logic, dual ready protocols, signal declarations,
       macro instantiations, etc.
       -> just function calls

     - Conversion of proxy code becomes a simplification process as well
       -> Move away from the awkward callback model, replace with simple 
C calls.

     - State macros in Cadence proposal may be unecessary. Simple function
       calls that can do state config/query in either direction will most
       likely do fine there

------------------------------------------------------------------
Addressing future needs - why wait ?

- Now is the right time
- DPI will accomodate multi-threaded HVL environments today - why wait ?
- DPI is a standard today - the work is done - why wait ?

- With work already done, perhaps we can sooner address
   "the next big thing" - modeling subset ?


______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
17 E. Cedar Place                   \   john_stickley@mentor.com
Ramsey, NJ  07446                    \     Phone: (201) 818-2585
________________________________________________________________