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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Mar 20 13:26:04 2008
This archive was generated by hypermail 2.1.8 : Thu Mar 20 2008 - 13:26:44 PDT