Re: [sv-ec] Re: [sv-bc] Opinions on semaphores and suspend operations

<I forgot to copy the sv-bc on this email>

-------- Original Message --------
Subject: Re: [sv-ec] Re: [sv-bc] Opinions on semaphores and suspend operations
Date: Wed, 21 Jul 2010 14:42:00 -0700
From: Neil Korpusik <neil.korpusik@oracle.com>
Reply-To: neil.korpusik@oracle.com
To: SV_EC List <sv-ec@eda.org>
CC: jarekk@aldec.com

<forwarding bounced email from jarekk@aldec.com>

-------- Original Message --------
Subject: Re: [sv-ec] Re: [sv-bc] Opinions on semaphores and suspend operations
From: Jarek Kaczynski <jarekk@aldec.com>
To: "J. M. Williams" <john@svtii.com>
Cc: sv-ec@eda.org, sv-bc@eda.org

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.
>
>

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