RE: [sv-ec] Re: [sv-bc] Opinions on...

John,

I am in agreement with you on trying to get SystemVerilog stable and
have written about this before: http://go.mentor.com/a-time-for-change.

The reason for limiting voting membership is an attempt to keep the
flood gates for enhancements limited as well. In practice, this does not
seem to work as well as I would have liked.

IMHO. this is a standards body, not a research and development
organization. We are here to standardize (i.e. document in a succinct
language) on what should have already been developed.

Dave

> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
John
> Michael Williams
> Sent: Wednesday, July 21, 2010 11:22 AM
> To: sv-ec@eda.org; sv-bc@eda.org
> Subject: Re: [sv-ec] Re: [sv-bc] Opinions on semaphores and suspend
> operations
>
> Hi Jerry.
>
> My complaints about SV are not constant, and calling them "rants"
> is unfair. Having been disenfranchized by denial of voting
> membership, I am complaining in the way that is available to me.
>
> I am merely voicing the same objections that others have
> in the past, and have given up on, in the face of persistent
> unwillingness of the SV working groups to attend to customer and
> tool developer complaints about ever-increasing complexity of SV,
> and the endless "enhancements" which make it harder and harder
> for anyone to know SV.
>
> How on earth is anything in this group a "moral" obligation
> of any kind?
>
> There are few if any "incomplete" specifications in verilog, but the
> open doors in all directions of these SV groups' work have done little
> to complete SV (as opposed to verilog). Complication has taken the
> place of completion. Verilog is done; VHDL is done: When will SV be
> done?
>
> In fact, some languages are inferior to others. Now, how can ANY
> language be improved if the weaknesses in certain other languages are
> not recognized and improved upon?
>
> Pascal failed because there was too much typing and too many
> restrictions. PL failed because there was too much typing and
> it was a complex jumble of features. Lisp failed because there
> was to much typing (of parentheses!) and it was too hard
> to read. Of course, all these languages survive in niches.
> Don't you think that one can learn from the mistakes of others? Or,
> is the only learning possible, that from ones own mistakes?
>
> I am trying to IMPROVE SV; it is not my duty to "advance" it or
> verilog, or anything else. I am not an advertising agent for
> any language or tool. Noone in any SV working group should
> be "advancing" SV. That is a matter for IEEE marketing.
>
> I teach verilog, and I would like to teach SV; however, almost no one
> wants to learn SV, and no one has tools for even half of the Std.
> I see little improvement, so far. I blame the SV working groups
> for this; do you think this blame is misplaced?
>
> On 07/20/2010 02:17 PM, Jarek Kaczynski wrote:
> > John,
> >
> > While I agree that possibility of deadlock is 'a feature' of
> semaphores, not
> > 'a bug' that should be caught by compilers etc., I strongly disagree
> with
> > majority of your arguments because they are doing SystemVerilog
major
> > disservice instead of advancing it:
> > 1. Your analogy with race conditions in 'always' blocks is the worst
> > possible - for goodness sake, the semaphores were invented to
prevent
> race
> > conditions and similar synchronization issues!
> > 2. One of the major weaknesses of Verilog was its incomplete
> specification,
> > opening doors to different behaviors of different tools. It has
nothing
> to
> > do with curbing/enabling designer's creativity - it is faulty design
of
> the
> > language. SV was doing great job of addressing those issues so far,
so
> > improving specification of semaphores is technical and moral
obligation
> of
> > the committee.
> > 3. Your constant rants about inferiority of other languages are not
the
> > proper way of making SV more popular. Neither the language itself,
nor
> this
> > groups need such a horrible waste of time the new 'language wars'
would
> be.
> >
> > Thank you,
> >
> > Jerry Kaczynski
> > Research Engineer
> > ALDEC, Inc.
> >
> > On Tue, Jul 20, 2010 at 11:16 AM, John Michael
> Williams<john@svtii.com>wrote:
> >
> >> Hi Brad.
> >>
> >> Yes, SV includes optional always_?? blocks which can avoid races
> >> as well as force synthesizer decisions.
> >>
> >> I am sure that the purpose of the always synthesis limitation was
to
> >> make compiler design easier, not primarily to avoid designer
> >> errors. For example, one can use synthesizable continuous
> >> assignments to the same wire to create exactly the same race
> >> risk, or always_?? blocks in different modules.
> >>
> >> Also, assigning to the same variable in different always blocks
> >> does not necessarily cause a race -- for example, if the blocks are
> >> clocked on opposite edges of the same clock, or if they include
logic
> >> preventing a race.
> >>
> >> Sometimes, one doesn't realize how aggravating built-in language
> >> limitations, triggered by fear in a standards writer or
> >> compiler developer, can be to a skilled designer.
> >>
> >> Returning to the semaohore question, I think system-level risks
> >> should be left to the designer, to be caught by the simulator and
> >> not by the simulator compiler.
> >>
> >> For example, a designer might WANT a deadlock under certain
> >> conditions as a (sub)system fail-safe; or, one might want
> >> a deadlock because of normal operation which would break it
> >> by means of a third process. How could these situations
> >> be permitted in SV, if it were changed to prevent deadlock
> >> in the first place? The risk of a buggy compiler to achieve this
> >> would exceed any designer risk of an unintended deadlock.
> >>
> >> Verilog hasn't become more popular than VHDL because it includes
> >> more safety limitations; likewise, C has not been adopted over
> >> Pascal, PL, even COBOL, because it is less risky to a beginner
> >> designer.
> >>
> >> I urge this group not to try to use the compiler to prevent
> >> operational design errors.
> >>
> >> Even if some optional construct could be added to reduce
> >> semaphore risk, it only would burden SV with yet more complexity,
> >> complexity which has made it so unwieldy already.
> >>
> >>
> >> If people want to just keep adding enhancements without limit, the
SV
> >> Std should be reorganized so that it could be specified in stages
of
> >> development, not as a single language. For example, the base level
> >> could be verilog, a second level could be verilog plus C++
> enhancements,
> >> a third might add the assertion constructs, etc. There could be
> >> a safe-coding level which would limit the available constructs
> >> to reduce designer risk or to be synthesizable . . ..
> >>
> >>
> >> On 07/20/2010 09:30 AM, Brad Pierce wrote:
> >>
> >>> even though it risks a race condition
> >>>>
> >>>
> >>> But if you write to the variable from an always_comb, always_latch
or
> >>> always_ff, then not even an old-style always block can legally
write
> to
> >>> that
> >>> same variable. A methodology that forbids old-style always blocks
> protects
> >>> from some race conditions.
> >>>
> >>> -- Brad
> >>>
> >>> On Tue, Jul 20, 2010 at 9:21 AM, John Michael Williams
> >>> <jwill@basicisp.net>wrote:
> >>>
> >>> Hi All.
> >>>>
> >>>> I don't think this should be a language issue, unless it can be
> >>>> included in the Std independent of whether there is a block
> >>>> during operation or not.
> >>>>
> >>>> By analogy, synthesizable SV forbids assigning the same variable
> >>>> in two always blocks, but SV itself allows this, even though
> >>>> it risks a race condition. The language allows the writer to
> >>>> take this risk. So also should it allow the writer to risk
> >>>> a deadlock during operation. That's what watchdog code is
> >>>> there for!
> >>>>
> >>>> On 07/19/2010 05:25 PM, Steven Sharp wrote:
> >>>>
> >>>> I ran across this issue a month or so ago, and hadn't gotten
> around to
> >>>>> bringing it up. I didn't consider the specific case of a
process
> at
> >>>>> the head of the queue with some of its requested keys available.
I
> >>>>> didn't consider this to be any different from the general case
of
> being
> >>>>> suspended while waiting on the semaphore.
> >>>>>
> >>>>> That is because I don't view the process at the head of the
queue
> as
> >>>>> having taken the initial key. It waits until there are two, and
> then
> >>>>> takes them both. So there are none held, and none to be
rescinded.
> So
> >>>>> this "partial" situation is not special. It is the same as any
> other
> >>>>> situation where a process is suspended while waiting in the
queue.
> >>>>>
> >>>>> A while ago I pointed out what I considered to be an error in
the
> LRM.
> >>>>> It says that a try_get will proceed if the requested number of
keys
> is
> >>>>> available. It does not say that it proceeds if the requested
> number is
> >>>>> available and there are no previous processes waiting on them.
One
> way
> >>>>> to view this is that if there is a process at the head of the
> queue,
> >>>>> it is holding all of the keys that were available, so that the
> try_get
> >>>>> cannot get them. The other way to view this is that the partial
> set
> >>>>> of keys has not been taken, so that the try_get can grab them,
> bypassing
> >>>>> the normal fifo order. Since I was viewing it this second way,
I
> felt
> >>>>> that this violation of fifo order was bad. But I think that
Arturo
> or
> >>>>> Dave said that it was supposed to work this way. If so, that
would
> >>>>> confirm the view that a process does not take the keys until its
> entire
> >>>>> request is satisfied. I went back and did not find the
discussion
> I
> >>>>> remembered, but I see Mantis 1738 is similar. I consider this
to
> be a
> >>>>> more likely situation than the suspend, and a more important
reason
> for
> >>>>> settling whether the first process is holding those keys.
> >>>>>
> >>>>> So anyway, I tend to reject your option 1 as being based on an
> incorrect
> >>>>> premise.
> >>>>>
> >>>>> I considered your option 2, and noted that it destroyed the fifo
> >>>>> ordering.
> >>>>>
> >>>>> I saw another bad option:
> >>>>>
> >>>>> 4. The process is considered to do its own operations to take
the
> keys
> >>>>> and remove itself from the front of the queue. Since it is
> suspended,
> >>>>> it cannot do this, so all processes in the queue are frozen
until
> this
> >>>>> first process can take itself off of the queue. This preserves
> fifo
> >>>>> ordering, but locks up the queue until the process resumes.
> >>>>>
> >>>>> I decided that your option 3 was the right answer, since it
> preserves
> >>>>> the fifo ordering and does not lock up the queue.
> >>>>>
> >>>>> I assume that when you say this is bad for resource management,
you
> are
> >>>>> referring to the fact that this process ends up holding those
keys
> and
> >>>>> making them unavailable while it is suspended. But the same is
> true if
> >>>>> the process is suspended (or worse, killed) immediately after it
> gets
> >>>>> the keys. If you suspend or kill processes that could hold
keys,
> then
> >>>>> you have this problem, and none of these options fix that. On
the
> other
> >>>>> hand, option 3 does ensure fifo behavior.
> >>>>>
> >>>>> I think we should guarantee linearization, because we can
actually
> do
> >>>>> that successfully. That should take priority over trying to
keep
> the
> >>>>> resources available, since we can't guarantee that in the
general
> case
> >>>>> anyway.
> >>>>>
> >>>>>
> >>>>> Steven Sharp | Architect | Cadence
> >>>>>
> >>>>> P: 508.459.1436 M: 774.535.4149 www.cadence.com
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>> John Michael Williams
> >>>> jwill@BasicISP.net
> >>>>
> >>>>
> >>>> --
> >>>> This message has been scanned for viruses and
> >>>> dangerous content by MailScanner, and is
> >>>> believed to be clean.
> >>>>
> >>>>
> >>>>
> >>>
> >> --
> >> John Michael Williams
> >> Senior Adjunct Faculty
> >> Silicon Valley Technical Institute
> >>
> >>
> >> --
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >>
> >
>
> --
> John Michael Williams
> Senior Adjunct Faculty
> Silicon Valley Technical Institute
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.

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