30 August 2007 - P1778 workgroup Meeting Minutes

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

Attendance

• Eric Badi, Raphael Berhnard, Gerard Berry, Robert de Simone, Sylvan Dissoubray, Stephen Edwards, Mike Kishinevsky, Marc Perreaut, Klaus Schneider, R.K. Shyamasundar,

• See Attendance Record for meetings participation history

Agenda

Process

• Start: Chair declares the meeting open at 5:04
• 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

The translation of the TeX manual into IEEE Framemaker format has been started by Marc Perreaut. The Working Group should work ony on IEEE format chapters from now on.

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

Action: G. Berry and M. Perreaut will gather change request and still open dicussion points for data and Arithmetic.

Action: M . Perreaut will put the Framemaker sources on the Wiki together with IEEE style guide extract for Stephen Edwards and Luigi Zaffallon to make corrections directly on the source (in red).

IEEE-format Signals chapter

This is the main active discussion from now on. It has actively started on the Wiki. The current LRM chapter does not refer to this discussion yet, except for full / mem / reg points.

Signal Kinds

• Perreaut make a distinction between interface signals in interfaces and executable signals in modules. Is this an appropriate naming?
• Change in signal qualification: this is an important issue since current '''temp''' and '''value''' keywords have proved inappropriate; temp value seems to be the natural default.
• Berry: temp value should be the default, '''mem''' / '''reg''', and '''full''' should be the keywords.
• Schneider: this is quite complicated. Quartz has less notions and simpler notions.
• Edwards: it's a question of type-checking vs. type inference, several points of views possible, each consistent
• Kishinevsky: mem vs reg can be confusing for hardware designers, because they all involve registers.
• Berry / Badi : it could be useful to say that the status of a full signal could be another predeclared pure signal, at least for inputs, and several signals could share the same status
• Berry: is there a better word than '''full''' ?
• Edwards: consider '''bundle''' or '''bundled''' - ''cool!''

• Action: continue this essential discussion in the wiki
• Berry to add a specific page
• Scheider to write a description of Quartz signals and why Quartz is designed that way
• Berry / Perreaut to add the design rationale of Esterel signals
• Discussion to continue from there - ''hardware designers and modelers point of view is crucial there, don't let language designers take all decisions!''

Access to undefined values

The notion of undefined is currently supported, but with some problems, and has been carefully discussed in the meeting. This subject is considered very important.

• Forcing full initilization is a bad idea. It may require fake initializations that in turn may hide bugs. It may be much too expensive in hardware. Uninitialized signals are normal.
• An initialized signal in Esterel need not be initialized in the hardware: clever semantically correct multi-cycle initialization schemes have already been discussed. However, this is an implementation matter and not a language matter
• The current simulator / formal verifier behavior is to raise an error if an undefined signal is accessed. This should be the normal semantics.
• Such errors cannot be found by type-checking, but can be (and are) detected by formal verification. They could also be detected by abstract interpretation.
• However, Esterel Studio currently raises some errors wile it should not, see the Wiki example.

• Action: G. Berry / M. Perreaut will describe the current rules.

• Action: discussion will continue from there on to exhibit the correct rules.

Dealing with interfaces and refinements

Several points are raised about partial interface extension:

• should mirror be made in two different parts, for inputs and outputs?
• the observe proposal makes all signals input. Can it be derived from simpler proposals?
• when extending interfaces, Badi would like to hide some signals.

• Action: Discussion should continue on the Wiki, the kernel extension / mirroring / hiding mechanisms should be carefully investigated, as well as how to make more elaborate ones as combinations of kernel ones

• As pointed out by Badi, there is a need to '''factor out refinements''' on an interface. Is the current proposal adequate?

• Assertions in interfaces: one should be able to add code in interfaces, for instance for protocol checking. Proposal on the Wiki, to be discussed. Same for functional code in interfaces.

• Action: this subject is very important and should be carefully discussed, maybe in conjunction with PSL / SV way of doing things. External expertise needed?

Other subjects scanned

Discussion should continue on this in the Wiki.

• status dimension list of a value-only signal: Schneider to explain how the same is done in Quarz.
• pre status of temp signals: to continue
• clock signals in interfaces: please check, should be quite straightforward.
• clock equation syntax: please check, should be quite straightforward.
• oracles. Free inputs, locally declared in the same way as assertions, saving declaration propagations. Difficult to drive in simulation. Still a bit unstable. Advice welcome.
• Port assignment: Basi's proposal to be discussed, probably in relation with the interface discussion, for instance for partial assignment on output fields
• Arrays of ports: Badi's proposal to be discussed
• Scope of local signals, and sequential or parallel elaboration of declarations, Traulsen's proposal. Currently, declarations are parallel, while they were sequential in v5. Edwards thinks this is good, since nesting declarations is clearer if sequentiality is needed. Berry agrees, and says that he has never seen a problem occurring in practice, and that ',' means in parallel for equations as well.
• Action: Traulsen to complete his proposal, to be later discussed

Next chapters for discussion

• The Statement chapter should be simple and with less discussion. Some v7 statement added to v5 ones actually proved useless and should be removed.

• The Expression chapter should be more involved, since we need to add and understand functional module calls in expressions

Tasking

Raphael Bernhard asks whether tasking will be part of v5. Berry answered no, because almost nobody used it in v5. RB says they would use it a lot at France Telecom, and they have to do it by hand. Edwards says it cannot be a simple issue, and needs more experience.

''Follow-up comment [Reinhard von Hanxleden]:'' I have to admit that I did not see heavy uses of this myself, but I like the concept very much. Perhaps it's also a matter of educating the users a bit about the potential of this mechanism. Just as one data point, consider http://drops.dagstuhl.de/opus/volltexte/2005/161/pdf/04491.WhiteDavid.Paper.161.pdf - which had (at least partially) re-invented the tasking concept to serve their needs, in the context of interfacing with data base queries (see also the acks in that paper). I could envision similar uses in the hw world, where a tasking mechanism could provide a clean mechanism to control external, asynchronously running processes, including preemption and suspension.

• Action: RB to write a paper explaining how he drives tasking from v7.

Motions and actions items with name and due date

• SE Will do a check pass about formality of the manual wrt standards vocabulary like shall and should and indicate wrong places.
• MP Distribute IEEE rules excerpt to SE
• KS to add to the signals types, infered or explicit delayed (=reg)
• Share framemaker source with Luigi, lets's put on wiki.

Adjournment and Next meeting date

Next meeting will be October 10 or 12 - 5 PM Paris time

Meeting is closed at 6:15 PM.