Mark and others -
> Meeting minutes from the 4/15/98 DC-WG teleconference
> -----------------------------------------------------
...
> 1. Charter/scope discussion
>
> We spent a fair amount of time on this.
>
> Jin-sheng suggested that it is important to develop
> a conceptual model.
I quite agree and found his work todate very helpful!
> Mark suggested that a persistent representation is
> needed as a deliverable, and that a command language
> has advantages over other representations in terms of
> immediate usability and user friendliness.
>
> Proposal:
> - Deliverables should include
> - A presentation on the conceptual model, combining
> ideas from the different point of views.
If Jin-sheng would like, I would be glad to take the conceptual
model he is coming up with, and convert it into EXPRESS formal
semantic model. The format of the model he has provided todate is
very understandable and moving to ever greater depth and detail.
An EXPRESS version of his model would allow those of us working on
data representation using that latter format to then start to
understand the impact of supporting this emerging constraints work.
- Please note that I do not here propose at all to replace his
format/style with EXPRESS - His approach is very useful for
understanding the proposed architecture and data elements.
> - A constraint dictionary
> - A constraint command language
Presumably the above is targetted at defining constraints in a flexible
way (and I apologize if I have missed earlier discussions on this point!).
- Will there also be a format/method also for implement the constraint
data/rules data population within an EDA tool, such as an API
(e.g. C++)?
> For the overlaps between DC-WG and other standards efforts,
> we discussed several options, and decided that we would start
> with a Chair to Chair discussion with each group.
>
> 2. Presentation by Enrico on constraint transformations
> and conceptual model
>
> Some points made in the discussion include
> - In the top-down process, some constraints come from
> transformations, while some are injected directly
> by the user (these may be obtained through implicit
> transformations or they may represent detailed
> implementation controls)
> - Enrico suggested that the constraint description
> should include a description of how to verify the
> constraint and auxiliary data required to do so
> - Mark suggested that auxiliary data used in verification
> is really an extended form of boundary conditions/operating
> environment
> - We talked about the idea of an internal and an external
> data bus for transferring constraints between tools.
I am, of course, following this important work from the POV of
incorporating a richer support of constraints into the proposed
draft standard, CHDStd; so thats one potential target. However,
in practical terms, the world will not switch to the API-based
CHDStd overnight ... and some of the EDA/design world will perhaps
move to it (from a large variety of circumstances).
- Therefore, general discussion about an 'internal data bus' for
sharing constraints between tools is useful and should help us
understand how it will work in a normal tool flow.
> The constraint command language would be the external
> data bus.
Good.
> 3. Constraint dictionary discussion
> We postponed this to the next meeting.
Can someone point me at a working document on this area? I haven't been
able to read all the DC-WG email and seemed to missed discussion on
this.
...
> --Mark
--Steve Grout
Design Thrust - ECAD Program - CHDS/CHDStd
SEMATECH
2706 Montopolis Dr, Austin, TX 78741-6499
Phone: (512)356-7071 Fax: (512)356-3110
email: grouts@bootskut.eng.sematech.org or Steve.Grout@SEMATECH.Org
--Boundary_(ID_Ty8zJyrFRoysOfK/NocJGQ)--