►
From YouTube: CHIPS Alliance - Analog Working Group - 2021-08-17
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Hello,
everybody,
and
thanks
for
making
time
today
and
joining
us
for
an
analog
workgroup
meeting
today,
I'm
pleased
to
introduce
dr
steve
hertz,
who
is
a
recent
phd
recipient
in
electrical
engineering
from
stanford
and
he's
going
to
share
the
work
that
he's
done
on
the
modeling
of
ams
type
circuits
in
fpga,
which
I
think
is
an
important
topic.
A
B
C
Rob
just
as
I
can
all
set
this
up.
A
C
All
right
is
this:
sharing
the
right
screen
right,
you're,
seeing
just
the
slides
or
the
slides
look
good,
yeah,
okay,
cool,
great,
all
right
yeah.
C
So,
as
rob
was
mentioning,
you
know,
the
verification
topic
is
really
important
for
chip
design
both
for
you
know,
digital
design
as
as
well
as
ams
design,
and
in
addition
to
that,
before
the
chip
comes
back,
we
also
want
to
be
able
to
interact
with
the
design
to
develop
software
and
firmware
so
that
we
can
reduce
the
the
overall
development
time
for
the
for
the
product.
C
So
the
unfortunate
thing
is
that,
when
we're
working
with
a
pre-silicon
design,
if
we
want
to
simulate
the
whole
thing,
often
that's
not
really
fast
enough
for
the
work
that
we
want
to
do,
whether
it's
software
development
or
running
very
long
tests
like
booting,
an
operating
system
or
verifying
operation
over
billions
or
trillions
of
cycles.
C
So,
what's
often
done
instead
is
we
take
digital
parts
of
the
design
and
map
them
to
an
emulation
platform
which
could
be
a
commercial
fpga
board
like
the
one
that
I've
shown
here
or
it
could
be
a
commercial
emulation
platform
like
zebu
from
synopsis
or
palladium
from
cadence.
C
C
So
that's
that's
really
what
my
research
was
about
during
my
phd
was
exploring
the
this
techniques
for
modeling
analog
blocks
in
an
emulation
context,
and
in
doing
that,
I
found
for
some
types
of
designs,
a
bottleneck
with
the
traditional
approach
to
emulation,
came
up
with
a
new
modeling
technique
to
address
that
and
then
also
sort
of
in
parallel
with
that,
I
developed
an
open
source
framework
for
emulating
analog
mixed
signal
designs
on
fpgas,
mostly
for
for
research
purposes.
C
You
know
for
doing
comparisons,
for
example
between
the
traditional
approaches
for
emulation
and
the
new
methods
that
I
was
working
on,
but
I
I
also
have
you
know.
The
framework
has
also
been
applied
to
some
commercial
designs
as
well,
and
I'll
talk
about
that
a
little
bit
later
so
this
this
brings
me
to
the
outline
for
the
talk
I'm
going
to
give
an
overview
of
the
traditional
approach
for
emulating
analog
blocks.
C
So,
to
illustrate
how
emulation
is
typically
done
today
for
analog
blocks?
We
can
start
off
with
just
the
most
basic.
You
know,
sort
of
the
hello
world
of
analog
blocks,
which
is
an
rc
filter,
and
if
we
want
to
include
this
block
in
our
emulation,
then
we
immediately
run
into
an
issue
because.
D
C
We
do
have
lookup
tables,
flip
flops
and
so
on
on
an
fpga.
What
we
don't
have
are
user-defined,
resistors
and
capacitors,
or
you
know
other
analog
primitives
like
that,
so
we
need
to
come
up
with
some
way
of
modeling,
the
behavior
of
analog
circuits
using
the
stuff
that
we
do
have
and
the
the
typical
approach
for
doing
that
is
called
over
sampling.
C
C
So,
if
we
think
about
you
know
for
in
an
emulator,
typically
in
an
emulator
we're
working
mainly
with
digital
signals,
but
if
the
analog
signals
we're
trying
to
represent
are
a
lot
faster
than
those
digital
signals,
then
we're
going
to
have
to
take
really
small
time
steps
in
order
to
capture
the
behavior
of
the
analog
waveforms
with
enough
detail.
C
So
that
means
that
we'll
have
to
slow
down
the
emulator
a
lot
to
accommodate
the
analog
modeling,
which
is
not
a
good
thing,
because
still,
even
though
we're
trying
to
model
it
analog
blocks,
there's
probably
the
bulk
of
the
system
is
going
to
be
digital.
C
So
it
means
that
we'd
lose
most
of
the
speed
up,
that
we
were
hoping
to
get
from
emulation,
and
so
the
other
way
that
this
trade-off
can
can
become
apparent
is
when
even
for
digital
events,
if
we
have
things
like
clock,
jitter
that
we're
trying
to
model
in
a
high
speed
link
the
in
a
traditional
approach
that
uses
a
fixed
time
step.
The
resolution
of
modeling
those
kind
of
effects
is
just
equal
to
the
fixed
time
step
that
we're
taking.
C
So
if
we
want
to
say
double
the
the
time
resolution
for
modeling
jitter,
we
need
to
cut
the
speed
of
the
emulator
in
half,
which
is
is
pretty
unfortunate
because,
typically,
the
the
resolution
that's
needed
to
model
jitters
say
in
a
high
speed
link,
is
a
few
orders
of
magnitude
faster
than
the
the
bit
period.
You
know
the
say
of
the
data
being
transmitted
through
this
link,
so
it's
it
represents
a
significant
slowdown.
C
So
my
my
goal
was
to
kind
of
come
up
with
some
some
techniques
for
eliminating
the
need
to
take
really
small
time,
steps
to
represent
analog,
behaviors
and
emulation
and
instead
get
back
to
more
of
an
event-driven
style
where,
if
there
are
changes
in
digital
signals,
they
are
evaluated
in
the
emulator.
C
But
we
try
to
represent
the
behavior
of
analog
signals,
even
more
complex
behavior
between
digital
events,
without
taking
additional
time
steps
or
with
taking
a
small
number
of
a
very
small
number
of
time.
Steps.
C
So
that
that
brings
me
to
the
the
new
techniques
that
I
explored
that
are
in
the
adventure
of
an
emulation
space.
So
I
think
the
the
first
thing
to
bring
up
is
just
what
does
this
look
like
from
an
implementation
perspective?
So
you
know
conceptually
for
the
traditional
oversampling
approach.
We
have
an
emulator
clock,
that's
running
in
the
background,
and
this
is
you
know,
say
driving
the
model
of
an
rc
filter
that
we
have
and
either
implicitly
or
explicitly.
C
C
Perhaps
we
would
count
up
a
total
number
of
emulation
cycles,
but
the
actual
time
is
then
just
some
scale
factor
of
that
that
number
of
cycles-
but
this
looks
really
different
if
we
want
to
try
to
do
something,
that's
more
event,
driven
like
what
I
was
talking
about,
because
it
means
that
each
cycle
of
the
emulator
corresponds
to
a
time
step
of
a
different
size
and
potentially
a
very
different
size.
C
Because
you
know,
if
you
imagine,
let's
say
two
digital
waveforms
that
are
have
a
slight
phase
offset
then
they're
going
to
be
handled
in
separate
emulation
cycles.
But
you
know
it
might
be
that
the
first
time
step
between
say
the
rising
edges
of
those
signals
is
a
picosecond.
And
then
maybe
you
have
to
wait
for
most
of
a
period
to
see
the
next
event
after
that.
C
So
the
other
change
is
sorry.
Was
there
a
question
or
stop?
No,
I
think
you're,
okay,
okay,
so
in
the
you
know,
the
other
issue
is
that,
if
we're
taking
these
large
time
steps,
we
need
to
be
able
to
represent
the
the
shape
of
analog
waveforms
over
longer
periods
of
time
than
you
know
what
what
we
would
typically
have
for
an
oversampled
system
and
the
I
explored
a
couple
of
approaches
for
this.
C
But
what
I
found
worked
well
is
to
use
a
a
list
of
spline
points
for
representing
a
shape
of
a
waveform
out
to
some
maximum
time
step.
So
example,
at
the
start
of
a
time
step,
we
project
out
the
waveform
using
a
couple
of
spline
points
to
a
maximum
time,
and
then
the
only
requirement
is
that
the
actual
time
step
that's
taken
by
the
emulator
is
something
that's
less
than
that
maximum
time.
C
We
then
you
know,
discard
the
the
points
that
come
after
that.
So
you
know,
even
though
we're
passing
around
just
a
couple
of
spline
points.
The
idea
is
that
their
implicitly
connected
by
an
interpolation
method,
which
is
used
for
resolving
things
like
how
the
models
with
analog
dynamics,
respond
to
this
analog
stimulus.
C
So
what
I
showed
through
through
my
research
was
that
we
can
use
the
this
concept
of
spline
points
as
a
kind
of
common
language
for
having
emulation
models
talk
to
each
other,
even
if
they're
modeling
different
kinds
of
things.
So,
for
example,
we
can
model
a
static
non-linearity
as
a
mapping
from
a
set
of
input.
Spline
points
to
output
spline
points,
but
we
can
also
use
them.
The
the
spine
points
approach
to
represent
systems
that
have
dynamics
like
a
lossy
channel
or
a
system,
that's
described
by
state
space
equations.
C
So
you
know,
as
I
was
working
on
this
on
this
sort
of
study,
of
different
emulation
techniques.
C
One
thing
that
I
found
is
that,
whether
I
was
working
on
the
new
techniques
or
trying
to
build
up
comparison
models
using
oversampling
methods
that
it's
not
that
easy
to
create
a
an
emulator
for
an
ams
system
in
the
first
place
and
there's
a
lot
of
hurdles
that
you
have
to
go
through
in
order
to
get
one
up
and
running,
and
that
often
means
that
that
that
people
just
don't
really
pursue
that
as
as
a
way
of
speeding
up
their
simulations,
because
it's
not
worth
it
if
you
have
to
invest
so
much
time
in
order
to
get
started,
so
that
really
motivated
me
to
develop
some
tools
to
make
that
process
simpler
and
faster.
C
So
what
I
ended
up
creating
was
a
framework
that
consists
of
three
three
tools:
they're,
all
you
know
open
source
are
all
available
on
github
and
as
python
packages,
and
the
basic
flow
is
that
you
take
a
system
that
has
a
mixture
of
analog
blocks
and
digital
blocks.
C
The
for
the
analog
blocks.
You
create
synthesizable
models
for
them
using
a
tool
called
msdsl
and
that
produces
verilog
that
uses
a
library
called
sb
real
for
implementing
synthesizable
real
number
operations.
C
So
at
that
point
because
the
digital
blocks
already
synthesizable,
we
have
a
synthesizable
view
of
the
entire
chip
design,
which
we
can
then
wrap.
C
So
I'll
just
you
know,
there's
not
time
to
go
through
all
the
different
use
cases
for
the
framework,
but
I
thought
I'd
just
give
a
flavor
for
it.
So
the
msdsl,
as
I
mentioned,
is
a
tool
for
generating
synthesizable
models
and
it
has
a
number
of
input
modes,
but
you
can
use
it
in
its
simplest
fashion,
just
as
a
way
of
writing
down
discrete
time
equations.
C
So
there's
some
operator
overloading
that
makes
it
pretty
straightforward
to
write
down
expressions
in
a
readable
fashion
and
then
generate
a
synthesizable
rtl
from
from
these
expressions,
and
that's
that's
leveraging
a
library,
the
library
sv
reel
that
I
mentioned,
which
is
a
a
macro
library
that
provides
a
both
a
fixed
point
and
floating
point
implementation
of
real
numbers
in
verilog.
C
So
you
know
the
again.
I
I
don't
really
have
don't
want
to
go
too
far
into
the
the
details
on
this
on
sv
real.
C
But
I
just
wanted
to
highlight
that
you
know
if
we
look
at
this
code
sample,
which
is
generated
from
from
msdsl,
that
there's
no
there's
actually
no
reference
to
fixed
point,
formatting
information
anywhere
in
these
macros
that
that's
all
abstracted
from
the
user,
so
that
it
makes
it
easy,
for
example,
to
switch
between
using
a
floating
point
representation
or
a
fixed
point
representation,
and
this
is
basically
done
by
at
least
for
the
fixed
point
side
by
keeping
track
of
signal
ranges
at
compile
time
and
then
using
that
to
determine
the
formats
for
for
fixed
point
signals
with
the
the
trick
being
that
you
know
it's
this.
C
Might
this
had
to
be
done
in
a
way
that
was
implemented
in
system
verilog,
so
it
was
easy
to
integrate
into
existing
rtl
and
system
verilog.
I
I
definitely
found
a
number
of
pitfalls
and
supported
features,
especially
relating
to
real
numbers
and
doing
this.
So
it
was
a
interesting
exploration
of
synthesis
support
for
for
real
numbers.
C
So
you
know,
in
addition
to
supporting
these
basic
arithmetic
operations.
Msdsl
also
provides
some
abstractions
for
higher
level
operations.
So,
there's
a
tool
for
converting
regular
python
functions
into
a
synthesizable
format
and
there's
also
a
tool
for
generating
pseudo-random
noise,
particularly
gaussian
noise.
Although
it's
it's
also
possible
to
implement
arbitrary
noise.
If
you
basically
provide
the
statistics
of
that
noise
to
msdsl.
C
And
there's
also
a
couple
of
different
ways
of
describing
the
behavior
of
of
circuits
as
well
that
they
can
be
written
down
as
a
transfer
function.
There's
also
a
symbolic
differential
equation
engine
that
will
allow
you
to
describe
systems
as
kind
of
linear
switched
linear
systems
where
you,
you
can
have
a
differential
equation
system.
That
also
includes
some
conditional
expressions.
C
So
it's
a
slight
extension
of
the
basic
linear
dynamical
system
and
then
finally,
there's
also
a
kind
of
netlist
like
mode
for
msdsl,
where
it
will
take
a
set
of
analog
primitives
like
resistors
switches,
capacitors
and
solve
the
system
at
compile
time
to
certain
using
kvl
and
kcl.
It
will
generate
a
system
of
differential
equations
solve
at
a
compile
time
and
then
have
an
efficient
sort
of
fir-iir
implementation
of
those
behaviors
on
the
fpga.
C
So
up
to
this
point,
I've
been
just
describing
how
we
can
generate
synthesizable
models
for
analog
blocks,
but
I
did
also
want
to
talk
a
little
bit
about
the
other
piece
of
this,
which
is
what
happens
after
we
have
a
synthesizable
view
of
the
whole
chip.
C
So
the
first
part
is
that
we
need
to
wrap
some
control
infrastructure
around
around
the
dot
that
we're
trying
to
test
out,
and
you
know
you
might
wonder,
okay,
what
what
kind
of
infrastructure
is?
Am
I
talking
about?
Well,
there's
some
of
the
infrastructure
ends
up
being
a
little
bit
unique
for
for
the
analog
modeling
case,
because,
if
we're
building
a
venture
of
an
emulator,
then
it's
the
case
that
analog
models
are
able
to
generate
their
own
events
that
have
to
be
scheduled
so
that
they
appear
in
the
right
order.
C
So
in
this
example
here
I'm
showing
a
case
where
we
have
two
different
oscillators
models
that
are
operating
at
different
frequencies.
C
We
take
the
minimum
of
those
requests
and
then
feed
it
back
to
all
of
the
analog
models.
So
in
other
words,
perhaps
for
oscillator
0.
It
wants
to
take
a
time
step
of
one
nanosecond
until
its
next
edge
is
scheduled
to
occur
and
maybe
for
oscillator
one.
It
wants
to
take
a
time
step
of
two
nanoseconds
until
its
time
its
next
clock
edge
is
going
to
occur,
so
the
emulation
infrastructure
will
take
the
minimum
of
those
two
requests.
C
So
the
other
piece
of
this
is
that
you
know
when
we're
working
with
things
like
say,
an
oscillator
where
it's
generating
clock
clock
signals.
C
We
need
to
be
careful
about
the
way
that
that's
done,
because
it's
generally
not
a
good
idea
to
drive
clock
signals
directly
through
combination
logic
on
an
fpga,
particularly
considering
that
we've
got
a
large
digital
block
that
has
probably
multiple
clock
inputs
to
it
that
we
don't
want
to
modify
for
for
emulation.
So
we
want
to
just
be
able
to
create
a
true
clock
signal
that
we
can
plug
into
digital
parts
of
the
design
without
any
modification.
C
So
that's
sort
of
some
of
the
infrastructure
that's
needed
for
ams
models,
but
I
also
found
it
useful
to
add
some
features
that
are
more
generic
for
just
getting
data
into
and
out
of
the
emulator
and
the
approach
that
I
settled
on.
There
was
a
kind
of
firmware
in
the
middle
approach
where
we
have
a
host
computer.
C
That's
orchestrating
the
the
emulator
at
high
level
and
it's
sending
commands
over
usb
to
an
arm
core
which
is
on
the
fpga
and
then
the
arm
core
itself
is
running
firmware
that
interacts
with
the
programmable
logic
on
the
fpga.
C
So
this
sort
of
provides
a
hierarchy
of
you
know
trade-offs
of
flexibility
versus
performance
where
we
can
make
changes
and
see
them
immediately
on
the
host
computer.
Whereas
you
know
we
can
modify
the
firmware.
That's
in
the
middle
and
see
you
know.
Maybe
the
compiled
time
takes
is
a
few
minutes
to
both
compile
it
and
load
it
onto
the
fpga,
but
that's
a
lot
better
still
than
the
potentially
hours
or
maybe
even
a
day
to
build
the
bitstream
for
the
programmable
logic
on
the
fpga.
C
So
it's,
I
guess,
kind
of
one
of
the
strategies
that
I
found
as
well
is
that
I
could
start
off
by
prototyping
features
in
python
on
the
host
computer
and
then,
depending
on
whether
those
features
were
becoming
a
bottleneck
or
not.
I
could
start
to
push
them
further
into
you
know,
perhaps
into
firmware
on
the
fpga
or
maybe
even
into
programmable
logic.
C
So
the
the
emulator
infrastructure
provide
that's
generated
by
nsmod
makes
it
pretty
easy
to
do
this
by
auto,
generating
a
lot
of
the
firmware
that
is
used
to
interface
between
the
host
computer
and
programmable
logic,
and
it
also
kind
of
wires
up
the
programmable
logic
to
the
to
the
arm
core.
In
an
automated
fashion.
C
C
One
other
thing
I
would
add,
is
I
actually
just
recently
wrapped
up
with
a
project
with
sign
links
to
apply
this
to
one
of
their
high
speed
length
designs
as
well,
so
I'll
just
show
an
overview
of
three
of
these
that
cover
a
variety
of
different
types
of
analog
use
cases.
C
So
the
first
one
was
a
firmware
controlled
flyback
from
infineon,
where
in
this
case
they
were
they
wanted
to
develop.
C
They
wanted
sort
of
a
platform
that
would
make
it
easier
to
develop
a
firmware
that
runs
on
a
digital
controller
that
interacts
with
a
flyback
converter,
and
you
know
at
the
time
that
I
started
on
this
project.
They
they
had
an
existing
setup
where
they
were
simulating
the
the
flyback
converter
at
spice
level
and
then
had
a
spice
plug-in
that
was
running
c
code
to
model
the
behavior
of
the
the
firmware
that
was
controlling
the
flyback.
C
But
this
wasn't.
This
wasn't
very
fast,
and
so
it
wasn't
necessarily
a
effective
tool
for
doing
firmware
development.
They
asked
me
to
look
at
whether
emulation
could
be
used
to
speed
up
the
simulations
and
and
make
it
easier
to
do
firmware
development.
C
So
in
this
case
the
answer
was
that
you
could
get
a
speed
up
of
about
3000
x,
using
msdsl
to
to
generate
a
model
for
the
flyback
converter,
using
a
spice
like
netlist,
that's
solved
at
compile
time,
so
I
guess
the
the
data
point
for
this
ended
up
being
it's.
You
know
on
the
or
about
three
orders
of
magnitude
speed
up
for
for
modeling
this
type
of
system.
C
I
also
looked
at
an
nfc
powered
chip
from
infineon,
where
in
this
case
it
was
is
a
little
bit
different.
They
had
a
hardware-in-the-loop
emulator
that
included
physics,
say
physical
coils
and
rectifier
circuitry
load
modulation,
but
they
wanted
to
explore
whether
it
was
possible
to
fully
virtualize
this
emulator
so
that
it
would
be
easier
to
distribute
to
developers
or
potential
customers
and
also
easier
to
change,
analog
behaviors
without
pcb
modifications.
C
So
they
they
had
a.
They
were
already
doing
real
number
modeling
of
verilog
for
simulation
purposes.
For
this
and
what
I
found
was
in
this
case.
We
could
get
a
speed
up
of
about.
Let's
say
you
know,
500
x,
between
two
and
three
orders
of
magnitude
by
building
synthesizable
models
with
msdsl.
C
And
the
last
application
that
I
wanted
to
talk
about
is
dragonfly,
which
is
a
an
open
source
high-speed
link
receiver
that
was
developed
at
stanford.
So
in
this
case
the
key
behaviors
that
had
to
be
modeled
were
a
lossy
channel,
which
you
know.
C
Ideally,
we
would
be
able
to
describe
according
to
s-parameters
that
were
measured
in
the
lab
and
we
also
needed
to
model
the
certain
non-idealities,
both
in
terms
of
the
the
noise
of
the
adcs
that
are
used
in
the
high
speed
link,
as
well
as
timing
jitter
and
when
adc
samples
are
taken.
C
So
this
is
really
where
the
the
event-driven
emulation
that
I
was
talking
about
earlier,
I
think,
shows
its
best
performance
because
we're
able
to
completely
eliminate
the
the
trade-off
between
timing
resolution
for
modeling
jitter
and
the
throughput
of
the
emulator.
C
So
this
achieved
the
best
speed
up
of
the
three
use
cases
of
about
5000
x
compared
to
our
you
know,
already
optimized
real
number
models
that
we
were
using.
C
I
should
also
mention
that
just
recently
like
as
in
like
about
a
week
ago-
or
so
I
finished
a
project
with
xilinx,
to
apply
this
to
one
of
their
high-speed
link
designs
and
found
a
similar,
a
similar
speed
up
actually
a
little
bit
better
than
this
for
working
with
a
larger
commercial
high-speed
link
design.
So
it
seems
like
at
least
with
those
two
data
points
that
the
the
event
driven
emulation
approach
can
has
a
path
to
scaling
for
for
larger
designs.
C
But
in
order
to
achieve
that
speed
up,
we
need
to
use
the
right
modeling
techniques
and
in
some
cases
that
means
using
the
event
the
new
event-driven
emulation
approach
that
I
talked
about
earlier
and
the
other
piece
of
this
is
just
that.
Building
synthesizable
ams
models
is
not
always
easy,
so
that
had
motivated
me
to
create
an
open
source
framework
for
for
ams
emulation,
so
that
it's
easier
for
people
to
achieve
these
kind
of
speed.
Ups
in
the
first
place.
C
So
kind
of
looking
forward,
you
know
this
is
I
wanted
to
leave
some
time
so
that
we
could
discuss
sort
of
what
what
might
be
some
good
next
directions
for
this
project,
because
you
know,
as
rob
mentioned,
I've
I've
graduated
at
this
point,
so
I'm
not
actively
working
on
the
the
open
source
tools
at
the
moment,
but
at
the
same
time
it's
it's
a
you
know,
pretty
pretty
complete
set
of
tools
that
has
been
applied
and
is
is
still
being
used
at
infineon.
C
So
I'm
sort
of
curious
to
have
you
know
to
hear
some
thoughts
on
sort
of
what
what
I
should
do
with
these
open
source
tools
going
forward,
particularly
you
know,
both
from
the
the
user
side.
You
know
if
there
are
any
folks
that
are
interested
in
trying
out
these
tools,
kind
of
think
about
how
that
might
work.
Maybe
I
can
connect
them
to
some
students
who
are
currently
at
stanford,
who
might
be
able
to
you
know,
provide
continuing
support
for
that,
but
also
on
the
developer
side.
C
You
just
thinking
about
how
to
integrate
these
tools
with
some
of
the
new
open
source
chip,
design
tools
that
have
been
have
come
out
in
the
last
couple
of
years,
and
also
just
in
terms
of
making
it
easier
to
to
create
models.
You
know
just
trying
to
continue
to
raise
the
level
of
abstraction
from
model
generation
so
that
it's
it's
easy
for
someone
who
has
backgrounds
just
in
verilog
level,
simulation
modeling
to
approach.
C
So
with
that
I'll
end,
the
talk
then
we'd
be
happy
to
to
take
any
questions.
A
Okay,
thank
you
for
excellent
and
very
informative
talk.
I
I
think
it's
a
great
work
that
you
have
accomplished
as
part
of
your
your
studies
and
our
sharing
with
the
community.
It
certainly
is
a
you
know,
difficult
and
challenging
area.
So
I'd
like
to
open
it
up
to
questions
from
the
audience
folks
might
have.
D
I
have
two
questions.
One
is
how
much
development
effort
is
recorded
like,
for
example,
how
many
engineers
would
turn
around
time?
This
is
number
one,
and
the
other
question
is
that:
is
there
any
limitation
on
the
science
of
a
circuit?
You
can
emulate
the
two
questions:
yeah
yeah.
C
Those
are
both
great
questions
so,
on
the
first
one
I
have
a
recent
data
point.
So,
as
I
mentioned,
I
I
just
recently
wrapped
up
a
project
with
xilinx
to
apply
this
to
one
of
their
designs.
So
in
that
case
the
answer
was,
it
took
me
250
hours
to
model
their
commercial
design,
so
it's
about.
If
I
was
working
full
time
on
it
would
be
about
maybe
a
month
and
a
half
a
little
bit
longer
than
then
would
be
ideal.
C
I
think,
but
when
I
looked
at
the
time
that
I
spent
on
that,
actually
a
large
portion
of
the
time
was
on
preparing
digital
aspects
of
the
design.
C
This
is
also
a
common
thread
that
I
found
as
well
for
the
academic
design
and
for
the
designs
I
worked
on
at
infineon,
so
that's
sort
of
just
in
general
highlighted
to
me
the
fact
that
you
know
it'd
be
great
even
just
from
a
digital
emulation
perspective.
If
we
had
some
open
source
tools,
it
just
made
it
really
easy
to
get
a
digital
emulation
running.
C
So
yeah,
I
think
that's
that
definitely
seems
to
be
an
area
where
there
there's
still
a
lot
of
work
that
could
be
done
on
the
the
tooling
side
to
do
just
make
it
easier
to
handle
multiple
clocks
in
a
design
without
having
to
really
you
know,
go
in
depth
and
learn
the
clock
tree
as
an
outside
user
and
there's
also
a
lot
of
just
syntax
discrepancies
between
fpga
synthesis
tools
and
and
asic
synthesis
tools
that
take
a
long
time
to
smooth
out.
C
C
You
know
maybe
a
few
million
lookup
tables
on
them,
which
is
not
enough
to
emulate
very
large
strip
designs,
it's
enough
for
small
commercial
designs,
so
I
think
another
future
direction
would
be
looking
at
using
these
synthesizable
models
in
a
commercial
emulator
context
where
those
systems
have
the
capacity
to
to
emulate
a
full
chip,
design,
you're
recommending,
say
palladium
and
the
like
yeah.
I
think
that
would
be
interesting
to
look
at
yeah.
C
C
See
I
think
I
probably
have
something
in
here
about
that.
I
don't
remember
where
exactly
but
that's
I
think
I
saw
something
about
that.
C
Oh
okay,
yeah
yeah,
so
looks
like
yeah.
I
guess
the
there
were
actually
a
couple
of
different
versions
of
the
emulator
that
I
built.
I
guess
the
the
highest
performance
one
is
this
middle
one,
the
high
the
high
level
fixed
point
design.
So
in
that
case
the
the
dsp
was
maxed
out,
and
that
was
the
design
choice
where
basically,
I
was
tuning
the
the
parallelization
or
adjusting
the
parallelization
of
the
analog
models
to
max
out
the
dsp
resources
so
that
I
could
get
as
much
parallelization
as
possible,
given
the
fbga's
dsp.
C
But
in
terms
of
the
the
what
resource
utilization
it
was
about.
You
know
a
little
bit
less
than
half
and
I
think
there's
actually
kind
of
an
interesting
trade-off
there
as
well,
because
what
I
found
in
some
of
my
work
on
commercial
applications
is
that
the
digital
digital
parts
of
the
design,
in
other
words,
stuff,
that
we're
not
changing
that
we're
just
trying
to
pull
into
the
emulator
mostly
consumes
lots.
B
C
Yeah
I
did
have
to,
I
think
I
went
through
a
couple
of
cycles
on
that
I
mean
it's.
It's
not
it's
not
very
difficult
to
estimate
the
resource
utilization,
but
it's
not
it's
also,
not
automated.
So
it's
like
I
would.
I
would
have
to
make
a
guess
of
like
okay.
I
think
this
is
gonna
use
about
this
many
dsp
slices
and
then
maybe
iterate
on
that
a
little
bit
once
I
think.
A
So
steve
thanks
for
for
the
presentation
and
also
if
you
can
make
the
slides
available
to
me,
I
will
work
on
getting
this
posted
for
folks
to
look
at
as
well
as
the
video.
You
know,
you
asked
a
question
about
possible
next
steps,
and
you
know
relative
to
the
framework
that
you've
created
and
the
modeling
as
well
there's
definitely
interest
from
the
chips
alliance
side.
A
In
your
work.
We
are
actually
starting
up
a
a
work
group
on
fpgas
we've
been
working
on
trying
to
get
some
different
company
members
participant
in
that
which
we'll
focus
on,
in
particular,
open
source
tooling,
to
address
in
fact
address
some
of
the
concerns
that
you
correctly
highlighted
here.
So
I
think
you
know,
if
that's
something
that's
of
interest
of
you,
we
would
be.
You
know
very
welcoming
to
have
you
know
your
participation
in
that
in
that
group
and
to
help
us
move
that
forward.
A
So
I
would
be
very
happy
to
introduce
you
to
the
right
folks
that
we
we
have
on
board
to
try
to
help
get
this
going.
A
So
no
thank
you
and
also
I
look
forward
we'll
look
at
your
charts,
I'm
kind
of
curious
about
the
the
time
step.
Work
that
you
did
my
background.
More
is
in
static
timing,
analysis
and
then
originally
gate
level,
then
in
the
transistor.
So
it
looks
very
similar
types
of
modeling
approaches
that
were
used
for
or
considerations.
I
should
say:
there's
a
better
way
to
put
it
for
for
handling
that
as
well.
C
Yeah,
it's
it's
an
interest.
I
think
the
it's
definitely
an
interesting
area,
because
it's
it's
a
little
bit
counter-intuitive.
I
think
that
when
you're
looking
at
direct
logic,
analyzer
traces
from
an
fpga
that
you
know
the
the
emulator
clock
is
always
running
at
a
fixed
frequency,
but
it's
representing
something
which
is
has
a
has
no
connection
to
that
frequency.
So
another.
C
You
know
the
traditional
emulators
run
out
of
either
a
fraction
of
real
time
or
some
multiple
of
real
time,
whereas
in
this
case
there's
there's
a
separation
between
the
the
physical
time
that
this
is
being
taken
by
the
clock
on
the
fpga
versus
the
thing
that
it's
modeling,
which
took
it's
it
definitely
is
it
took
some
time
to
sort
of
wrap
my
head
around
that
and
build
some
yeah,
some
debugging
tools
to
to
better
understand,
what's
happening.
A
Although
I
appreciate
the
innovative
thinking
there
on
that
specific
point
because
it
you
know,
certainly
I
don't
think
that's
been
considered
in
the
past.
So
so
I
do
appreciate
that
you
know
I
just
was
this:
maybe
a
dumb
question,
but
you
know
were
there,
would
you
look
at
any
other
different
interpolation
methods,
possibly
for
the
waveforms
or
just
kind
of
stuck
with
you.
C
Know
what
you
suggested
yeah.
I
looked
at
a
couple
of
different
methods
for
that,
so
I
guess
there's
both
there's
there's
kind
of
the
general
question
about
just
how
do
you
represent
analog
waveforms
in
a
way
that
is
richer
than
a
piecewise,
constant
waveform
right
over
shot
here,
but
then
there's
also
the
you
know
so
for
that
I
I
looked
at
using
both
polynomial
coefficients
so
kind
of.
C
In
this
particular
case,
I
found
that
the
spline
points
us
ended
up
lending
themselves
to
a
simpler
implementation
because
they,
for
example,
if
you
think
about
modeling
a
non-linearity
with
spline
points,
you
can
just
apply
the
non-linearity
to
each
one
of
the
spline
points,
whereas
with
polynomial
coefficients
it's
a
much
more
complex
transformation
that
ends
up
also,
it
turns
out
consuming
more
hardware
resources,
but
in
terms
of
the
interpolation
that
there's
that's,
actually
a
a
really
possibly
application,
dependent,
even
question,
because
if
I
only
tell
you
that
there
are
certain
points
that
appear
on
a
waveform,
any
method
of
connecting
the
dots
is
still
consistent
with
that.
C
So
there's
it's
almost
like
there's
some
natural
shape
of
analog
waveforms,
that's
kind
of
described
by
the
interpolation
method,
and
it
could
be
that
you
know
that
you
know
the
approach
that
I
used
was
just
using
a
piecewise
polynomial
interpolation,
without
any
assumption
about
what
the
underlying
waveforms
look
like.
C
But
you
could
also
imagine
a
case
where,
if
you
know
that
there's
a
certain
class
of
waveforms
that
you're
trying
to
represent
that
the
given
a
couple
of
points
on
those
waveforms
that
you
could
reconstruct
the
shape,
even
more
accurately
than
without
knowledge,
of
the
shape
of
the
waveform.
A
No,
that
makes
sense.
I
you
know
I
was
asking
my
question
part
because
I
know
you
know
some
years
back
when
you
know
in
my
role
at
sun
and
oracle,
we
had
built
our
own
cell
characterization
application,
and
you
know
one
of
the
studies
was
looking
at
different
interpolation
methods
to
improve
the
accuracy
of
the
model
representation
of
the
underlying
circuit,
so
that
so
that
and
appreciate
the
the
commentary
on
this.
A
So
are
there
any
any
other
questions
today
for
steve.
A
So
with
that,
I
will
wrap
up
today's
meeting.
Look
to
see
a
meeting
in
two
weeks
again
from
today,
muhammad
kaslan's
going
to
be
coming
in
and
helping
me
run
this.
So
I
appreciate
that
and
I'll
look
to
get
out
an
agenda
for
that
meeting.
So
if
there
aren't
any
other
questions,
I
want
to
thank
everyone
for
their
time
today
and
steve
again
for
an
excellent
presentation.