Re: feedback

Kevin,

Some answers to your remarks on the minutes of the last call.

<snip>

> > - multirate, parallelism or latency should not be made explicit in 
> > the language. Rather, if a tool supports it, it is up to the 
> > underlying implementation to make optimal use of it and not have the
> > model writer or simulation user worry about this. There are 
> > sufficient reasons to believe that user interaction for support of 
> > multirate, parallelism and/or latancy is not needed. 
> It needs to be clear which operations are atomic, e.g. if things are
> evaluated in parallel do threads have exclusive access to (say) an 
> array/vector or just scalars?
> 
> A simple rule you can add (if it isn't there already) is: no two 
> processes that directly share data should be active at the same time. 

Agreed, formulation may be slightly different

> Note: with copy-in/copy-out the copy operations probably need to be 
> atomic, but not the process evaluation.
 
<snip>

> > - copy-in, copy-out behaviour has too many restrictions to be 
acceptable. 
> I think my earlier point on that was: that's how the simulator 
> works, it's not really something you can change.

Then we need to be clearer on what copy-in-copy-out behavior is. As stated 
in the multiple analog block document it is considered the fact that if 
separate processes are associated with the concurrent analog blocks that 
the data made available to the other processes is copied out at the end of 
the evaluation of all these processes so that for the next evaluation all 
processes have exactly the same set of values for each of the shared 
variables. The problem is that it is not possible to communicate a value 
to a different process in the same time step in which it was calculated. 
For many module initializations this will lead to uninitialized blocks 
which in many analog cases will lead to wrong behavior, non-convergence or 
worse.

                  <real xv, k>
                      |
copy-in        +------+-------+
               |              |
         +----------+   +-----------+
         |          |   |           |
         |  analog  |   |  analog   |
         |   proc   |   |   proc    |
         |          |   |           |
         |  xv = 1  |   |  k = xv   |
         |          |   |           |
         +----------+   +-----------+
               |              |
copy-out       +------+-------+
                      |
               <xv = 1, k = 0>

Does this correspond with your ideas on copy-in, copy-out behavior? If 
not, could you try to explain what you mean?

> > - for switch branches it was concluded that the best approach was do
> > disallow concurrent switch branches, i.e. a switch branches whose 
> > contributions are distributed over multiple analog blocks. In most 
> > cases this would be the result of bad modelling, while a few cases 
> > that might be legal can also be described using switch branches on 
> > named branches that are local to the analog blocks. 
> It can't see how you can enforce that, it's going to be difficult to
> analyze statically and how can you tell in a large design using 3rd 
> party IP where the switch branches are?

As a switch branch is a contribution statement inside a conditional 
controlled through a dynamic expression, the limitation says that you 
cannot contribute to the same branch in another (concurrent) analog block. 
Where do you see the problem in analyzing that statically?
 
> The wired-or case I posted before seems like a simple case that 
> should be handled properly. 

A wired-or is not a switch branch. Could you provide a link to the post 
(or reissue the example)?
 
> Looking at the discussion document I think you are confusing the 
> race-condition argument with the switch branch condition evaluation.
> For any given branch the contribution from each analog block is 
> evaluated independently, if you can't tell from static analysis that
> they are all flow or there is always a potential it's going to be a 
> switch branch, if it's a switch branch then there should only be one
> potential contribution active at any time (unless the contributions 
> are identical), and that has to be a runtime check.

Even if they would switch in such a way that they all have the same 
nature, the suggested course of action is to disallow switch branches 
distributed over multiple analog blocks. An OOMR contribution is not 
making a switch branch either, so I don't see the issue.

> > - for continued analog blocks, it was considered that this was a 
> > legal extension necessary for the support of generate constructs 
> > where a specific order of evaluation of the resulting multiple 
> > analog blocks was required. As it is, for the various options 
> > described in section 3.2.2, option 2 extended for named blocks was 
> > considered best in being more easily to read, allowing sufficient 
> > flexibility in not having to write the blocks to concatenate next to
> > each other, and associateing the continuation with the analog 
> > statement rather than the sequential block (as in option 3). For the
> > keyword to use, we did not want to reuse "continue" to prevent 
> > confusion, and settled for the word "concatenate". 
> I still advise against "concatenate" because it will meet resistance
> in other committees - new keywords always do.

concatenate is positioned as a qualifier - I don't know if that makes it 
less a keyword...

The reason for choosing a keyword is the improved clarity and readibility 
that it gives to the model code. If there is a very large model with many 
analog blocks it may not occur to the reader that the same name is used 
multiple times. The concatenate keyword would focus his attention to the 
fact that it will be concatented to a previous (similarly named) block, 
not evaluated concurrently.

> The concatenate keyword should have a label so that you can 
> concatenate different groups of blocks within a module separately. 
> You could make the label optional, but I think making it mandatory 
> would be better - and you can relax that rule later.

It seems reasonable to allow either.

> As another alternative you could skip the keyword and just label the
> analog statement and concatenate the statements with the same label,
> e.g. scopes first and last below would be concatenated:
> 
>        analog : foo begin : first ... end  // concat. group: foo, scope: 
first
> 
>        analog : bar begin ... end  // concat. group: bar, scope: first
> 
>        analog : foo begin : last ... end  // concat. group: foo, scope: 
last
> 
> - less typing, no new keywords.

More confusion, if the blocks are hundreds of lines apart from eachother.

> > - based on the discussion results and the decisions taken, the 
> > following will now be done: 
> >   * Marq will update the multiple analog blocks document with the 
> > current insights and discussion results. 
> >   * Marq will make a new update of Chapter 7 of the LRM 2.3 to 
> > reflect the decisions, to be discussed next week. 
> >   * Marq will make a document on the impact of changes to Chapter 7 
> > to the other chapters in the LRM 2.3 as well as the syntax 
> > maintained by Graham Helwig. 
> I don't think we are at a point where we can commit to changes yet. 
> I would prefer to see more discussion on the items individually on 
> the reflector and proper proposals for each item before any updates.

The observation from the committee members present in the call was that 
we've converged far enough to pick up section 7 again. If I read back your 
comments your main objections now are with the handling of switch 
branches. Unless you can provide compelling evidence that the proposal to 
restrict of switch branch contributions to a single analog block is 
problematic, I do not see a reason not to extend section 7 with a 
subsection describing the syntax and semantics of multiple analog blocks. 
There is still a large amount of work if we want to meet the current 
deadline!

Cheers,
Marq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.