Subject: Re: DirectC: C layer - abstract vs direct
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Wed Dec 11 2002 - 12:46:49 PST
Kevin Cameron x3251 wrote:
>>From doug_warmke@mentorg.com Wed Dec 11 10:55:22 2002
>>
>>Kevin,
>>
>>We already discussed abstract vs. direct at length
>>and we took a poll on the issue. Recall, proposal c)
>>carried the vote at the face-to-face. In essence,
>>that proposal says we should use direct access techniques
>>wherever possible, and only resort to abstract access
>>when strictly necessary. In addition, there should be
>>no redundancy of access (i.e. user can choose between
>>abstract and direct styles).
>>
>>Andrzej's proposal is totally in line with proposal c).
>>Let's stay focused on the unresolved issues we have
>>on our plate.
>>
>>***
>
>
> IMO, a direct mechanism is nice-to-have but this one is
> going to be really expensive to implement and won't give
> any speed advantage.
Disagreed.
>
> E.g. if you declare a large array with 4-state fields and
> the SV simulator decides to split the value and "control"
> data into seperate structures then patching it together
> into a single structure for a call, and breaking it up
> again is not cheap.
>
> Joao already said that he found three different internal
> representations of logic types in the Synopsys simulators.
>
> In fact, Andrzej's proposal says: let's not bother with
> abstract access, just go direct. It's not option (c).
Also disagree. I feel it is option (c).
There are abstract methods where necessary,
and not elsewhere.
>
>
>>IMO runtime type checking is a feature of secondary
>>importance. Simplicity of use and consistency with
>>established mixed language use models is primary.
>>
>
>
> It's not simple to use if it's easy to break, IMO the SV
> interface should be minimally vulnerable to bad programming.
>
It is not easy to break if you follow the rules.
Also, I mis-typed something below and I apologize.
I meant to say it is consistent with established
mixed language use models (meaning Verilog and VHDL
mixed together in a design hierarchy). Users
have accepted the use model for language mixing that
is already available in industrial simulators, and I
would like to continue in that vein with our work.
>
>>The established Verilog/VHDL use models don't do
>>strong type checking and sometimes users can mess up.
>>However, if they read the manual and do simple experiments,
>>they quickly catch on and get their code working. I do
>>not agree that these issues are hard to debug.
>
>
> VHDL does bounds checking (as well as strong type checking).
>
> The current mix we have of Verilog an C++ is extremely difficult
> to debug. The same issues will exist with using SV in conjunction
> with SystemC.
>
> Memory misuse bugs are often extremely difficult to track down.
>
>
>>In addition, the inter-language function call boundary
>>is not something that changes much after initial
>>verification setup. Once it is working, it stays
>>working forever.
>
>
> If users adopt our DirectC interface and use more SystemC in
> their design flows then there will be a lot more use for
> this interface than for existing PLI.
True - however the point remains that users don't often make
changes at the language boundaries of their designs. They
set up their configuration once, and then uses it extensively
for lots of verification tests.
Regards,
Doug
>>
>>Kevin Cameron wrote:
>>
>>>In my mind an abstract interface is one that uses an opaque handle as a reference to
>>>some object and lets you apply methods to it. In C++ fully abstract interfaces are
>>>implemented with virtual functions, in C it's ususlly:
>>>
>>> <ret data> = <method>(<handle>{,<args});
>>>
>>>- which is more-or-less the approach taken with PLI/VPI. It is not usually necessary
>>>to implement all methods for all objects. Calling an unsupported method usually just
>>>gets you a bad return value.
>>>
>>>Andrzej's proposal is not an abstract interface, it is a direct interface - i.e. the SV
>>>simulator provides a pointer to it's memory, and the user gets to write into it. Since
>>>SV can't perform array bounds checks on that interface it is error prone and is likely
>>>to lead to hard-to-debug crashes. Also, since in many cases the SV simulator's internal
>>>representation of the data is not likely to match the structure defined for C, the
>>>simulator has to create a copy of the data and pass a reference to that - which will
>>>be virtual copy-in/copy-out, and may be considerably slower than an abstract interface
>>>if only small parts of the structure are being accessed. There has been no official
>>>agreement that C type structures in SV actually layout the same as for C yet, I don't
>>>see there ever being agreement on SV types laying out the same.
>>>
>>>Kev.
>>>
>>>--
>>>National Semiconductor, Tel: (408) 721 3251
>>>2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>>>
>>>
>>
>>
>
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 12:55:54 PST