Marq,
I'm with you, I think we should remove the old current discipline
from disciplines.vams. I don't think anyone uses it, and it creates
confusion.
-Ken
On 10/05/2010 12:22 AM, Marq Kole wrote:
> Hi Ken, David,
>
> Finally came around to looking into this item.
>
> It looks like all the changes we made to section 3.6.2 have magically skipped over 1.3.4 and 1.3.5 so these are now completely out of date. By the way from the example in 1.3.5 the access function depends on the nature, not on whether that is a flow nature or a potential nature - it is valid in both the old situation and the new situation. It was already there in LRM 2.0 :-)
>
> It is clear that sections 1.3.4 and 1.3.5 need to be updated - I have already done so previously in mantis item #2266 as Ken pointed out in mantis item #3203.
>
> The only ambiguity that was that in the disciplines.vams the previous definition of the current discipline as a potential-only discipline was consciously maintained for backward compatibility. I still question whether we should have this backward compatibility or rather consistency with section 3.6.2.1 (specifically the 3rd example in that section in LRM 2.3.1). I am leaning now more toward consistency...
>
> Best regards,
> Marq
>
>
> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Ken Kundert
> Sent: Monday 13 September 2010 22:54
> To: David Miller
> Cc: verilog-AMS LRM Committee
> Subject: Re: Mantis Issue 2266: Signal-Flow Disciplines
>
> Dave,
> I have to say, that I did not understand the post you quoted as it
> seemed that backward compatibility was being used to justify not making
> the fix, whereas the fix was being requested for reasons of both
> consistency and backward compatibility. The problem now is that the LRM
> is a weird state where in section 1.3.4 the LRM clearly limits signal
> flow ports to being potential only, whereas in section 1.3.5 an example
> is given that uses a current signal flow ports.
>
> I will create a new issue in Mantis for this.
>
> -Ken
>
> On 09/13/2010 12:53 PM, David Miller wrote:
>> Hello Ken,
>> The resolution for this issue was:
>> <QUOTE>
>> Marq Kole 18-12-2008:
>> After discussion it is agreed that the definition of the Current
>> signal-flow discipline in Annex D.1 will not be updated to maintain
>> backward compatibility. For the rest the description of single nature
>> disciplines as signal-flow disciplines according to the note (0007324)
>> of Srikanth_Chandrasekaran made on 2008-08-13 04:08 is not in LRM 2.3.
>> Therefore, this item shoudl remain open for the next LRM iteration.
>> </QUOTE>
>>
>>
>> I made the changes identified in LRM 2.3.1 draft B which made it into
>> the AMS LRM 2.3.1 - Section 3.6.2.1 Nature Binding. The fix was simply
>> to identify a single nature discipline as a signal-flow discipline with
>> the following sentence:
>>
>> "Disciplines with a single nature are called signal-flow disciplines and
>> the nets with signal-flow disciplines are called signal-flow nets."
>>
>> Once an issue has been "resolved" I don't think it can be undone (I
>> can't at least, although I assume the Mantis admin can). We would need
>> to create a new item and reference this one if you feel it has not been
>> resolved correctly.
>>
>> Cheers...
>> Dave
>>
>> On 09/13/2010 02:37 PM, Ken Kundert wrote:
>>> All,
>>> This issue is marked as being resolved as of the release of v2.3.1
>>> of the LRM, but the required changes are not actually in this version of
>>> the LRM. I tried to re-activate the issue in Mantis, but I cannot see
>>> any way to do that.
>>>
>>> How do I re-activate this issue?
>>>
>>> -Ken
>>>
>>
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Oct 5 10:59:52 2010
This archive was generated by hypermail 2.1.8 : Tue Oct 05 2010 - 10:59:53 PDT