Bresticker, Shalom wrote: >wreal is fundamentally different from the digital domain. >In the digital domain, each signal is either 0 or 1. >A number is represented by a set of bits (= set of signals) large enough >to represent the number. >So the number 5 is represented by 3 bits/signals, the first and last of >which are 1, the middle one is 0. >But these are three different wires. >You may be able to group these wires together into a vector, but they >remain three wires. > >In contrast, wreal (as I understand it) is a single wire with a >continuous value set (quantized, of course). This is analog SPICE-like >logic, not digital. The whole idea of digital logic is to abstract >voltage levels into logical 0 and 1. > > > It's only Spice-like if it's piecewise linear (pwl), if it's dicrete it's "digital" (or event-driven) simulation. >The whole idea of resolving two real entities in the digital domain is >not relevant. > > I don't think it's unreasonable to want to do something like sum currents at a node using a resolution function. There is a lot of analog behavioral modeling you can do without using a solver. VHDL let you have user-defined types like wreal (resolution optional) before analog was added. Kev >I'm not sure I am explaining this clearly, but I hope the idea comes >across. > >I can access eda.org . > > >Shalom > > > >>-----Original Message----- >>From: owner-verilog-ams@server.eda-stds.org [mailto:owner-verilog- >>ams@server.eda-stds.org] On Behalf Of Sri Chandra >>Sent: Tuesday, August 08, 2006 7:52 AM >>To: Jonathan David >>Cc: Kevin Cameron; Verilog-A Reflector; Martin O'Leary >>Subject: Re: Regarding support of wreal >> >>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? >> >>Coming to wreal query, im 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. >> >>Probably 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. 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. >> >>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 >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>-- >>Srikanth Chandrasekaran >>DTO Tools Development >>Freescale Semiconductor Inc. >>Ph: +91-120-439 7021 F: x5199 >> > > > >Received on Tue Aug 8 14:52:27 2006
This archive was generated by hypermail 2.1.8 : Tue Aug 08 2006 - 14:52:29 PDT