October 12 2007 - P1778 workgroup Meeting Minutes

  • Workgroup: P1778 - Esterel v7 language standardization
  • Location: Teleconference (see Next Meeting to connect)
  • Date: 12 Oct 2007
  • Chair: Gerard Berry
  • Vice Chair: Stephen Edwards
  • Secretary: Sylvan Dissoubray

Attendance

  • Eric Badi, Claus Traulsen, Charles Andre, S. Ramesh, R.K. Shyamasundar, Gerard Berry, Marc Perreaut, Reinhard von Hanxleden, Sylvan Dissoubray, Marc Duranton, Luigi Zaffalon, Stephen Edwards, Raphael Bernhard, Badr Bentaybi, Jean-Philippe Cousin, Klaus Schneider, Mike Kishinevsky, Robert de Simone,

Agenda

Process

  • Start: Chair declares the meeting open at 5:05
  • Agenda: The agenda is approved by participants
  • Minutes: No objections about last meeting minutes -- they are approved
  • Patents: No new item . The page IEEE Patent Policy holds the call for patent, and workgroup status.

Technical topics

Brief summary of discussion, pros and cons, and conclusions

Specific Working Groups Organization

  • WG1 : Data, arithmetic, and expressions
    • Eric Badi, Gerard Berry, Stephen Edwards, Mike Kishinevsky, Marc Perreaut (organizer), Klaus Schneider.

  • WG2 : signals, interfaces, ports
    • Eric Badi, Badr Bentaybi, Gerard Berry (organizer), Jean-Philippe Cousin, Reinhard von Hanxleden, Klaus Schneider, Claus Traulsen,.

  • WG3 : inheritance, genericity

  • WG4 : Tasking

    • Raphael Bernhard (organizer), Gerard Berry, Luigi Zaffalon

IEEE-Format Data and Arithmetic chapters

Three chapters have been written in IEEE format by Marc Perreaut, Data, Arithmetic, and Signals. They have been put on the Wiki mid-August but not yet reviewed by all participants.

  • Data chapter put in IEEE style, not all change proposals have been incorporated yet
  • Arithmetic chapter idem

A new proposal for Esterel v7 signals

See New proposal for signal declaration

Value signals

MK: replace init / default with and operator, e.g. '':=''

Maintained values

CA: ''Eventually maintained'' as a better naming than ''semi-maintained''

MK: or ''always defined'' and ''eventually defined''. '''Approved'''. To be added to glossary.

Control signals

CA: pre1 also available for control? Yes

RDS: opposite of ''control'' is usually called ''data'', better than ''value'' for hardware people. MK: OK. Approved. ''data'' and ''control'' signals to be added in glossary.

Controlled signals

CA: why not have a special naming for the clock associated with the control signal. See later.

MK: Should control signals be simply called signals like before. TB analyzed.

RvH: Should we allow declaration of "full" signals (simultaneous declaration of control and data signals)? Because it is painful to declare a second name for the control of a controlled signal? But how to disambiguate the control and the data for such a signal (currently done by using '?' for the data)? To be analyzed and decided.

N.B. In ''output X when X_change'', X_change is an output control.

Controlled signals arrays

Decision point about Claus comment. '''We miss this comment here.'''

Port value and assignment

NB. right hand side can be another port, or a struct being the result of a function call.

 emit P <= {X_change: false, X: 3}

This does no emission of the data signal X, (and no error either). NB the false status can be the result of a computation .

NB. struct are unordered.

SE: Problem if structs partially share names. OCAML makes the choice that names are globally unique to solve it, which is awkward. To be analyzed.

A shorthand to test the control

Before, you had X and ?X now you have @X and X (but there are much less @ than ? in programs). In HW designs, data signals are generally more frequently used than control signals.

Actually ?S would be a natural name control of S, unfortunately it would be a rather confusing change.

Questions

RB: Is there a danger of making software more complex when simplifying hardware design ?

A page for the document discussion to be added.

Reinhard von Hanxleden. Have a glossary, with mapping to previous notions to ascertain terminology.

Inheritance and Genericity

SE: Difference between module wo body and interface

GB: Interface is not equal to module headers, which have refinements. Module without body is a module headers, while interfaces are just pin lists with directions and types/sorts, no dynamic properties. You can mirror an interface, you can not mirror a registered signal.

SE: not convinced.

GB to add examples on this topic.

Adjournment and Next meeting date

Next meeting will be decided by email

Meeting is closed at 6:37 PM.

Topic revision: r2 - 2008-09-23 - 15:24:13 - SylvanDissoubray
 
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback