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

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
>         '
> 
>