Subject: Re: strategy for DirectC
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Dec 12 2002 - 11:51:42 PST
> From: "Andrzej Litwiniuk" <Andrzej.Litwiniuk@synopsys.com>
> Subject: strategy for DirectC
>
> Swapnajit & Ghassan,
>
> Do you have a strategy for dealing with a deadlock? Kind of Plan B?
>
> What if we, the team, fail to provide a palatable solution?
Personnally I think we're making good progress, we've covered a lot of the
issues, and we have proposals for most functionality anyone is asking for.
We can easily cut back to the lowest common denominator on the proposals
if we need to.
As I see it the bulk of the delay for 3.1 will probably come from issues
that the BC and EC have still to address.
> I don't mean here the differences of opinions nor conflicts of preferences
> for alternative solutions.
> Those conflicts/differences can be dealt with via negotiations or through
> the voting process. I don't see any evil in diversified views or needs.
> And I understand and accept that such a diversification means that some
> people will be more satisfied with the outcome than others.
>
> I'm worried, however, how we will proceed if we don't solve technical issues
> in a satisfactory way in the alloted timeframe?
> [Note: "satisfactory" is a subjective term.]
>
> Maybe the bar is too high and we'll have to lower our expectations.
> Sometimes technical issues are plain hard. Or a perfect solution simply does
> not exist. Or is hard to find.
>
> Sometimes people tend to not accept facts, like that something is undoable
> or doesn't come for free, or that there is a trade-off and one cannot have
> two conflicting things at the same time. (Personally, I'm frustrated that I
> cannot see any solution that would grant binary compatibility, would impose
> no restrictions upon simulator and would not involve any overhead for arguments
> copying, yet would provide elegant access to SV objects using SV indexing in
> C code.)
The solution is: have one open-source simulator that every one uses (not
happening anytime soon).
Plan B: Fix the asymmetry between struct/class/module in SV and define a
proper mapping between those objects and C++ so that it all works like C++
(still has a problem with the name-mangling and linking).
- a proper decomposition of 4-state into value/strength/certainty would
also help.
> If there are alternative partial and imperfect solutions, shall we consult
> the requirements to guide us in the decision making process?
>
> Maybe the initial requirements need a revisit? (Or a revision?)
> Maybe more time is needed. Maybe a lame solution has to be accepted?
> I don't know.
>
>
> Regards,
> Andrzej I. Litwiniuk
Note: after 3.1 almost all the functinality of C/C++ will be available
in SV, so the requirement for writing code in C/C++ will (hopefully)
diminish over time. In theory SV should be more efficient than C/C++
for many software problems, and at least no worse.
Regards,
Kev.
This archive was generated by hypermail 2b28 : Thu Dec 12 2002 - 11:53:45 PST