It is supposed to allow post-synthesis verification as well. Shalom > -----Original Message----- > From: Kevin Cameron [mailto:Kevin.Cameron@truecircuits.com] > Sent: Thursday, March 20, 2008 10:24 PM > To: Bresticker, Shalom > Cc: Verilog-A Reflector > Subject: Re: List of mixed-signal subjects > > > I had a look at the UPF stuff and was not particularly > impressed, at best it's a methodology for driving synthesis. > The aim of the AMS extensions is to get a proper description > of the hardware post-synthesis so that the Verilog-AMS is a > complete description and not dependent on external stuff like > UPF, and to have it work with back-annotation so that you can > verify the power grid and related effects. > > Kev. > > Bresticker, Shalom wrote: > > Some of the issues with specifying multiple power supplies > and voltage > > domains have been dealt with recently in the context of > digital design > > for low power, using the competing UPF and CPF formats. > > > > Shalom > > > > > >> -----Original Message----- > >> From: owner-verilog-ams@server.eda.org > >> [mailto:owner-verilog-ams@server.eda.org] On Behalf Of > Kevin Cameron > >> Sent: Thursday, March 20, 2008 8:29 PM > >> To: verilog-ams > >> Cc: Marq Kole > >> Subject: Re: List of mixed-signal subjects > >> > >> Marq Kole wrote: > >> > >>> Hi everyone, > >>> > >>> In response to a private question from Shalom for a more > >>> > >> specific list > >> > >>> of subjects I have collected the following items as > >>> > >> subjects to work > >> > >>> on in the mixed-signal subcommittee. > >>> > >>> - Supply sensitivity in connect modules - how to make > >>> > >> connect modules > >> > >>> connect to a particular net as a supply reference, and have the > >>> connect modules automatically switch off at low supply. > There are a > >>> few other supply net related issues in the Mantis database. > >>> > >>> > >> There isn't really a significant difference between a power > >> supply and any other signal, the problem is that in Verilog > >> (being a logic-design language dating back to single-supply > >> chip days) there is no way to describe the connections. > >> > >> I suggested fix for the general problem of connecting > >> implicit signals a while ago - > >> > >> http://www.eda-stds.org/verilog-ams/hm/1941.html > >> > >> Note: the location of auto-inserted connect modules needs to > >> be fixed too (see below). > >> > >> > >>> - Discipline compatibility - can mixed-signal designs > with multiple > >>> supply domains be made correct by design by declaring disicplines > >>> incompatible. Ken Kundert will make a proposal for this in > >>> > >> the LRM 2.3 > >> > >>> Draft 3 but this needs to be extended to wreal at least; > it may not > >>> even be accepted given that there has been no open > discussion on it. > >>> > >>> > >> Specifying discipline (in)compatibility was in some of the > >> original work (a decade + ago), and should be easy to add - I > >> suggested it as a means to avoid (accidentally) connecting > >> logic signals across different voltage domains, so it's > >> functionality that's applicable to digital designs (it's an > >> elaboration-time check). > >> > >> Wreal should be deprecated. There is no reason you can't just > >> use a signal flow wire instead of wreal, the missing > >> functionality is the ability to assign flow/potential > >> directly from a digital process. That would give better > >> plug-and-play behavior too. A/D connect module insertion (and > >> a solver) is only required if the signal in question has > >> analog contributions. > >> > >> > >>> - Elevate wreal or equivalent SV real to full signal status > >>> > >> - use of > >> > >>> Verilog-AMS at a higher abstraction level is currently > >>> > >> frustrated by > >> > >>> the limitations on wreal, while communication by means of 64-bit > >>> busses for 1364 reals is not an acceptable alternative. > >>> > >> Also for this > >> > >>> item more issues are present in Mantis. > >>> > >>> > >> This is part of a general problem in HDLs : no distinction is > >> made between a signal representing a single physical wire or > >> a bunch of wires. E.g. it would be nice to be able to have a > >> pair of reals represent a complex value apply to a single > >> physical wire, or an array of the same for representing a > >> discrete spectrum, similarly it would be nice to bind two > >> physical wires to a single logic value for differential signaling. > >> > >> I recommend leaving this problem to later SV committees to > >> solve - i.e. > >> it should be possible to bind any type to a single wire, > >> making a special case for real/wreal is unnecessary. > >> > >> > >>> - Access to analog variables - how can a safe access to analog > >>> variables be created to make test bench creation simpler > and making > >>> test bench structures more powerfull, i.e. revealing more of the > >>> (analog) module internals. This has been discussed in the > committee > >>> but as no save resolution was found the LRM 2.3 adopts > the position > >>> that no such access is possible. As this is a very > interesting and > >>> useful feature I would like to revisit this in the mixed-signal > >>> subcommittee. > >>> > >>> > >> OK > >> > >> > >>> - convergence of analog and digital functions - call analog > >>> > >> fuctions > >> > >>> from digital and vice versa. > >>> > >>> > >> OK > >> > >> > >>> - extension of connectrules block - support for local > definition of > >>> connectrules so subblocks in an SoC model can be selfcontained. > >>> > >>> > >> Might be best left to scoping/packaging in SV. > >> > >> Note: the intention with connect-rules was that it should be > >> possible to > >> add any missing and/or extra rules to existing code as an > >> afterthought - > >> i.e. as a design grows you may encounter connections that the > >> original > >> block designer had not considered. As such the preference is > >> not to have > >> local definitions overriding global definitions, rather an > >> extra global > >> rule should be used to clarify ambiguities. > >> > >> > >>> - stronger integration of analog and digital simulation > >>> > >> cycles - make > >> > >>> analog and digital continuously aware of when they will > >>> > >> process their > >> > >>> next event/timestep. This can lead to significant efficiency > >>> improvements and prevent hard-to-trace errors in simulation. > >>> > >>> > >> That's a bit vague. > >> > >> > >>> - SV assertions in the analog context. > >>> > >>> > >> Might be better to do another committee for assertions in > analog - I > >> know Jonathon David has some ideas in that area. > >> > >> > >>> - Support for absolute delay in digital statements. > >>> > >>> > >> I think that one just needs agreement (with SV) on syntax. > >> > >> > >>> - Use of SV packages and/or global variables for collecting > >>> user-defined functions and tasks to are to be used in > >>> > >> multiple modules. > >> > >> OK > >> > >> > >>> In addition, I will need to go through the current Mantis items > >>> together with some of the feedback I already received from > >>> > >> some users > >> > >>> and outside contacts that I've been talking to. > >>> > >>> > >> Another key item that needs to be addressed sooner rather > >> than later is > >> back-annotation. I made a simple proposal for supporting it > >> in the past > >> (2001): > >> > >> > >> http://www.eda-stds.org/verilog-ams/htmlpages/tc-docs/issues/0 > >> 007/fllwup-1.html > >> > >> http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/misc/b > >> ack_ann.pdf > >> http://www.verilog.org/mantis/view.php?id=866 > >> > >> - as above, placement of connect module instances needs to > be correct > >> for it to work properly > >> (http://www.eda-stds.org/verilog-ams/htmlpages/tc-docs/issues/ > >> 0003/index.html) > >> - > >> > >> http://www.verilog.org/mantis/view.php?id=1765). > >> > >> Regards, > >> Kev. > >> > >> > >>> Best regards, > >>> Marq > >>> > >>> -- > >>> This message has been scanned for viruses and > >>> dangerous content by *MailScanner* > >>> > >> <http://www.mailscanner.info/>, and is > >> > >>> believed to be clean. > >>> > >>> > >> -- > >> True Circuits Inc. - http://www.truecircuits.com > >> Tel: (650) 949 3400 Ext 3415 > >> > >> > >> -- > >> This message has been scanned for viruses and > >> dangerous content by MailScanner, and is > >> believed to be clean. > >> > >> > >> > > > --------------------------------------------------------------------- > > Intel Israel (74) Limited > > > > This e-mail and any attachments may contain confidential > material for > > the sole use of the intended recipient(s). Any review or > distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > > > > -- > True Circuits Inc. - http://www.truecircuits.com > Tel: (650) 949 3400 Ext 3415 > > --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 20 13:38:53 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 20 2008 - 13:38:56 PDT