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

> Verilog hasn't become more popular than VHDL because ...

Is Verilog really more popular than VHDL? VHDL is still popular for ASIC design worldwide, and, even in N. America, is much more popular than Verilog for FPGA design.

And, for programming languages, don't count out VHDL's cousin Ada

   http://www.techworld.com.au/article/223388/-z_programming_languages_ada?pp=4

-- Brad
________________________________________
From: owner-sv-bc@eda.org [owner-sv-bc@eda.org] On Behalf Of John Michael Williams [john@svtii.com]
Sent: Tuesday, July 20, 2010 11:16 AM
To: sv-ec@eda.org; sv-bc@eda.org
Subject: Re: [sv-ec] Re: [sv-bc] Opinions on semaphores and suspend operations

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.