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/0007/fllwup-1.html
    
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/misc/back_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.