[sv-dc] Freescale SV-DC Roadmap Content

From: Little Scott-B11206 <B11206@freescale.com>
Date: Fri Aug 13 2010 - 13:33:03 PDT

Hi all:

Below you will find Freescale's contribution to the content that was
requested for the roadmap.

Thanks,
Scott

Freescale SV-DC Roadmap Content

0. Executive Summary

  -Real value modeling is desirable for high performance abstract
modeling of AMS
   circuits in system-level simulation
  -We are not adding additional solvers to SystemVerilog. We want
event-based
   simulator performance for these models.

1. Motivation and Use Cases [why]
  
  -There are several cases in our designs where we have mixed I/Os. The
same wire
   may be driven at times by a digital clock and at other times by an
analog
   voltage. Modeling these I/Os as real/composite nets gives us an
acceptable
   accuracy/performance trade-off.
  -Swapping models of various abstractions (i.e., plug and play) should
be easy.
   Easy means that the different models should have compatible
interfaces (i.e.,
   same names/numbers of ports) and structural connections should remain
unchanged.

2. Requirements [what]

  -Real valued nets [Compatible with Verilog-AMS wreal in the sense that
a
   Verilog-AMS wreal could be directly connected to a SV real valued
net.]
  -Composite nets [multiple component values carried in a single net]
  -Resolution functions for multiple real/composite drivers [we desire
both high
   performance, predefined resolution functions and the capability to
define our
   own resolution functions]
  -Ability to represent z(undriven)/x(unknown) for real-valued/composite
nets [For
   composite nets this should be doable for the entire net or the
individual
   parts. The representation of z/x for real-valued/composite nets
should be
   consistent across SV/VAMS]
  -Conversion mechanism between real/composite types and logic types
[This is
   motivated by the mixed I/O use case. We want to connect a real net
to a logic
   net without having to configure more than the logic threshold for the
real.]
  -Generic interconnect constructs that can be used for structural
connectivity [we
   should be able to create buses of generic interconnect where
individual selects or
   slices may connect to ports of different types]
  
3. Timeline and Vision [when]

  -We would like see these requirements addressed in this PAR cycle

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Aug 13 13:33:45 2010

This archive was generated by hypermail 2.1.8 : Fri Aug 13 2010 - 13:33:49 PDT