[vhdl-200x-ft] RE: Fast track vhdl200x

Hi,

I agree with Peter's overall recommendation for the VHPI working group.

I think ft7 should follow VHPI semantics for force/release with no
implied dependence on a VHPI implementation to exist. Eventually the
LRM might define the semantics for the force and release statements and
VHPI might refer to it. It is important the the LRM guarantee semantic
consistency.

In general, it is a good strategy for the FT features to be defined as
part of the language and state that certain semantics be equivalent to
specific VHPI definitions as normative specification. If the FT working
group is not sure about VHPI semantics, however, my recommendation is to
define the semantics you want and indicate your intent that this should
be consistent with VHPI as rationale. It will help us review the LCS
later.

It is good tactics to consider the possibility that certain aspects of
VHDL 200x changes could be implemented in VHPI or substantially so. A
new statement like finish could be enabled by vhpi_control. A simulator
control statement could bring whatever flexibility vhpi_control has
directly to the language, too. The equivalent of a force or release
could be enabled with vhpi_put_value. Some aspects of XMR could be
implemented with handle_by_name and vhpi access to information about and
actions on the XMR object. ...and so on.
I have similar advice to define what you think you want for feature
semantics and then refer to the fact that alignment with VHPI semantics
and features affords opportunity to build this directly with VHPI. We
can review this for accuracy later.

I was glad to hear the progress on FT (whatever I was actually able to
hear) and review the proposals. There is a lot of work ahead!

Regards,
John Shields

On Wed l, 2004-03-10 at 19:35, Peter Ashenden wrote:
> Françoise,
>
> I'm sorry the telecon didn't work out very effectively. You can find the
> list of fast track proposals at www.eda.org/vhdl-200x/vhdl-200x-ft.
>
> Before you joined the telecon, I presented the status report we had prepared
> earlier in the week, including the suggestion that LCSs need to be done
> before we can properly assess VHPI impact. You are right that many of the
> proposals are in early stages - yet to be analyzed. Others, however, are
> just about ready for drafting LCSs.
>
> Given the schedule we estimated for VHPI LRM editing, I'd suggest we proceed
> with that work as currently planned, and review the status of FT proposals
> when the first VHDI LRM draft is ready. If LCSs are ready by then, we can
> do a more accurate assessment of VHPI changes at that stage. Otherwise, we
> can go ahead with VHPI as an amendment to the LRM.
>
> Below are the notes I took at the meeting, summarizing the VHPI impact of
> each FT proposal. (We only had time to get down to FT20.)
>
> FT1: Generalize to implicit subprograms, not just operators.
> No VHPI impact.
>
> FT2: No VHPI impact.
>
> FT3: No VHPI impact.
>
> FT4: Define as implicit function.
> Overload for numeric bit/std.
> No VHPI impact.
>
> FT5A: No VHPI impact.
>
> FT5B: -> Modeling and productivity.
>
> FT6: Closed (dead).
>
> FT7: Hierarchical references using aliases.
> Some VHPI changes.
> Sort out format of the string.
> Need to address how to do elaboration.
> If that can't work, fall back to proposal based on xref
> procedures.
> Investigate trial use amendment? Or just trial use of full LRM.
> Force/release: make like VHPI feature?
> Define VHDL force in terms of VHPI force (eg, reference
> definition).
>
> FT8: No VHPI impact.
>
> FT9: No VHPI impact.
>
> FT10A/B: VHPI impact to be analyzed.
> Allow for variable-assignment analogs for symmetry.
>
> FT11: VHPI impact to be analyzed.
>
> FT12: VHPI impact - mode rules.
>
> FT13: VHPI impact - reconcile arguments to vhpi_control with
> parameters of VHDL stop/finish.
>
> FT14: Impact on info model for types - to be analyzed.
>
> FT15: Impact on info model for types - to be analyzed.
>
> FT16: VHPI impact to be analyzed.
> Allow multiple contexts.
> No default context - keep current default library/use clauses.
>
> FT17: Off fast track.
>
> FT18: VHPI impact to be analyzed.
>
> FT19: Only do combinational form to FT.
> Syntax to be determined.
> Impact on VHPI to be analyzed.
>
> FT20: Relax aggregate rules for 1D aggregates so that if an apparent
> element is of the 1D type, it is flattened to elements.
> Details to be analyzed.
> Impact on VHPI to be analyzed.
>
>
> Cheers,
>
> PA
> --
> Dr. Peter J. Ashenden peter@ashenden.com.au
> Ashenden Designs Pty. Ltd. www.ashenden.com.au
> PO Box 640 Ph: +61 8 8339 7532
> Stirling, SA 5152 Fax: +61 8 8339 2616
> Australia Mobile: +61 414 70 9106
>
>
> > -----Original Message-----
> > From: Francoise Martinolle [mailto:fm@cadence.com]
> > Sent: Saturday, 6 March 2004 04:38
> > To: peter@ashenden.com.au
> > Cc: vhpi-pilot@eda.org
> > Subject: Fast track vhdl200x
> >
> >
> > Peter,
> >
> > It was quite difficult to understand over the phone
> > yesterday. I wished I
> > had been there in person.
> > If they are planning to meet again, please le tme know as I
> > would like to
> > attend.
> >
> > I particularly missed the discussion about the interaction
> > between VHPI
> > and the fast track. What is the schedule for fast track? When
> > would they
> > have an LRM ready for ballot?
> > Is VHPI expected to be ballotted with the fast track items if
> > those are
> > ready in June?
> > I don't know if any decisions were taken on the ballot issue, but my
> > opinion is that if we have to wait on the fast track to be ready and
> > additionally have to do some VHPI modifications, I think that
> > there could
> > be quite a bit of delay (definitively > 1 month) if VHPI
> > modifications are
> > implied. The reason for this is that in order to estimate the
> > impact, we
> > would need the final LRM changes.
> >
> > My impression is that many of the fast track items discussed
> > yesterday are
> > still quite immature, some don't even have a proposal, some
> > proposals are
> > outdated... A stime allows, we can start tracking the fast
> > track items and
> > estimate their impact on VHPI but I feel that for some of
> > them that could
> > be quite difficult as the technical proposal is not final and
> > many issues
> > have yet to be solved (ex XMR).
> > Additionally we don't have time at the moment to spend trying
> > to understand
> > the fast track specification, so we should suggest that the
> > fast track
> > people take some responsibility to make proposals on the VHPI
> > changes which
> > we will review. In some cases we could volunteer to craft out
> > the VHPI changes.
> >
> > Anyway if you could clarify the course of action which was decided
> > yesterday and
> > summarize the action items for the VHPI commitee, that would
> > be great. Then we could decide how to proceed with the fast track.
> >
> > Francoise
> > '
> >
> >
>
Received on Wed Mar 10 22:45:25 2004