Subject: Re: [sv-cc] SV Layer Feedback
From: Andrzej Litwiniuk (Andrzej.Litwiniuk@synopsys.com)
Date: Tue Mar 04 2003 - 08:35:56 PST
John Stickley:
> Here's my feedback:
>
> -------------------------------------------
> page 1 section 1.1.1 2nd statement of 2nd paragraph
>
> "In particular, the external functions shall be non-blocking ..."
>
> I'm uncomfortable with the term "non-blocking" although I agree
> with the point you're trying to convey here. All function calls
> are in one sense "blocking" and in another sense "non-blocking".
> You can think of function calls as "blocking" if you observe
> that when a function call is made, the statement following
> the call site is not executed until the function itself has
> completely executed and returned.
>
> But in the sense you're trying to convey, inside the function call,
> you cannot block for example on a thread to allow time to pass.
> I understand what you're saying but, using "non-blocking" can
> be confused with the other meaning I described above.
>
> So, to avoid all ambiguity, I would prefer you remove the
> term completely and instead just say "0-time" to always
> imply that function calls execute instantaneously (which
> you already correctly state here).
I agree. I've adopted a jargon. "Blocking" and "non-blocking" shall be
removed. [All remaining remarks concerning "blocking" are skipped.]
> -------------------------------------------
> top of page 4 section 1.3.3 last paragraphs describing context
> [...]
> you've left out the single most important aspect of
> why "context" is important: it adds context sensitivity to
> the function call. It provides a way for C code or models
> to know from what specific HDL instance the function is
> being called.
> [...]
> I would like to request that we make these adjustments to the
> C layer. I thought we had reached agreement on this previously
> but it is still missing from the specs.
It is my mistake. I simply forgot about it (actually even worse!).
But this turned out for the better. Somehow, I have had different - wrong - picture of what we agreed upon for C-to-SV calls. (See your remarks for page 10
section 1.7 examples at the very end). I was kind of fixed on that solution.
So I described bona fide what I had in my mind without realizing that it
was not what had been agreed on (poll on Issue 1.1, December 1-2).
At first, I was susprised with your feedback and was thinking that you were demanding something deviating from our agreed solution. Then Joao corrected me and pointed out that actually it was me who was wrong. My apologies.
We have to rework the appropriate parts of both SV and C Layers.
> -------------------------------------------
> page 4 section 1.4 6th paragraph
>
> You specify the syntax "$root.xf"
> to override locally visible identifiers that conflict in name.
>
> How about $root::xf for more symmetry with module scope
> specification in export declarations ?
Well, regular hierarchical paths made sense for "my" solution that allowed
to export functions from well defined unique instances.
It is not necessary for instance-related exports.
Now, I don't know if exports with absolute paths are still allowed or not.
> -------------------------------------------
> page 4 section 1.4
>
> What about cname aliasing ? I think this is important
> in the SV-to-C direction as well as C-to-SV. Your spec
> shows it in one direction but not the other. My understanding
> is that we all agreed support aliasing in either direction.
Possibly I misinterpreted our decisions, once again. Didn't see any good
rationale for cname aliasing for SV-to-C.
Anyway, the most recent proposal for extern export/import (or is it
export/import extern?) allows cname aliasing for both directions.
> -------------------------------------------
> page 5 section 1.4.3
>
> Can we allow packed arrays up to 64 bits as return types rather
> than 32 bits ? Since all modern language compilers support 64 bit
> scalar types (for ANSI C it is "long long") let's make the most use
> of today's machine architectures. 32 bits is rather limiting.
> Even if code is running on 32 bit machines, all the compilers
> still support the long long type so let's just make it 64.
>
> And for 64 bit machines it's a big win.
The sole rationale for this limitation was implementation isssues
on hardware with 32-bit registers (function result in a register).
But I guess that there should be no major problems. Yes, 64 bits should be
fine.
> -------------------------------------------
> page 10 section 1.7 examples at the very end
>
> I have a big problem with these examples. I don't ever remember
> coming to agreement in this committee that we can export instances
> of functions. All we agreed to was to be able to export
> functions in specific module scopes.
I might have been wrong. It wasn't intensional.
As already explained, I wrote it having quite opposite
picture in mind. Thanks for identifying this! No one else seems to have noticed
this discrepancy.
> What you're suggesting here may be highly problematic
> for implementations
Actually, the implementation of instances of functions (i.e. functions bound
to a specific instance) is much simpler than the implementation of context
sensitive calls. Much simpler and pretty more efficient. (Maybe this is why
I got so biased?)
> and is probably not very useful anyway.
Would it be useful? CBlend seemed to be quite successful.
Regards,
Andrzej
This archive was generated by hypermail 2b28 : Tue Mar 04 2003 - 08:36:36 PST