►
From YouTube: CHIPS Alliance Technology Update July 13 2023
Description
Hear the latest about CHIPS Alliance open hardware collaboration activities in these 6 talks.
A
Okay,
hi
everybody.
Thank
you
for
joining
us
today
for
the
chips
bi-annual
Tech
update.
It's
great
to
see
everyone
here
and
thanks
to
Google
for
providing
us
a
beautiful
location
here
in
San.
Francisco
I
really
appreciate
that,
and
thanks
all
for
coming
in
person
and
then
also
for
all
all
of
us
all
those
joining
us
online
I
apologize
for
the
logistical
challenges
that
always
seem
to
come
with
any
event
or
any
meeting
so
anyway,
but
that
just
seems
to
be
par
for
the
course.
No
matter
what,
but
again.
Thank
you
very
much.
A
So
you
know
just
provide
a
couple
introductory
comments.
We
have
some
great
talks
this
morning.
I
look
forward
to
to
hearing
them,
but
you
know
really
what
Chip's
Alliance
is
all
about,
and
what
Linux
Foundation
more
broadly
is
about
it's
about
collaboration
right.
It's
about
different
folks,
different
teams,
different
companies
working
together
on
hard
problems
and
the
belief
that,
by
having
a
community
or
building
a
community
to
collaborate
on
these
hard
problems,
that's
how
the
best
Innovation
comes
forward.
That's
how
these
problems
are
tackled.
A
But
irrespective
it's
been
a
long
road,
but
it's
really
starting
to
accelerate
now
and
that's
in
large
part
because
of
the
amount
of
collaboration
right
so
at
least
in
terms
of
Linux
Foundation,
what
we
sponsored
right,
we're
up
to
like
18,
000
developers
and
that's
been
in
the
past
couple
years.
So
that's
really
rather
remarkable.
A
You
know
we're
trying
to
do
that
in
chip
design
right
and
it's
it's
a
long
journey
and
there's
obviously
different
constraints
in
the
chip
world
compared
to
AI.
But
there
are
also
similar
concerns
right
and
a
lot
of
that
boils
down
to
you,
know
security
or
proprietary
data
right
and
how
to
handle
that
and
treat
that
right.
So
that's
something
that
you
know.
We
continue
to
look
at
relative
to
chips,
but
again
for
all
of
this.
A
It
really
tastes
boils
down
to
collaboration
and
participation
by
different
companies
and
organizations
to
help
make
this
go
forward
and
really
to
build
up
a
trusted
source
of
Ip
catalog
and
that
IP
could
be.
You
know
actually
RTL.
It
could
be
firmware.
It
could
be
Eda
Etc
right,
but
building
that
confidence
so
that
you
know
you
know
if
you're
part
of
a
company
or
university
when
you
pull
a
piece
of
RTL
or
something
from
our
repository
as
an
example.
A
So
you
know,
we've
been
fortunate.
You
know:
we've
been
gaining
some
members
over
the
past
six
months
or
eight
months
that
we've
joined,
so
it's
it's
great
to
have
AMD
part
of
us
Microsoft,
Nvidia
Marvel,
amongst
others,
exoto
who've
joined
us,
and
so
we
welcome
them
and
particularly
in
participation
on
the
root
of
trust
project
collector,
which
we'll
be
hearing
more
about
later
today.
A
So
look
forward
to
hearing
about
that
and
again,
as
I've
already
said,
this
really
in
so
many
words,
but
really
we're
about
open
collaboration
across
the
entire
spectrum
of
building
chip
design.
So
with
that
I
will
stop
chatting
and
I
will
introduce
our
first
Speaker,
which
I
am
very
pleased
to
announce
and
that's
Michael
Gilda
from
Ant
micro.
So
Michael
is
a
VP
of
a
development
business
development
at
micro
and
also
a
great
Enthusiast
and
sponsor
and
supporter
of
chips.
A
B
C
Great,
let
me
see
if
I
can
change
the
slides
easily,
all
right
good,
so
welcome
it's
a
pleasure
to
be
here
and
great
to
have
everyone
attending
virtual
as
well.
So
today,
I'm
going
to
talk
about
calypra
and
Veer
and
all
the
work
we're
doing
this
is
all
enabled
by
chips.
Alliance.
It's
really
taking
a
lot
of
Prior
great
work
and
putting
into
practice
in
a
collaborative
project.
C
Very
often
we
find
ourselves
work
with
tooling
and
specifically,
we
work
a
lot
with
async
and
fpga
oriented
tooling,
as
well
as
you
know,
IP
development,
all
sorts
of
Open
Source
tasks
that
help
people
build
practical
things
and,
of
course,
like
you,
can't
do
it
well
without
software,
without
automation,
without
CI,
and
that's
a
major
Focus
Veer
that
we're
going
to
be
talking
about
today
is
a
family
of
32-bit,
open
source
risk,
5
CPU
cores.
It
comes
in
three
options:
they're
all
hosted
by
chip
science.
C
So
these
links
here
in
the
slides
we'll
share
the
slides,
of
course
as
well.
They
all
point
to
a
different
version
of
the
same
thing.
So
so
today,
specifically
we'll
be
talking
more
about
the
the
the
el2,
the
kind
of
ore,
that's
embedded
inside
the
the
caliptra
route
of
trust,
but,
of
course,
you
you're
free
to
explore
the
entire
family,
of
course,
and
use
it
for
your
own
designs.
This
is
Asic
proven
RTL.
C
Eliptra,
if
you
are
not
familiar
with
the
project,
it's
an
open
source
rule
of
trust.
It's
specifically
meant
to
be
integrated
into
other
Solutions,
so
bigger
socs
that
need
a
root
of
trust
functionality.
The
idea
comes
from
a
collaboration
in
ocp,
open
compute
project,
where
four
big
players-
Nvidia
Google,
AMD
and
Microsoft
got
together,
and
you
know
they
have
the
same
problem.
They
need
a
root
of
trust
so
that,
if
they're
buying,
Hardware
or
developing
hardware
for
their
servers,
they
can
actually
rely
on
the
security
of
those
blocks
to
be
well
uniform,
unanimous,
comparable.
C
You
know,
12
different
solutions,
the
same
problem,
so
it's
meant
to
and
again
it's
kind
of
is
really
well
tied
into
the
mission
of
chips,
which
is
standardizing,
which
is
making
people,
reuse,
RTL
and
tools
instead
of
kind
of
Reinventing
the
wheel
and
it's
kind
of,
is
a
great
example
of
a
collaborative
project
because
since
it
started
with
those
four
companies
and
of
course
by
now,
we
have
like
probably
a
dozen
others
collaborating
yeah.
Obviously,
we
need
to
find
ways
to
work
together
and
processes
to
make
that
collaboration
efficient.
C
So
so,
overall,
the
mission
of
chips
here
is
to
host
the
implementation,
so
the
spec
is
kind
of
hosted
in
ocp,
but
the
actual
implementation
and
all
the
technical
work
is
going
on
in
chips.
Alliance
all
the
repos
are
kind
of
found
under
the
chips,
Alliance
GitHub
organization,
and
it's
a
paragon
project.
You
know
where
we're
kind
of
helping
establish
methodologies
to
collaborate
on
open
source.
Rtl
collector
itself
is
kind
of
at
least
the
1.0
version
of
it
is
focused
on
very
specific
features.
C
We're
not
trying
to
kind
of
boil
the
ocean,
but
more
like
specifically
address
the
need
as
this
today
and
there
are
plans
to
integrate
that
first
version
into
real
products
in
the
near
future.
As
I
said
before,
it
uses
the
VR
El
to
core,
and
of
course
it
has
more
than
just
the
core
right.
It
has
a
bunch
of
different
peripherals.
Many
of
these
are
actually
reusing.
You
know
open
Titans,
peripherals
again
we're
not
trying
to
reinvent
the
wheel.
C
C
But
the
challenge
is
that
it's
kind
of
hard
to
share
that
methodology
easily
to
make
it
completely
reproducible
for
other
people
for
new
partners
during
the
project.
You
know:
how
do
you
actually
get
them
on
board
quickly
and
how
do
you
make
it
easy
for
them
to
reproduce
your
results
right,
so
open
source
is
a
good
answer
to
this,
and
certainly
we're
not
meaning
to
like
replace.
You
know
every
existing
tool
out
there,
but
more
like
augment
exiting
workflows
that
each
and
every
of
those
companies
so
Microsoft
Google
ND
Nvidia,
have
internally
right
internally.
C
They
have,
of
course,
their
own
huge
flows
and
tools
and
everything,
but
we're
trying
to
kind
of
add
an
open
source
layer
of
great
stuff.
On
top
of
that,
which
would
enable
us
to
have
you
know,
smoke
tests
and
the
ability
to
reason
about
the
quality
of
the
code
and
lint
it
and
so
on.
So
so,
basically,
that's
the
focus
of
this
project
and
and
we're
kind
of
executing
on
this
project.
C
So,
let's
start
with
all
the
things
that
we've
done,
starting
with
variable
variable
is
a
tool
that
was
donated
by
Google
internships.
Alliance
is
being
developed
within
Chip's
Alliance,
we're
pretty
involved
in
in
the
variable
development
itself
and
what
it
does
it's
a
system
very
loud,
parser
and
toolkit
for
linting
formatting
and
also
includes
like
a
lexical
diff,
obfuscator
and
indexer,
and
from
interesting
things.
It
also
has
a
language
server,
so
it's
a
pretty
versatile
framework
for
working
with
systemvale
code
and
it's
completely
open
source.
It's
it's
under
active
development.
C
It
also
includes
the
language
server,
which
is
kind
of
makes
it
even
more
useful,
because
it
integrates
very
well
with
a
variety
of
editors,
so,
whatever
tool
you're
using
for
editing
your
code,
you
can
actually
integrate
through
this
LSP
layer
and
there's
documentation.
That
tells
you
how
to
do
that
and
we
support
most
of
the
features
that
are
capable
possible.
With
you
know,
language
servers,
including
Auto
expansion,
there's
also
blog
notes
that
we
wrote
about
this
specific
feature
so
feel
free
to
read
it
for
more
backgrounds,
there's
also
a
plugin
for
vs
code.
C
We
were
aware
that
vs
code
is
kind
of
becoming
the
de
facto
standard
for
IDs.
So
to
make
things
easy
for
people
there's
an
official
plugin
we
have
to
go
through.
You
know
like
registering
our
official
account
in
in
the
vs
code,
extension,
Marketplace
and
so
on
and
so
on,
but
we
have
an
officially
supported
plugins,
but
there's,
of
course
other
ones.
But
this
one
is,
you
know
the
ones
that's
being
maintained
by
chips,
lines
from
interesting
things
with
variable.
C
We
also
have
GitHub
actions
which
make
it
super
easy
to
integrate
with
existing
code
bases
on
GitHub
I.
Believe
it's
pretty
awesome
because
you
can
get
you
know,
feedback
on
your
pull
requests.
You
can
get
linting
suggestions
or
even
kind
of
formatting.
You
know
real
changes
to
your
code
that
you
can
just
accept
right,
so
you
kind
of
submit
a
PR
and
it
sees
that.
Okay,
this
change
is
not
really
great.
C
D
C
C
So
the
core
was
verified
by
the
original
authors
to
a
very
kind
of
deep
extent,
given
that
it
was
shipped
in
like
millions
or
perhaps
even
billions
of
devices,
but
the
the
actual
test
benches
you
know
could
not
be
fully
released,
so
we
only
had
system
level
tests
to
start
with.
So
basically,
one
of
our
goals
is
to
kind
of
increase
the
coverage
that
we
started
out
with
and
we've
been
adding
this
as
like.
C
Pub
click
CI
checks
so
that,
if
there's
any
changes
to
the
core,
they
kind
of
we
continue
to
test
against
all
those
scenarios.
And,
of
course
we
generate
a
report
with
coverage
and
there's
a
summary
web
page
with
links
to
more
specific
details
and
so
on.
There's
a
link
in
this
presentation
as
well
and
now,
naturally
kind
of
taking
it
to
the
next
level.
We
want
to
make
sure
that
you
know
things
continue
to
work.
C
C
Nowadays,
it's
kind
of
the
funding
is
coming
from
different
sources,
but,
generally
speaking,
we're
pretty
close
to
parsing
the
entire
UVM
library
with
their
later
as
well
as,
of
course,
we'll
need
a
few
more
features
to
actually
go
and
do
proper
UVM.
You
know
large-scale
testing.
So
definitely,
if
you
have
need
for
this,
you're
invited
to
kind
of
talk
to
us-
and
you
know
kind
of
figure
out
a
way
to
accelerate
this
work,
because
we
know
from
many
sources
it
would
be
really
really
great
to
get
it
past.
The
finish
line
so
so
far.
C
We
can't
do
this.
Unfortunately,
we
can't
you
know,
do
actual.
You
know
UVM
end-to-end,
but
also
we
believe
it's
possible
and
it's
not
extremely
far
away.
On
the
other
hand,
of
course,
there's
open
source
methodologies
that
people
might
be
aware
of
Coco
TB
by
UVM
being
two
of
vampire
VMS,
actually
Siemens
tool
cocoa
to
be
as
a
Community
Driven
fossil
foundation-backed
project,
and
they
they
work
together.
C
You
can
use
them
to
test
things
in
a
uvm-like
methodology,
so
if
you're
not
afraid
of
python,
it's
it's
a
great
way
to
you
know,
do
your
stuff,
and
especially
if
you
want
to
keep
to
something,
that's
like
familiar
Pi
UVM
would
be
a
way.
Coco2B
is
more
generic.
You
can,
of
course,
do
kokuti
B
testing
without
Pi
UVM,
and
you
can
trust
the
developers
that
consistently,
you
know
rate
Goku
to
be
as
an
excellent
tool.
C
That
does
a
great
job,
but
we're
also
aware
that
a
lot
of
the
world's
developers
in
the
verification
space
they
they're
just
used
to
system
very
long
they're
used
to
UVM,
so
we'll
have
to
tackle
all
these
ways
of
testing
in
parallel
right
and
eventually,
we
want
to
be
able
to
do
this,
but
in
case
you're
you
want
to
do
open
source
testing
and
verification.
Today
there
is
a
way
and
there
there
are
also
examples
in
the
VR
and
clicker
apples.
How
to
how
to
do
this.
C
One
other
interesting
thing
that
we
added
it's
still
kind
of
experimental
but
I
think
very,
very
useful.
We
do
run
the
entire
VR
core
through
the
open
source
RTL
to
GDs
flow
with
open
road,
and
this
is
part
of
the
the
CI
I
mean
it's.
It's
a
work
in
progress
PR,
but
it's
kind
of
working
now,
so
we
just
need
to
clean
it
up
and
merge
it
now.
This
allows
us
to
do
like
the
smoke
test
where
any
changes
to
the
RTL
like
we
can
certainly
see
if
they
compile.
C
C
You
know,
perhaps
with
AI
on
a
thousand
computers,
or
you
can
experiment
with
different
parts
of
a
tool
chain,
and
you
know,
do
research
on
top
of
it,
and
even
if
you
get
worse
results,
you
might
just
get
them
quicker
compared
to
to
other
tools.
So,
overall,
we
believe
that
having
open
road
support
here
is
important.
We
would
want
to
extend
it
to
cover
all
of
colletra
in
the
future.
We
haven't
done
it
yet
and
also
one
other
limitation.
C
So
far
is
that
normally,
if
you
want
to
run
things
through
the
open
road
Flow
by
default,
it'll
support
some
system
very
loud,
but
not
enough
to
cover
your
real
designs.
So
one
of
the
ongoing
projects
within
Chip's
Alliance
is
also
Sherlock
uhdm
and
related
eosis
plugin,
where
we
can
actually
parse
a
very
significant
part
of
the
system,
works
back
and,
in
fact,
we're
not
far
away
from
parsing
all
of
beer
encryptra
in
general.
So
there's
ongoing
work
to
just
enable
this.
We
can
parse
open
Titan.
E
B
C
Okay,
so
moving
on
to
another
way
of
improving,
you
know
the
verification
of
of
the
core
there's
a
framework
called
risk
5dv
which
is
originating
from
Google,
but
also
now
donated
into
chips
Alliance,
and
this
is
an
open
source
framework
for
instruction
set
generation
and
and
testing.
Of
course,
comparing
you
know,
generating
random
streams
of
data
and
trying
to
see
if
the
implementations
behaving
correctly
as
compared
to
instruction
set
simulator.
C
So
we
had
to
add
a
bunch
of
things
to
make
it
work
with
the
current
code
base,
but
it
wasn't
extremely
hard.
One
other
interesting
piece
of
work,
we'd
managed
to
do
in
the
last
few
months
is
improving
the
python-based
generator
in
Risk
idv,
so
risk
idv
itself
is
kind
of
based
on
UVM
for
the
instruction
generation
part,
and
that
means,
of
course,
if
you
were
listening
to
what
I
was
saying
earlier,
we
can't
do
that
with
open
source.
Yet
it's
something
we'd
like
to
do
so.
F
C
All
of
risk
idv
in
the
future,
which
we'd
also
like
to
do
another
thing
like
from
from
the
technical
work,
that's
gone
into
the
project
recently
and
that
part
will
kind
of
grow.
So
so
right
now,
we'll
probably
be
kind
of
extending
the
project
to
also
cover
some
additions
and
extensions
to
the
core
itself.
So
now
that
we
have
some
methodologies
to
test
it
better
and
the
framework
to
kind
of
run,
CI
and
so
on,
we
can
start
adding
features
without
the
fear
of
you
know,
making
things
explode.
C
So
one
of
the
problems
we
had
was
that
you
know
we
needed
a
JTAG
and
collector
as
this
jdeg
interface,
and
we
created
some
testing
to
make
sure
that
the
jdeg
interface
actually
works
again
open
source.
It
can
run
in
CI
and
we
actually
found
a
problem
right.
So
we
we
kind
of
found
that
you
couldn't
access
approval
from
the
debug
interface
and
culture
just
didn't
connect
to
the
bus
in
a
certain
way.
C
You
know
it
was
kind
of
a
simple
and
stupid
bug,
but
certainly
kind
of
proves
that
this
testing
is
needed
because
it
felt
like
a
very
obvious
addition
right,
a
small
change,
but
actually
it
wasn't
fully
correct.
So
that's
why
we
need
this
entire
infrastructure
here
and
now
we
have
tests
to,
of
course
see
that
this
bit
is
working
fine,
so
going
towards
the
end
of
the
presentation.
C
One
of
the
things
that
was
also
pretty
Central
to
the
project
is
trying
to
figure
out
okay,
how
to
actually
make
this
scale
how
to
make
it
collaborative
and,
as
you
know,
in
in
the
Asic
space,
you
know
many
of
the
workloads
are
not
trivial,
they're,
not
something
you
can
just
run
in
five
minutes.
They
might
take
hours
to
complete
and
require
a
lot
of
memory
and
a
lot
of
compute
power.
So
one
of
the
projects
that
we've
been
working
on
in
chips
Alliance
for
years
now
is
so-called
custom.
C
You
run
your
own
machine,
we're
using
gcp
for
this,
obviously,
because
it's
collaboration
with
Google-
and
this
allows
us
to
pretty
much
scale
up
to
whatever
kind
of
machine
we
want
and,
however
many
resources
we
require
run.
You
know
lots
of
things
in
parallel
without
fear
of
running
out
of
resources
and
stalling
everything
and
we're
kind
of
using
it
in
a
bunch
of
projects.
This
is
not
the
only
project
using
those
Runners,
but
specifically
for
cliptra.
C
One
of
the
things
you
were
working
on
I
mean
we
will
recreate
blazed
this
Trail,
but
here
it's
going
to
be
especially
important.
The
ability
to
run
proprietary
tools
on
top
of
the
open
source
stuff
so
that
you
know
we
can
do
it
without
exposing
Secrets
without
kind
of
causing
any
problems
for
everyone.
But
still
we
can
get
the
support
we
need.
You
know
we
can
kind
of
run
the
real
flows
that
those
companies
are
using
in
a
in
a
secret
and
secure
way
only
exposing
the
results
that
we
need
to
expose.
C
So
this
is
one
of
the
ongoing
tasks,
partly
because
it's
kind
of
hard
to
set
it
up.
One
of
the
problems
that
open
source
is
trying
to
to
to
fix
is
that
open
source
is
really
easy
to
set
up
like
everything's
just
there
and
you
get
the
code
and
voila.
But
of
course
this
is
hard
to
do,
but
we
want
to
do
this
so
that
we
can
increase
the
confidence
in
the
code.
So
the
GitHub
Runners
are
a
central
technology
here
and
they're
also
open
source.
C
One
last
thing
I
wanted
to
say
is
that
the
work
is
ongoing,
so
we'll
probably
have
some
more
news
by
September
and
in
September
right
at
the
beginning
of
Oktoberfest,
so
no
suggestions
there,
but
you
can
come
to
Munich
and
enjoy
not
only
the
beer
but
also
a
really
really
awesome
conference.
It's
one
of
the
greatest
open
source
conferences
out
there.
It
it
definitely
kind
of
groups,
a
really
interesting
crowd.
It's
happening
in
September
15th
to
17th.
C
Some
of
the
things
I
was
talking
about
that
are
in
progress,
might
already
be
in
place,
so
yeah
you're
very
kindly
invited
if
you're
interested
in
these
things,
I'm
sure
that
you'll
find
Oracle
interesting,
there's
also
an
American
version
of
Alarcon
called
latchap
that
some
of
you
might
have
attended,
and
this
happened
already
this
year,
but
I
assume
that
next
year,
there's
going
to
be
a
new
addition
that
you
should
definitely
join
too
all
right.
Thanks
for
your
attention.
That's
all
I
have
foreign.
C
So
I
would
repeat
the
question
for
for
everyone
to
hear
what
made
that
choose
or
implemented
in
system
verilog.
It's
a
great
question
because
we
also
host
chisel,
right
and-
and
there
are
other
kind
of
languages
and
methodologies
to
build
RTL
in
these
days.
I
guess
system
verlock
is
just
a
conservative
choice
of
you
know,
like
all
those
big
companies
are
huge
silver
luck,
shops,
including
Google,
including
you
know,
Nvidia
and
Microsoft
and
AMD.
C
H
C
C
I
I
mean
I've
heard
about
it,
but
I
think
that
the
problem
in
this
space
is,
of
course
everyone
has
a
bit
of
a
different
idea:
how
to
do
things
and
including
like
even
the
language,
you're
writing
in
and
the
testing
methodology,
and
so
on,
so
even
getting
to
like
agreement,
how
we
should
do
things
in
collector.
It's
not
easy,
but
but
yeah
I
mean,
if
you
have
Concepts
on
how
things
should
be,
could
be
done
better
in
a
more
open
source
friendly
way.
Then
we're
happy
to
talk
to
you
so.
C
B
C
What's
the
main
difference
with
open
typing
and
collector?
That's
a
question.
We
get
a
lot
and
thank
you
for
it,
of
course.
So
of
course,
we're
friendly
towards
open
Titan
and
we're
actually
using
a
lot
of
the
great
stuff
that
open
Titan
has
built.
The
project
was
born
from
the
need
to
actually
do
an
integrated
route
of
trust.
You.
E
C
C
The
the
you
know
the
root
of
trust
implementation
on
Google,
so
I
think
that's
a
major
difference
now,
of
course,
like
ultimately
I
think
both
projects
could
theoretically
cover
both
use
cases
because
there's
no,
no,
nothing
stopping
you
from
just
taking
calyptra
and
making
it
into
a
chip,
but
it's
just
a
different
focus,
and
also
it's
just
governance
as
well
like
Calypso
wanted
to
be.
You
know,
independent
and
set
up
as
a
Chip's
light
work
group
rather
than
a
standalone
project,
or
part
of
you
know
open
Titan.
C
So
but
ultimately,
of
course,
a
lot
of
people
kind
of
ask
this
question,
and
the
answer
is
obviously
there's
a
vast
amount
of
collaboration
that
we're
hoping
for
here
and
the
aim
was
never
to
you,
know
kind
of
be
competitive
in
the
direct
sense
just
like
in
the
open
source
space
in
other
areas.
You'll
always
get
you
know,
20
different
ways
to
solve
the
same
problem,
which
is
a
good
thing.
C
C
C
B
C
Media
integrated
and
dependent
values
variants,
but
in
terms
of
like
the
actual
security
model
implemented
by
those
two
projects,
I
am
not
the
expert
for
sure
you
can
talk
to
Prabhu.
You
can
talk
to
Matt,
I.
Suppose
they'll
probably
be
able
to
give
you
more
detailed
information
how
these
two
persons
compare.
A
Actually,
you
have
a
few
minutes
to
spare,
but
you
did
very
well
so
thank
you
so
much
for
an
excellent
talk.
That
was
that
was
really
good.
I
appreciate
it,
so
our
next
speaker
will
be
corn
Nielsen.
He
is
going
to
be
chatting
with
us
about
collector,
validating
firmware
against
multiple
Hardware's
models.
Continuous
integration
core
is
a
embedded
engineer,
working
for
Google
he's
written
firmware
for
Google's
in-house
Titan
root
of
trust
ship
and
has
dabbled
in
Rust
firmware
development.
Since
2015
is
now
leveraging
rust
to
develop,
secure,
maintainable
firmware
for
calypra.
So
core.
J
J
J
You
can
follow
links
there
to
the
main
repos
too.
So
what
I
want
to
talk
a
little
bit
about
is
testing
The
Collector
firmware.
This
is
going
to
be
a
bit
lower
level
talk
than
the
last
one,
but
so
maybe
just
a
first
little
bit
about
just
software
testing
in
general.
You
know
we
have
unit
tests,
and
these
are
you
know
great
everybody
uses
them
they're
faster
right.
They
fast
execute
it's
really
easy
to
to
do
coverage
guided
fuzzing.
J
So
it
can
like
create
input
for
the
test
to
try
to
find
interesting
branches
and
other
problems
and
just
explore
the
possible
State
space
of
the
code
and
unit
tests
are
a
great
way
to
do
this,
but
in
tests
also
are
not
really
great.
When
you
want
to
say
hey,
is
this
firmware
safe
to,
like
you
know,
put
into
the
you
know
into
put
into
the
ROM?
You
know
because
they
well
one
thing:
they
test
source
code,
not
the
final
compiled
machine
code.
J
So
if
there's
compiler
bugs
or
other
you
know,
issues
like
that,
you
know
the
young
tests
aren't
going
to
really
help.
You
find
those
because
usually
they're
being
compiled
for
a
different
architecture
or
using
you
know,
obviously
different
optimization
passes
and
whatnot
they're
unlocked
like
they've,
noticed
runtime
issues
like
stock
spec
overflows
or
Watchdog
timeouts,
it's
very
difficult
to
write
unit
tests
that
interact
with
Hardware.
You
can
but
oftentimes.
J
Seen
and
100
coverage
is
unrealistic
because
you
know
there's
lots
of
kind
of
glue
code
and
stuff
like
that,
that
you
can't
that's
part
of
the
firmware.
That's
you
know
not
part
of
the
unit
tests
and
they're,
often
brittle,
because
they're
testing
components
of
the
firmware
rather
than
the
firmware
as
a
whole.
So
as
those
internal
bits
change,
you
know
you
oftentimes
have
to
update
the
test
cases
so
and
so
for
validation.
We
kind
of
prefer
to
use
integration
tests
and
you
can
run
these
against
the
final
machine
code.
J
They
can
be
executed
against
an
RTL
environment
so
where
the
the
firmware's
running
you
know
inside
the
final
RTL
that
it's
going
to
be
bundled
with,
and
we
can
discover
any
bad
assumptions
that
the
firmer
makes
about
how
the
hardware
behaves.
We
can
sometimes
even
discover
Harbor
bugs
and
100
coverage
as
possible.
Right
like
it's
directly
possible
to
write
your
integration
test
to
You
Know
cover
every
single
branch
that
the
machine
code
does
and
you
can
take
your
assertions
which,
in
unit
tests
are
typically
part
of
the
actual
running
binary.
J
Test
because
you've
kind
of
got
your
test
has
two
parts:
the
firmer
running
inside
the
test
environment,
and
then
it
has
the
test
Runner
itself,
which
can
do
assertions
based
on
what
it
observes
the
firmware
do,
and
you
know,
even
if
the
firmware
goes
in
completely
crazy.
You
know
it's
not
returning
the
expected
results.
J
So
they
are
exhaustive
and
we
can
make
it
so
that
we
can
write
a
single
test
once
that
executes
in
multiple
different
environments,
which
is
kind
of
the
what
I,
what
I'm,
what
we're
trying
to
do
with
with
clipdro
so
I.
Just
before
we
go.
Let's
talk
a
little
bit
about
about
just
general,
very
high
level.
Block
diagram
is
very
simplified,
just
to
point
out
the
parts
that
I
care
about
for
this
talk.
J
J
So
if
I
go
over
to
it's,
it's
Clipper
top
RTL,
which
is
a
domain,
a
very
long
module.
It
has
these
APB
signals
which
are
wired
up
usually
to
some
fabric
in
the
soc
that
some
management
controller
will
will
talk
to
so
that
APV
bus
here
is
generally
what
we
want
our
test
case
to
manipulate.
So
we
want
to
be
able
to
basically
generate
any
possible
memory
transaction
on
that
bus
from
the
test
case
and
using
you
know
that
bus
we
can
do
stuff
like
fill
in
the
fuses.
J
So
we
can
we
can.
We
can
write
commands
to
the
mailbox,
which
is
the
main
way
to
communicate
with
the
firmware,
and
we
can
do
a
bunch
of
stuff
like
set
various
configuration
signals
and
whatnot,
and
then
the
viewer
CPU
encycloped
right,
which
is,
is
where
is
running
the
firmware
that
we
actually
want
to
test.
So
this
has
access
to
a
bunch
of
peripherals
cryptographic.
J
Peripherals
has
access
to
the
ROM,
has
access
to
SRAM
all
that
stuff
is
kept
secret
from
the
outside
world
by
the
hardware,
and
we
want
to
test
the
firmware.
That's
running
inside
that
environment,
so
I'll
just
go
again
through
the
RTL.
Here
we
have
I
mentioned
the
APB
bus
signals.
We've
also
got
some
reset
signals
that
you
know
assess
might
want
to
manipulate.
J
J
What's
it
called
system,
RDL
I
think
which
generates
a
bunch
of
great
registered
documentation,
and
also
we
generate
all
of
our
our
code
to
access
these
registers.
Based
on
that
too,
so
the
test
cases
can
easily
access
any
of
these
registers.
The
APB
registers
that
are
exposed
to
SOC
whenever,
whenever
it
wants
to
and
can
do
so
in
a
pretty
a
pretty
nice
way,
which
I'll
show
later
oops,
so
I'll
just
kind
of
scroll
down
I
got.
J
You
know
the
ability
to
you
know
lock
the
mailbox
check
the
mailbox
link,
so
you
know
execute
it,
set
all
the
fuses
which
are
done
only
at
startup,
ideally
being
done
by
a
hardware,
State
machine
and
not
the
soc
CPU.
But
you
know
the
anyways
we'll
talk
a
little
bit
about
the
various
different
horror
models
that
we're
using.
So
the
first
one
is
the
one
that's
basically
not
using
the
real
RTL,
because
at
the
time
we
started
working
on
the
firmware,
the
RPL
didn't
really
exist
at
all.
J
But
you
know
over
time,
as
we've
tested
you
know,
in
this
environment
and
other
barns,
we
were
able
to
converge
the
the
the
full
system
simulator
to
behave
the
same
as
the
RTL,
at
least
in
the
scenarios
we
care
about
I'm,
going
to
test,
compile
to
self-contained
executables.
That
can
run
on
Linux
and
Mac.
Os
and
I
can
probably
run
other
places
too,
but
I
don't
think
anybody's
tried
and
these
tests
are
running
really
fast,
like
we
can
run
our
entire
test
Suite.
J
This
was
I,
don't
know,
50
plus
tests
that
they're
booting
multiple
clipped
or
you
know
many
many
times,
and
we
can
run
that
test
Suite
in
just
a
few
minutes,
but
it's
not
super
high
fidelity.
Obviously
the
timing
is
not
is
not
accurate.
The
real
Hardware
is,
you
know,
takes
a
lot
longer
to
go
to
operations
and
whatnot,
but
these
are
great,
as
kind
of
did.
We
actually
break
anything
really
significant,
and
so
we
run
these
test
cases
for
app
for
every
commit.
J
J
Oh
and
we
can
log
the
CPU
bus
activity,
which
is
pretty
great
for
debugging
certain
things
and
we
can
even
simulate
some
impossible
scenarios
like
bad
Hardware
or
one
star
that
I'm
really
interested
in
is
actually
is
glitch
resistance.
So
this
is
where
the
you
have
a
attacker
who's,
manipulating
the
clock
or
the
or
the
reset
signals,
or
the
maybe
in
the
power
supply
to
the
CPU
or
to
the
whole
SOC
and
trying
to
correct
the
CPU
into
like
skipping
some
instructions,
and
you
know
to
maybe
get
past
coin
verification,
or
something
like
that.
J
So
we
can
add
hooks
to
the
to
The
Interpreter
to
basically
simulate
you
know,
skipping
branches
or
corrupting
register
contents
and
stuff
like
that.
So
you
could
you
can
imagine-
and
we
haven't
done
this
yet-
but
I'd
love
to
be
able
to
run.
You
know
millions
of
iterations,
where
it's
randomly
trying
to
you
know
screw
around
with
the
CPU
registers
or
the
CPU
execution,
and
then
CFA
does
this
clifter
ever
let
you
know
non-validated
machine
code
get
into
the
instruction
memory
or
whatever
right.
J
So
that's
the
kind
of
our
you
know
our
our
our
our
main.
You
know
test
environment,
but
not
super
accurate,
and
then
you
know
three
or
four
months
ago
we
started
working
on
a
second
model
which
is
a
varilator
model,
so
this
model
can
is
built
against
the
real
RTL
and
it's
High
Fidelity
single,
accurate.
So
and
you
know
it's
actually
compiles
pretty
fast,
you
can
make
a
change
to
the
RTL
and
then
see
your
your.
The
change
live.
Writing
the
real
firmware.
J
You
know
usually
within
a
few
minutes-
and
you
know
the
in
this
case
the
APB
bus,
reads
and
writes
these
are
basically
the
test
case
itself
or
the
infrastructure
behind
all
this
is
manipulating
the
actual
signals
being
passed
to
Clipper
top
and
because
of
that,
it's
very
cycle
accurate.
You
can
your
test
case.
Can
you
know
be
really
fussy?
What
happens
if
this
signal
happens
at
exactly
this
time?
What
does
the
firmware?
J
So
you
know
it's
not
really
feasible
to
run.
You
know
100,
plus
tests
on
every
commit.
If
it's
going
to
take.
You
know
seven
days
of
a
relatively
powerful
machine
to
run
those
tests.
So
we
can't
we
don't
actually
want
our
tests,
but
we
do
run
nightly
some.
What
we
call
because
consider
important
tests
that
test
the
the
success
cases
and
stuff
like
that,
and
you
know
it's
also
a
great
environment
for
debugging.
J
J
You
can
have
the
test
or
the
environment,
basically
just
parse
all
the
bus
activity
and
log
into
a
text
file
which
you
know
makes
it
easy
to
grip
and
whatnot,
and
this
is
the
yeah
the
best
place
to
debug.
You
know
issues
with
the
with
the
hardware
or
the
firmware
you're,
not
sure.
What's
wrong
and
unfortunately
their
leader
is,
you
know
not
perfect,
it's
not.
J
What
I
understand
has
something
to
do
with
the
Clipper,
not
supporting
some
kind
of
clock
or
sorry,
barely
they're,
not
supporting
some
sort
of
clock
eating
or
something,
and
then
this
new
model
which
just
started
working
this
week
is
a
real-time
fpga
model.
So
here
we're
trying
to
Target
the
zcu
104
Dev
board,
which
is
you
know
about
roughly
two
thousand
dollars
and
this
thing
barely
fits
collector.
J
We
actually
had
to
trim
down
some
of
the
the
number
of
key
Vault
registers
and
stuff
like
that
to
make
it
fit,
but
it
was
the
kind
of
most
reasonable
Choice,
given
the
cost
and
size
constraints
that
we
needed,
and
so
this
has
a
this
is
the
zinc
the
zinc
fpgs
have
this
application
processor,
which
can
basically
run
Linux
and
run
rust
binary.
So
we
can
just
compile
our
test
cases
to
run
this
a53
processor
and
then
those
test
binaries
can
just
talk
to
the
APD
bus
using
mmio
directly.
J
So
it's
super
fast
and
and
and
super
great,
you
know
this
environment
here
is
probably
I
mean.
Hopefully
we
can.
We
can
start
running
test
cases
on
pre-submits
with
this,
so
we'll
need
a
little
form
of
fpgas
and
somebody's
basement
somewhere
to
to
execute
these
execute
these
tests,
but
yeah
I'm
I'm
hopeful
that
this
will
become
part
of
our
standard
CI
to
execute
everything
in
this
environment.
J
One
of
the
downsides
to
it
right
now
is
that
we
are
using
the
clock
signal,
that's
being
generated
by
the
oscillator
on
the
on
the
board,
so
the
test
case
itself
doesn't
have
any
control
over.
You
know
single
stepping
or
trying
to
control
the
test.
So
there's
some
test
cases
that
involve
timing,
that
we
can't
really
run
in
this
environment.
J
But
you
can
imagine
that,
with
some
tweaks
to
the
art,
the
test
harness,
we
should
be
able
to
to
be
able
to
give
the
the
test
control
over
the
clock
and
and
do
those
sort
of
timing.
Things
in
this
environment
as
well,
and
the
main
downside
to
the
fpga
is
that
if
you
want
to
change
the
RTL,
it
takes
hours
to
to
recompile
the
Midstream.
And
you
know
it's
not
a
great
prototyping
environment
for
our
talents
for
sure,
but
for
as
an
environment
that
tests
the
firmware.
J
J
So,
let's
see
here
so
I'm
going
to
share
a
different
tab
here,
so
this
one
can
here's
kind
of
a
basic
test
case.
That's
that's!
That's
that's
doing
a
basic
scenario
here,
so
here
we're
just
creating
a
the
hormone
itself,
and
so
this,
depending
on
on
basically
the
environment
variables
or
the
configuration
Flags
to
the
test.
They
will
instantiate
various
models.
J
J
How
do
you
want
to
wait
for
it
in
the
case,
so
here
I'm,
basically
saying
Hey
I
want
to
create
a
new
model
I'm,
giving
it
some
initialation
when
I
want
to
use
this
ROM,
please
so
I'm,
just
building
our
regular
ROM,
but
I
could
pass
in
Iran.
That
you
know
is
testing
some
specific.
You
know
Hardware
feature
or
something
like
that,
but
it
doesn't
start
to
be
the
actual
production
firmware.
But
in
this
case
it
is
telling
it
well
I
want
the
security
state
to
be
our
production,
Security
State.
J
J
Saying
I
want
to
run
this
this
flawless,
throwing
down
to
manufacturing
and
generates
the
the
certificate
signing
request
for
clip
drill
which
is
done
early
in
manufacturing,
and
then
we
can
receive
the
actual
request
from
the
mailbox
and
then
parse
it
in
SSL.
So
you
know
again
because
this
test
case
is
not
running
and
that's
part
of
the
firmer,
but
it's
running
outside
the
firmware
can
use
libraries
like
openssl
and
other
things
to
just
parse
out.
J
A
test
ran
really
fast
right
and
it's
pretty
much
as
fast
as
you
can
test,
even
though
it
actually
would
be
collectora
inside
the
emulator,
and
you
can
see
the
you
know
the
our
debug
version
of
the
of
the
firmware
you're
printing
out
everything
it's
doing,
and
then
here's
the
actual
CSR
that
came
out
and
it
was
you
know
it
started
that
it
matched
the
golden
data.
You
know,
and
so
it's
a
pretty
great
as
a
development
environment,
because
you
can
just
you
know,
write
these.
J
So
this
is
again
running
the
same
test,
but
I've
added.
This
features
equals
there
later,
which
will
run
it
in
the
very
later
environment.
As
you
can
see,
it's
running
really
slow.
I
already
started
it.
You
know
it's
was
four
thousand
Cycles
in
it
wrote
the
actual
set
the
value
of
the
the
boot
FSM,
but
it
hasn't
even
printed
the
first
line,
yet
so
I
think
it
takes
around
a
minute
to
print
the
first
line,
but
as
you
can
see,
this
isn't
very
fun.
J
J
So
if
I
control
see
this
and
I'm
going
to
take
a
look
at
this
Trace
file,
I
hold
the
right,
and
this
contains
all
the
activity
that
saw
so
here
we
can
see
the
soc
from
the
test
case,
basically
writing
to
various,
probably
a
fuse
registers
and
various
things
and
and
preparing,
and
then
you
can
see
the
microcontroller,
which
is
what
we
call
the
viewer
core
inside
clifter
and
starts
doing
a
bus
activity,
and
here
you
can
see
it's
it's
clearing
the
main
memory.
It's
clearing.
J
You
know
our
main
SRAM,
which
is
what
it's
been
doing
and
profitable.
Is
it
doing
like
it
when
I
stopped
it
right?
So
you
know
you
can
get
one
of
these
Trace
files
for
the
for
the
whole
Boot
and
try
to
crack
down
what's
going
wrong
or
if
you
want
more
detail
on
that,
you
can
have
it
right
there,
making
all
the
videos
just
change
this
to
the
BCD,
and
then
that
gives
me
a
nice
vcd
file.
That
gives
all
the
signal
and
clicker
which
you
don't
really
want
to
use
with
the
full
firmware.
J
But
if
you
have
an
isolated
test
case,
you
can
usually
get
something
to
send
to
the
hardware
Engineers
with
above
their
their
TL,
or
you
can
look
at
it
yourself
and
then
I'll
take
a
look
at
the
same
test
case
this
time
running
in
the
fpga
environment
and
I
kind
of
forgot
to
test
this
today.
So
hopefully
this
works.
Let's
see.
J
Oh
yeah
there
it
goes
all
right,
so
it's
a
little
bit
slower
than
the
software
emulator
I.
Think
that's
just
because
we
haven't
really
got
the
clock
set.
You
know
to
the
ideal
speed
yet,
but
you
can
see
it
it
through
the
whole
thing.
This
is
still
very
early.
The
clock
cycle
counter
is
not
quite
accurate,
yet
I
think
that's
just
like
real
time
or
something.
C
I
actually
have
two
if
I
may,
so,
if
we
can
go
back
to
her
later,
the
the
slide
there.
You
mentioned
a
bunch
of
things.
So,
first
of
all,
you
said
that
execution
is
very,
very
slow,
I
mean
it's
partly
expected,
but
on
the
other
hand,
I'm
interested
in
you've
been
investigating
the
changes
we've
been
doing
both
in
terms
of
execution
runtime,
but
also
you
you
mentioned.
Compilation
was
was
kind
of
long
because
we
have
been
optimizing
this
for.
J
J
C
So
but
it
would
be
interesting
to
have
a
conversation
about.
You
know
why.
Why
is
the
execution
so
slow
and
if
that
could
be
improved
because,
like
we
are
looking
at
these
things
in
other
contexts,
and
even
if
it's
you
know
not
anything,
we
can
do
anything
about.
It's
still
useful
to
to
understand
where
the
bottlenecks
are.
J
J
B
C
All
great
stuff,
by
the
way,
kind
of
I
really
like
the
testing
methodology,
but
have
you
thought
about
co-simulation
between
so
for
context?
We
have
a
simulator
called
Reno
that
can
do
like
close
simulation
over
later
so
you'd
run
peripherals
in
verilator
and
you'd
run
the
core
in
a
fast
instruction
set
simulator,
which
potentially
you
could
get
pretty
good
performance
and
pretty
good
Fidelity.
J
Yeah,
this
is
something
that's
definitely
possible
and
I
would
love
to
do
it.
It's
just
a
matter
of
basically
getting
exposing
the
the
internal
HP
bus
to
all
the
peripherals
to
a
test
harness.
So
it's
it's
really
just
you
know
running
a
bunch
of
RTL
boilerplate
to
kind
of
link
that
stuff
back
and
writing.
The
actual
horror
model
should
be
pretty
easy
to
take
our
risk
five
interpreter
and
hook
it
up
to
hook
it
up
to
the
HP
bust
of
a
violator
instance.
J
In
favor
of
this,
that
said,
I'm
not
and
I
really
want
to
do
this
before,
but
now
that
we
have
the
fpga
working
I'm,
not
quite
as
excited
because
the
fpga
you
know
always
almost
as
fast
and
handles
most
of
the
stuff
we
care
about.
But
you
know
if
I
had
infinite
time.
I
would
absolutely
do
that
and
I
think
it's
a
great
a
great
solution.
F
J
No,
this
is
just
using
bravado
with
a
TCL
script,
so
we
just
have
a
TCL
script
that
just
generates
all
this
basically
interacts
with
the
Movado
garbage
or
proprietary
stuff
and
then
generates
the
Midstream
at
the
end.
And
then
you
know,
as
far
as
RCI
cares,
it's
really
just
a
black
box
that
takes
in
RTL
and
returns
to
bitstream.
F
Cool
thanks,
second
question:
it
kind
of
comes
from
a
lack
of
understanding,
my
own
lack
of
understanding,
of
how
non-psycho
accurate
simulations
run.
Could
you
go
to
the
the
hardware
model
number
one
slide,
so
it
mentions
low
Fidelity,
and
so
it's
not
clock
cycle
accurate.
So
do
you?
Do
you
ever
encounter
a
situation
where
the
emulator
actually
gives
a
result?
That
is
actually
not
accurate
to
how
the
real
system
would
run
if
it
was
running
cycle,
accurate.
J
Well,
a
great
example
where
this
would
happen
would
be
say
something
like
a
testing
a
watchdog
like
are
we
single
watch
that
timer
correctly
right,
so
the
Watchdog
timer
is
going
to
be
said
in
Cycles,
right
and
so
the
number
of
Cycles
it
takes
to
get
up
to
a
particular
point
in
the
time
you
know
the
on
the
real
Hardware
it's
going
to
be
different
than
what
it
is
similar
I
mean
it's
not
impossible.
We
could.
You
know,
obviously
people
that
are
writing.
You
know
Nintendo
emulators.
J
They
get
the
stuff
right,
but
it's
a
lot
of
effort
and
it
isn't
that
important
for
us.
You
know
you
know
we
can
have
certain
tests
that
are
testing
some
of
these
more
timing,
related
scenarios
which
there's
not
many
like
for
the
most
part.
Clipart
doesn't
care
about
time
at
all.
But
it's
you
know
we
can
we're
we're
happy
that
we
can
test
those
things
in
in
in
in
one
of
the
more
accurate
environments,
and
we
don't
necessarily
have
to
you
know
it
comes
something
like
a
watchdog.
J
J
A
Thank
you
so
much
core
for
your
great
talk
and
I
do
hope.
You
feel
better
yeah.
Thank
you
all
right.
So
our
next
talk
is
Jocko
Hoffman,
who
was
from
Western
Digital.
He
talked
is
entitled.
Omni,
extend
coherence,
scale
out
confusion
over
commodity
Fabrics.
He
is
a
member
of
the
research
organization
at
Western
Digital.
His
research
interests
include
application,
specific
accelerators
coherence
and
open
source
Hardware
design
tools.
He
holds
a
PhD
in
computer
science
from
TU
darmstadt.
K
K
F
L
L
L
We
have
released
a
memory
endpoint
for
Omnia,
extend
which
you
can
use
to
expose
any
kinds
of
memories:
XI
attached,
memories
like
hbm
or
DDR
DDR
over
ethernet,
and
that's
the
important
thing
it's
coriantly,
so
to
use
that
we
also
release
an
open
piton
to
Omni,
extend
Bridge.
So
you
can
take
your
existing
CVA
6
design
and
take
the
Koreans
past.
They
are
using
the
open,
p
term
and
translate
that
transparently
to
Omni
extend
another
thing.
L
Both
of
them
are
released
under
Apache
2.0,
completely
available
on
GitHub
and
also
has
been
used
in
on
fpga.
So
far,
and
also
in
simulation,
which
I
will
talk
about
later
so
what's
on
the
extent
for
those
of
you
who
don't
know
it,
it's
an
approach
to
get
a
single
coherence
domain
over
multiple
ethernet
attached
hosts.
L
So
you
can
just
use
your
off
yourself
Hardware,
you
don't
need
any,
for
instance,
Infinity
band
links
or
anything
it's
just
using
ethernet
to
be
as
a
widely
usable
as
possible,
and
the
whole
thing
is
based
on
Open
Standards.
So
for
one
we're
using
Thai
link
as
like
the
base,
bus
on
which
can
be
found
on
older
sci-fi
risk.
Five
trips,
for
instance,
and
then
Omni
extend,
is
a
layer
around
that
which
deals
with
the
whole
nastiness
of
ethernet
being
not
in
order
being
like
dropping
packets.
L
L
L
The
whole
thing
is
available,
as
I
said
on
GitHub.
So
if
you
want,
you
can
just
use
these
QR
codes
and
the
memory
endpoint
itself
is
designed
to
run
on
fpgas
the
open
source
release
targets,
10
gig
ethernet,
just
because
of
the
availability-
and
it's
really
easy-
you
can
just
buy
a
hundred
dollar
switch
on
Amazon.
If
you
want
to
and
get
this
running
with
relatively
cheap
fpgas.
L
So
it's
very
easy
to
use,
even
for
let's
say,
resource
constraints,
organizations
it
uses
axi
for
memory,
interfaces
which
targets
a
bunch
of
memory
controllers
which
are
available.
So
if
you're
running
sidings
fpga,
you
usually
have
like
hbm
or
ddr4
or
all
other
kinds
of
memories
and
the
endpoint
that
supports
the
whole
stack
of
tiling
operations.
L
The
other
part
of
CVA
6
is
100
Gig
compatible
and
gives
the
CVA
6
the
transparent
access
to
to
the
endpoint
memory
or
any
other
Omni
extend
compatible
memory
and,
in
addition,
I
also
have
a
software
Library,
which
gives
you
the
and
we
get
request
the
interface.
So
you
can
talk
from
the
software
to
the
endpoint,
so
you
can
play
around
with
playing
yeah
the
whole
software
stack
and
you
can
also
easily
debug
the
whole
stack
to
see
where
it
locks
up
and
so
on.
L
L
L
Omniac
sign
gives
you
the
flow
control
mechanisms,
as
I've
said
earlier,
ethernet
is
not
really
suited
well
for
for
these
kinds
of
high
reliable
protocols,
because
what
happens
on
a
CPU
if
a
message
gets
lost,
it
will
just
look
up,
usually
there's
no
recovery,
because
it's
assumed
that's
not
really
happening
or
ethernet.
We
have
to
assume
that
so
omniax10
gives
you
a
way
to
deal
with
the
out
of
order
transfers,
drop
packet
detection
and
how
to
handle
that.
L
The
memory
endpoint
is
compatible
to
103
and
what
I
call
1.1,
which
adds
some
convenience
features
onto
omniax10s
like
dropping
and
creating
connections.
So
the
system
is
less
static.
It's
completely
implemented
in
RTL,
in
this
case
blue
Speck,
which
is
sadly
a
bit
not
well
known,
but
completely
available.
Now
on
the
under
bsd3
on
GitHub
and
it's
a
highly
productive
RTL.
So
it's
not
doing
high
level
synthesis
or
anything,
but
it's
very,
very
productive
way
of
describing
Hardware
down
to
the
lowest
registers
or
whatever
the
endpoint
is
device
independent.
L
L
L
L
L
L
If
you
want
to
just
use
excitingx
design,
you
can
use
topasco,
which
packages
the
whole
thing
and
gives
you
a
bit
stream
and
makes
it
available
over
PC
Express,
and
so
that's
all
the
ethernet
stuff
up.
The
GitHub
also
contains
pre-compiled
ipx
SEC,
very
lock
releases,
so
you
can
just
plug
and
play
if
you
want
to.
L
L
L
Let's
see
if
this
video
works.
Sadly
those
here
in
the
room
might
have
a
hard
time
seeing
it
because
the
screens
are
a
bit
small,
but
I
will
try
to
stop
so
I'm
just
starting
it.
So
nothing
interesting
happened
yet
and
that's
the
script
I
provide
which
starts
on
the
top
left
the
simulation.
And
then
you
get
three
of
those
two
windows
which
are
basically
three
clients
for
this
memory
and
you
can
do
a
variety
of
reads.
L
L
So
let's
go
on
exactly
what
I'm
showing
here.
So
when
you
go
on
to
Hardware,
you
can
go.
Yeah
use
the
same
software
and
analyze
your
your
system,
Behavior
just
a
quick
overview.
How
fast
is
it
with
a
lot
of
caveats?
The
protocol
is.
The
hardware
protocol
is
not
where
it's
used
for
software,
it's
also
not
using
stuff
like
dbtk,
which
would
also
improve
performance.
L
But
that
said,
the
software
can
saturate
a
10
gig
Link
at
four
kilobytes
chunks
can
do
a
bunch
of
requests
so
up
to
2
million
requests
per
second
with
batching
and
the
average
time
per
request,
which
is
a
bit
tricky.
It's
total
request,
divided
by
runtime,
is
about
484
nanoseconds,
but
again
as
with
batching,
the
average
latency
is
much
higher
69
microseconds
in
this
case,
and
if
you
tweak
a
bit
I
got
it
down
to
3.8
microseconds,
that's
it
it's
in
software
and
Hardware.
It's
a
lot
faster
than
that.
L
Omni
extend
part
has
been
developed
by
Lewis
Communications
and
provides
you
transparent
access
to
this
memory,
for
instance,
the
memory
endpoint
and
it's
based
on
open
Pizza
on
CVA
6.
transparently
translates
these
open
python
requests
to
tilings.
So
if
you
already
have
open
Petron
in
some
project,
you
can
try
and
add
this
translation
layer
to
see
how
it
would
work
over
Omni
extend.
L
There
is
a
tightly
coupled
simulation
right
now
available
with
the
Omni
Excel
endpoint,
but
the
VF
socket
simulation
is
right
now
not
yet
available,
but
that
will
be
coming
soon.
Hopefully
how
does
it
look
like?
You
have
signings
fpga
with
the
CVA
6
in
this
case,
which
has
multiple
levels
of
caches.
In
this
case
we
have
a
level
one
data
instruction
cache
and
then
a
NOC
and
the
NOC
attaches
to
the
tiling.
L
The
network
on
ship
that
changes
to
the
tiling,
1.8
interface
encapsulated
encapsulates
those
into
the
omniax10
1.0.3
and
form
it
and
then
sends
it
out
over
in
other
open
source
tool.
That's
Lewis,
100
gigabit
Ethernet
Mac,
which
is
also
completely
open,
source
and
available
on
GitHub.
If
you
need
a
100,
Gig
Mac,
for
instance,
Fork
science,
fpgs
and
the
translation
is
also
pretty
straightforward.
It
takes
the
on
Twitter
messages
from
the
NOC
puts
it
on
five
roles,
translated
to
the
format
that
the
Mac
needs
and
sends
its
art
over
the
LMX
3
core
yeah.
L
As
I
said,
the
main
thing
that's
still
Missing
is
like
integrating
the
cvx6
into
the
socket-bit
simulation
to
make
it
even
easier,
accessible
or
better
accessible.
Apart
from
that,
it's
ready
to
experiment
and
I'm
glad.
We
also
have
some
users
with
interesting
questions
and
fruitful
conversations
and
I
hope
more
will
come
and
play
around
with
this.
H
G
L
A
All
right,
so
our
next
speaker
is
Jack
kainik,
who
is
going
to
be
chatting
about
chisel,
3
and
Beyond.
Jack
is
a
senior
staff
engineer
at
sci-fi,
where
he
works
on
digital
design
methodology.
He
is
active
in
the
open
source
Community
as
a
maintainer
of
chisel
Hardware
description,
language
and
he
holds
an
MS
in
electrical
engineering
and
computer
science
from
our
friends
across
the
bay
here.
Berkeley.
M
Okay,
so
hi
everyone,
thank
you
for
the
introduction.
Rob,
so
I
have
been
true,
so
I'll
just
kind
of
dive
in-
and
this
is
maybe
my
second
talk
in
person
since
before
the
pandemic.
So
sorry
I
think
they're
still
a
little
rusty.
It's
it's
nice
to
see
people
in
person,
but
it
is
a
different
experience
than
just
the
little
boxes
on
the
screen,
but
I'm
glad
that
all
of
you
are
here
as
well
so
good
to
see
everyone.
M
M
I
have
like
four
slides
kind
of
explaining
which
is
Liz,
and
then
the
most
of
this
is
four
chisel
users.
So
sorry,
if
you
don't
know
anything
about
it
and
that's
not
enough
of
an
introduction,
but
it's
mainly
going
to
be
about
features
and
what's
been
going
on.
So,
first
of
all
what
is
chisel,
it's
a
acronym
or
a
bit
better,
a
acronym
or
constructing
Hardware
in
scholar,
embedded
language.
M
It
is
a
domain
specific
language
where
the
domain
is
digital
design.
This
is
just
like.
Verilog
is
a
domain-specific
language
where
the
domain
is
digital
design,
just
distinguishing
it
from
general
purpose
languages
like
python,
C,
plus
or
Scala.
It
is
neither
high
level
synthesis
nor
behavioral
synthesis,
so
it
is
not
C
to
Gates.
It
is
not
skeleton
Gates,
it
is
a
program.
M
You
write
a
scholar
program
and
the
execution
of
that
program
constructs
a
hardware
graph
that
Hardware
graph
is
turned
into
verilog,
which
you
can
then
use
with
your
standard
tool
flows.
Why
it's
embedded
in
Scala
is
because
Scala
has
a
general
purpose.
Programming
language
has
a
lot
of
things
that
we
in
the
programming
languages,
communities
like
like
parameterized
types,
object-oriented,
programming,
functional
programming
and
static
typing.
These
are
things
that
are
popular.
You
know
the
previous
talk
talked
about
rust.
A
lot.
M
Russ
is
another
one
of
these
great
languages
with
these
great
features
and
there's
a
reason
why
they
are
growing
in
popularity,
and
it
is
intended
for
writing
reusable
Hardware
generators,
AKA
libraries,
the
goal
of
being
productive
in
writing
software
is
you
can
leverage
other
people's
software?
The
goal
of
all
this
open
source
work
is,
you
can
leverage
other
people's
work
and
in
order
to
do
that,
it
has
to
be
reusable,
and
our
experience
has
been
that
you
know
very
long,
especially
but
vhl
as
well.
M
It
can
be
hard
to
write
things
like
you
can
reuse
at
some
level
right.
This
is
why
we
have
bus
protocols,
but
that
is
a
very
specific
and
well-defined
level.
There
are
a
lot
of
other
places
where
you'd
like
to
get
reuse
and
it's
harder
to
do,
and
we
hope
that
different
language
trucks
can
make
it
easier.
M
M
You
know
digital
design,
we're
not
talking
about
anything
analog,
we're
not
talking
about.
You
know
all
the
kind
of
the
weirder
more
electrical
engineering
aspects
here,
it's
mainly
just
the
like
the
functional
description
of
what
you
do,
but
at
that
level,
which
you
often
write
in
verlog,
you
can
write
things
in
chisel
that
look
very
similar.
So
you
know,
let's
not
worry
too
much
about
the
syntax
here,
but
this
is
just
a
basic
module
that
has
ports.
We've
got
an
input,
we've
got
an
output,
it's
parameterized
by
a
bit
width.
M
We've
got
a
couple
registers
and
we're
just
summing
a
value
over
three
Cycles
where
we
have.
You
know
two
registers
with
the
previous
two
cycles
version
of
it
right,
and
so
this
is
a
three-point
moving
sum,
but
what
would
happen
if
you
wanted
more
than
three
points?
What
if
you
wanted
different
weighting
for
the
values
from
previous
Cycles?
What
we
really
want
is
a
generic
fir
filter
and
so
in
chisel
and
I
will
not
dive
into
this
code.
So
just
trust
me
and
you
can
go
run
this
example.
This
is
an
example
that
is
parameterized.
M
M
You
know
the
number
that
you
have
is
parameterizable,
as
well
as
their
values,
and
so
this
lets
us
completely
make
it
generic
in.
However,
many
cycles
we're
filtering
over
and
how
we're
waiting
the
different
pieces,
the
different
delayed
values-
and
so
this
allows
us
to
parameterize
by
those
with
no
loss
in
the
quality
of
the
of
the
RTL.
That's
going
to
come
out,
you
can.
You
can
do
the
exact
same
moving
sum
filter
before
with
this
more
generic
version.
M
But
what's
nice
about
the
generic
version,
is
you
can
also
have
like
a
one?
You
could
express
a
one
cycle.
Delay
filter,
that's
just
a
register,
but
you
can
do
that.
You
can
do
a
triangle
filter
with
different
impulse
responses,
and
so
the
point
of
chisel
is
allowing
you
to
write
this
sort
of
thing
where
you
can
be
as
parameterized
as
possible,
with
no
loss
in
the
quality
of
the
design.
You're
Building,
no
qor
impact
okay,
so
that
was
for
the
people
who
don't
know
what
chisel
is.
The
rest
of.
M
M
So
first
of
all,
this
has
been
the
longer
term
effort,
but
we
have
a
new
compiler
underneath
chisel,
so
chisel
emits
an
IR
called
fertile
and
then
fertile
has
a
compiler
that
compiles
it
down
to
verilog.
We
have
we
used
to
have
our
our
compiler
implemented
in
Scala.
Similarly
to
how
chisel
is
implemented.
Now
it
has
been
re-implemented
with
mlir.
Mlir
is
a
kind
of
a
generalization
of
llvm,
it's
part
of
lldm
and
it's
for
writing
custom.
M
Compilers
importantly,
this
uses
it's
much
faster
and
uses
a
lot
less
memory,
that's
like
a
great
thing,
but
the
real
goal
of
it
with
those
benefits
aside,
because
those
are
very
nice,
it's
really
more
about
more
rapid
feature
development.
So
mlr
stands
for
multi-level
intermediate
representation.
I
think
it
was
originally
machine,
learning
and
then
a
very
convenient
re-backronyming
to
multi-level,
and
it
allows
for
coexistence
of
multiple
IRS.
M
Now
part
of
this
part
of
this
move
to
a
new
compiler.
This
is
a
common
issue.
When
you
have
large
infrastructural
changes,
a
lot
of
older
features,
kind
of
in
order
to
make
development
easier,
we
had
to
drop
some
of
our
older
features,
so
the
old
chisel
2
compatibility
layer
is
now
gone.
Fixed,
Point
interval
types
are
gone,
I'll
talk
about
fixed
point
in
a
second
and
the
old
scholar,
fertile
compiler
apis,
which
were
nice
and
I
use
them.
M
A
lot
are
no
longer
there
either,
but
the
benefit
of
this
is
that
the
smaller
public
API
surface
is
making
development
a
lot
easier
and
you're
going
to
see
some
we're.
Finally
starting
to
reap
the
benefits
of
some
of
that
pain.
I'll.
Note
that
there's
ongoing
work
on
on
fixed
point
to
make
it
a
library,
so
I
recently
saw
the
library
work
here.
I
think
there's
some
improvements
we
should
make,
but
it's
not
fully
gone.
It's
just
gone
as
like
a
primitive,
so
it's
just
some
other
minor
organizational
changes.
M
M
We've
changed
our
versioning
scheme
from
kind
of
a
Haskell
style
PVP,
where
the
major
version
was
3.6.
Like
the
point.
The
sixth
part
was
part
of
the
major
version
which
is
now
that
everyone
has
been
December
confuses
people,
so
we
have
moved
over
to
now.
It
is
chisel
5
and
then
chisel
6
for
don't
worry
about
it.
It's
kind
of
reserved
for
possible
future
use
and
chisel
5
has
been
released
in
chisel.
6
is
on
the
verge
of
being
released,
which
has
made
my
life
a
lot
easier
for
doing
releases.
M
M
Okay.
So
now
what's
new
as
of
6.0.0
M2,
that
m
is
Milestone
two.
This
is
just
a
way
of
like
marking
things
before
we're
willing
to
call
it
6.0,
but
I
will
say
that
we're
very
close
to
the
actual
6.0
release,
and
most
of
this
is
from
like
the
last
three
to
six
months,
so
we
have
much
better
Source
locators.
So
this
example
doesn't
really
matter
too
much.
M
But
what
I'm
trying
to
show
is
that
this
trait
bar
is
in
a
file
called
file.spella
in
a
certain
directory
and
class
example
is
also
in
a
file
called
file.bar,
but
in
a
different
directory.
It's
very
common
that
you
end
up
with
the
same
name
like
people
really
like
the
name,
utils,
that's
a
common
one
and
there's
other
names
that
just
come
up
all
the
time
and
when
you
have
a
large
code
base
with
you
know,
hundreds
or
thousands
of
files.
M
You
end
up
with
Source
locators,
and
you
look
at
this
and
you're
like
okay
file
about
scholar
and
file.scala,
which
one
did
it
come
from.
I
actually
came
up
with,
like
nice,
little
grep
tricks
where
you
could
like
check.
If
that
thing
existed,
and
it
would
tell
you
that's
the
right
one,
but
in
reality
it's
better
to
just
have
a
source
locator
that
gives
you
a
more
descriptive
path
and
so
the
new
source
locators
do
that
you'll
also
notice.
We
have
Source
locators
on
ports
which
we
didn't
have
in
the
past.
M
That
was
true
as
of
chisel
3.6,
which
was
released
in
April
I,
think,
but
one
of
the
best
parts
about
those
new
source
locators
is
if
it's
unambiguous.
What
something
points
to
now
the
tooling
can
use
that
for
error
messages,
and
so
in
this
example,
I
have.
This
is
an
out
of
boundance
index
bar
is
an
8-bit
value
and
I'm
asking
for
bit
eight
but
we're
computer
scientists.
We
start
counting
at
zero,
Oops
I
messed
up
off
by
one
as
usual.
M
M
This
is
such
a
small
thing
and
it
wasn't
even
that
hard
to
implement,
but
it's
amazing
how
much
nicer
things
feel
when
you
get
this
kind
of
error,
reporting
and
also
in
the
you
know,
that
was
an
error
message
from
chisel
itself,
but
we
have
a
compiler
underneath
it
and
that
compiler
has
its
own
error
messages.
Sometimes
because
there's
certain
things
we
can't
check,
and
so
this
is
an
example
where
this
wire
is
not
fully
connected
under
all
circumstances.
M
And
so
you
get
an
error
saying
it's
not,
and
then
you
get
this
other
representation
that
doesn't
look
like
the
Chisel.
You
wrote,
Because,
that's
what's
the
compiler
seeing
and
so
now,
with
virtual
and
these
better
Source
locators.
It
will
point
you
to
your
original
chisel
to
tell
you
where
you
messed
up,
which
is
very
handy.
M
M
Sorry,
I
use
those
interchangeably
but
they're.
The
same
thing
virtual
is
a
part
of
the
circuit
project
that
was,
for
this
Benchmark
3.2
times
faster
for
combined
speed
up
of
two
and
a
half
X
and
memory
use.
Similar
benefits.
Now
Memory
use
is
more
of
a
Max
than
an
additive
thing,
so
you
can
see
that
chisels
using
18
less
memory,
but
in
this
particular
Benchmark
furtool
uses
72
percent,
less
memory,
and
so
the
overall
memory
use
has
gone
down
quite
a
bit
now,
a
better
benchmarking.
M
Chisel
is
kind
of
hard
because,
as
it
evolves,
my
the
designs
I
would
use
the
Benchmark.
It
also
evolve,
and
so
I
have
to
like
back
Port
things
to
do
benchmarking
and
that's
why
it's
kind
of
annoying,
but
it's
easier
with
with
benchmarking,
just
fertile
because
it
has
a
spec,
and
so
it's
it's
much
easier
to
compare
across
versions.
M
Here's
some
benchmarks
from
my
my
friends
on
the
circuit
project,
where
for
a
small,
microcontroller
kind
of
a
larger
in
order,
PPU
and
then
a
large
out
of
order
CPU,
you
can
see
that
the
runtime
of
circuit
was
from
6
to
11x
faster,
which
is
huge
right.
That's
that's
much
much
better
and
in
memory
use
fairly
similar
on
the
microcontroller
14x
up
to
the
outer
border.
Cpu
4.4
X,
like
all
this,
this
reduced
memory
use
is
incredibly
helpful
for
our
you
know.
M
Your
CI
runs
on
your
servers
and
all
of
that
all
right,
so
performance
is
great.
But
that's
not
the
point.
The
point
is
all
the
new
features.
So
that's
what
I'm
going
to
talk
about
constant
types
are
kind
of
a
small
one,
but
still
useful
so
prior
to
Chisel.
6
and
again,
206
isn't
quite
out
yet,
but
you
can
use
the
Milestone
to
release
async
reset
values
had
to
be
literals,
and
these
checks
were
kind
of
haphazard.
It's
somewhat
complicated
to
implement
something
that
will
you
know
when
you
base
your
functionality
on
optimizations.
M
It
leads
to
weird
behavior
and
and
hard
to
understand
Behavior.
So
these
constant
types
give
us
a
more
principled
way
to
deal
with
that,
such
that
it's
very
predictable
and
it
also
supports
new
use
cases.
For
example,
how
do
you
have
an
async
reset
register
that
is
reset
buy
a
strap
pin?
You
could,
of
course,
just
allow
it,
but
how
do
you
check
that
people
are
doing
it
right?
Well,
the
way
we
do
that
is
with
these
constant
types,
and
so
here's
an
example
of
the
old
error
message
in
the
past.
M
It's
like
this
looks
like
it
should
work,
but
it's
not
known
to
the
compiler
that
some
is
literal
because
you
could
assign
a
non-literal
later,
and
so.
Instead,
if
you
use
this
modifier
for
your
types
called
const
now
the
compiler
knows
it's
a
constant
and
it
will
check
it,
and
so
you
get
much
better
Behavior
here
and
there's
also
possible
future
integration
with
physical
design
right
because
why
is
it
dangerous
to
reset
something
asynchronously
from
a
port?
Well,
because
if
that
value
can
change
there
at
certain
times,
you
can
have
physical
issues
right.
M
M
M
There
were
ways
to
do:
verilog,
xmrs
for
verification
or
whatever
or
physical
design
in
your
chisel,
but
it
required
like
a
lot
of
custom
user
extensions
to
the
the
Scala
photo
compiler
and
really,
as
a
user.
You
don't
care
about
that.
You
just
want
a
guarantee
and
a
mental
model
for
how
you
can
lower
from
chisel
to
verilog
and
how
you
can
use
it
with
your
system,
parallel,
UVM
verification
flow,
for
example,
and
so
this
is
now
at
the
Chisel
level.
We
have
a
first
class
feature
to
capture
these
use
cases.
M
This
isn't
that
interesting
of
an
example.
It's
just
showing
that
you
can
declare
ports
that
are
what
we
call
probe
ports,
which
is
something
that
you
can
read
from
the
outside
and
rather
than
lowering
to
an
actual
Port,
it
will
lower
to
a
barrel
log
XMR-
and
these
read
write
ports
are,
are
these
are
xmrs
that
can
be
forced
and
that's
really
important,
because
for
any
of
you,
who've
done
a
lot
of
system
analog
verification.
The
semantics
of
force
can
be
surprising.
M
We've
added
are
intrinsics,
so
I
pre
I
mentioned
that
you
could
extend
the
Scala
fertile
compiler
with
annotations
and
custom
Transformations,
but
this
was
arguably
too
flexible,
like
you
could
do
almost
anything,
and
that
makes
composition
difficult
and
it
also
didn't
really
support.
Custom
system
error,
login
Mission,
which
was
really
problematic
for
a
lot
of
the
extensions
that
people
wanted
to
do.
Intrinsics
are
like
reeling
that
back
into
something
a
lot
more
restricted,
but
because
of
the
way
mlir
works
and
therefore
how
circuit
and
virtual
work.
M
It's
really
easy
to
do.
Really.
Nice
custom
system,
dialogue,
emission
and
this
it
gives
us
a
nice
platform
for
taking
some
of
these
more
ad
hoc
extensions
that
you
might
have
seen
in
rocket
ship
and
turning
them
into
like
first
or
at
least
supported
features
with
like
a
defined
API
as
part
of
chisel.
M
Some
simple
examples
that
are
already
there,
but
there
are
more
coming,
are
clock
Gates,
that's,
obviously
a
really
important
thing,
plus
art
readers
or
plus
args,
which
are
obviously
useful
in
in
simulation,
a
way
to
check
if
something
is
X
which
I'll
just
kind
of
leave
at
that.
But
a
really
big
one
that
has
already
been
implemented
now
is
very
exciting,
which
is
temporal
properties.
So
this
is
something
people
have
asked
for
for
years.
M
You
might
think
of
you
might
be
thinking
of
this
as
SVA
or
system
barlog
assertions,
but
people
want
the
ability
to
describe
more
complicated
temporal
properties
and
not
just
immediate,
like
a
equals
B
they
want
well
I'll
show
you
they
want
that
a
implies
B,
followed
by
C
right
and
things
like
that.
This
is
like
the
you
know,
industry
standard
in
verification,
especially
in
formal
verification,
and
so
this
API
is
built
on
top
of
those
intrinsics
which
allows
it
to
happen
faster.
M
Eventually,
we
will
turn
these
into
first
class
IR
features,
but
the
intrinsics
give
us
kind
of
a
a
way
to
hoist
ourselves
to
that
level.
Much
faster.
This
took
one
of
my
colleagues
only
a
few
weeks
to
implement
on
his
own,
maybe
like
two
or
three
weeks,
and
so
there's
some
tweaks
that
will
probably
be
likely
before
we
release
6.0.
But
this
code
is
code
that
I
ran
yesterday.
It
works.
You
can
generate
your
system
very
log
assertions,
it's
very
exciting.
M
Another
thing
that
I
I
originally
had
seven
slides
on
this,
but
in
the
interest
of
time
I
turned
it
into
one.
I
could
talk
about
these
types
of
semantics
all
day.
It
would
bore
everyone
in
this
room,
so
I'll
just
kind
of
gloss
over
it,
but
the
connection,
semantics
and
chisel
in
the
past
were
way
too
permissive
until
two
years
ago.
It
didn't
care
if
the
types
matched
at
all
nominal
hyping,
meaning
if
you
name
a
type
like
this,
is
a
class
named
Foo.
M
Then
you
know
it
didn't
require
that,
though,
that
you
could
only
connect
foods
to
Foods
structural
typing
is
like
are
the
actual
fields
of
this
type?
The
same
it
didn't
require
that
either
and
it
didn't
require
the
width
to
match,
didn't
require
much
it
just
kind
of
did
something.
Chisel
3
made
this
a
bit
stricter.
The
fields
had
to
match,
but
being
that
rigid
is
also
problematic,
because
if
you
have
two
types
you
want
to
connect
and
their
fields
match
99,
but
one
doesn't
match.
What
do
you
do?
M
That
rigidity
then
causes
you
to
blast
out
the
connection
and
you've
thrown
away
the
safety
anyway,
so
not
actually
helpful
and
so
and
it
also
it's
still
just
happily
deal
with
mismatch
switch
with,
which
is
not
great.
So
we
have
new
operators
starting
in
chisel
3.6
that
checked
the
nominal
types
must
match,
but
you
can
easily
opt
out.
It
checks
that
the
structural
types
the
fields
match,
if
you
don't
have
matching
nominal
types,
but
you
can
wave
those
fields
and
it
checks
that
the
widths
must
match.
But
you
can.
M
The
term
is
squeeze
that's
the
API,
but
you
can
say
yes,
this
width
doesn't
need
to
match,
but
all
the
rest
do
so
that
gives
you
the
rigidity
of
when
you
connect
things.
It
checks
everything
for
you,
but
if
you
have,
if
you
have
a
need
to
waive
just
one
small
part
of
it,
you
can
do
that
and
it's
really
useful.
It's
been
very
successful
for
us
at
sci-fi
at
least,
and
we're
planning
to
migrate
the
older
operators
in
newer
versions,
all
right.
So
that
was
everything
that
is
already
there.
M
M
This
may
come
as
a
big
surprise,
but
even
these
expensive
proprietary
tools,
don't
always
do
as
good
of
a
job,
as
you
think,
and
the
optimizations
we
run
in
for
a
tool
on
well,
let
me
show
you
the
the
current
lowered
output,
the
optimizations
we
run
on
the
scalarized
output
actually
does
improve
the
QR
you
get
out.
I
think
we
need
to
do
more
of
a
study
on
that,
so
I'm
going
to
kind
of
hand
wave
a
bit,
but
we
have
noticed
that
you,
when
you
turn
this
on,
you
can
get
worse
QR.
M
That
being
said,
this
example
just
shows
something
very
simple:
we've
got
an
input,
Vector
an
index
and
an
output
and
we're
just
dynamically
indexing.
It
right
common,
like
array,
access,
if
you
will
and
as
in
each
of
the
users
know,
chisel,
will
scalarize
that
Vector
into
individual
pieces
and
then,
of
course,
this
output
from
fur
tool
is
already
better
than
what
sfc
used
to
do.
It
used
to
kind
of
unroll,
muxes,
which
looked
really
ugly,
even
though
it
gave
you
good
results.
People
didn't
like
how
it
looked
for
a
tools
doing
something
better.
M
M
I
talked
I
talked
a
bit
about
Connections
and
so
there's
other
aspects
of
width
safety
that
have
been
weaker
than
they
should
be
in
chisel
in
the
past.
These
are
kind
of
famous
warts
that
we're
fixing,
and
so
here's
an
example
where
I
have
a
dynamic
bit
selection,
so
I
have
an
8-bit
value
and
I
can
select
a
bit
using
four
bits
or
two
bits
which
are
wrong.
M
You
only
need
three
bits,
and
so
in
both
of
those
cases,
you'll
get
a
warning
that
your
width
is
too
large
or
too
small,
and
so
we're
rolling
out
more
of
these
warnings
in
order
to
kind
of
tighten
up
the
semantics
around
widths.
Now,
one
really
big
problem
with
rolling
out
new
warnings
is
for
certain
things.
M
You
might
get
a
lot
of
them,
and
so
this
is
a
little
bit
of
a
scary
example,
because
but
the
real
numbers
that
I
have
internally
are
over
a
hundred
for
some
of
these
new
warnings,
like
100
warnings
and
I,
talked
about
those
great
new
warnings
where
you
get
the
warning
the
line
and
the
carrot.
So
that's
three
lines
per
warning
right.
So
if
you
had
241
warnings,
that's
700
lines
of
warnings
right,
which
is
almost
worthless,
because
you
know
you're
not
going
to
fix
this.
M
Many
things
in
one
go
and
you're
going
to
just
try
to
make
more
progress,
and
then
one
of
your
co-workers
is
going
to
add
a
new
one
and
no
one's
going
to
notice
right
and
that's
like
a
huge
problem.
You
want
like
really.
You
want
warnings
as
errors,
but
if
you
have
hundreds
of
them
you
can't
like
in
in
GCC,
you
can't
turn
on
warnings
as
errors.
M
When
you
have
too
many
warnings
right
and
it
makes
it
really
difficult
to
kind
of
manage
that
so
there's
a
feature
in
Scala
itself
that
worked
basically
deriving
a
similar
feature
in
chisel,
where
you
can
have
more
focused
warning
configuration.
This
is
currently
an
open
PR,
so
the
actual
syntax
is
not
fully
specified
yet.
But
what
I'm
getting
at
here
is
you
can
pick
by
ID.
M
Another
thing
that's
pretty
exciting,
and
this
is
very
much
Half
Baked.
So
don't
don't
hold
me
to
the
syntax,
our
groups.
This
is
a
way
of
kind
of
grouping.
Non-Functional
statements
you
can
think
about
this
as,
like
the
traditional
methodology
of
having
a
module
that
you
bind
in
for
your
verification.
M
And
so
these
groups
can
then
be
optionally
included
in
simulation,
and
this
will
and
a
really
nice
feature
of
these
groups
as
they're
currently
specified.
Is
they
allow
nesting
and
hierarchical
access?
So
if
any
of
you've
done
a
more
traditional
system,
bear
log
verification
methodology
where
you
put
your
assertions
in
a
module
and
you
bind
it
in
it-
is
outside
of
the
verilog
spec
to
have
a
nested
bind
to
have
a
bind
that
you
bind
into
your
bind,
that's
not
allowed.
M
It
is
allowed
by
varilator
in
at
least
one
proprietary
tool,
but
rejected
by
the
other
one,
and
so
you
know
one
nice
thing
about
a
compiler
is
that
we
can
support
that
API
and
then
lower
it
to
something
that
works
according
to
the
parallelog
spec
and
so,
and
also
if
you
have
like
some
hierarchy
of
modules
say
here:
I
have
Foo
instantiating
bar
in
system,
Barrel
log.
If
you
have
two
bind
modules
that
you're
binding
into
each
of
those
they
you
can't
talk
across
those
modules.
There's
no
way
to
communicate.
M
Like
you
have
the
sideband
collateral
and
the
sideband
collateral
can't
talk
well
with
these
groups.
It
can
okay,
I'm
almost
done
so,
mostly
okay
timing
and
so
here
I'm,
showing
that
you
can
have
your
design.
You
can
have
this
optional
group
that
I've
called
assertions,
and
you
can
do
something
with
it.
It
doesn't
really
matter
what
the
logic
is:
I'm,
delaying
it
by
a
cycle,
and
then
you
can
in
the
parent
module.
M
M
That's
you
can
keep
separate
from
your
your
system
for
all
you
emit,
which
is
really
important
for
traditional
flows
for
synthesis
or
verification,
and
it
lowers
it
generates
things
such
that
it
just
automatically
handles
the
fact
that
some
of
these
constructs
are
not
directly
supported
by
verilog,
and
so
you
can
lower
them
to
cross
model,
references
and
stuff
and
another
thing
that
I'll
just
kind
of
gloss
over,
because
this
is
very
much
a
work
in
progress.
Our
properties,
which
are,
is
a
new
type
system
for
information
about
the
generated
Hardware.
M
This
is
for
for
a
lot
of
things
like
you
know.
What
is
the
the
latency
of
your
interconnect
that
may
be
a
derived
parameter
based
on
how
the
generator
works
or
your
address
map,
and
these
are
things
that
you
need
for
software
verification,
physical
design,
whatever
and
then.
Finally,
the
native
dependency
on
Virtual
has
made
chisel
installation
a
bit
more
annoying.
So
we
have
some
work.
M
That's
almost
finished
where
we
will
co-distribute
virtual
with
chisel
such
that
when
you,
this
is
kind
of
obvious,
but
it's
you
know:
Distributing
Scala
things
has
a
very
convenient
process
for
it
and
then
Distributing
native
binaries
has
its
own
entirely
different
process,
and
so
trying
to
mix
those
worlds
can
be
complicated.
So
we've
come
up
with
a
system
to
make
them
distribute
together
and
there's
also
now
windows
binaries
for
my
windows,
users,
and
if
you
have
other
platforms
that
we're
not
currently
supporting,
please
come
help
us
out.
M
M
I,
don't
know
how
much
I
can
say
at
this
point,
but
there
is.
There
are
ongoing
discussions
on
that.
So
the
simple
answer
is
today:
you
have
the
source
locator.
So
if
you
find
an
issue
with
a
signal,
it's
it's
pretty
easy
to
see
what
it
comes
from,
but
more
integrated
support
with
the
tools
there
are
discussions.
That's
all
I
can
say.
G
F
M
M
M
M
Yeah
so
fortunately,
fertile
already
had
a
speck,
and
so
implementing
the
spec
was
pretty
easy.
As
with
most
things,
you
know
that
first
90
took
almost
no
time
and
then
I
talked
about
all
those
custom,
extensions
that
we
had.
That
was
by
far
the
hardest
part
and
that's
part
of
the
motivation
for
why
we're
just
like
we're
not
doing
it
that
way
anymore.
M
If
you
want
like
a
lot
of
these
features,
you're
seeing
are
more
more
principled
and
specified
versions
of
things
that
we
at
sci-fi
kind
of
already
had
in
ad
hoc
forms
and
the
reason
that
they
weren't
public
was
not
because
they
were
Secret
Sauce,
but
because
the
implementation
was
bad
and
you
don't
want
other
people
relying
on
your
bad
code,
because
then
you
have
to
fix
it,
and
so
a
lot
of
this.
A
lot
of
the
effort,
the
hard
part
has
been
okay.
The
basic
spec
that
supports
Hardware
is
like
really
easy.
H
M
So
fertile
and
fertile
is
our
intermediate
representation.
It
is,
there
is
a
fertile
spec
on
the
chips
Alliance
repo
and
whereas
in
the
past,
like
all
these
custom,
extensions
via
annotations
were
like
not
in
the
spec,
because
they
were
custom
extensions.
All
these
features
I'm
talking
about
are
in
the
fertile
spec.
So
if
you
want
to
see
it's,
it
was
basically
stagnant
for
like
three
years
and
it
is
evolving
pretty
fast.
Now
so
I
recommend
checking
it
out
and
you
can
totally
generate
it
from
whatever.
B
J
A
Right
so
our
next
speaker
will
be
Mikhail
mosif
and
he
is
a
senior
staff
engineer
with
Intel
Labs
he's
working
in
Hardware
design
and
verification
automation
tools.
He
is
a
maintainer
of
the
Intel
compiler
persistency
and
participates
in
system
C
work
group.
He
has
a
PHD
in
computer
science,
so
McHale.
The
four
is
yours.
D
So
my
talk
today
is
about
a
single
Source
library
for
digital
design
and
virtual
prototyping.
Let
me
start
with
a
problem
statement,
so
normal
in
conventional
Hardware
design
flow
beside
Hardware
design,
RTL
sources.
There
are
some
another
models
like
pre-silicon
models
used
for
architecture,
exploration
or
performance
evaluation.
D
D
These
systemc
design
can
be
translated
into
synthesizable
system
data
log
with
Intel
compiler
for
systemc,
which
is
open
source
tool,
and
this
system
very
local,
synthesizable
and
finally,
silicon
can
be
can
be
created
from
from
it
to
be
used
in
pre-silicon
models
and
virtual
models.
The
systemc
design
just
taken
as
a
C
plus
plus
source
and
compile
it
with
a
normal,
C
plus
plus
compiler.
D
So
let
me
introduce
a
single
Source
Library.
It's
a
library
of
high
level
communication
channels
which
supports
two
modes.
The
first
mode
is
cycle,
accurate,
which
is
a
normal
cycle,
accurate
mode
with
clock
reset
and
all
the
details
and
simulation
and
second
mode
is
a
fast
simulation
mode.
There
is
a
Knock
Lock,
no
reset
and
all
the
simulation
is
request
or
data
driven,
as
that
leads
to
no
extra
process
activation
until
there
is
really
the
process.
Functionality
is
really
needed.
D
D
There
are
also
some
additional
channels
which
are
not
open,
sourceed,
yet
so
I
skipped
my
detailed
descriptions,
each
of
the
channels
support
to
motorcycle
accurate
mode
and
for
simulation
mode
and
each
of
the
channel
implements
interfaces,
for
example,
City
put
interface,
ticket
interface
and
others.
These
interfaces
looks
very
similar
to
tlm
1.0
interfaces.
D
Let's
briefly
discuss
the
interface
details
so
put
interface,
allows
a
process
to
put
some
request
or
some
data
into
a
channel,
and
there
is
a
radio
function
to
know
that
the
channel
is
really
related
to
the
next
request.
So
of
course,
Channel
could
be
reset
and
cleared
and
there
are
non-blocking
and
Main
block
input,
a
function
to
be
used
in
method
and
thread
process
get
interface
looks
very
similar,
but
instead
of
red
there
is
a
request
function
to
know.
D
So,
let's
discuss
the
typical
use
cases,
as
I
said,
initiator
and
Target
Houston
player
to
connect
to
processes.
One
process
put
some
data
into
initiator
processing
module,
one
processing
module
two
get
some
data
from
the
Target
and
of
course
this
is
the
same
data
which
is
which
is
sent
by
initiator
to
Target.
D
Fifa
can
be
used
as
convenient
buffer
just
to
store
a
number
of
data
chunks
in
it
so
signal
input.
Output
ports
can
be
used
as
a
normal
signal
and
in
input
output.
Ports
of
system
scene
about
FIFA
also
can
be
used
as
convenient
inter-process
communication
mechanism
between
two
processes
inside
of
one
module.
Although
there
are
on
dipport
it's
a
baseboard
for
implementation
of
Amber,
Port,
meister
and
subordinate
port
or
ocp
port
or
other
ports.
D
D
So
there
is
a
very
simple
piece
of
code:
a
system
C
code
with
module,
a
module
B
in
module
a
we
have
initiator
and
a
random
process
which
generates
some
random
numbers
and
put
random
numbers
into
the
initiator
in
module
B.
We
have
Target,
and
this
target
is
used
in
chat
products
as
these
checkprots
gets.
It
gets
a
request
from
the
target
checks
if
it's,
if
it
equals
to
42
and
it's
I
sort
of
the
inter.
D
So
here
a
random
process
is
thread
process.
So
there
is
a
reset
section
where
initiator
is
a
reset
and
while
loop,
where
all
the
all
the
functionalities
implemented.
So
here
you
can
see
my
block
input,
so
that
means,
if
initiator,
is
radius,
there
is
no
delay,
but
if
it's
not
ready,
there
is
a
wait
until
it's
ready
inside
of
this
block.
Inside
of
this,
my
blog
input
function
so
in
check
browsers,
also
reset
get,
which
is
just
initialized,
Target,
outputs
and
the
logic.
D
D
D
Let
me
give
you
a
simple
example
here:
in
this
example,
we
have
two
processes,
a
producer
and
consumer
and
producer.
Both
of
the
processes
are
combinational
processes,
method,
processors,
and
there
is
one
file
which
is
used
to
communicate
between
these
two
processes.
As
you
can
see,
size
of
the
FIFA
is
two,
so
we
can
store
two
two
requests
in
in
this
file,
so
in
producer
we
do
reset
put,
and
if
there
is
some
condition
and
fireplace
radium,
we
produce
next
value
and
put
into
the
five
and
in
consumer
process.
D
D
D
D
So
a
register,
as
I
said
it
used
to
extend
at
the
process
combinational
process
of
this
state.
So
normally
when
we
need
some
asynchronous
graduation,
so
means
need
to
take
and
process
some
input
or
data
without
a
latency.
We
are
using
method
process
and
if
we
need
to
have
state
for
this
process,
We
additionally
use
a
thread
process
to
avoid
extra
process.
We
just
add
the
register.
In
our
case,
it's
a
counter,
and
this
counter
here
is
used
to
count
number
of
input
request
taken
from
the
target
so
counter.
D
D
D
So
here
we
have
a
child
model
with
Target
and
in
this
target
administrator,
and
we
would
like
to
promote
this
into
the
Target
and
initiator
to
parent
module,
be
connected
to
some
initiator
and
Target
in
the
test
bench
So.
To
avoid
some
replication
of
initiator
Target,
we
just
have
a
support
which
is
internally
implemented
as
a
pointer
and
bound
a
support
to
real
initiator
and
Target
inside
of
the
child
mode.
D
Really,
there
are
lots
of
feature
I
avoid
to
discuss
every
feature
just
mentioned.
One
of
them,
C,
plus
plus
structures
or
classes,
could
be
used
as
a
channel
payload
for
signal
for
initiator
for
Target
for
python
to
support
that
to
support
that
we
need
to
satisfy
some
requirements
from
systemc.
First
of
all,
such
a
structures
should
have
a
default
Constructor
and
comparison
operator,
although
it
should
have
operated
less
for
output
stream
and
easy
Trace.
D
D
D
The
main
difference
is
that
this
library
is
intended
to
be
used
with
catapult
chos2
and
only
visit,
and
this
tool
is
a
commercial
one.
Our
library
is
can
be
used
together
with
Intel
compiler
for
systemc,
which
is
open
source.
Also,
this
Library
much
lip
has
some
limitation.
It
can
be
used
in
a
clock
threads
only
and
because
of
that,
a
latency
of
every
module
could
be
one
or
more.
So
we
cannot
create
your
combination
of
module.
D
Okay
experience
this
single
Source
library
has
been
created
about
half
of
years
ago
and
open
sourced
just
a
few
months
ago,
but
we
already
have
about
100
designs
with
these
channels,
and
currently
we
have
one
big
internal
project
twin
tool,
which
is
using
this
single
Source
Library.
Here.
I
just
provide
a
few
examples
to
show
how
using
the
single
Source
Library
can
use
the
total
number
of
lines
of
codes
and
what
is
the
simulation
speed
up
for
a
fast
simulation
mode
and
comparison?
This
cycle,
accurate
model.
D
F
K
D
And
using
these,
it
was
not
even
shows
that
it
increases
design,
efficiency
and
design.
Time
can
be
reduced
about
two
times
single
Source
Library
channels
are
synthesis
and
distributed
as
a
part
of
this
file,
and
you
can
find
the
library
and
these
toolians
GitHub
repa,
which
is
showed
here.
So
thank
you
for
your
attention.
E
A
H
A
D
A
D
No,
it's
quite
a
new
technology
and
I,
of
course,
I'm
promoting
this
technology
inside
of
and
outside
the
window.
So,
yes,
we
have
multiple
projects
with
the
Ingle
compiler
of
system,
C
and
number
of
silicons
already
alive,
developed
residential
compiler
for
system
C,
but
most
of
the
project,
of
course,
some
big
course
some
other
projects
they
do
not
use.
B
D
A
Last
speaker
this
morning
is
melissin
from
University
of
Michigan
he's
a
researcher
there
and
works
actively
in
the
analog
community
and
in
particular,
open
fast
suck
and
I've.
Had
the
pleasure
of
working
with
many
for
over
two
plus
years
now,
I
guess
right
so
chairing
the
and
many
children
chairs.
Excuse
me
our
analog
work
group,
so
thank
you
for
making
the
time
to
come.
Thank.
H
A
I
All
right,
thanks
for
the
intro
Rob,
my
talk
is
about
building
confidence
in
open
IC
design
using
openfa
stock.
So
there
are
so
many
reasons
why
open
design
is
a
must.
Today
we
need
more
chips,
which
means
more
open
source,
Eda
software,
more
collaboration
and
a
drastic
shift
in
our
mindset
as
designers
or
Hardware
designers.
I
The
way
to
do
this,
obviously,
is
by
lowering
costs
and
barrier
to
to
design,
but
the
current
status
call
in
the
chip
industry
is
limiting
and
we
have
to
go
through
a
bit
of
History
to
understand
why?
So,
let's
take
an
example
on
software
development
in
the
90s,
this
is
what
it
looked
like.
We
had
in-house
compilers
lots
of
incompatibilities
and
a
lack
of
standardization,
so
everything
was
always
dependent.
I
Relics
of
the
90s
is
a
common
way
to
refer
to
these
absurd
issues.
We
had
back
then
and
there's
a
whole
bunch
of
funny
Vlogs
about
it,
but
more
seriously.
This
reminds
us
of
something
today
to
me.
It
definitely
looks
like
IC
design
today,
where,
of
course,
we
have
access
to
much
more
computing
power,
but
in
general
the
semiconductor
companies
have
in-house
tools.
I
Now.
Imagine
if
you
ask
new
generations
of
students
with
an
already
software
oriented
mindset
who
might
have
less
motivation
to
sit
and
debug
where
their
tool
is
crashing
after
TDS
placing
route
run
without
actually
being
able
to
look
into
the
source
code,
I'm,
not
sure
if
this
may
still
make
chip
design
as
exciting
and
the
usual
comment
is.
We
are
fighting
the
tool
instead
of
learning
chip
design,
so
at
one
of
the
major
tech
companies
where
they
have
an
army
of
software
Engineers
like
Google.
I
Here,
the
ratio
to
Hardware
Engineers
is
very
imbalanced,
which
is
actually
very
symptomatic
of
the
overall
U.S
Workforce
situation,
and
also
new
students,
career
choices
based
on
the
career
Explorer
website.
We
have
about
70
000
in
Hardware
engineers
in
the
United
States
and
which
is
growing
by
five
percent
in
a
in
a
decade.
While
we
have
a
10
times
more
software
Engineers,
which
is
supposed
to
grow
by
30
percent
in
the
same
time
span.
I
E
I
Who's
19
years
old,
undergrad
student
from
computer
engineering
department,
so
he's
more
software
friendly
he
reached
out
and
wanted
to
work
on
to
do
some
work
around
open
at
Bay
sock
and
he
ended
up
winning
at
the
Issac
code,
the
chip,
notebook
competition
and
presented
his
work
on
openfa
stock,
digital
ldo
and
the
reason
he
was
able
to
do
that
to
do.
That
is
because
he
was
working
with
software
rather
than
working
with
transistors.
I
That's
a
great
demonstration
of
having
more
software
minded
students
to
do
hardware
and
software,
so
at
companies
at
software
companies,
development
is
within
hours,
which
means
deployment
of
new
products
could
be
done
in
weeks,
while
in
ic
design
it
will.
It
is
well
accepted
to
talk
about
months
and
years
during
project
planning
and
I'm,
not
even
mentioning
the
risk
and
costs
here
now.
I
In
fact,
we,
if
you
talk
to
our
software
colleagues
and
even
smaller
community
of
Eda
friends,
it
sounds
like
Hardware.
Development
is
broken,
that's
how
they
feel
about
it,
and
is
this
the
case,
though?
The
answer
is
no.
We
still
make
a
very
complicated
chips,
but
we
can
we
do
better,
yes,
and
it
is
about
time
to
find
to
fight
in
windmills
and
democratize
ship
design.
I
So
this
is
my
last
for
my
motivation
here,
but
another
angle
is
costs
right.
Chips
are
very
expensive
to
make.
What
we
really
need
to
understand
here
is
when
it
comes
to
fabricating
a
new
chip.
The
cost
of
building
up
a
new
integrated
circuit
from
scratch
at
the
wafer
level
can
be
very
high.
Licensing
IP
is
expensive,
very
in
for
custom
designs
and
Ada.
Software
can
be
very
costly
and
j-pass
masks
can
vary
from
widely
from
a
few
thousands
to
millions
of
dollars.
I
This
year
at
the
issaccc
planner
session,
it
was
discussed
that
it
is
required
about
18
times
supported
designed
from
65
nanometer
to
to
a
500,
nanometer
node
and
it
to
build
a
design
at
five
nanometer.
It
was
about
half
a
billion
which
is
crazy
when
you
think
about
it.
So
in
2020
with
my
co-author
here,
Team
Ansel,
we
published
this
work
about
enabling
open
design
with
the
release
of
the
open
source
pdk,
as
you
may
have
heard,
and
our
work
on
EDS
software,
such
as
openroad.
I
I
So
in
summary,
fa
stock
is
a
DARPA
program,
part
of
idea.
It
is
a
military
University,
an
effort
led
by
the
University
of
Michigan,
in
partnership
with
arm
the
Facebook
specializes
in
autonomous
SOC
synthesis,
which
include
all
the
building
blocks,
such
as
analog
generators,
memories,
and
course.
So
over
the
course
of
the
program.
We
checked
out
a
good
number
of
chips
since
we
have
12
csm-65,
and
we
demonstrated
all
of
this
in
in
the
Ari
summits
and
the
past
four
years,
I
have
been
involved
in
new
initiatives
that
aims
to
enable
chip
design.
I
We
started
with
the
idea
program,
fa,
stock
and
open
road
and
then
thanks
to
skywater
and
Google,
and
the
open
source
pdk
initiative,
where
I
work
closely
with
with
these
guys
and
along
with
Partners
like
Nest,
we
started,
we
think
in
some
of
the
hardware
design
methodologies
that
could
potentially
revolutionize
how
cheap
design
is
done.
Now
that
the
idea
program
is
is
over,
we
are
still
alive
thanks
to
funding
industry,
Partners
such
as
Google,
KLA
and
nist,
and
thanks
to
the
open,
PW
program
and
open
source
tools.
I
So
these
are
some
of
the
projects
we've
been
working
on,
and
the
reason
mentioned
in
openfa
stock
here
is
that
it
allowed
us
to
crank
out
these
chips,
which
will
build
confidence
to
Silicon
results.
So
some
of
the
projects
we've
been
working
on
are
usually
just
demonstrators
in
open
source
Community
like
sensors
and
bldos,
but
also
the
Nano
fabrication
accelerator.
We're
typing
out
a
huge
chip.
This
week
and
next
week
we
also
started
working
on
privacy
Mass.
I
So
the
release
of
the
skywater
pdk
has
been
a
huge
success
and
enabler.
It
is
activating
Innovation
and
collaboration
in
many
ways
for
different
semiconductor
communities
and
as
such,
Nissan
Nano
fabrication.
Community
are
extensively
benefiting
from
this,
and
now
we
are
building
a
career
wafer
with
integrated
CMOS
circuits
that
allow
physicists
and
nanofabrication
Engineers
such
as
Dr
Brian,
Hoskins
and
and
his
team
to
monitorically,
integrate
and
characterize
emerging
novel
memory
devices.
I
This
is
exciting
and
unprecedent
for
designers
to
create
new
circuits
to
complement
the
nanofab
research
work.
We
are
currently
building
an
automated
platform
using
our
openfa
stock
framework
to
enable
this
across
different
nodes
and
cater
to
different
specifications
defined
by
the
Nano
fabrication
researcher.
I
We
are
also
putting
together
proposals
with
other
partners
to
seek
funding
for
this
type
of
effort
to
NSF.
We
have
achieved
some
initial
results,
including
the
release
of
the
cryo
models
in
Skyward
130,
together
with
the
partners
such
as
cool
cat
and
nist,
we
have
developed
a
test
style
to
enhance
these
models.
Thanks
to
the
assistance
from
Dr
Akin
from
cool
cad.
We
have
also
created
more
complex
circuits
for
the
nanofab
accelerator
capable
of
operating
at
4
Kelvin.
I
The
fabricated
chip
was
tested
by
nist
across
the
wide
temperature
range
from
400
Kelvin
down
to
20
Kelvin,
and
the
setup
is
shown
on
the
left
before
getting
to
this
point.
We
had
to
build
confidence
in
this
tools,
as
I
said,
and
our
framework
heavily
used
open,
overroad,
which
in
open
source
tool,
and
since
we
were
part
of
the
the
team,
we
were
able
to
crank
out
this
chip
here,
which
consists
of
64
temp
sensor
array
in
the
first
mpw
program.
I
The
the
curves
here
are
obviously
can
result
which
I've
shown
previously
in
in
the
chicks
Alliance
meetings.
Similarly,
in
mpw2
we
have,
we
have
made
an
SOC
with
the
array
of
digital
ldos
for
different
load
currents.
We
can
trade
off
settling
time
output,
voltage,
Ripple
efficiency
and
even
overshoots
and
other
shoots.
I
This
type
of
generators
combined
with
the
usage
of
cloud
infrastructure
provided
by
Google
we
will
enable
we
are
enabling
data
based,
optimization
and
hoping
to
see
more
of
this
work
using
programmatic
layout
approaches
using
GDs
Factory,
for
instance,
foreign
and
as
part
of
the
idea
program,
we
were
able
to
to
use
the
gf12
shuttle
to
create
prototypes
using
open
tools.
Our
team
successfully
designed
the
first
version
of
the
open,
Titan
root
of
trust,
which
included
temp
sensors
that
we
developed
using
openface
up.
I
We
also
made
the
Bluetooth
transmitter
using
an
adpl
which
used
a
sub
framework
back
to
the
Nano
fabrication
accelerator
program.
We
have
put
some
test
apparatus
on
a
test
chip
on
a
silicon
chip
which
will
be
used
as
a
career
wafer
for
nanofabrication
or
Nano
device
fabrication.
This
leads
to
improved
measurement
quality
and
test
due
to
the
reduced
parasitics.
I
Next
was
the
Fitbit
Team
who
reached
out
and
started
the
collaboration
with
my
group
to
help
with
rapid
prototyping
and
accelerating
the
custom
design
process.
They
typically
utilize,
off-the-shelf
components
and
assemble
them
on
their
bench.
A
workbench.
However,
occasionally
they
may
be
missing.
Some
of
the
components
with
particular
specifications,
so
open,
okay,
stuff
was
was
a
great
great
fit
here
and
we
taped
out
already
two
chips
in
GF,
180
and
Skyward
130,
which
consists
of
another
front
ends
that
will
be
used
in
their
prototype
signal
chain.
I
Finally,
Intel
has
provided
us
as
well
with
their
16
nanometer
shuttle
where
we
used.
We
used
it
to
build
three
fairly
complicated
test
ships.
One
of
them
is
the
complete
opentizing
route
of
trust
with
security
blocks.
Noise
injection
circuits
I'll
go
through
that
in
some
of
my
slides
next
and
and
and
then
we
did
a
tape
out
on
first
November
2022
and
we
did
one
another
one
a
month
ago,
which
consists
of
a
2.8
Giga
sample
per
second
time,
interleaved
ADC,
so
yeah.
I
So
now,
I
would
like
to
discuss
this.
The
open
Titan
work,
we're
making
and
all
the
peripherals
we're
building
around
it,
and
this
work
is
funded
through
SRC,
so
my
group
was
funded
to
SRC
to
implement
an
open
which
of
trust
using
fully
open
and
open
Flow
that
is
transparent
and
auditable.
Since
open
Titan
is
on
GitHub,
it
was
logical
to
adapt
it
and
include
our
analog
peripherals,
such
as
the
two
random
number
generators
and
pmus
to
make
the
root
of
trust
diagram.
On
the
left
fully
auditable
and
transparent.
I
We
propose
to
use
our
expertise
in
open
source,
Eda
and
IC
design,
combined
with
the
openfa
stock
framework.
We
have
developed
multiple
silicon
validated
IPS
before,
and
we
plan
to
extend
this
work
here
to
add
the
necessary
building
blocks
for
our
route
of
trust,
such
as
the
secure
pmu
and
the
RM
based
trng.
So
I'll
I'll
go
through
that
in
the
next
slide.
I
So
we
are
proposing
different
counter
measures,
measures
to
mitigate
side,
Channel
attacks
such
as
voltage
domain
stacking,
which
I
believe
could
minimize
the
power
signature,
our
AES
accelerator.
We
are
also
developing
a
new,
secure
and
programmable
pmu,
which
underscore
the
flexibility
and
Broad
applicability
of
the
openfa
stock
generator
approach.
The
pmu
generator
include
office,
power,
specification
circuits
for
side,
Channel,
attack,
resilience
and
include
voltage.
Regulation
and
noise
are
not
and
a
novel
noise
injection
technique.
I
I
To
perform
the
power
of
physication
and
reduction,
the
whole
system
is
partitioned
in
two
power
domains.
The
memory
instance
such
as
the
instruction
data
and
boot
memory,
should
be
sitting
at
the
higher
voltage
domain.
Here
it
is
around
2.4
to
1.2,
while
the
computational
logic
is
actually
at
a
sub
threshold
voltage.
Since
the
bottom
voltage
domain
only
contains
glue
digital
logic,
including
the
encryption
blocks,
we
plan
to
use
a
voltage
scale
engine
to
further
improve
the
Energy
Efficiency,
as
well
as
reduce
the
power
signature
during
the
AES
operation.
I
In
stacked
voltage
implementation,
the
current
drawn
by
the
memory
is
directly
reused
by
the
logic
in
the
bottom
voltage
domain,
ideally
bypassing
the
voltage
regulator.
As
a
result,
the
reused
current
is
not
subjected
to
power.
Conversions
losses,
therefore,
improving
power,
delivery
efficiency,
two
dc-dc
converters
based
pmus
using
our
openfa
stock
framework,
are
going
are
being
implemented
to
to
provide
the
Municipal
Power
domains,
and
we
expect
that
the
two
similar
voltage
swing
would
confuse
the
attacker
and
make
DPA
harder.
I
The
second
counter
measure
is
the
secure
programmable
pmu,
with
noise
injection
structures.
The
top
level
architecture
consists
of
six
stage
converter
and
the
non-orbital
app
in
Cloud
digital
DAC
and
noise
injection
block,
which
will
be
implemented
using
open
face
Arc
and
based
on
this.
In
our
early
stage
exploration,
we
try
to
replicate
the
work
in
the
previous
slide.
We'll
use
the
pulse
weight,
making
the
RM
cell
go
from
reset
to
set
and
delete
phase,
so
there's
there
isn't
any
Technologies
using
RM.
I
So
this
is
mainly
a
research
project,
but
we
have
other
options
using
a
fully
Digital
two
random
numbers
which
we
actually
implemented
in
Intel
16.
Last
statement,
this
is
the
November
2022.
We
already
got
the
chips
from
Intel.
They
actually
provided
us
with
the
socket
and
also
this
was
great
and
my
student
is
building
the
PCB,
so
it
can
be
so
we
can
start
the
testing
in
this
test
trip.
I
The
second
tape
out,
which
is
actually
the
final
version,
we're
planning
to
do
in
in
in
using
open
Titan.
We
have
already
taken
of
this
block
here.
We
actually
included
two
random
numbers,
you
know,
HSB
is
oscillator
and
the
pmu
and
the
PLL
and
so
on,
and
all
of
this
is
using
open
source
tools
which
is
really
great,
except
for
verification
where
we
don't
have
open
tools
yet
at
a
pinped
technology.
I
This
is
the
implementation.
There
is
a
PLL
as
I
said,
and
a
trng.
All
of
these
are
using
open
road
for
the
implementation,
since
they
are
digital,
friendly
and
and
and
and
on
the
next
slide.
I
would
like
to
talk
about
our
our
framework
and
and
how
we're
using
python
to
to
do
to
use
openfa
stock
here.
I
Openfa
stock
here
is
actually
mainly
code
right,
so
it's
actually
very
different
than
how
circuit
design
works.
So
it's
kind
of
confusing
for
Hardware
designers
but
open
a
Facebook
is
actually
auditable
and
transparent.
No
malicious
or
jumping
with
the
generated
designs
can
be
done.
We
also
are
having
regression
tests,
systematic
metrics
extraction
and
dashboards.
I
Automation
has
been
an
issue
for
a
long
time
and
it's
it's
really
hard
to
say
that
analog
automation
is
is,
is
fixed
now,
but
since
we're
working
in
the
open
now
we
can
still
combine
multiple
expertise
in
the
Eda
analog
circuits
and
software.
So
we
can
fix
this
problem,
so
we
started
exploring
new
ways
of
automation,
using
GDs,
Factory
and
so
on.
Certain
blocks,
such
as
objective
cells,
which
we
use
in
our
procedural
generators
and
on
circuits
like
transimped
and
simplifiers
and
other
circuitry.
I
This
is
a
direct
control
over
the
layout
and
are
not
suitable
for
the
cell-based
approach
that
we
usually
use
in
openface
Hub.
So
this
provides
a
Time
limiting
step
reporting
to
new
pdk.
We
want
to
automate
as
much
as
possible
while
keeping
the
generator
agnostic
pdk
agnostic.
To
address
this.
We
are
developing
programmatic
generators
employing
GDs
Factory,
which
is
developed
here
by
Joaquin
from
the
from
Google
X
photonics
team.
I
Gds
Factory
provides
a
framework
for
programmatically
built-in
layouts
with
object-oriented
code.
The
main
advantage
of
this
is
to
keep
cell
software
generation
dependent
on
pdk,
so
pdk
is
in
our
framework,
is,
is
implemented
as
a
python
class,
including
the
layer
stack
design
rules
and
the
library
of
component,
such
as
P
cells.
I
The
generators
are
now
implemented
as
python
functions,
which
will
return
full
layout
stored
in
GDs
Factory
components.
This
function
can
act,
accept
Arguments
for
automatic
customization.
Generators
can
also
call
other
generations
to
produce
a
hierarchical
design.
The
user
interface
with
the
generator
is
a
python
package
user.
The
user
can
import
a
pdk
package
and
the
target
generator.
Then,
in
one
of
the
line
of
the
code,
they
can
actually
create
a
full
layout
with
programmatic
generators.
I
The
other
work
that
is
being
done
here
and
thanks
to
Google
summary
of
code
this
year,
which
allowed
us
to
have
three
motivated
students
who
are
actively
working
on
implementing
features
to
enable
Automation
and
interfacing
between
tools
Mojito
made.
This
diagram
here
is
implementing
print
the
front
end
of
the
lion
classes
in
open
road,
as
well
as
the
zdl's
GDs
writer
and
reader
to
help
cointegrate
with
other
tools
such
as
videos
Factory.
This
is
a
really
enabled
enablers
for
Android
automation,
since
we
can
build
our
circuit
within
opennode
rather
than
outside
of
node.
I
Now
next,
in
my
talk,
I'll
talk
about
activities
that
utilize
is
actually
funding.
These
are
this
is
our
committee
here,
which
is
the
sscs
IEEE
sscs
committee,
which
is
chased
by
Professor
Boyce
merman,
and
this
is
the
our
roster
here.
It
is
open.
We
are
always
turning
the
members,
so
please
reach
out
if
you're
interested
in
joining
us,
but
Chief
science
has
helped
us
through
Google
and
so
on,
to
fund
some
of
these
efforts
here.
I
So
one
of
them
is
the
chippeton
which
started
in
2021
and
we
launched
it
with
Professor
Boris.
We
see
students
from
industrial
communities
in
the
US
and
all
over
the
world,
joining
us
in
a
weekly
meetings
to
learn
how
to
do
a
tape
out
and
and
there
and
get
travel
grants
to
Collective
conferences
such
as
ICC
and
so
on.
I
I
But
in
this
year's
tripathon
we
changed
a
bit
the
way
we
want
to
run
the
we
want
to
run
it
by
making
the
teams
propose
new
circuit
ideas
that
could
be
used
to
build
a
lab
on
a
chip
and
the
reason
we
want
to
do
that
is
because
there's
a
lot
of
communities
that
doesn't
have
equipment
this
equipment
to
to
test
their
chips
or
their
open
design.
So
having
this,
this
lab
on
a
chip
would
allow
them
to
have
oscilloscopes
macros
that
they
can
use
to
test
their
circuitry.
I
The
other
things
we
started
is
and
to
funding
to
Gypsy
lines
the
coded
chip,
competition,
which
we
had
the
first
version
here
at
iss6203.
We
had
about
seven
winners
from
different
places
across
the
globe,
globe
and
chips.
Alliance
has
funded
it
here,
as
you
can
see
on
the
on
the
picture,
the
next,
the
next
code,
that
your
composition
happened
in
BSI
2023,
we
had
two
winners
from
University
of
Toronto
and
and
and
one
interesting
thing
is.
I
I
The
other
thing
we
wanted
to
do
is
allow
venues
for
publication
right.
So
open
design
is
not,
as
you
know,
Leading
Edge
as
a
closed
design.
So
it
is
hard
to
publish
in
conferences
like
isscc
and
vlsi.
So
with
the
with
our
community,
we
we
did
the
first
session
at
iskas,
which
is
around
open
source
design,
and
we
did
a
review
of
all
the
Silicon
results
we
had
in
mpw
one
and
two
and
so
on.
I
The
other
thing
I
wanted
to
mention
here
is
we
had
an
open
source
workshop
at
vdsi
which
had
about
180
attendees.
That's
unheard
of
that's
a
recording
video
side
in
the
circuit
community
and
it
was
great
to
see
so
many
people
in
Japan
join
us
in
our
Workshop
and
I
think
they
are
thinking
about
making
this
as
a
as
a
as
a
normal
thing
that
happens
every
year.
F
F
I
Okay,
so
there's
this
is
a
good
question
right,
so
I'm
running
a
research
group
and
I
deal
with
a
lot
of
with
students.
So
one
thing
we
do
I'm
trying
to
implement
is
having
you
know
more
software
student
to
hardware
and
the
way
we
do
that
is
through
abstraction
and
open
fa.
Soft
allows
that,
to
our
frame
the
cell
based
approach,
you
can
check
the
other
talks
in
chips.
I
Minus
that
goes
through
that
I
do
want
to
repeat
the
same
talk
over
again,
but
the
idea
is
basically,
you
identify
some
cells
that
are
basically
a
block,
and
you
don't
have
to.
If
you're
a
software
person,
you
don't
have
to
understand,
what's
happening
in
terms
of
transistors,
you
can
just
reuse
that
block
and
build
it
with
the
whole
topology.
I
Now,
regarding
the
education,
it's
very
good
for
the
students
to
to
play
with
the
code
and
generate,
at
the
end
of
the
day,
a
circuit
that
that
is
simulatable
and
all
the
other
thing
is
we
actually
work
with
industry
Partners
to
create,
or
even
a
government
transition
is
to
create
real
circuits,
so
is
being
used
to
generate
blogs
that
are
working
on
silicon,
and
we
put
that
through
our
results.
So
we
address
both
I
guess.
H
H
I
I
Making
a
study
is
using
open
tools
is,
is
not
easy,
but
we'll
go
in
with
the
baby
steps
and
building
a
PLL
and
so
on,
like
all
the
building
blocks
and
when
we'll
have
it
ready,
I
think
we're
gonna
use,
openfa
stock
and
Port
is
across
Technologies,
so
I
think
that's
in
our
plans.
Now
it's
taking
time
and
resources.
A
So
I
had
I
had
one
question:
I
always
always
enjoy
your
talks
and
the
work
oops.
We
do
have
a
question,
but
I'll
ask
my
question
first,
but
how
you
know
I
talked
a
little
bit
about
this
last
night.
As
you
know,
you
know
it
seems
with
the
open
source
CDA,
which
is
a
great
effort,
and
it's
very
similar
to
you
know
what
I
experienced
in
my
career
in
terms
of
developing
internal
tools
within
a
large
Semiconductor
Company
right.
It's
it's
always
hard.
A
The
designers
hate
you,
whatever
I
mean
it
just
it
goes
on
and
on
and
I
won't
go
on
and
on.
But
you
know
in
terms
of
how
are
things
going
in
terms
of
industrial
adoption
of
the
work
that
you
are
doing?
Is
it
do
you?
Have
anybody
who's
using
this
in
Industry
right
now,
or
is
that
still
kind
of
a
challenge.
I
I
So
the
only
thing
we're
using
is
actually
Python
scripts
and
open
road,
which
is
great
already,
but
you
know
SRC
is
another
example:
it's
it's
an
industry
driven
thing
and
they
are
interested
in
our
two
random
numbers,
generators
and
pmus,
and
this
is
the
other
option
right
with
the
Nano
fabrication
accelerator.
So
I
think
this
is
a
good
adoption
adoption
now
you
know
we
need
to
disseminate
this
more
and
if
there's
any
interest,
please
let
me
know,
because
we
have
silicon
results
and
we've
shown
this
across
different
designs.
I
I,
don't
understand
what
means
provide
more
Technologies,
but
basically
supporting
you.
Technologies
like
what
pragma
I
see
pragmatic
is
doing
that's
definitely
possible
and
we
reported
fa
sock
or
open
a
face
up
to
different
nodes.
So
I
don't
see
why
that's
not
going
to
happen.
The
other
thing
is
GDs.
Factory
is
actually
a
really
great
platform
to
create
Python
scripts
to
generate
layouts.
So
now
we're
supporting
both
and
we're
creating
this.
These
designs,
that
can
you
know,
support
different
Technologies,
actually.
A
I
was
gonna
also
just
agree
relative
to
the
efforts
that
you're
doing
I
know
Tim
this
Champion
as
well
about
trying
to
make
Hardware
design
more
software
like
and
approachable
people
right.
You
know
and
my
time
in
this
role
and
chatting
with
different
government
entities
or
regions
of
the
US
or
the
world
right.
It's
like
we
have
this
Global
problem
of
getting
people
interested
in
engineering
and
I.
Think
a
lot
of
that
has
to
do
making
it
approachable
I
was
chatting
with
some
folks
with
from
Germany
last
night.
A
A
G
I
That's
a
really
good
point
right
and
I
think
one
thing
we're
trying
to
address
with
openness,
office
obstruction,
because
building
generators
requires
expertise.
Right,
like
you,
can't
be
a
PL
guy
and
an
ADC
guy
and
so
on
right.
So
you
have
to
obstruct
some
of
these
issues
and
that's
how
we're
building
open
and
pay
stock.
So
people
don't
have
to
deal
with
some
of
the
analog
black
magic
or
basically.
A
All
right
well,
thank
you
so
much
for
an
excellent
presentation,
Maddie
and
thanks
to
everyone
for
presenting
today
and
for
everyone
who
attended
both
here
in
San,
Francisco
at
Google
and
also
online,
and
thanks
again
to
Google
for
hosting
us
here
today,
so
appreciate
it
we'll
work
on
making
the
video
available
and
if
the
presenters
could
send
me
the
the
slides
we
will
get
them
out
there
as
well.
So
thank
you
again.
Everybody.