Sri Chandra wrote: > Hi all, > > I would prefer that we keep the discussion on the reflector purely > technical - as to what is broken in the language today, what we need > to do to fix it or if people feel that there is not enough information > about a particular feature defined in the language for them to > implement it correctly. Of course, as part of this we need to > understand the original underlying requirement - what was missing > pre-2.0 LRM that necessitated the addition of the new syntax, and > whether its required, restrictive or better alternatives available? On purely technical grounds: wreal is an unecessary hack. > Coming to wreal query, in my opinion i think it needs to be in the > digital syntax - given that its a digital/mixed signal feature (and > can be assigned only in the digital domain), i would think that it > should be part of the 1364 std. But today 1364 does not allow ports of > type real. So we need to take this with digital committee in the true > spirit of a mixed signal common language for them to support it (if > required). If there are good reasons for them not to support it or if > it is already supported through existing syntax in digital then we > need to reconsider the value of additional syntax that we define in AMS. This is a mixed signal language, there's no reason you shouldn't be able to assign a wreal type driver from either analog or digital processes. Making unnecessary distinctions just adds complexity for the users. I didn't think anyone was working on 1364 anymore. > SystemVerilog probably addresses this problem partially by having > something called user defined types, but again i am not sure whether > they have defined clearly how resolution is performed on this type. The SV committees have not done any work (to the best of my knowledge) on signal resolution with user defined types, or added any new resolved types. > I think Graham suggested a while back that wreal should just be > treated as another discrete net type with an associated discipline and > we can do discipline resolution appropriately. Been there, done that - http://www.eda.org/verilog-ams/hm/0241.html Kev. > > Dave, > Well there are only two places for you to look for digital and mixed > signal features - AMS LRM2.2 or 1364-2005, if there are other > documents in which its documented it should be part of these stds :-). > Probably you can post an email to the digital std. Some of the contact > people for 1364/SV are sharp@cadence.com (Steven Sharp), Michael > Mcnamara (mac@verisity.com) or shalom.bresticker@intel.com (Shalom > Bresticker). > > Is it just me who cant access eda.org, eda-stds.org or verilog.org? > > cheers, > Sri > > Jonathan David wrote: > >> I'm all for BETTER solutions.. >> I don't see the problem about the resolution function.. If I connect >> wreal to logic by accident.. I don't want the simulation to run.. the >> design is wrong. fix the design, then there are no more resolution >> issues.. >> Generally I can't afford to have these signals in the Continuous Time >> domain.. any other Suggestions.. ? >> >> In this case, no solution would leave VHDL as the only available >> solution. >> Not all nets are something you could swap a logic driver with.. MY >> complaint about the wreal solution is that CADENCE won't let me >> put 10 wreals in a bus (wreal [9:0] signal_p;) >> it was nearly the first AMS bug I reported on learning about wreal.. >> and they still haven't fixed it.. Any better AMS simulators out >> there? Jonathan >> ----- Original Message ---- >> From: Kevin Cameron <kevin@sonicsinc.com> >> To: Verilog-A Reflector <verilog-ams@eda.org> >> Cc: Martin O'Leary <oleary@cadence.com> >> Sent: Monday, August 7, 2006 2:12:04 PM >> Subject: Re: Regarding support of wreal >> >> >> Martin O'Leary wrote: >> >>> (another perspective on the wreal feature) >>> >>> Wreal part of the Verilog-AMS standard not the Verilog standard and has >>> been there since LRM2.0, >>> released in 2000. >>> >>> It has proven popular with users and is supported by multiple >>> implementors. >>> >>> >> - on the principal that a bad solution is better than no solution. >> >> The reason that it is unnecessary is that wires should be neutral and >> have their type/discipline derived at elaboration be looking at the >> drivers/contributions. A wreal is essentially a wire with a driver of >> type real (a non-resloved type). As far as I remember you can't >> connect wreal to anything else so it breaks the plug-and-play >> approach intended in the original design of the language - i.e. you >> should be able to swap a "digital" module with a real driver for an >> analog module with a contribution and have it handled automatically. >> >> Kev. >> >>> Thanks, >>> --Martin >>> -----Original Message----- >>> From: owner-verilog-ams@eda-stds.org >>> [mailto:owner-verilog-ams@eda-stds.org] On Behalf Of Kevin Cameron >>> Sent: Monday, August 07, 2006 1:14 PM >>> To: Dave Miller >>> Cc: verilog-ams@eda-stds.org >>> Subject: Re: Regarding support of wreal >>> >>> >>> wreal was a (unecessary) Cadence hack that only exists in >>> Verilog-A[MS]. >>> >>> Hopefully it will go away some day. >>> >>> Kev. >>> >>> Dave Miller wrote: >>> >>> >>>> Hello all, >>>> I am a bit confused about the support of the net type 'wreal'. I >>>> see that it is included in the AMS syntax that Graham has done but >>>> I can't >>>> >>> >>> >>> >>>> find any mention of 'wreal' in 1364-2001, or 1364-2005. Is 'wreal' >>>> a type that is only valid in the digital domain (i.e. can only >>>> assign to >>>> >>> >>> >>> >>>> it in digital), if so why can't I find it in the digital LRM's or am I >>>> >>> >>> >>> >>>> looking in the wrong place? >>>> Thanks for any help, >>>> >>>> Regards >>>> Dave >>>> >>>> >>> >>> >>> >>> >> >Received on Tue Aug 8 14:35:46 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 08 2006 - 14:35:58 PDT