From: Guy Mosenson
Sent: Friday, October 19, 2007 10:15 AM
To: Shlomi Uziel; Matan Vax
Subject: RE: IEEE 2008 doc [Guy's review]

I had little time, so I ended up reading only the intro and overview, until section 1.3.4 (of draft 3 dated 8-Oct-07)

My comments follow, arranged by page + quote from text + my comment.

(for page number I use the “PDF page count”, not the printed page number)

If you reviewing more later on is still relevant, let me know

· When is the next deadline

· Should I read draft 3 or wait for draft 4

Cheers,

Guy

---- My comments follow -----------------------------------

· Page 4:

o “experimented with as early as 1993,”

§ My notes say our experiments (in Digital) with e in started 1992, if it matters…

o “Beyond objects, e supports aspects”

§ May be better to explicitly refer to “aspect oriented programming (just like the previous bullet speaks of “object oriented”

· Page 4-5

o Following the listing of e features, here are a few other attributes of the e language not mentioned there, which I find possibly relevant to mention too:

§ Spec driven automation (declarative coding, such as physical fields, constraints and cover statements, etc.)

§ Built in checking and coverage capabilities

§ Modeling for generation (when inheritance, constraint driven, “infinity minus”, generation of “trees” of units and structs)

§ Extensibility of the language (by “macros” which truly expand the language)

· Page 25, section 1.3.1 Fundamental considerations

o “In principle, an e program can be either compiled or interpreted.”

§ At the end of this section, I think it should say something like “from here on, in places where the text discusses ‘loading’ e files, take into account that same can be true for compiled files

· E.g., in the next section, 1.3.2, it explains loading e files in different orders can make a difference – same is true for compiling them in different order

· Page 25, section 1.3.2 Organization of e programs

o “Each e program induces an ordered list of modules… Loading the modules in a different order might result in a program that is malformed or is different”

§ Maybe need to explain more explicitly that currently e files are loaded/compiled in a strict stream, on after the other (as opposed to C, where files can be compiled separately and then simply “linked” together)

· Page 25-26: section 1.3.3 Modes of execution (and also the two sub sections 1.3.3.*)

o This whole section is not clear enough

o First flaw is in the text “e programs are distinguished based on the modeling of time during execution. A more complete discussion of treatment of time can be found in Clause 10 and Clause 11.”

§ This text needs to say more as an intro to how Specman relates to time and execution, and briefly talk about the two modes (which are elaborated in the sub sections, something like:

· e programs are focused on verifying HDL designs, therefore they often run “attached” to a simulator, in what is called co-simulation mode . However, they can also run in “standalone” mode (without a simulator). These two modes of execution impact the way time progresses in the simulated run, and are explained in the following sub sections

o , 1.3.3.1 Stand-alone execution

§ “e programs can execute independently. In such cases, the program shall use cycle-based semantics.”

· This phrasing makes no sense in this context. The reader was not introduced yet to the fact that e programs usually run “against” a simulator running an HDL program (DUT). Therefore I expect readers will be baffled by the sentence “e programs can execute independently”. They will assume running standalone is the most natural thing in world, and “can execute independently” will sound like a hint that e is actually crippled and can not run standalone reasonable

§ In order to improve the section, something like the following info needs to be added

· (a) when attached to a simulator, the simulator controls time units and progress, and the e program “gets” time from the simulator

· (b) when running stand alone, the e “simulation core” will control time progress.

· this would lead to explaining there is such an “e simulation core” that uses ”cycle-based semantics” and all the rest of the explanations in this section