|
# 3 - Hierarchical modeling for SoC Integration |
|
 |
Whoever came-up with SoC as a new acronym for "System-on-Chip" must sadly acknowledge that most of its users aren’t even able to specify the difference with an ordinary IC.
Meanwhile VSIA is educating us about the quandaries of Hierarchical design, i.e. ViC Integration into a SoC. It involves a gamut of weird issues preferably ignored, including Mastering protocols for bilateral gates, ViC accessibility, asynchronism, clock phasing and Jitter simulation… BIST and JTAG, you name it, and you know how often these testability devices are faulty for lack of appropriate simulation.
Mere EDA developers occupy
two extreme positions with respect to users’ operating procedures:
either they supply isolated applications, e.g. a simulator like
SMASH, or they offer an all-encompassing Framework for tightly
controlling design flows.
Both result in the unfortunate EDA gap, namely the inability to
address real issues with appropriate “solutions”,
due to the lack of understanding by EDA developers of the real
needs of IC and SoC designers.
Just consider that new operating modes are required for a ViC within a SoC: not just a standby mode, not even an extinction mode, but also its opposite, namely a mode where a single ViC is on and accessible in-SoC.
The SoCKET™ innovation amounts to emphasizing that any EDA application must be an Enabling Technology to provide the “solution”, with circuit design focus and ISO-9001 expertise: i.e. the EDA application must be complemented with problem-centric models, plus above all the guidance of appropriate “operating protocols”.
The new names of the game for a mere ViC are its contribution to "in-SoC Cost" and its "design Yield".
|
These protocols of simulation guide the typical designer to solve two
complex simulation issues such as:
- isolating the circuit areas where typical knowledge
of simulation languages is not enough, and zooming-in to highlight all
potential danger zones in the circuit,
- measuring the severity of local properties so as to specify the requirements
to be met by other circuit functions.
Thanks to SMASH and to an accurate methodology splitting the simulation
in several small sequences, critical problems such as bilateral gates
or jitter simulation can be mastered.
Operating protocol for isolated simulations
CASE 1: Protocol for homing onto physical
dependence of logic
Example:
 |
Hereafter an instance of bugs
that can be left in when no protocol is set for zooming. This
instance documented in an Application Note illustrates the difference
of results between a model in Verilog known to a typical designer
and that requiring advanced Verilog fluency for modeling at a
level intermediate between gates and transistors. |
The transistor-level simulation ascertains which
Verilog simulation is right
 |
 |
The transistor-level simulation ascertains which Verilog simulation is right
| With Gate-level Verilog, the result is wrong |
 |
With lower-level Verilog, the result is right |
 |
|
 |
Such a protocol homing on danger zones enables
to benefit from Pareto’s law of 80%-20%:
Most of the circuit areas are properly modeled at gate-level with the
typical fluency of digital designers, but some fast circuits or cases
of asynchronism will require either multi-level modeling for an electrical
simulation, or advanced modeling expertise with more rare logic features
for transient analysis.
Operating protocol for dependent simulations
CASE 2: Protocol where a measurement defines
a requirement
Jitter simulation
In nearly every type of digital communication
system, skew and jitter not only affect data integrity, but also magnify
the tradeoff between data rate versus transmission distance. Meanwhile
synchronization of complex blocks within a SoC is highly demanding of
low jitter PLLs.
Unfortunately, no EDA application until now could help either specify
or even measure the acceptable jitter threshold for a SoC. Consequently,
logic designers are uncomfortable with the concept of jitter, and are
unable to define the specific jitter required by their SoC, or dually,
they are unable to investigate the critical paths in their SoC which
may be bugged by jitter.
It is now essential to be able to specify
accurately the jitter requirements of embedded Virtual Component (ViC)
like PLL, DLL or data clock recovery circuitware. Wrong specifications
may result at best in an unpredictable fabrication yield and at worst
in a non-working SoC.
Specifying the jitter value which can
be tolerated by a SoC, while avoiding any yield drop is enabled by SMASH,
thanks to an innovative simulation protocol based on HDL models (VHDL
or equivalently VERILOG). Such a protocol is useful to SoC integrators
for drastically shortening simulation time when diagnosing jitter: it
only requires ascertaining the maximum jitter value guaranteed by a
PLL provider for checking whether the PLL matches the SoC needs.
i.e. the EDA application is SMASH,
enriched with problem-centric models to represent behaviorally the communicating
processors,
and the guidance of appropriate “operating protocols” is
provided in an Application Note.
Discover our Jitter Simulation Tutorial
< SMASH Differentiators
|
|
Printer-friendly version
