RE: BOUNCE sv-xc@eda.org: Non-member submission from [Ulrich Holtmann <Ulrich.Holtmann@synopsys.com>]

Hi,

We reviewed and agree with the proposal from Uli, however, we'd like to
add some additional questions concerning the:
  1 Interface with SystemC
  2 Transaction Level Modeling (TLM) Interface, and
  3 Native C++ Support


SystemC Interface

It is our experience that a major portion of the integration problems is
caused by the differing simulation semantics between SystemVerilog and
SystemC.  We therefore would like to add the following two questions:

1) Do you require that SystemC is notified about events at the
SystemVerilog side (signal changes, modifications of variables or native
events) instantly (see definition below)?  If yes, which kinds of events
are important?

2) Do you require that SystemVerilog is notified about events at the
SystemC side (modifications of sc_signal or sc_buffer variables or
events) instantly?  If yes, which kinds of events are important?

An instant notification happens:
A) On the SystemVerilog side in the same time slot (without consuming
time),
within the earliest region that matches the related simulation semantic.
A 
SystemC component that is interfacing as design object should provide
the
notification in the innermost loop handling design updates, while a
component that is interfacing as testbench object should provide the
notification in the innermost loop handling Testbench updates.

B) On the SystemC side in the same time slot (without consuming time),
within the earliest delta cycle that matches the interfacing scheme with
the SystemVerilog side.


Any update between both sides must occur in the same iteration of the
outermost loop of the SystemVerilog simulation semantics within one time
slot.


TLM Support

It is important to have a vendor independent portable support of the
SystemC TLM standardization.  Therefore we suggest adding the following
question:

3) Do you require native support for SystemC's Transaction Level
Modeling (TLM) interface in SystemVerilog?
[Native support means that it is permitted to directly instantiate a SC
TLM within SystemVerilog, with the help of some appropriate helper
class. Possible implementation could be a standard package supporting
SystemC TLM's similar to the support of mailboxes or semaphores within
SystemVerilog]


Native Support for C++

Finally native support of the other C++ language features might be very
useful.  Therefore we (in this case, more Rob than Michael) suggest
adding the following three questions:

4) Do you require to instantiate and use C++ classes within
SystemVerilog?
5) Do you require to instantiate and use SystemC sc_modules within
SystemVerilog ?
6) To you require to instantiate and use SystemVerilog classes within
SystemC ?


Rob Slater & Michael Rohleder
Freescale Semiconductor


-----Original Message-----
From: owner-sv-xc@eda.org [mailto:owner-sv-xc@eda.org] On Behalf Of
Logie Ramachandran
Sent: Wednesday, January 24, 2007 6:12 PM
To: sv-xc@eda.org
Subject: FW: BOUNCE sv-xc@eda.org: Non-member submission from [Ulrich
Holtmann <Ulrich.Holtmann@synopsys.com>]

Feedback from Ulli

Thanks

Logie. 

-----Original Message-----

// re-sending this email, the first attempt seem to have been lost
// by my mailer

Hi Arnab,

I propose to extend your SV/SC questionaere for these
two areas: use model and problems-encountered-so-far.

The extended questionaere is below.

Best Regards,

Ulli Holtmann



(1) At what level should a SystemC model communicate with a
  SystemVerilog model ? (choose one or more, use numbers to prioritize,
  1 = most important, 2 = less important than 1, X = not required)

  (a) Algorithmic or behavioral, not timed
  (b) Algorithmic or behavioral, timed
  (c) Communicating processes
  (d) Cycle-accurate
  (e) RTL
  (f) Other, please specify


(2) What are the most important use models for designs containing both
  SystemVerilog and SystemC ? (choose one or more, use numbers to
  prioritize, 1 = most important, 2 = less important than 1, X =
  irrelevant)

  (a) SystemC models are abstract functional models written at the
  transaction-level, e.g. bus models, CPUs, peripherals, etc.
  They are plugged into a SystemVerilog testbench and serve
  as golden reference models.

  (b) The testench is written in SystemC and is used to drive
  the DUT written in Verilog or VHDL.

  (c) SystemC models are behavioral synthesis models. They are
  used together with RTL models written in Verilog. The testbench
  is SystemVerilog.

  (d) SystemC models are written at the RTL level. They are used
  together with other RTL models that are written in Verilog,
  SystemVerilog or VHDL.

  (e) The SystemC model is a wrapper around some model written in C.
  It has an RTL interface meaning it is driven by value changes
  going through ports and is timing or cycle accurate.

  (f) The SystemC model is a wrapper around some model written in C.
  It has a TL interface meaning it is driven by function calls.
  The SystemC model has a notion of timing and may even be cycle
  accurate.

(3) Use numbers to prioritize the following based on their value
  in interfacing SystemC and SystemVerilog: (choose one or more,
  use numbers to prioritize,
  1 = most important, 2 = less important than 1, X = not required)
  (a) Pin-level(rtl) connection between SystemC and SystemVerilog
      using simple built-in types provided by each language.
  (b) Connection between SystemC and SystemVerilog using complex
      types like arrays and structs of built-in types.
  (c) Connecting objects that operate at higher level of abstraction
      as provided by each language like events, mailboxes, semaphore
      and fifos.
  (d) Hierarchically referencing external objects defined in one
      language from another.
  (e) Pass parameters across the language boundary. What type of
      parameters are these?
  (f) Other, please specify


(4) What kind of problems did you encounter so far when connecting
  SystemC with SystemVerilog? (use numbers,
  1 = frequent and difficult to resolve, 2 = infrequent and
      diffcult to resolve, 3 = frequent but easy to resolve,
  4 = no problem, 5 = not encountered so far

  (a) converting datatypes int, sc_[big]int, [big]sc_uint,
      sc_lv, sc_bv to/from SystemVerilog

  (b) converting complex datatypes such as user-defined
      structures or arrays

  (c) scheduling semantics were not as expected, e.g. value
      changes came too late or processes were executed too late

  (d) Calling blocking (=consumes simulation time) SystemC
      methods from Verilog did not work as expected or
      was difficult to do

  (e) Calling blocking (=consumes simulation time) SystemVerilog
      tasks from SystemC did not work as expected or
      was difficult to do

  (f) Differences in timescale (time resolution / time units)


(5) Additional comments ?


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.