Re: SystemC interfacing to SystemVerilog survey questions

Saha, Arnab wrote:
> Hi Kevin,
>
>    Please see my comments below prefixed with "ARNAB".
>
> Thanks
> Arnab 
>
> -----Original Message-----
> From: owner-sv-xc@server.eda.org [mailto:owner-sv-xc@server.eda.org] On
> Behalf Of Kevin Cameron
> Sent: Thursday, January 11, 2007 2:59 PM
> To: sv-xc@server.eda.org
> Subject: Re: SystemC interfacing to SystemVerilog survey questions
>
>   
>> From:     Saha, Arnab <arnab_saha@mentor.com>
>>
>> (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
>>    (b) Communicating processes
>>    (c) RTL
>>    (d) Cycle-accurate
>>    (e) Other, please specify
>>     
>
>   
>
>     I'm not sure what you mean by your categories.
>
>     I would assume that it would be fairly easy to hand off all the
>     scheduling for SystemC to the SV/VHDL/AMS simulator if there was
>     an API
>     for that. Most of the rest of the communication will be through
>     signals/events (which just happens when it happens).
>
> ARNAB: There are various methodologies involved with how SystemC and SV interact.
> You have a plain old pin-level connection method where you instantiate a module
> of another language and then connect signals and ports(c).  You can also take the DPI
> approach and in that case the two models communicate using function calls (a).
>   
(a) sounds like it's completely abstract, are you asking if the object 
level interfaces should match? E.g. a SV class should have a defined 
C/C++ interface so that you can swap simulators/implementations easily.
> I don't think we can hand off all the scheduling for SystemC to a SV/VHDL/AMS simulator
> without handling SystemC objects separately.  The scheduling semantics for these 
> languages don't match.
>   
SystemC seems pretty much a subset of the others to me. Generally there 
are not many kinds of events to schedule: process wakeup and driver 
updates. Otherwise processes wake up on signal events which is usually 
done by registering a callback. SystemC is only marginally more awkward 
because it is multi-threaded.

It's just easier to say that there will be one shared scheduler than to 
come up with the semantics for passing control around between schedulers.

Kev.
>
>   
>> (2) Use numbers to prioritize the following based on their value
>>    in interfacing SystemC and SystemVerilog:
>>   (1 = most important, 2 = less important than 1, X = not required)
>>     
>
> ARNAB: I guess, I was not clear in my explanation above.  I want you to use
> numbers to proritize the items below like 1, 2, 3, 4, 5 .... with 1 being
> the most important and 5 the least.  Use as many numbers you want.
>   
>>       (a) Pin-level(rtl) connection between SystemC and SystemVerilog
>>        using simple built-in types provided by each language.
>>     
> 1
>   
>>    (b) Connection between SystemC and SystemVerilog using complex
>>        types like arrays and structs of built-in types.
>>     
> 2
>   
>>    (c) Connecting objects that operate at higher level of abstraction 
>>        as provided by each language like events, mailboxes, semaphore 
>>        and fifos.
>>     
> 2
>
> 1 for mailboxes/fifos, since they are a good mechanism for communicating
> between different kinds of processes.
>   
>>    (d) Hierarchically referencing external objects defined in one
>>        language from another.
>>     
> 2 +/-
>      - suspect SystemC is more likely to be on top so it's unlikely
> [System]Verilog would want to reference it.
>   
>>    (e) Pass parameters across the language boundary.
>>     
> 1.5
>   
>>    (f) Other, please specify
>>     
>
>   
>> (3) Additional comments ?
>>
>>     
> Assuming single thread of control?
>
> Kev.
>
> --
> 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.