Marq Kole wrote: > > 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? This is the only race condition I think you'll see in analog, i.e. the order in which you do the copy-out's will maybe give you different results in the next delta cycle if the processes write to the same shared variable. Whether it will effect convergence is debatable since you will have had to converge before you can do the copy-out, but it may lead to different results in different simulators. However it is the kind of thing you can spot fairly easily with static analysis of the elaborated design. AFAIK $strobe statements should not fire until after convergence so there should be no race between a $strobe in one process and another process evaluating it's inputs. > > > > - 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)? The switches in a wired-or would all be switch branches (potential 0, or open). Multiple potential 0 contributions in parallel are not a problem physically, but if the voltage is calculated dynamically you can't statically analyze the case. As far as the solver is concerned it can only have one potential contribution to a branch, if you have multiple potential contributions in parallel of the same potential then the matrix will look the same, you just can't tell how the flow is split. Given that a number of simulators seem to handle this case I assume it is a) a solved problem, b) something that is present in existing designs. > > > 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. Not quite seeing your point either - probably need an example of what you are disallowing. > > > > - 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... It's a keyword - unfortunately the syntax definition for Verilog doesn't allow for keywords to have limited scope, so until that changes you will definitely be causing a backward compatibility issue. The reason that C++ reuses a lot of keywords from C is the same - new keywords always cause backward compatibility problems. > > 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. Since a large number of people using Verilog(-AMS) don't understand English (well), I'm no longer convinced by that argument. If it held water I'm sure VHDL and ADA would be much more popular. Even if you are correct, I still think the problems that introducing keywords will cause with other committees will not be worth the effort. Sounds like you'll need a smart editor either way ... > > > 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. Making it mandatory will avoid confusion :-) > > > 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. Not really, they aren't going to be on the same page if they are hundreds lines apart so whether it's "concatenate" or ":" isn't going to make much difference. If you don't like ":" you can use some other symbol(s), the construct just needs to be something that can't be the LHS of a single statement - to avoid confusion if you don't have the "begin". E.g.: analog <foo> V(x) <+ I(y) * R; - works because "<" can't start a statement. > > > > - 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! If putting modules with simple switches and ideal batteries in parallel works OK then I won't have a problem. Kev. > > Cheers, > Marq > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Apr 17 16:58:23 2007
This archive was generated by hypermail 2.1.8 : Tue Apr 17 2007 - 16:58:29 PDT