►
From YouTube: CHIPS Alliance Workshop - March 30, 2021
Description
The CHIPS Alliance held its Spring 2021 workshop, to share milestones, progress, updates and more.
Slides are available at: https://events.linuxfoundation.org/chips-alliance-spring-workshop/program/schedule/
A
So
let
me
start
by
providing
a
brief
introduction.
I
am
relatively
new
to
chips
alliance.
I
just
joined
in
early
january
and
it's
my
pleasure
to
be
a
part
of
this
exciting
community
of
folks
participating
in
this.
I
have
quite
a
bit
of
industrial
experience
going
back
through
ibm
sun
microsystems
oracle.
A
A
So
what
that
has
evolved
to
more
what
I
call
a
supply
chain
management
type
of
thing,
which
you
might
see,
for
example,
as
apple
amd
or
what
I
saw
at
oracle
sun.
Where
you
reply,
you
rely
upon
different
suppliers
to
provide
you
different
things,
whether
that
be
eda,
tooling,
that
might
be
particular
ip,
that
you
license
a
from
a
ip
developer
and,
of
course,
from
your
foundry
as
well,
that
being
through
one
of
the
major
players
that
we
all
work
with.
A
And
what
we're
seeing
now
happen
is
that
we're
going
more
towards
an
open
collaboration,
type
of
environment
where
different
companies
may
come
together
and
collaborate
on
something
or,
as
we
are
now
promoting
in
chips.
Alliances,
open
source
collaboration
in
the
hardware
space,
which
really
will
provide
an
entirely
new
ecosystem
to
bring
forward
the
best
ideas
and
iep
that
is
shared
and
developed
by
the
open
source
community.
That
can
be
used
to
build
interesting
products.
A
B
A
Development
and
verification,
the
implementation
and,
of
course,
the
manufacturer-
it
just
takes
a
lot
of
time
and
money
or
nre
to
get
a
product
to
the
point
where
you
tape
it
out
and
when
you
do
tape
it
out.
Of
course,
you
want
to
make
sure
that
is
correct
and,
of
course,
in
terms
of
innovation,
we're
really
moving
beyond
the
cpu
and
gpo
type
of
environment.
We're
moving
to
specialty
accelerators
for
machine
learning.
Image
processing
could
be
database
accelerators
as
an
example.
A
So
what
chips
alliance
really
is
promote?
Promoting
or
proposing
is
an
open
design
ecosystem
right
that
moves
all
the
way
from
specific
specification,
rtl,
open
process,
design
kits
tooling,
physical
implementation
and
standards,
and
there's
many
potential
contributors
to
this
type
of
environment,
individuals,
universities,
foundations,
companies.
What
we're
really
trying
to
do
is
bring
forward
the
best
minds
on
very
complex
problems
and
to
build
a
platform
of
innovation
that
all
can
contribute
to
and
benefit
from.
A
If
we
look
at
the
chips
alliance,
it's
really
an
arena
of
pillars
of
interest
and
opportunities
right,
it
could
be.
Architecture
could
be
specification,
it
could
be
implementation,
it
can
be
tooling,
it
can
be
verification,
and
there
are
others
too,
as
time
goes
forward
right.
So
it's
providing
a
venue
of
collaboration.
A
If
we
look
at
the
open
source
model,
it's
really
about
ip
and
innovation
and
then
building
your
product
right.
So
we
could
start
with
an
open
ip
catalog,
that's
in
the
open
source
community
and
then
your
innovation
on
top
of
that
or
in
conjunction
with
that,
can
yield
a
market
differentiating
product.
But
we
have
a
number
of
areas
where
we
already
have
had
successful,
open
collaboration,
whether
that
be
on
the
successful
risk,
vise
implementation
with
the
swerve
core.
It
could
be.
A
We
also
have
recently
formerly
formed
an
analog
interest
group,
which
is
of
interest
to
many
different
participants
that
has
characteristically
been
one
of
the
most
difficult
arenas
of
chip
design
and
is
often
the
long
pole
in
the
development
of
any
particular
piece
of
silicon
in
terms
of
goals
of
what
we
want
to
try
to
do
in
chips
alliance,
we're
interested
increasing
the
membership,
that's
certainly
a
key
goal.
We
want
to
get
folks
participant
in
it
and
take
advantage
of
what
we
offer
and
also
to
help
have
them
contribute
different
ideas
and
to
extend
the
ecosystem.
A
I'd
like
to
see
increased
collaboration
both
in
entarto
artificial
intelligence,
automotive,
5g.
Those
are
some
new
arenas
that
we'd
be
happy
to
participate
in,
of
course,
getting
more
ip
contribution
to
the
alliance
would
be
a
benefit
too.
I
think
that's
useful
for
everyone
and
really
provide
a
menu
of
choice
for
innovation
right,
so
that
any
anyone
can
pick
and
pull
different
items
from
that
to
help
build
differentiated
products.
A
We
also
have
quite
a
bit
of
interest
in
open
tooling,
as
I
mentioned
earlier,
so
I
just
generically
call
it
open
eda
that
could
be
architectural
simulation,
rtl
development,
verification,
analog,
digital
fpga
type,
tooling,
so
there's
a
lot
of
opportunity
there.
The
other
thing
that
I
want
to
formulate
this
year
as
well
is
a
university
mentorship
program
and
also
a
contest
for
students
to
participate
in
and
to
create
excitement
for
the
alliance
and
also
for
different
participants
right
in
terms
of
both
learning
from
a
career
perspective
and
also
academically
as
well.
A
So
with
that,
I
will
introduce
our
first
speaker,
which
is
who
is
professor
bora
nicholak
at
university
of
california,
at
berkeley?
He
is
going
to
talk
about
shipyard.
Professor
nikolic
has
many
interesting
different
activities
under
his
research
is
an
expert
in
solid-state
circuit
design.
So
with
that,
I'd
like
to
turn
it
over
to
you,
professor
nicolette.
C
C
C
We
have
two
types
of
generators,
digital
and
analog,
and
most
of
this
talk
will
cover
the
digital
generator,
so
I'll
touch
on
the
analog
ones
as
well
towards
the
end,
digital
generators
in
our
world
are
written
in
a
language
called
chisel
which
stands
for
constructing
hardware
in
scala
embedded
language,
which
is
essentially
a
piece
of
software
and
gets
executed,
generates
data
flow
graph.
That
is
a
presentation
of
the
rtls.
It
is
not
high
level
synthesis.
It
is
essentially
writing
hdl
code
in
a
bit
more
powerful
language
host
language.
C
In
this
case,
scala
version,
3.4
is
current
and
chisel
and
trans
translates
to
its
intermediate
form,
which
is
called
fertile
and
then
from
fertile.
It
emits
verilog
and
various
kinds
of
design
and
verification,
collaterals
and
chisel
originated
in
berkeley,
but
over
the
past
year
has
moved
to
chip's
alliance,
and
is
you
know
the
repository
actually
is
hosted
by
the
chips
alliance?
On
the
other
hand,
bag
is
an
open
source
python-based
framework
for
generating
analog
blocks.
C
Everything
we
do
is
based
on
risk,
5
say,
which
is
an
open
and
license
free.
I
say
that
most
familiar
most
people
are
familiar
with
it's
important
to
keep
in
mind
that
isa
is
different
than
the
ip.
So
there
are
many
research
and
commercial
implementations
of
risk,
5
cores
out
there.
For
example,
there
are
well-known
palpina
cores
and
there
are
rocket
cores
that
came
from
berkeley.
Rock
core
is
an
example
of
a
generator
written
in
chisel.
C
These
open
source
components
include
chisel
that
I
mentioned,
and
it's
intermediate
form
fertile
and
risk
5
isa
and
the
back
berkeley,
analog
generator
and
various
cores
like
the
boom
core
and
the
rocket
core
and
a
good
number
of
accelerators
to
go
with
that,
and
there
are
caches
that
have
been
contributed.
You
know
that
were
designed
in
berkeley
then
contributed
by
sci-fi,
just
style
length
also
developed
by
berkeley,
then
improved
by
sci-fi
diplomacy
from
sci-fi,
a
number
of
peripherals
from
berkeley
and
other
places
configuration
system
our
flow
tool,
which
is
called
hammer.
C
There
is
our
fpga
simulation
environment,
which
is
called
firesim,
and
it
became
obvious
that
that
whole
thing
is
pretty
disorganized
and
lives
in
a
very
large
number
of
independent
repositories
that
are
moving
independently
of
each
other.
It
has
become
even
harder
for,
even
even
for
our
students
to
put
systems
together
from
these
different
kind
of
components
that
not
unnecessarily
always
fitted
with
each
other.
C
C
Shipyard
is
a
framework
that
enables
us
to
put
together
many
things
that
exist
in
the
open
source,
primarily
from
berkeley,
but
from
many
others
as
well.
So
they're
grouped
into
these
sections
that
involve
tooling,
which
are
the
languages
and
the
tools
for
bringing
up
risk
five
systems,
then
things
associated
with
the
rocket
chip
and
the
design
flows
that
are
targeting
either
software
rtl
simulation,
fpga
simulation
or
vlsi
flows.
C
C
C
One
can
take
various
kinds
of
parameters
and
change
them
to
their
liking
or
replace
pieces
of
the
of
the
generator
with
their
own
ip,
including
a
separate
core
typical
customizations
involved,
as
I
said,
changing
the
parameters
adding
coprocessors
or
adding
ip
inside
the
rocket
chip.
There
is
also
a
library
of
reusable
ssc
components
where
you'll
find
memory,
protocol
component
converters,
various
kinds
of
arbiters
and
crossbar
generators
and
clock
crossings
and
asynchronous
cues.
It
is
the
largest
open
source
chisel
code
base.
It
has
been
used
in
industry,
sci-fi
is
maintaining
it
it.
C
It
was
developed
in
berkeley,
but
now
primarily
is
maintained
by
chips
alliance
than
sci-fi,
and
it
has
been
used
in
sci-fives
products
when
we
look
into
what
is
inside
of
our
of
a
rocket
chip,
soc
we'll
find
tiles,
which
are
the
units
of
replication
for
a
core.
So
in
our
case
we
can
have
our
cpus
that
are
either
rocket
or
berkley
out
of
order
machine
or
we
as
an
example
of
integrating
verilog
source
code.
We
have
integrated
eth,
zurich's
ariana
or
what
is
now
called
cva6.
C
Cache
has
a
two
level
cache
system.
There
is
a
front
bus
that
connects
to
the
dma
devices
and
there
is
a
control
bus
that
connects
to
the
core
complex
devices
and
interrupt
controllers
bootrom
and
the
jtag
unit.
Periphery
bus
connects
to
the
other
devices
and
the
system
bus
ties
everything
together.
C
In
order
to
integrate
many
of
these
generators,
you
know
you
have
to
have
the
right
version
that
works
with
each
of
those,
and
we
have
built
and
tested
many
configurations
that
work
together.
For
example,
we
have
the
cores
that
I
mentioned,
and
then
there
is
a
number
of
accelerators
that
we
have
put
out
in
the
open
source
or
adopted
from
the
open
source.
So
we
have
a
huacha
which
is
a
custom,
not
standard
risk,
5
vector
accelerator
gemini
is
a
machine
learning
matrix
multiplication
accelerator.
C
There
is
an
educational
accelerator,
people
can
go
through
and
quickly
run
through
the
exercise
of
integrating
it
in
their
design,
and
we
have
taken
nvidia's,
nvdla
and
integrated
with
our
design.
A
memory
system
is
a
sci-fi's
last
level
cache,
and
there
is
a
number
of
peripherals
that
are
out
there.
That.
C
So
when
we
customize
this,
there
are
many
ways
for
customizing
components
and
the
entire
soc.
So,
for
example,
one
one
of
the
good
examples
that
people
can
do
in
order
to
bring
themselves
up
to
speed
is
to
configure
a
minimum
configuration
of
the
of
the
rocket
core
to
build
it
as
a
controller
core
or
a
power
management
unit
or
system
management
unit.
C
Now
it
is
important
to
have
tooling
that
enables
us
to
evaluate
these
kind
of
systems,
so
we
have
simulation
implementation
targets
where
we
can
target
fpgas
in
the
cloud
through
our
firesim
flow.
We
can
just
simulate
the
you
know
as
software
rtl
simulation
through
behavior
verilog
and
we
can
have
vrs
lsi
verilog
to
drive
the
automated
vlsi
flow.
C
C
C
Shipyard
has
been
bumped
to
version
1.4,
and
here
are
a
few
highlights
that
you
know,
may
be
of
interest
to
people
who
who
are
interested
or
are
using
gpr.
First
open
sbi
has
been
integrated,
and
that
is,
I
believe,
in
chip's
alliance.
It
originates
from
western
digital,
which
is
an
open
source
implementation
of
a
respire
supervisor,
binary
interface.
C
That
basically
replaces
berkeley's
bootloader.
So
this
is
something
that
has
a
much
broader
community
supports
that
the
bvl,
but
bbl
is
still
an
option
for
legacy
implementations
and
legacy
workloads
we
implemented.
Some
things
is
called
harness,
binders
that
are
generally
replacing,
so
something
is
called
io
binders,
which
were
the
the
generalized
abstraction
for
io
interfaces
from
the
chip
perspective
and
they
have
been
primarily
eyebinders
have
been
targeting
test
chips,
but
we
have
found
out
that
many
people
are
interested
not
just
in
the
test.
C
So
there
there
was
a
number
of
relatively
convenient
features
that
have
been
added
to
that.
We
also
have
you
know
more
of
our
vlsi
site
tool.
Flow
has
become
visible
by
putting
a
lot
of
it
into
open
source,
so
we
have
a
largely
automated
make
file
based
flow
that
takes
the
target
rtrt
target
verilog
and
passes
it
through
a
set
of
commercial
tools,
as
well
as
some
of
the
open
road
tools
to
generate
the
drc
and
lvs
clean
gds
file.
C
What
I
said
it
is
becoming
more
obvious.
What
we
are
doing.
Most
of
that
has
been
abstract.
There
have
been
a
lot
of
obsessions
because
we
have
been
targeting
commercial
tools
and
nda
protected
design
kits,
but
now
with
open
road,
then
skywater
we
can
actually
publish
most
of
that
and
it
is
in
the
open
source
and
there
is
quite
a
bit
of
added
documentation
because
we
use
it
in
classes.
C
C
To
start
wrapping
this
up,
we
would
like
to
enable
complete
mixed
signal:
soc
integration,
so
we
have
been
building
mixed
signal
socs
based
on
on
shipyard,
but
the
integration
of
mixing
all
blocks
has
not
been
automated
to
say
our.
It
has
been
mostly
and
mostly
manual
integration
of
automatically
generated
blocks.
C
So
we
have
these
tools
that
I
mentioned
early
on,
which
are
back
two
and
bag,
three,
which
are
our
ways
to
generate
mexican
ip
blocks.
Majority
of
the
existing
generators
are
in
the
bag,
two
version
of
berkeley
analog
generator
and
we
have
some
fairly
complex
stuff.
That
includes
time,
interleaved
adcs.
C
High-Speed
services
and
plls
and
they're
targeting
commercial
technologies
like
tsmc,
16
28
until
22
or
global
founders,
14.,
we
do
have
a
bag.
3
migration
pad
back
3
is
not
backwards,
compatible
to
back
2,
but
over
the
next
few
weeks,
people
may
enjoy
seeing
some
of
these
generators
published
completely
in
the
open
source
and
sky
130,
and
there
will
be
equivalent
versions
that
will
be
targeting
state
of
the
art
technology
kits
in
intel,
22
or
global
foundry
12..
C
C
So
in
summary,
we
have
already
enjoyed
quite
a
bit
of
community
support.
We
were
very
pleased
to
see
in
the
risk
fire
summit
in
december.
There
were
a
couple
of
talks
that
presented
their
own
innovations
by
using
chip
yard
in
education,
we're
using
it
successfully
in
three
classes,
we're
using
it
in
three
classes
in
spring
2020
and
we're
using
it
in
four
classes
during
spring
2021.
C
C
They
took
shipyard
and
they
are
the
two
components
from
the
shipyard
added
their
custom,
stuff,
asc,
accelerator,
aes,
accelerator
and
bluetooth
transceiver,
and
that
whole
thing
is
going
to
be
taped
out
in
a
month
if
they
persist
with
that.
So
with
that,
we
have
quite
a
bit
of
a
documentation-
it's
not
as
rich,
but
there
are
about
140
pages
out
there
of
the
of
the
on
on
shipyards,
documentation
pages
that
enable
people
to
get
started.
There
is
a
number
of
tutorials,
some
of
them
have
been
recorded
and
can
be
replayed.
C
The
one
that
is
coming
up
soon
is
pisca.
2021.
mailing
list
has
200
threads,
and
that
is
basically
it
everything
that
we
have
is
in
the
open
source.
We
are
happy
for
people
to
use
it.
We
are
even
happier
if
you
put
a
pr
with
an
improvement
that
you
would
like
us
to
adopt
and
to
to
wrap
it
up.
I
we
have
made
it
easy
to
design
specialized
socs.
A
Thank
you
so
much
professor
nicholas
for
an
excellent
presentation.
I
I
really
do
appreciate
it.
I
have
one
question
so
far
on
the
q
and
a
line
which
I'll
ask
that
first
and
I'll
ask
with
the
following
question
myself
too
and
appreciate:
if
there's
any
others
from
others,
so
question
is:
can
local
prototyping
be
done
by
distributing
the
target
design
over
multiple
fpgas,
as
occurs
in
firesim
on
the
cloud.
C
C
C
So
we
will
generally
use
you
know,
say
xilinx's
closed
source
rules
in
the
vlsi
flow.
We
have
two
options
to
go
with
the
cadences
flow,
which
is
what
is
we
mostly
support
and
target
nda
protected
technologies,
but
you
are
now
supporting
and
open
source
tools
from
open
road
and
target
and
completely
open
source
sky
130
kit.
It
is
not
completely
stable.
The
the
release
is
not.
You
know
the.
There
are
gaps
in
those
flows,
but
I
think
other
speakers
are
going
to
address
and
tell
us.
A
A
C
C
A
Okay
and
final
question
is
what
steps
or
approaches
are
being
taken
to
introduce
chisel
into
the
industry.
As
a
recent
chisel
learner,
I'm
really
impressed
with
the
flexibility
chisel
offers,
but
whenever
I
recommend
someone
to
learn
it,
they
are
hesitant
to
say,
are
hesitant,
saying
verilog
or
sv
are
the
industry
standard
being
just
a
marilyn.
C
Yeah,
that
is
true
it
we
do
have
a
boot
camp
that
people
can
take
over
five
days
and
it
is
in
sitting
in
the
open
source.
I
can
point
people
to
that.
People
can
take
a
boot
camp
and
teach
themselves
a
chisel.
If
you
talk
to
our
students,
they
really
don't
like
you
know.
If
you
are
20
year
old,
you
really
our
students
that
are
20
years
old,
really
don't
like
verilog.
They
feel
like
that.
A
A
F
F
The
obligatory
anti-trust
policy,
then
we
get
to
the
agenda
so
good
morning
or
good
evening,
depending
on
where
you
are.
My
name
is
matt
cockrell
and
I'm
joined
today
by
tao,
lu
and
udi
jangalada.
We
are
pleased
to
give
you
an
update
on
the
risk
dv
work
group,
we'll
begin
with
an
overview
of
the
group
itself.
F
F
So
it
goes
that
we
create
a
forum
for
discussing
chip's
alliance
contributions
that
will
provide
or
enhance
verification
platforms.
The
work
group
should
strive
to
accept
support
platforms
that
demonstrate
compliance
functionality
and
perhaps
eventually
performance.
So,
in
short,
the
current
focus
of
the
work
group
is
the
risk
five
dv
tool
that
the
tao
has
put
created,
but
in
general
we
want
to
foster
discussions
of
all.
You
know,
design,
verification,
related
tools
and.
F
F
Participants
from
various
parts
of
the
industry,
simon
from
in
paris,
joins
us
on
a
regular
basis,
and
he
gives
us
great
insights
on
the
tool
from
an
iss
and
other
perspectives
of
you
know
some
of
what
embarrasses
customers
are
looking
for
in
the
tool.
We
have
numerous
participants
from
google.
You
know
myself,
tau
and
uday
being
you
know,
part
of
them
also
the
tool
is
used
pretty
heavily
in
the
open
titan.
You
know
verification
of
the
ibex
core,
and
so
we
have
participants
on
that
front
too,
that
come
from
google.
F
We
have
participants
from
western
digital
they've
used
the
tool
for
their
risk.
Five
cores
as
well
andes
has
been
helping
to
develop
support
for
the
vector
extension,
so
they
have
a
lot
to
offer
in
that
discussion.
Doug
and
amy
from
metrics
attend
on
a
regular
basis.
They've
had
quite
a
bit
to
do
with
helping
to
get
the
continuous
integration
platform
up
and
running,
and
perfect
vips
has
been
large
contributors
to
the
python-based
flow.
F
They
consistently,
you
know,
tend
to
provide
insight
on
development
of
the
the
python
based
generator
as
well
as
understand.
You
know
the
risk
5d
tool
and
enhancements
that
can
be
made.
In
addition
to
just
you
know,
general
discussion
on
this
five
dv
and
other
associated
topics.
We
we
have
we've
had
some
great
presentations
from
you
know
from
various
presenters,
a
few
of
them.
F
F
F
So
the
evolution-
this
is
an
updated
version
of
the
slide
that
tao
presented
last
september.
As
you
can
see,
the
tool
has
had
a
healthy
evolution
over
the
past
few
years
as
we
move
into
2021.
We
want
to
continue
the
progress
that
we've
we've
had
up
to
this
point.
You
know
we
want
to
continue
having
the
work
group,
you
know
on
a
regular
basis
and-
and
you
know,
grow
the
attendance,
so
we
can,
you
know,
gather
the
valuable,
valuable
feedback
you
know
we're
going
to.
F
One
of
the
top
priorities
for
2021
is
is
bringing
the
tool
up
to
compliance
with
the
vector
extension
version.
1.0
we've
gotten
some
feedback
that
there's
some
users
that
would
like
to
have
that
capability
in
the
tool
and
then
we'll
continue
work
on
and
then
we're
going
to
add
support
for
the
enhanced
pmp
extension.
That's
been
proposed
and
I'll
talk
about
that.
A
bit
more
later,.
F
So
for
those
of
you
who
aren't
familiar
with
the
tool,
this
is
a
high
level
overview
of
how
it
works,
so
the
tool
takes
in
various
inputs.
You
know
such
as
processor
configuration,
you
know,
supported
instructions,
whether
it
be
integer,
multiply,
compressed
and
so
forth,
and
it
generates
a
program
that
can
be
fed
into
an
iss
and
executed
in
you
know:
a
uvm
system,
verilog
simulation
environment,
the
outputs
of
the
iss
and
the
simulation
can
be
compared
for
correctness.
F
F
You
know
tutorial
on
on
the
github
that
you
can
look
at
that
will
guide
you
in
getting
the
tool
up
and
running
if
you
want
to
experiment
with
it.
But
if
you
have
questions
beyond
that,
I
encourage
you
to
join
the
work
group
and
you
can
voice
your
questions.
There
and
you'll
certainly
get
some
sort
of
answer.
F
So
the
continuous
integration
platform
in
the
workgroup
discussion
we
determined
it
would
be
valuable
to
have
a
ci
flow
that
would
maintain
the
stability
and
health
of
the
tool
against
the
tool
chain
and
make
sure
all
of
the
contributions
are
keeping
things
intact
and
not
breaking
anything.
So
when
we
first
share
this
idea
with
the
larger
chips
alliance
forum,
we
got
some
feedback
on
how
that
should
look,
and
ideally
it
would
be
all
totally
free
and
open
source.
You
know
like
hosted
on
a
travis.
F
F
Now,
an
update
on
the
the
python
based
instruction
generator
in
one
of
our
first
workgroup
meetings.
The
question
came
up
is
how
do
I
use
this?
You
know
risk
5db
tool.
If
I
don't
have
a
license
from
you
know,
one
of
the
large
eda
vendors
caden
synopsis
or
another
eda
vendor,
and,
as
I
mentioned
earlier,
the
uvm
based
tool
requires.
You
know
those
types
of
tools
from
those
those
vendors.
F
F
So
our
approach
includes
using
the
pyvsc
as
the
randomization
and
functional
coverage
framework.
It's
an
open
source
package
for
generating
random
stimulus
and
collecting
functional
coverage.
The
syntax
is
familiar.
It
looks
like
system
verilog,
randomizing
constraints
and
functional
coverage
syntax,
and
we
are
also
using
the
same
class
structure
as
we
did
in
the
original
tool,
and
this
you
know
we
have
the
same
randomization
randomization
flow
as
we
did
with
the
system
bare
log
uvm
tool.
F
F
F
Then
the
rv32i,
functional
coverage
and
implementation
and
perfect
vips
did
the
pyvsp
instruction
class
framework,
then
a
basic
implementation
of
the
generator
itself,
and
then
they
were
able
to
generate
a
random
program
that
fed
right
into
our
end-to-end
flow.
So
now
any
other
enhancements
made
to
the
the
pygen
or
the
pi,
the
risk
five
db
pi
flow
can
be
fed
into
our
end
and
integration
flow
to
make
sure
it
doesn't
it
still
works
properly.
F
Where
are
we
at
now?
So
as
of
now,
we've
implemented
the
instruction
class
and
generator
framework.
The
constrained
random
program
generation
is
done
with
the
ability
to
mix
in
random
and
directed
instruction
streams
for
rv
32i.
You
know,
mcdfda
also
multi-heart,
program,
execution
and
most
directed
streams
are
supported.
F
We've
implemented
the
rv32i
coverage
model
for
32-bit
instructions,
and
it's
also
been
integrated
into
the
end-to-end
flow.
Future
work
for
this
year
includes
support
for
64-bit
instructions,
extending
the
functional
coverage,
support
for
all
instructions,
support
for
different
privilege
levels,
user
supervisor
and
eventually
we
want
to
reach
full
parity
with
the
system.
Verilog
based
generator.
F
Perfect,
so
the
pmp
enhancement
are
epmp,
so
for
those
of
you
that
are
not
familiar
with
the
proposal,
the
original
pmp
is
meant
to
protect
internal
memory
ranges.
Ie
memory
accesses
are
checked
for
access
to
a
particular
user
or
lesser
privileged
mode,
but
I'm
summarizing
from
the
proposal
here,
but
with
with
the
current
spec.
If
we
want
a
pnp
to
be
enforced
on
a
non-machine
mode
and
denied
on
a
machine
mode
so
that
we
can
only
allow
access
to
a
memory
region
by
a
less
privileged
mode.
F
The
current
pmp
spec
doesn't
have
that
option,
so
the
enhanced,
pmp
or
epmp
proposes
a
new
csr
that
can
bypass,
update
or
enforce
existing
pmp
rules.
We
plan
to
implement
support
for
this
in
risc-v
for
this
register.
We
want
this
support
to
be
modular
so
that
we
can
maintain
backwards.
Compatibility
with
the
original
pmp
spec,
and
we
have
an
immediate
in
use
case
that
we
can
test
this
with
the
ibex
core
for
the
open,
titan,
router
trust
chip.
F
F
The
quality
and
the
value
of
the
contributions
is
a
function
of
the
feedback
and
guidance
we
get
in
particular
from
the
work
group
discussions.
So
if
you
have
anything
to
add,
please
join
us.
There's
a
link
to
the
mailing
group.
Here,
that's
what
we
use
for
the
correspondence
says
agenda.
You
know
if
we
have
to
cancel
a
meeting
or
postpone
a
meeting.
We
we,
you
know,
share
that
information
through
the
mailing
group.
There's
a
link
in
the
slides
and
our
next
meeting
is
this
friday.
A
Thank
you
so
much.
I
really
appreciate
it.
It's
very
informative
about
presentation
matt,
so
we
do
have
a
couple
minutes
for
questions,
so
I
don't
have
any
from
the
audience
yet,
but
I
will
kick
off
with
one
question.
I
was
curious
as
to
how
continuous
integration
has
worked
in
practice
for
you
and
also
if
it
leverages
cloud
computing.
F
So
it
does
leverage
cloud
computing,
it's
actually
hosted
on
google
cloud
instances,
it
works
pretty
good.
We've
had
a
few
hiccups,
you
know,
and
most
of
those
were
really
just
related
to,
I
think
getting
the
proper
accesses
for
github
so
that
metrics
could
pull.
You
know
the
the
top
of
tree
version
and
fold
it
into
the
test
bench
that
we
that
we
were
using.
So
it's
worked
pretty
good.
A
Appreciate
that
so,
but
we
will
be
publishing
the
slides
after
the
event.
So
for
those
that
wish
to
refer
to
them,
they
will
be
out
there
and
I
have
a
question
from
the
audience
which
is:
is
there
any
direct
method
to
transform
and
execute
the
programs
written
in
cpu-based
python
program
on
risk,
5,
cpus.
H
Yeah,
so
I
think
I
think,
if
I'm
understanding
the
question
correctly.
Basically,
the
python
based
generator,
is
just
able
to
generate
an
assembly
program
as
well
and
that
can
directly
be
fed
into
you
know
an
iss
and
compiled
and
loaded
into
a
a
verilated
test
bench
as
well.
So
the
same
execution
methods
are
still
available,
but
this
is
you
don't
have
to
rely
on
having
an
eda
simulator
that
requires
you
know
expensive
licenses
and
so
on
to
actually
be
able
to
use
this.
So
the
same
methods
of
simulation
are
available
as
well.
H
Pack,
I
make
this
one
also
as
of
right
now
we're
actually
experiencing
some
performance
hiccups
due
to
the
pi
vsc
library
that
we're
using,
which
is
developed
by
an
external
github
contributor,
basically,
and
so
there's
some
issues
with
how
it
implements
its
rent.
It's
a
randomization
constraint
solver,
which
is
causing
a
lot
of
performance
slowdowns.
F
A
A
I
I
I
We
are
effectively
kind
of
an
open
source
business,
that
kind
of
flourishes
in
building
new
workflows
and
new
design
methodologies
based
on
open
source,
and
then
we
use
them
to
build
products
for
customers
in
various
fields,
and
so
we
span
a
wide
range
of
hardware
software
stuff.
But
of
course,
today
we're
also
going
to
specifically
focus
on
fpgas
and
asics
as
well
as
tooling,
which
is,
of
course,
a
big
chunk
of
our
work
for
our
clients.
I
So
now,
how
can
you
actually
enable
faster
innovation?
How
can
you
enable
more
of
it
in
this
pretty
complex
space?
So
chips
alliance
is
trying
to
achieve
that
with
various
activities,
and
I
chose
to
break
it
down
into
five
groups
of
things.
So
how
do
we
enable
those
open
source
flows?
How
do
we
kind
of
help
people
scale
into
real
real
life
projects
in
asic
and
fpga
development?
I
First
up,
I'm
gonna
talk
about
like
enabling
scalable
and
hybrid
cloud
computation,
which
is
necessary,
of
course,
for
just
kind
of
making
these
very
heavy
flows
work.
Secondly,
broadening
the
outreach
to
cover
you
know
more
people
that
can
be
attracted
to
this
very
interesting
space,
which
is
currently,
of
course,
a
little
bit
niche
as
compared
to
other
things.
Thirdly,
you
know
bridging
things
that
already
exist,
but
perhaps
haven't
really
been
benefiting
much
from
the
open
source
innovation.
I
At
the
same
time,
so,
starting
with
enabling
computation
at
scale
for
eda
development,
we've
been
working
with,
google
and
others
to
you,
know
enable
the
workflows
that
are
needed
in
the
cloud
to
build
complex
designs
and,
of
course,
as
you
know,
eda
related
flows
take
up
a
lot
of
time
and
complexity
and
and
they
involve
a
lot
of
tools,
many
of
which
are
not
open
source.
So
the
challenge
here
is
that
you
need
to
combine
various
things
coming
from
various
worlds.
You
need
to
make
sure
that
these
things
scale.
I
I
The
flexibility
offered
by
custom
runners
is
really
useful
and
what
we've
done
is
we've
container
enabled
containerized
builds
with
virtualizations
inside
our
own
cloud.
We've
also
made
it
work
with
google
cloud,
because
it's
a
collaborative
project
with
them,
so
you
can
essentially
manage
jobs
in
between.
I
So,
of
course
those
all
those
heavy
flows
need
some
kind
of
ability
to
present
and
analyze,
whatever
you've
done
and
we've
been
implementing
bits
and
pieces
that
were
needed
to
help
integrative
systems
such
as
the
google
build
event
server,
so
that
you
can
basically
take
those
results
of
your
ci
bit.
An
internal
ci,
or
perhaps
this
github
action
ci
with
the
custom
runner
integration
and
pushing
it
to
whatever
sync
that
gathers
the
results
and
enables
other
people
to
view
them.
I
We
can
enable
custom
visualizations
like
usage
of
resources,
viewing
of
artifacts
in
specific
ways.
We
can
have
unlimited
storage,
both
in
terms
of
you
know,
amount
of
storage,
but
as
well
as
the
time
we
can
store
results
for
and,
generally
speaking,
this
is
a
very
vibrant
space.
The
best
protocol
itself
was
created
for
for
bazel,
which
is
also
a
very
interesting
tool.
I
Another
thing
I
want
to
talk
about
in
this
chunk
of
my
presentation
is
about
containerization
about
packaging,
so
in
order
to
enable
people
to
use
the
tools
that
we're
working
on
you
need
stable
reproducible
builds.
You
need
stuff
that
you
can
just
download
and
start
working
with,
so
we've
been
working
on.
You
know
packaging
things
into
docker
containers
into
conda.
I
It's
a
very,
of
course,
large
endeavor
that
takes
a
lot
of
people
and
it's
collaboration,
so
so
we're
working
on
some
aspects
of
this
google,
efables
and
and
people
like
uni
and
martinez.
Coral
are
helping
out
and
generally
speaking,
it's
a
very
vibrant
community
that
we're
building
there
with
the
help
of
chips,
and
you
can
take
a
look
at
the
hdl
organization
on
github.
That's
where
you
find
many
of
our
packaging
related
stuff.
Also,
we've
been
working
a
lot
on
eagle
eyes
of
olaf,
of
course,
and
and
the
fast
foundation.
I
So
the
next
thing
you
need
to
do
to
actually
enable
all
those
open
source
flows
is
making
sure
that
you
invite
the
right
people
to
the
table
that
you
brought
in
the
outreach.
And
basically,
we
were
looking
at
how
to
really
make
open
source
city
design
happen,
and,
ironically,
part
of
that
is
that
you
need
to
make
asics
more
like
software,
because
software
is
the
very
vibrant
space
that
you
want
to
attract
talent
from
you
want
to
attract
this
innovation
and
new
ways
of
thinking
about
design.
I
So
fpgas
is
one
thing
that
enabled
that
new
hdls
and
new
methodologies
is
another,
and
the
fpgas
are
actually
an
important
entry
point
into
a6,
a
lot
of
people
that
interest
get
interested
in
asics.
They
can't
really
build
an
asic
at
home,
so
instead
they
go
into
fpgas,
but
the
flows
in
fpga
are
also
closed
and
and
it's
a
fairly
niche
technology
anyway,
as
compared
to
you
know,
system
on
chips.
I
So
we're
kind
of
trying
to
change
that
and
we're
trying
to
make
sure
that
fpgas
are
also
open
because
open
source,
fpg
design,
open
source
development
boards
are
key
to
generating
enthusiasm
about
asics
and-
and
you
can
take
a
look
at
the
risk.
Five
context
contest
example
that
we
organized
a
few
years
ago
how
you
can
make
that
happen
by
going
into
asic
through
fpga.
I
So,
of
course,
sim
flow
is
one
of
the
key
projects
in
this
space.
It's
a
fully
open
source
tool
sheet
for
fpga
development
and
want
to
provide
an
end-to-end
and
vendor
neutral
flow,
because
of
course,
you
want
to
pull
those
engineers
from
you
know
all
those
islands
of
platforms
that
they're
working
on.
We
want
to
make
fpga
development
more
software-centric
with
simbiflow,
more
collaborative
and
we've
already
accomplished
a
lot
of
cool
stuff,
especially
a
niche
scenario.
I
I
We
want
to
make
them
something
that
you
just
use
for
a
configurable
silicon,
because
why
not-
and
one
of
the
successes
we've
had
here
in
the
space
is
the
collaboration
of
quick
logic
where
we've
developed
an
open
source
tool
chain
with
their
support,
which
is
kind
of
first
in
the
industry.
The
tutoring,
of
course,
was
the
key
part,
but,
like
we
also
enabled
a
lot
of
other
things
in
bristol
and
other
communities,
we
enabled
zephyr
rtos,
portland's,
open,
ips,
created
renault
support
and
so
on,
and
so
on.
I
I
We
want
to
make
fpgas
just
much
more
widespread,
and
last
thing
I
want
to
mention
here
is:
is
chisel,
of
course,
and,
and
you
know
all
the
related
work
in
new
hdls,
all
those
ideas
that
you
can
borrow
from
mainstream
software
development
are
kind
of
channeled
through
things
like
chisel
into
you,
know,
other
areas
and
chips
alliance.
In
general,
we
have
a
working
group
for
chisel.
That
is
a
vibrant
space
for,
for
this
kind
of
development.
Borah
has
already
described
a
lot
of
this.
I
So
okay,
we
have
new
methodologies
and
we
want
to
enable
new
people.
But
how
do
we
kind
of
also
reuse?
Whatever
has
been
done
before?
We
need
to
bridge
existing
things,
so
we
need
to
make
it
easy
to
combine
and
remix
stuff
that
already
exists,
and
we
saw
a
problem
here,
namely
there's
a
lot
of
great
open
source
tools
that
could
bring
value
to
asus
design,
but
unfortunately
it
wasn't
so
easy
to
interface
them
with,
for
example,
system
verilog,
which
is
broadly
used
in
the
industry.
I
So
we've
been
kind
of
tackling
that
problem
and
we
have
great
progress
here.
So
why
would
you
need
open
source
system
verilog
support?
Well,
a
lot
of
groups
use
system
very,
like
open,
titan
chips
alliance.
You
know
western
digital
designs
like
square,
even
ibex
are
in
a
system
very
log,
so
we
just
need
to
somehow
make
it
happen
and
also
the
the
risk
five
dv
update,
probably
kind
of
made.
I
You
realize
that
it's
an
important
thing
and
we
basically
took
this
approach
where
we
can
first
measure
so
we've
created
a
test
suite
for
system
verilog
tools
that
we
can
kind
of
measure
the
current
support
of
system
verilog
in
various
open
source
tools,
and
you
can
go
to
sv
tests
the
links
here
to
to
see
a
dashboard
that
we
can
generate
to
show
the
current
support.
But,
of
course
that's
the
dashboard.
I
But
of
course,
we've
also
been
working
on
improving
the
situation
and,
together
with
google
and
the
low
risk
and
open
titan
teams,
we've
been
actually
working
on
projects
such
as
sherlock
and
uhdm,
where
we
have
really
great
successes,
we've
been
able
to
simulate
and
synthesize
the
open,
titan
designs
with
fully
open
source
tools.
You
can
take
a
look
at
that
on
github,
so
that's
the
diagram
of
how
it
works
uses
the
uhdm
library.
I
The
last
thing
in
this
section
is
about
open
source
uvm,
which
we're
trying
to
enable
together
with
western
digital
and
and
chips
alliance
in
general,
we're
implementing
dynamic
scheduling
and
verilator,
which
is
the
first
step
to
getting.
You
know,
partial
uvm
support
and
we've
very
good
progress,
so
watch
this
space
as
well
for
for
updates
very
soon
about
being
able
to
do
some
simple
uvm
stuff.
I
So
we've
been
working
on
projects
that
enable
you
know,
rapid
innovation
in
in
this
space,
there's
still
a
lot
of
things
happening,
but
not
so
much
open
source,
actual
implementation,
which
I
think,
tools
like
aib
and
frameworks
like
ab,
are
trying
to
change
so
great
kudos
to
intel
for
releasing
their
aib
chiplet
specification,
as
well
as
implementation
into
the
chips
alliance.
There's
going
to
be
a
talk
about
this
later
today,
but
it's
a
great
you
know:
high
performance,
chiplet
implementation,
that's
being
adopted.
I
I
I
One
of
the
things
that
we've
been
doing
ourselves
is
also
a
simulator
called
reno,
that
is,
enabling
people
to
create
designs
from
building
blocks
and
do
various
interesting
things
and
simulate
entire
socs.
Before
actually
implementing
them
and
we've
been
enabling
things
like
co-simulation,
with
verilater
to
quickly
prototype
different
solutions,
we've
been,
of
course,
also
implementing
consolidation
with
fb
with
physical
fpgas.
I
That's
also
a
way
to
break
down
the
complexity
and
bring
in
software
developers
into
the
space
and
make
sure
the
problems
we're
trying
to
tackle
are
easier
and
the
last
part
and
I'll
be
kind
of
writing.
Now.
This
talk
with.
How
do
we
enable
collaboration-
and
I
think,
that's
kind,
of
course,
the
most
important
part
and
risk
five
has
demonstrated,
of
course,
that
ac
design
can
be
collaborative.
But
in
order
to
to
make
that
happen,
we
need
a
lot
more
than
just
cores.
I
One
of
the
things
that
you'll
also
hear
about
today
is
the
open
source
pdk.
It's
a
white
collaboration
between
multiple
entities
and,
as
the
first
you
know,
open
source
pdk,
even
though
it's
130
nanometer.
This
is
a
very,
very
important
thing
to
happen,
because
this
enables
open
sourcing
other
things.
Wherever
you
have
tools,
interface
with
all
of
that
stuff
is
typically
very
close
and
very
proprietary,
and
without
an
open
source
pdk,
it's
very
hard
to
create
examples
that
can
be
actually
used
to
manufacture
chips
that
can
be
published
online
without
problems.
I
Skywater
pdk
is
solving
that
and
watch
out
there's
going
to
be
more
in
that
space,
there's
going
to
be
a
90,
nanometer,
pdk,
upcoming
and
and
better
stuff
after
that,
so
definitely
listen
to
tim
ansel's
talks
later
and
on
top
of
the
open
source
pdk.
There's
an
open
shuttle
program.
People
can
make
chips
and
it's
free
for
them.
There's
been
dozens
of
participants,
including,
of
course,
on
micro
building,
various
risk.
I
And
of
course,
this
talk
wouldn't
be
complete
without
mentioning
open
road,
which
is
you
know,
a
fully
open
flow
that
you're
also
going
to
hear
more
about
today
from
andrew
kang
and
tom
spyro.
So
I
won't
get
into
details
and,
of
course
you
need
open
source
ap,
but
that's
perhaps
a
topic
for
for
yet
another
talk,
one
of
the
things
that
have
happened
very
recently
and
I
think
it's
worth
sharing.
It's
we've
just
established
an
analog
working
group,
so
we're
not
just
about
digital
design.
It's
also
mixed
signal.
I
I
This
is
led
by
university
of
michigan
as
well
as
university
of
virginia
and
arm.
So
this
is
a
fully
open
flow.
I
mean
as
open
as
it
gets,
perhaps
at
this
point,
with
both
a
focus
on
digital
but
also
analog,
and
we
want
more
analog
related
tools
in
chips
alliance
to
make
sure
that
the
entire
space
is
covered.
I
So
summarizing,
there's
a
lot
of
work
to
be
done,
but
a
lot
of
stuff
is
is
going
really
well.
We
need
this
collaboration
between
the
asic
and
the
fpga
design.
Space
and
chips
alliance
is
playing
a
key
role
in
this.
You
can
also
get
support
in
building
real
stuff
in
this
space.
If
you
want
to
do
that,
go
and
talk
to
us,
we
can
help
you
get
commercial
support,
integrate
tools
and
implement
real-life
use
cases,
and
through
this
we
can
of
course
improve
the
ecosystem
so
happy
to
talk
to
you
afterwards.
A
A
The
next
talk
is
in
fact
about
the
aib
chippewa
ecosystem
that
dave
kellett
will
be
sharing
from
intel.
I
think
this
is
a
very
interesting
technology
that
they
have
put
into
the
open
source
community
and
I
think
it
really
opens
up
a
lot
of
opportunity
for
innovation.
So
with
that
dave,
take
it
away.
G
G
56
years
ago
gordon
moore
wrote,
it
may
prove
to
be
more
economical
to
build
large
systems
out
of
smaller
functions
which
are
separately
packaged
and
interconnected.
This
was
in
the
same
paper
where
he
articulated,
what's
known
as
moore's
law,
so
that
the
chiplet
idea
has
been
developing
for
a
long
time.
In
the
last
few
years,
technology
has
reached
a
point
where
triplets
are
practical
solutions.
G
In
my
presentation
today,
I'm
going
to
talk
about
how
chiplets
are
being
used,
just
as
gordon
moore
predicted,
I'm
going
to
cover
what
we're
doing
with
the
ship
project
that
we
have
with
the
us
government,
especially
about
aib
2.0
and
a
new
version.
We
call
aibo
we're
planning
open
source
release
of
protocol
ip
to
run
on
top
of
aib
for
the
purpose
of
increasing
interoperability,
and
then
I
will
wrap
it
up.
G
Multiple
companies
are
building
chiplets,
a
recent
article
in
semiconductor
engineering,
listed
20,
aib
chiplets
in
production
or
in
development
coming
from
seven
different
organizations.
In
addition
to
intel
the
standardization
effort
that
on
aib,
that
darpa
started
is
enabling
interoperability,
and
so
with
that
base
we're
now
starting
on
some
second
generation
concepts
like
security.
G
You
may
have
heard
last
fall
that
intel
was
awarded
the
second
phase
of
the
state-of-the-art
heterogeneous
integration
prototype
program
called
ship.
The
project
is
enabling
the
us
government
to
access
the
state-of-the-art
packaging
capabilities
at
intel.
Much
of
the
effort
with
ship
is
about
opening
up,
intel's,
advanced
packaging
and
manufacturing.
My
part
is
about
chip,
security,
interface
standards
and
protocols.
G
G
G
G
G
G
G
The
net
result
of
this
is:
we
can
hit
over
seven
terabits
per
second
per
interface,
even
at
a
relaxed
4
gigabits
per
second
per
wire.
Now,
with
all
this
bandwidth,
we
need
to
be
concerned
about
power.
This
is
addressed
by
using
low
swing
drivers
to
get
a
target
energy
per
bit
of
half
a
picojoule
and
with
all
the
aib
silicon
portfolio
from
intel.
Other
manufacturers
compatibility
with
aib
1.0
is
a
must-have.
G
G
So
we
have
an
open,
spec
and
an
open
draft
process.
You
can
read
the
open
spec
at
the
the
link
on
the
screen
here,
we're
developing
an
aib
2.0,
hard
macro
in
intel,
22
ffl
silicon
technology
with
a
company
called
analog
blue
cheetah
and
one
of
the
first
things
people
need
to
use.
Aib
is
the
logic
simulation
model.
We
just
posted
an
open
source
ab
2.0
simulation
model
under
the
chips
alliance,
github
repository.
G
Today,
I
want
to
introduce
a
version
of
aib:
that's
optimized
for
standard
packaging.
We
call
it
aibo
aab
for
standard
organic
substrate
packaging.
Now
aibo
is
a
subset
of
the
ab
2.0
capability
using
the
bump
spacing
that
standard
packaging
allows.
The
reason
to
do
this
is
that
standard
packaging
substrates
are
more
broadly
available
than
advanced
packaging.
G
Also,
you
have
many
choices
for
package
assembly
with
osats
three
years
ago,
I
gave
a
talk
about
how
you
might
design
differently
when
wires
are
free,
which
is
what
almost,
what
advanced
packaging
gives
you,
but
with
standard
packaging
wires
are
definitely
not
free
and
we
have
to
conserve
still.
I
think
there
are
applications
that
don't
need
the
highest
capability
and
for
these
standard,
packaging
density
will
work.
Just
fine.
G
With
aibo,
we
have
the
same
concept
of
channels
that
we
have
with
aib.
We
just
drop
the
number
of
data
bits
in
each
direction
from
40
down
to
10,
so
the
array
is
approximately
the
same
area
on
the
die
as
it
was
before
now,
since
we're
using
standard
packaging.
The
density
drops
by
a
factor
of
4.,
so
instead
of
a
ib
2.0
7.68
terabits
per
second,
we
get
a
quarter
of
that
1.92
terabits
per
second
and
and
just
like
aab
2.0.
G
G
G
G
G
G
Now
each
side
needs
to
know
how
the
protocol
is
mapped
to
the
aib
interface,
so
we're
providing
the
pro
protocol
adapter
pair
to
users.
They
see
the
familiar
protocol
interfaces
that
people
have
used
for
years,
like
axis
stream
and
xc4,
and
by
providing
the
protocol
ip
on
both
sides.
We
make
sure
the
mapping
to
the
aib5
is
understood.
G
We
originally
thought
about
using
the
pc
express
pipe
interface,
but
it
makes
more
sense
to
use
the
forward
looking
lpif
interface
as
cxl
starts
to
ramp
up
now.
The
really
important
part
is
is
that
as
part
of
the
ship
project,
the
protocol
adapter
code
will
be
released
as
open
source
under
our
chips
alliance.
Github
repository,
we'll
use,
apache
2.0
licensing,
so
this
is
freely
available
to
anyone.
A
G
So
if
your
silicon
interoperates
with
my
silicon,
we
together
can
meet
a
broader
set
of
customer
requirements
and
I
thought
I'd
kick
off
the
q,
a
with
a
question
I
received
on
friday
and
it
was,
it
was
kind
of
direct
and
it
was
why
should
I
use
aib
over
one
of
the
other
dietary
interface
ideas
and
and
I'd
say
that
there's
three
reasons
for
this:
the
first
one
is
aib
is
proven
in
silicon.
It's
in
production.
G
A
A
I
do
have
one
question:
thank
you
very
much
for
an
excellent
update.
I
appreciate
it.
The
question
I
have
from
the
audience
is:
could
you
take
a
moment
to
explain
the
rationale
behind
the
current
race
to
make
chips
smaller
and
smaller
to
seven
nanometer
down
to
three
nanometer
prototypes,
while
until
recently
130
nanometer
was
all
right?
This
has
caused
a
rush
to
one
or
two
fad
facilities
in
the
world.
A
What
is
achieved
by
this
condensation
are
there
benefits
in
exact
proportion
as
a
200
nanometer
chip
used
100
times
as
much
electricity
as
a
two
nanometer
chip,
and
it
had
a
hundred
times
as
much
latency
as
a
two
nanometer
chip.
How
important
is
it
to
aim
to
make
all
processors
in
sub
10,
nanometer
architecture.
G
G
That
is
just
well
suited
for
that
application
and,
and
it
doesn't
need
to
be
a
you-
know-
seven
nanometer,
five
nanometer
pro
process.
So
I
think
that
the
the
heterogeneous
integration
is
extremely
valuable
and
it
does
have
a
great
place
to
use
a
span
of
process
nodes.
All
the
way
from
you
know
the
most
recent
highest
density
to
things
where
there
are
some
specialty
functions
or
io
that
that
could
use
a
much
more
relaxed
geometry.
A
G
Okay,
so
the
the
the
maturity
of
the
design
process.
You
know
the
the
stratix
10
powered
on
in
2016,
and
so
that
used
aib
1.0.
It
used
a
intel,
advanced
packaging
technology,
so
we've
got
got
five
years
of
experience
on
that.
There
are
other
advanced
packaging
technologies
such
as
interposers,
there's
a
lot
of
interesting
work
being
done
in
rdl
or
or
fan
out
technologies
to
reduce
the
the
cost
of
a
very
high
density
packaging.
J
And
just
to
refresh
everyone's
memory
in
2018,
western
digital
was
faced
with
a
dearth
of
high
performance
interconnects.
That
would
allow
us
to
connect
very
low,
latency
high
performing
kinds
of
memories
like
magnetic
ram
to
the
prevailing
compute
architectures
in
a
data
center,
and
it
was
a
strategic
problem
for
us.
Since
faced
with
this
rapid
rise
of
the
risk
five
ecosystem,
we
proposed
a
new
format
or
new
standard
interconnect
which
wasn't
all
that
new
right.
J
Our
proposal
was
to
try,
in
this
period
of
the
open
sourceness
of
the
risc
5
ecosystem,
to
also
use
a
completely
open
fabric
such
as
ethernet
for
transporting
coherence.
In
other
words,
we
wanted
a
completely
unencumbered
modern,
high
bandwidth,
low
latency
bus
to
connect
not
just
cpus
excited
to
socket
buses,
but
also
all
these
other
kinds
of
devices
to
its
storage
in
our
case,
but
also
gpus,
fpgas,
accelerators
and
other
kinds
of
isas.
J
In
a
way
that
is
not
asymmetric,
like
you
know,
peripherals
buses
like
pci,
express
and
cxl
and
so
forth.
So,
in
other
words,
the
idea
would
be
that
a1
cpu
would
not
own
the
architecture
of
your
data
center
you'll
be
allowed
to
create
a
more
heterogeneous
architecture
out
of
despair,
components
that
are
assembled
in
a
way
that
fits
the
algorithm
and
the
purpose.
J
And
then
you
have
a
network
interface
card
which
is
a
dma
engine
and
then
typically,
you
have
some
sort
of
software
that
manages
the
so-called
fabric,
and
this
fabric
exposes
some
large
amount
of
memory
that,
basically,
you
have
to
run
your
local
software
to
fetch
blocks
pages
or
whatever
you
want
to
call
them.
And
then
your
nic
does
the
data
transfer
and
the
dma
engine
stuffs
it
in
dram,
and
then
you
have
to
load
it
through
the
cache
to
your
compute
pipeline.
B
J
The
the
sort
of
intermediate
solution
that
some
folks
played
with
in
particular
gnz
was
this
idea
that
you
have
some
sort
of
online
translation
that
happens
very
fast,
and
then
you
go
with
the
loads
and
stores
into
the
fabric,
to
fetch
your
data
and
store
your
data.
So
just
to
be
clear.
What
we
proposed
was
actually
a
full
clash.
Coheres
protocol,
like
the
protocols
that
go
between
sockets
on
many
computer
architectures
today,
but
they
will
go
straight
into
the
fabric.
In
this
case,
this
was
ethernet.
J
Other
containers
were
infiniband
other
high
performance
fabrics,
and
then
you
basically
fetch
cache
lines
straight
into
your
cache,
so
your
local
cpu
wouldn't
even
have
to
have
year
on
controller
or
low
speed
of
adherence,
and
this
is
illustrated
by
this
pt
here,
which
indicates
page
tables.
So
the
idea
was
that,
whatever
your
paging
mechanism,
that
your
cpu
or
your
os
use,
the
page
tables
might
be
sitting
on
the
other
side
of
the
fabric,
so
your
whole
fabric
will
be
hitting
like
one
single
computer.
J
Now,
what
we
envisioned,
like,
I
said,
was
a
completely
asymmetric.
Sorry,
a
completely
symmetric
interconnect,
and
so
these
little
noodles
represent
socs
that
a
lot
of
you
folks
are
taping
out
where
you
have
the
encore
with
a
bunch
of
local
facilities.
And
then
you
have
a
bunch
of
cores
that
talk
through
some
sort
of
a
local
on-chip
coherence,
bus
which,
in
the
risk-fire
world
was
tilink
traditionally,
and
the
idea
was
that
you
could
connect
two
of
these
socket
to
socket
via
this
on
the
extend
ethernet
fabric.
J
Or
you
could
connect
one
of
these
to
a
peripheral
that
would
contain,
for
instance,
a
non-volatile
memory,
a
high
performing
memory
that
would
appear
as
the
lowest
point
of
coherence
and
as
basically,
you
plug
this
into
your
soc
and
the
soc
will
just
see
drm
or
something
that
looks
like
drm
right.
But
more
to
the
point.
J
So
to
bring
you
up
to
speed,
we
published
a
protocol
called
omni
extend.
There
was
a
version
0.1
that
was
shown
off
in
december
2018
at
at
a
trade
show,
and
it
was
based
on
thailand
one
seven,
since
we've
actually
fixed
some
bugs
in
thailand,
in
collaboration
with
sci-fi
and
tiling.
1.81,
I
believe,
is
the
current
version.
That's
available
under
creative
commons
license
online,
and
this
is
transported
over
on
extend
version
103,
which
is
also
under
creative
commons,
license
on
github.
J
J
I
want
to
point
out
that
we
started
out
with
a
protocol
that
was
relying
on
these
custom
switches
that
will
allow
you
to
reprogram
the
ethernet
header
for
better
performance
and
so
on.
But
since
there
have
been
some
margins
and
movements
in
the
industry
and
we've
decided
to
revert
back
to
a
health,
ethernet
l2
compliant
header,
so
you
can
use
any
switch
any
of
the
shell
switch
like
a
broadcom
switch
or
even
these
very
inexpensive
switches.
You
can
get
off
amazon
for
100
bucks.
J
J
So,
just
to
point
out
again,
you
can
download
this
for
vcu,
not
118.
It
runs
very
stable
in
lab
and
it's
an
fpg
implementation
at
100
megahertz.
It's
a
sci-fi,
u5
risc-v
core
that
was
based
off
of
the
rocket
chip
developments
all
right.
These
are
some
performance
numbers.
Keep
in
mind.
This
is
fpga,
so
this
is
very
high
latency
in
general,
because
the
clock
rate
is
very
low.
J
J
All
right.
So
I
wanted
to
use
the
rest
of
the
time
to
bring
you
up
to
date
on
the
developments
with
this
on
the
extent
also
on
the
discussions
for
the
future
tiling
the
discussions
of
the
future
on
the
extent
so
the
first
thing
that
is
going
to
be
interesting
to
those
of
you
folks
who
are
hoping
to
attach
accelerators
to
on
the
extent
of
labeled
socs,
is
that
we
are.
We
have
developed
a
lowest
protocol
as
rtl.
That
is
going
to
be
fully
open
sourced.
J
This
is
at
the
moment,
is
based
on
a
standard
board
from
xilinx
alveolar
view
50,
it's
at
hpm
board
with
8
gigabytes
of
hpm,
and
you
will
be
able
to
run
a
storage
device
simulation
that
story
device
which
it
attaches
directly
to
on
the
extent.
So
it
essentially
shows
up
as
a
lowest
coherence
and
you
simply
get
a
memory
region
that
is
at
this
time,
backed
by
hbm.
J
But
this
rtl
is,
like
I
said,
going
to
be
fully
open
source.
Then
you
will
be
able
to
run
simulations
of
different
kinds
of
future
memory
technologies
by
simply
slowing
down
the
memory
or
introducing
algorithms
to
capture
the
idiosyncrasies
of
memory
such
as
flash
magnetic
ram,
resistive
ram,
and
so
on.
J
The
other
thing
that
we're
working
on
hard
is
what
we
call
beyond
intel
architectures,
with
apologies
to
our
co-op
editor.
So
these
are
things
that
you
cannot
do
with
current
off-the-shelf
hardware
right.
So
one
of
the
things
that's
been
generally
difficult
to
achieve
with
non-exotic
hardware
is
more
than
four
sockets
in
the
risc-five
world
off
the
shelf
for
sky
world.
J
So
far,
there
aren't
really
multiple
sockets,
so
omni
extend
is
your
only
game
in
town
if
you
want
to
play
with
scale
out
to
risk
five,
but
we're
hoping
to
show
pretty
soon
systems
with
up
to
64
sockets
of
one
switch.
And
then
there
are
efforts
to
understand
the
capabilities
of
these
smart
switches
to
have
the
switch
terminate
the
protocol
and
then
have
multiple
multi-switch
systems
that
enable
scale
out
to
in.
J
Unlimited
number
of
sockets
in
practice,
it's
limited
by
financing
right
and
then
another
thing
that
is
happening.
So
I
briefly
mentioned
we
have
a
boot
protocol
defined
now
that's
defined
online
on
github,
so
the
wood
protocol
allows
you
to
configure
the
endpoints
to
behave
as
any
kind
of
identity
right.
J
So
I
think
the
thrust
of
the
scale
out
efforts
at
the
moment
is
on
on
these
independent
os
systems
at
the
moment,
simply
because
the
change
is
required
to
say
linux,
kernel
and
the
infrastructure-
and
you
know
the
software
infrastructure
right,
the
the
signaling
to
the
user
process
of
failures
and
fault
alerts,
and
so
on
are
fairly
daunting
right.
So
we
will
probably
start
out
with
independent
os's
that
handle
or
try
to
handle
gracefully.
J
J
I
just
wanted
to
briefly
mention
the
discussions
that
have
commenced
about
the
2.0,
what
we
call
2.0.
So
a
lot
of
folks
have
complaints
about
thailink
that
it
doesn't
perform,
or
it
doesn't
do
this
or
doesn't
do
that.
Some
of
those
complaints
are
well
funded
and
there
have
been
discussions
among
us
here
in
western
digital
research
and
with
sci-fi
and
with
many
other
groups
of
what
this
should
look
like
going
forward
in
the
future.
J
So
I
just
wanted
to
point
out
that
the
current
focus
of
us
in
western
digital
research
is
actually
on
scale
out
and
fault
tolerance
right.
So
it's
not
necessarily
we're
not
necessarily
looking
at
raw
matchmak
performance
of
multi-socket
systems
in
risk
five.
We
think
there
are
a
lot
of
you
who
are
interested
in
this
and
there
are
probably
going
to
be
some
developments
here.
J
So
our
main
you
know,
thrust
of
these
efforts
is
basically
on
having
many
many
storage
devices
attached
to
single
cohere
in
the
main
and
then
fault
tolerance
when
they
wear
out
where
they
fit
when
they
fail,
when
somebody
unplugs
the
cable
and
so
on.
So
that's
why
we're
kind
of
focusing
on
the
independent
os
model
right
now
and
on
figuring
out
to
communicate
no
loss
to
user
processes,
so
you
don't
have
to
bring
the
whole
cluster
down
when
one
device
fails
or
wears
out,
and
so
I
think
I'm
just
about
out
of
time.
A
Thank
you
so
much
dejan,
so
very
good
talk.
I
appreciate
it.
One
question
I
just
had
from
my
side,
which
was
in
terms
of
architectural
modeling,
with
on
the
extend.
Is
there
any
capability
of
being
able
to
model
two
different
pieces
of
cpu
or
accelerators
together
or
how
is
that
better,
any
comments
you
might
have.
J
E
J
To
model
the
entire
cpu
pipeline,
the
entire
behavior,
all
the
caches
in
the
system,
the
serialization,
the
quirks
of
the
fabric
and
then
the
behavior
of
the
whole
system.
So
we're
not
quite
there
yet
right.
We're
making
strides
piece
by
piece,
and
one
thing
that
was
sorely
missing
was
the
network
part,
and
this
is
where
we
made
the
biggest
strides,
and
this
is
the
qemu
framework
for
emulating
the
actual
protocol
communication
and
so
on.
J
So
the
there
are
there's
this
whole
framework
for
emulating,
p4
switches
straight
and
formulating
loss
of
packets
and
so
on,
and
you
have
an
entire
software
switch
that's
available
for
free,
it's
completely
open
source
and
we've
leveraged
this
to
introduce.
You
know
coherence,
endpoint,
emulation
on
this,
and
I'm
not
sure
if
the
entire
thing
is
open
source,
but
we're
planning
to
open
source
all
this
stuff.
J
It's
built
on
open
source
infrastructure,
so
you
will
be
able
to
basically
take
you
know
frozen
traits
of
coherence,
commands
coming
out
of
your
pipeline
or
out
of
your.
You
know
last
level
cache
and
just
introduce
them
into
this
network
simulation
system
and
then
introduce
packet
loss
and
see
what
happens
right
now.
J
The
the
the
question
was:
can
you
get
from
software
to
there?
So
this
is
a
much
more
difficult
problem
where
you
sort
of
need
to
simulate
the
entire
cache
hierarchy,
where
we
don't
really
have
much
to
offer
like.
There
are
many
of
you
who
have
much
more
elaborate
infrastructure
for
simulating
caches
and
state
machines,
and
so
on.
A
J
So
let
me
try
to
parse
this
unified
memory
standard
right.
The
the
word
memory
is
perhaps
overloaded
right,
so
we
will
have
we
we're
proposing
a
unified
coherence.
Protocol
standard
right
now.
Coherence
protocol
is
an
overloaded
term
right,
so
it
contains
commands
or
rather
transaction
types
that
include
memory
access
and
also
the
non-memory
access
right.
So
there
are
mmio
transactions
and
coherent
transactions,
and
mmi
is
everything.
That's
non-coherent,
including
access
to
other
sockets.
You
know
interrupt
controllers
and
so
forth.
So
in
that
sense,
omni
extend
is
already
a
standard.
J
A
F
K
I
should
click
to
start
all
right.
I
should
be
able
to
control
now
excellent.
Okay.
So
let
me
start
my
timer
all
right,
hi,
everyone.
My
name
is
jack
koenig.
I
am
a
staff
engineer
at
sci-fi
and
I
am
you
can
see
the
nice
little
double
acronym
there.
I
am
a
member
of
the
chisel
working
group
technical
advisory
committee,
so
in
our
as
a
chips
alliance
project,
we
have
a
technical
advisory
committee
to
run
chisel
and
related
projects,
and
so
I'm
going
to
talk
a
bit
about
about
those
projects.
So
you.
F
K
Kind
of
letting
you
know
what
I'm
going
to
talk
about,
I'm
going
to
introduce
the
what
chisel
is
and
related
projects.
I
know
you
heard
a
little
bit
from
professor
nicolette
and
from
michael
previously,
but
I'll
I'll
talk
a
bit
about
that
as
well.
We'll
provide
some
highlights
from
the
last
six
months
since
the
last
chips,
alliance
workshop
and
I'll
talk
about
a
bit
about
what
we're
doing
going
forward,
what
to
look
forward
to
so.
First
of
all
like
what
is
the
chisel
working
group?
K
Well,
the
first
question:
there
is
what
is
chisel
and,
as
you
heard
earlier,
during
the
shipyard
talk.
Chisel
stands
for
constructing
hardware
in
a
sky-embedded
language.
It's
a
domain-specific
language
where
the
domain
is
digital
design.
That's
a
lot
of
words,
but
you
know,
verilog
is
a
domain-specific
language
where
the
domain
is
digital
design
and
chisel
is
as
well.
K
Chisel
just
differs
in
that,
rather
than
being
a
standalone
language,
it's
actually
embedded
in
another
language,
it's
embedded
in
scala,
which
is
a
general
purpose,
programming
language,
as
as
professor
nicolette
mentioned,
it
is
not
high
level
synthesis.
Nor
is
it
behavioral
synthesis.
What
it
really
is
is
you're
writing
a
scala
program
where
you
construct
hardware
objects
and
and
build
your
hardware
design.
That
way,
we
like
doing
this
in
scala,
because
scale
provides
modern
programming
language
to
things
like
parameterized
types,
object-oriented,
programming,
functional
programming
and
static
typing.
K
All
these
features
are
things
that
we
think
help
you
write.
You
know
reusable
and
maintainable
code
and
it's
intended
for
writing.
Reusable
hardware
generators
like
chip
yard
and
all
other
projects
related
projects
mentioned
in
there
as
well.
As
you
know,
others.
So
you
know
kind
of
to
give
a
brief
overview
of
what
chisel
really
is.
It's.
It's
there's
no
loss
of
expressibility
so
long
as
you're.
You're
writing.
You
know
synchronous
digital
designs,
so
this
is
a
moving
average
fir
filter
that
looks
pretty
similar
to
what
you
might
write
in
verilog.
You
have
some
inputs.
K
K
So
what
you
really
want
to
be
able
to
do
is
write
a
generic
filter,
not
just
one
specific
filter,
but
maybe
a
whole
family
of
filters,
and
so
chisel
makes
it
really
easy
to
write
a
parametrized
fir
filter.
So
I'm
not
going
to
dwell
on
this
code
here.
Please
check
out
the
drizzle
bootcamp.
If
you
want
to
really
understand
it,
but
you
write
something
that
kind
of
looks
software-y
but
in
reality
you're
just
manipulating
the
exact
hardware
constructs
you
want,
there's
no
synthesis
going
on
here.
K
You
know
how
you
know
how
much
in
the
time
domain
you're
stretching
your
filter-
and
you
know
this
is
meta
programming,
where
you're
writing
a
program
that
is
then
constructing
another
quote
program
now
that
second
program
is
the
hardware
itself,
so
not
quite
the
same,
but
you're
really
reasoning
about
constructing
hardware.
When
you
do
this,
and
so
using
this,
this
generic
filter
we're
able
to
create
that
same
moving
average
filter
just
by
parameterizing
this
one
we're
able
to
create.
K
You
know
other
types
of
filters,
a
simple
one
cycle,
delay,
filter
or
perhaps
a
triangular
filter
with
five
points.
The
point
is
that
we
wrote
this
one
filter
and
now
we
can
do
all
these
different
things,
and
so
that's
really
what
chisel
is
about.
That's
what
shipyard
is
built
on.
That's
what
sci-fi
uses
in
a
lot
of
our
technology.
So
this
is
really
what
chisel
is
about.
K
So
I
mentioned
previously
the
chisel's
about
writing
reusable
generators,
but
as
anyone
who's
done,
any
hardware
design
knows
that
that's
really
difficult
right.
As
soon
as
you
have
some
specific
platform,
you
end
up
doing
platform
specific
changes.
You
know
if
you're
doing
something
in
ibm,
45
versus
sc28
or
a
more
modern
technology.
K
You
end
up,
you
know
needing
to
do
srm,
macros
or
other
very
specialized
things
in
your
physical
design.
Similarly,
fpgas
have
a
whole
different,
a
whole
host
of
other
features,
and
so
it
it
really
breaks
reusability
when
you're
trying
to.
If
you
try
to
write
something,
that's
reusable,
but
when
you
have
to
leak
in,
you
know
platform-specific
stuff.
So
in
order
to
specialize
our
designs
for
different
platforms,
we
realized
we
needed
a.
K
You
know
a
hardware
stack
similar
to
what
you
have
in
software
right
when
you
write
c
plus
plus
you
don't
care
if
you're
writing
it,
for
you
know
for
x86
or
arm
or
risk
five,
and
we
want
the
same
thing
in
hardware.
So
what
we
did
is
we
took
it.
Chisel
2
was
pretty
monolithic
and
we
replaced
that
with
chisel
3,
which
is
chisel
as
a
language
really
just
kind
of
this
front
end
along
with
the
fertile
compiler
underneath
it
now.
K
This
is
a
gross
simplification,
because
I'm
it's
I'm
kind
of
leaving
out
a
lot
of
details
about
what
goes
on
underneath,
since
we
just
admit
verilog.
So
I
want
to
give
a
shout
out
to
all
the
other
projects
that
do
the
real
heavy
lifting
here,
especially
you
know
open
road,
varilator
and
open
fpga,
so
you
know
fertile,
which
is
you
know?
The
other
main
one
of
the
other
big
projects
in
the
chisel
working
group
is,
you
know
it's
a
compiler
that
allows
you
to.
K
Let
me
see,
I
should
be
able
to
use
a
pointer
so
allow
it
has.
You
know,
kind
of
a
your
design
is
a
abstract
syntax
tree
with
core
transformations
that
lower
it
to
verilog
or
does
do
other
specializations,
but
what's
really
critical
is
it
allows
you
to
insert
custom
transformations
to
specialize
the
flow,
so
this
is
really
important
in
shipyard
and
in
firesim
and
as
well.
K
There's
a
lot
of
different
customizations
that
you
may
want
to
do,
based
on
your
own
custom
flow,
your
physical
design
or
you
know
just
what
technology
you're
targeting.
So
that's
handled
a
lot
of
that's
handled
by
the
robust
metadata
and
annotation
support,
which
is
really
critical
for
that
extra
collateral
for
physical
designer
verification,
and
so
there
are
several
projects
in
the
chisel
working
group.
K
I
really
talked
about
chisel
infertile,
but
there's
a
few
others
in
particular
chisel
test,
which
is
our
testing
framework
to
write
unit
tests
and
treadle,
which
is
our
our
emulator
for
for
fertile
simulator
for
fertile.
But
there's
several
others
and
I'll
just
note
that
we're
currently
a
chips
alliance,
sandbox
project,
which
is
like
the
first
step
of
that
shipyard,
sorry
of
the
chips
alliance,
life
cycle
of
projects,
but
we
intend
to
graduate
in
the
near
future.
K
Okay.
So
now
I'll
talk
a
bit
about
what's
been
going
on
over
the
last
six
months,
you
know.
So
if
you
want
to
see
what
happened
in
the
year
before
that,
please
check
out
the
my
previous
talk,
which
is
part
of
the
workshop
on
youtube
of
the
previous
chip
slides
workshop.
So,
first
of
all,
we
actually
moved
the
projects
over
to
chips.
Alliance
github,
so
you
can
find
them
there,
there's
still
a
few
a
couple
more
to
move,
but
at
least
the
major
ones
are
moved
over.
K
We've
been
further
improving
our
website,
which
is
you
know,
important
for
documentation.
So
we
have.
You
know
the
api
docs
for
more
advanced
users
to
see
everything
that's
available.
We
have
more
project
specific
documentation.
That
chisel
link
is
especially
useful.
There's
a
lot
of
documentation
there.
We
have
a
community
page
where
you
can
see
all
the
cool
stuff
that's
going
on
and
find
links
to.
You
know
our
stack
overflow
or
getter
where
people
chat,
and
we
know
the
search
bar,
which
is
very
exciting.
K
K
K
K
One
thing
I'm
really
proud
of
is
that
we
have
a
robust
back
porting
methodology
for
bug
fixes
such
that,
even
though
we're
currently
on
3.4.2
and
about
to
release
3.4.3,
we
still,
as
you
can
see,
release
bug
fixes
for
3.2
and
3.3,
and
that
allows
people
who
you
know
may
be
stuck
on
older
versions
to
keep
getting
important
bug
fixes,
and
we
are
also
publishing
snapshots
of
all
the
stable
branches
and
the
unstable
branch
actually
so
for
people
who
want
to
try
the
bleeding
edge.
It's
pretty
easy
to
do
now.
K
This
is
from
last
time,
so
I'm
going
to
go
through
it
pretty
quickly,
but
starting
in
chisel
3.4.
We
did
a
lot
of
work
on
improving
naming.
So
you
know
you're
writing
a
program
to
generate
hardware,
so
you
can
of
course,
call
functions,
and
so,
in
this
case
it
used
to
be.
We
were
not
very
good
at
naming
these
signals,
but
now
we
actually
can
name.
K
You
know
x
and
y
as
well
as
we
give
them
a
prefix
from
the
result,
value
that
they're
returned
to,
and
this
is
really
important
because
you
could
call
this
function
multiple
times
from
multiple
places,
so
it
allows
you
to
kind
of
scope.
The
signals
that
are
created
based
on
your
actual
call
stack-
and
you
have
some
control
over
that.
But
what
I
want
to
really
get
into
is
in
the
last
six
months
we
kind
of
refine
this
naming.
K
So
this
example
is
a
little
specific,
so
it
may
you
know
it
may
work
well
for
people
who
are
more
familiar
with
chisel
and
maybe
not
so
well
for
others,
but
I'll
just
try.
So
you
know,
say
you
have
some
module
with
an
optional
some
optional
tap
and
let's
just
say
this
tap
is
for
debugging
a
signal
so
based
on
a
parameter
that
may
or
may
not
exist
an
option.
It's
just
something
that
may
be
set
or
may
not
be.
K
You'll
you'll
provide
a
width
and
if
the
width
is
set,
then
we'll
create
a
port.
So
the
question
is:
what
should
the
name
of
this
port
be?
And
this
is
actually
a
pretty
subtle
question
and
you
know
one
option
is
port,
because
when
you
construct
the
port,
that's
the
value
you
assign
it
to
one
option
is
tap
port
because,
as
I
talked
about,
we
have
this
prefixing
right
and
so
port
is
scoped
inside
the
tab
value.
K
Another
option
is
tap
because
you
actually
the
in
scala.
The
last
expression
is
the
return
value.
You
return
the
port
to
tab,
and
so
this
top
little
level
tap
value
is
the
port
or
it
could
be
tap
port.
Because
later
we
have
another
value
that
refers
to
the
same
port.
And
so
what
is
the
name
that
you
want
in
3.4.0?
When
we
first
introduced
this?
It
was
getting
tap
port,
which
is
it
turned
out?
Not
what
our
users
want.
K
K
Now,
just
other
shout
outs,
you
know
to
recent
tape
outs
a
lot
of
times.
You
know
you
kind
of
want
to
say
the
proof
is
in
the
pudding
on
the
the
google
sky,
water
efabush
shuttle
that
tim
will
talk
about
later.
There
were
at
least
three
designs,
including
chisel,
which
I
have
the
gds
plots
for
berkeley.
This
tape
out
was
a
little
while
ago,
but
they
just
recently
presented
it
at
isscc,
which
is
a
pretty
beefy
core
here,
with
eight
tiles,
four
l2
caches
and
l3
cache
lots
of
30s.
K
K
So
you
know
we
have
these
pretty
quick
dual
issue
in
our
cores
memory
hierarchy,
a
lot
of
stuff
going
on
there
all
implemented
in
chisel
and
there's
there
are
others
that
if
I
missed
any,
please
let
me
know-
and
there
are
others
that
I
wish
I
could
talk
about,
but
can't,
but
just
letting
you
know
that
there's
a
lot
going
on
in
real.
You
know
real
silicon.
K
So
now
with
I
have
about
five
minutes.
Five
minutes
perfect.
So
I'll
talk
a
bit
about
what
we're
working
on
and
what's
coming
so
historically
chisel's
been
used
primarily
for
asics,
as
I
just
kind
of
showed,
and
but
that
means
it's
been
difficult
to
take
advantage
of
a
lot
of
fpga
only
features
and
for
all
of
you
who
kind
of
work
in
that
open
source.
Fpga
realm,
that's
been
very
frustrating.
K
So
there's
been
some
recent
work
on
this
to
improve
our
support
out
of
the
box
for
fpgas
and
we'll
have
a
new
option
target
fpga.
To
help
with
that.
This
I
mentioned.
The
next
version
is
3.4.3,
so
this
will
not
make
that
boat,
but
should
make
the
next
minor
version.
So
I
just
wanted
to
let
you
know
that
that's
coming.
K
This
is
very
much
more
in
the
weeds,
but
my
chisel
users
will
probably
recognize
what
I'm
talking
about
here
and
be
happy.
So
clone
type
is
just
this
implementation
detail
that
leaks
into
the
user
api
and
that's
never
a
good
thing
right.
You
don't
want.
You
know
implementation
stuff,
and
but
when
I,
when
I
say
implementation
detail,
I
don't
mean
physical
design.
K
I
mean
implementation
of
chisel
itself,
so
this
has
just
been
a
huge
wart
in
the
language
for
a
long
time
we've
had
we
had
auto
clone
type,
one
as
you
can
guess
by
there
being
number
two,
but
it
had
three
important
limitations
it
would
it
required
you
to
do
some
boilerplate.
It
worked
in
most
cases,
but
not
all,
and
importantly,
it
was
actually
quite
slow.
K
Another
feature,
that's
a
little
more
half-baked,
but
it's
something
we're
working
on
is
what
we're
calling
data
view.
So
often
when
designing
hardware,
you
may
have
some
hardware
value
that
you
wish
you
could
reason
about
or
manipulate
as
if
it
were
a
different
type.
So
a
canonical
example
of
this
is
an
axi
style
flat.
Bus
interface,
which
is,
is
fine
and
that's
like
kind
of
what
the
standard
is,
but
a
lot
of
times,
you'd
like
to
manipulate
it
as
if
it
had
more
structure
right.
K
Sometimes
you
may
have
a
1d
array
of
registers
and
you'd
like
to
treat
them
as
if
they
were
two-dimensional,
and
so
this
is
kind
of
similar
to
a
union
and
system
verilog
and
people
use
that
for
similar
things,
but
there's
a
lot
of
use
cases
that
aren't
handled
by
that,
where
sometimes
the
raw
bits
mapping
may
not
correspond
one-to-one,
and
there
are
other
limitations
as
well.
That
will
be
described
more
in
documentation
for
this
feature
once
it's
done.
This
is
also
similar
to
a
facade
pattern
in
object-oriented
programming,
but
that's
very
boilerplate
heavy.
K
It's
similar
to
conversions
and
functional
programming,
but
those
are
those
don't
allow
you
to
manipulate
the
underlying
representation,
and
so
the
reason
we
came
up
with
the
name
dataview
is
the
best
analogy-
is
a
view
in
sql,
so
for
any
database
people
out
there.
This
is
very
similar
to
that,
and
so
this
is
a
really
powerful
feature
that
I
think
is
going
to
enable
a
lot
of
design
patterns
that
I
think
people
will
really
like
it's
a
work
in
progress,
but
I
look
forward
to
this
in
chisel
3.5.
K
I
want
to
also
note
that
there
will
be
a
chisel
community
conference
in
shanghai
on
june
25th,
so
I
made
this
slide.
I
submitted
my
slides
before
I
got
the
update.
It
will
be
june.
25Th,
not
the
26th,
just
the
25th
it'll
be
co-located
with
the
risk
5
summit
so
keep
an
eye
on
our
websites,
which
I'll
include
another
link
to
later
and
maybe
put
in
the
chat
for
the
details
about
submissions,
and
you
know
more
details.
F
K
Else
is
going
on.
You
know,
I
talked
last
time
a
bit
about
verification
and
I'm
only
glossing
over
at
this
time,
mainly
because
a
lot
of
his
work
people
are
worried
about.
You
know
pre-publication
rules,
but
I
can
tell
you
that
there's
a
decent
amount
of
work
going
on
and
I'm
very
excited
for
what
what
people
or
what
students
are
doing.
K
There's
you
know
all
these
things
I
mentioned
here.
There's
works
on
how
you
specify
and
run
your
formal
verification,
there's
constrained
random
stimulus
generation
and
there's
software-based
vips
that
people
are
working
on.
So
there's
a
there's.
It's
there's
a
lot
going
on,
but
I
can't
go
into
too
much
detail
at
the
moment.
We
continue
to
work
on
documentation
for
my
chisel
users.
K
A
K
Yes,
I
will.
I
will
say
that
that
predates
my
time
I
joined,
I
started
as
a
grad
student
at
berkeley
in
2014
and
I
think
chisel
was
created
in
2010,
but
I
can
say
that
you
know
scala
has
a
lot
of
support
for
dsls
for
or
for
embedded
dsls
if
a
lot
of
attributes
of
scala
make
it
easier
to
embed
a
language
that
was
one
of
the
design
goals
of
scala.
It's
also
a
modern
programming
language.
K
It
has
like
you
know,
functional
programming
is
getting
more
and
more
popular
and
scala
was
I
don't
it's
not
on
the
forefront
of
functional
programming,
but
certainly
on
the
forefront
of
trying
to
make
it
popular
by
making
it
run
well
on
the
jvm
and
stuff.
So
those
are
some
of
the
reasons.
I
know
that
the
original
chisel
work
was
actually
in
ruby
and
there
were
performance
problems
and
so
chisel
being
a
compiled.
Language
runs
a
lot
faster
than
that
or
scalloping
a
compiler
language
runs
faster.
K
A
K
Right
so
professor
nicholak
mentioned
that
in
chisel
3.4
we
added
we
added
system,
verilog,
assert,
assume
and
cover
style
constructs.
So
that's
those
are
at
least
basic
primitives,
by
which
you
can
build
a
lot
of
things.
We
also
have
chisel
test,
which
is
kind
of
a
scala
bindings
to
to
run
your
tests
kind
of
similar
to
what
you
might
write
in
system
barolog.
So
those
are
two
things
that
the
time
frame
is
that
they
exist
now.
K
You
know,
there's
there's
always
more
work
to
be
done,
and
so
you
know
I
don't
have
specific
time
frames
for
like
the
constrained
brand
of
stimulus
generation
or
you
know
better
formal
support,
but
I
can
say
that
they're
actively
being
developed
and
if
you're
interested
you
know,
I
can
put
you
in
contact
with
the
people
who
are
doing
the
heavy
lifting
of
that
work.
If
you
can
reach
out
to
me
on
gitter
or
in
the
chat.
A
L
L
It
was
the
original
original,
like
a
business
model
or
product
that
we
had,
and
recently
we
added
also
the
surfboard
support
package
that
nicely
complement
these.
These
two
items,
the
eda
technology
itself,
the
tools
that
we
are
using
for
customization
these.
These
tools
were
developed
at
the
university
here
in
bernard
in
czech
republic
back
back
a
long
time
ago.
Actually
we
are
founding
members
of
rescue
foundation
or
international
nowadays,
and
we
actually
introduced
the
first
licensing
burst
5ip
back
in
november
2015.
L
They
are
meant,
you
know,
for
the
embedded,
low-power
design
through
the
high
performance
embedded
up
to
linux,
capable
cores
plus
multi-core
multi-core
solutions
as
well.
So
these
are
the
cpus
that
were
developed
by
us
and
they
are
developed
using
our
methodology
that
builds
on
top
of
corrosive
studio.
E
L
Is
the
second
product
where
recognizable
studio
is
the
eda
tool
that
I
was
talking
a
while
ago?
So
this
is
a
da
tool
by
which
you
can
really.
You
know,
create
any
pretty
much
any
cpu
from
scratch.
We
did
it.
We
did
a
risk
five
in
this
case,
and
then
you
can.
You
know
we
can
customize
the
the
processor
in
any
way
as
a
customer.
L
So
it
means
that,
for
instance,
if
you
need
some
secret
sauce
that
you
would
like
to
eat
inside
of
the
cpu
or
if
you
need,
if
you
have
some
kind
of
key
differentiation
point,
then
you
can.
You
can
add
it
there,
thanks
to
the
methodology
and
the
methodology
itself
comes
with
the
the
full
flows,
which
means
the
design
as
well
as
verification
as
well
as
sdk,
as
well
as
debugging.
Pretty
much
everything
is
auto
generated
for
you
using
a
studio.
So
you
get
so
you
get
the
rtl.
L
You
get
verification,
a
suite
that
you
can
run
and
operate.
You
get
a
stimuli
either
fixed
one
or
randomized
one.
You
get
the
sdk,
including
compiler.
That's
a
vary
of
your
changes
and
and
many
more
so.
This
is,
this
is
the
third
sorry.
The
second
product
which
is
called
the
corrusive
studio
and
the
last
product
that
I
like
to
focus
today
is
is
a
kodaship's
of
course
upper
package.
So
what
this
actually
is?
L
L
So
it's
a
implementation
of
risk.
Five
spec
and
originally
we
had
swerve
h1,
the
h1
was
developed
by
the
western
digital
and
it
was
open
sourced,
yeah,
cheap
airlines.
Islands
later
on
the
digital
released
also
the
two
more
cores
with
this
eh2,
that's
kind
of
successor
of
each
one
and
then
also
vl2.
L
Now,
if
we
look
at
the
feature
set
of
these
cores,
then
if
you'll
start
with
the
eh1,
which
is
the
the
first
one
that
was
introduced,
then
it's
a
single
threaded.
Dual
issue:
implementation
really
high,
embedded
core
high
performance
embedded
core,
very
nice
one.
You
know
you
can
configure
it
in
many
way.
You
can
configure
simple
things
like
the
branch
prediction
through
a
number
of
pipeline
stages.
You
can
configure
many
things
and
everything
is
available
at
the
cheaper
lens
for
you
in
the
case
of
eh2,
they
added
a
second
thread.
L
You
have
to
have
a
deep
black
infrastructure
as
well,
so
you
can
debug
properly
on
the
cpu.
You
should
have
some
kind
of
you
know
comprehensive
documentation
that
helps
with
the
integration
of
the
cpu
and
so
on.
You
know,
then
there
is
a
question
about
the
support.
So
if
you
as
a
customer,
you
would
like
to
create
a
real
chip
out
of
this
one,
but
if
there
is
a
bug
in
it,
so
you
know
who
we're
going
to
call
no
less
than
digital
or
community
or
who?
L
Then,
if
you
do
some
kind
of
synthesis,
then
you
may
end
up
with
some
troubles
there
as
well,
because
the
synthesis
script
is
not
open
source
and
you
have
to
write
it.
So
you
know
what,
if
you
do
a
mistake
there
and
again
who
gonna
call
and
then
similarly
to
other
parts
like
you
know
the
rtl
simulation,
although
there
is
support
for
verilog,
but
what,
if
you,
you
need
to
to
have
a
support
for
the
for
the
commercial
grade,
rto
simulators
and
so
on.
L
So
as
you
can
see,
the
rtl
is
really
essential.
That's
true!
But
it's
not
enough.
I
mean
you,
you,
you
really
need.
More
than
that.
You
need
to
collect
more
information.
You
need
to
collect
more
tools
or
more
data
to
be
able
to
integrate
the
the
cpu
and
program
cpu
later
on
in
the
in
the
real
design,
and
it
was
actually
this
this
you
know
question
or
these
questions
were
actually
a.
L
You
know
kind
of
kickoff
for
our
support
package,
because
we
said:
okay,
let's
create
a
package
or
environment
in
which
you
can
actually
get
pretty
much
all
you
need
at
one
place.
Then
you
can
start
with
so
on
your
side.
You
don't
have
to
care
of
which
version
is
compatible
with
which
you
know
in
the
case
of
I,
don't
know,
compilation
and
simulation
and
the
rtl.
L
L
One
is
free
version,
that's
available
on
the
on
the
github
again
through
the
sheep
alliance
repositories,
it's
a
free
of
charge,
it's
for
students
or
educational
purposes
and
itself
it
contains.
You
know
a
lot
of
stuff
already,
including
the
whole
compilation
two
chain,
including
the
rtl
for
the
cpu
itself,
but
also
for
the
for
the
soc.
So
there
is
a
swerve
of
soc
that
integrates
the
sort
of
course.
Originally
it
was
done
for
eh1.
L
We
enhanced
the
scroll
wall
for
patch
this
robot,
so
it's
we
have
a
version
that
is
able
to
talk
with
eh2
as
well
as
el2,
and
you
can
use
these
variables
with
the
open
source
compilation
tool
chain
based
on
the
gcc,
to
run,
for
instance,
benchmarks
to
get
really
nice.
You
know
benchmark
numbers
out
of
out
of
the
swerve
and
reproduce
you
know
some
some
of
the
nice
benchmarks
using
using
correct
tools.
L
There
is
a
bunch
of
documentation,
so
it's
done
in
a
way
that
you
basically
download
the
docker
docker
image
that
contains
pretty
much
everything
it
contains.
The
free
on
open
source
packages
that
you
can
look
at
each
package
comes
with
the
documentation
that
shows
how
to
use
it.
So,
for
instance,
there
is
documentation
that
relates
to
the
benchmarking.
L
There
is
a
documentation
that
relates
to
the
ide
for
the
software
development
and
how
you
can
create
projects
or
or
c
project
really
easily
in
it,
because
then
subvert
support
package
preset
pretty
much
everything
for
you
in
terms
of
software
development.
There
is
also
automation
for
the
for
the
debugging.
So
then
you
can
use,
for
you
know
the
proper
version
of
the
open
ocd
with
the
cpus.
So
then
you
can
do
it
also
the
the
onto
debugging
either
under
you
know
real
silicon
if
you
have
it
or
on
the
on
the
fpga.
L
So
that's
you
know,
that's
what
I
have
mentioned.
Everything
is
prepared
for
you
guys
and
that's
part
of
the
free
version,
but
we
have
also
the
pro
version.
Now
the
pro
version
comes
with
additional
stuff
in
it
and
the
basically.
If
you
look
at
the
content,
then
you
can
find
out
that
there
is
set
of
eda
scripts
that
cannot
really
easily
open
source
one
open
source.
So
there
is
a
flow
complete
flow
for
commercial
grade,
eda
tools
from
guys,
like
you
know,
cadence
or
synapses.
L
So
then
you
can
just
really
simply.
You
know,
integrate
or
install
this
commercial
grade
package
inside
of
the
environment,
and
then
you
get
pretty
much
all
scripts.
You
need
to
run
to
run
the
synthesis
flow.
There
are
also
other
parts
like
verification
or
about
advanced
verification
flow,
including
verification,
environment
for
swerve.
So
then,
if
you
need
or
if
you
would
like
to
do
some
kind
of
modifications,
then
we
may
help
you
with
that,
because
we
have
verifications
to
it.
L
L
Last
but
not
least,
what's
important
is
that,
with
the
pro
version,
we
offer
a
professional
support,
which
means
that
you
can
have
a
account
where
you
can
ask
questions
related
to
the
surf
in
general,
so
it
can
be
on
the
integration
side.
It
can
be
on
the
feature.
Richard
said
it
can
be
on
the
customization.
Even
so
so
this
comes
with
the
with
the
pro
version.
That's
well,
that's
again,
the
commercial
grade,
version
of
a
silver,
of
course,
support
package.
L
L
L
So
this
is
something
that
we
also
also
fixed
or
added
on
top
of
each
one.
So
now
the
data
cache
is,
is
there
as
well
and
you
can
configure
it
similarly
to
to
the
instruction
cache,
which
means
that
you
can
configure
the
interface
you
can
configure
certain
features
of
the
data
cache
such
as
such
a
size
in
a
number
of
ways,
cache
line
these
kind
of
things
that
you
couldn't
expect
that
are
configurable.
That's
that's
part
of
part
of
the
add-on
or
add-ons
as
well.
L
Last
but
not
least,
is
that
we
integrated
the
zbb
extension
for
the
bid
manipulation.
So,
as
you
may
know
so,
eh
ii
or
el
2
comes
with
some
bit
manipulation.
Instructions
already,
and
I
think
that
the
final
bump
or
final
latest
update
at
the
japanese
with
regards
to
al2
comes
with
quite
a
few.
Actually,
a
bit
money
polishing
instructions,
it's
kind
of
missing
on
the
in
the
original
eh1.
L
So
then
you
can
you
can
ask
for
all
in
one's
package
where
you
can
have
pretty
much
everything,
but
you
can
also
pick
and
choose
so,
for
instance,
if
you
know
you
need
just
the
just
the
floating
point
you
need,
then
then
we
can
do
it.
We
can
really
do
it
for
for
you
without
without
an
issue,
so
it
was
really.
You
know
high
level
view
or
description
of
what
we
have
in
terms
of,
of
course,
support
package.
A
L
Well,
the
the
support
that
we
we
are
providing
covers
the
core
itself,
plus
also
the
tools.
So,
for
instance,
we
did
a
lot
a
lot
of
improvements
in
the
case
of
openocd
to
making
make
it
up
and
running
for
for
each
one
as
well
as
other
other
cpus
like
eh2
and
er2.
So
we
are,
you
know,
supporting
also
these
projects
as
well
and
actively
donating
back
what
we.
A
A
Our
next
presenters
will
be
giving
an
introduction
to
the
open
road
project,
so
it
gives
my
pleasure
to
introduce
professor
andrew
kong
from
university
of
california
at
san,
diego
and
also
tom
sparrow,
of
precision
innovations
who
both
come
to
share
all
the
development
of
open
road
and
the
progress
that
they
have
made.
So
professor
khan.
M
Open
road
delivers
an
open
source
rtl
to
gds
eda
system
as
part
of
the
darpa
idea
program
and
there's
a
lot
of
friends
and
supporters
of
open
road
that
we
can
see
in
this
meeting.
So
we'd
like
to
start
out
by
saying
thank
you
from
the
entire
team,
and
this
is
the
open
road
team
tom
has
been
the
chief
architect
and
technical
project
manager
of
open
roads
since
july
2019
I
serve
as
the
pi
of
the
project,
and
some
new
faces
in
the
past
year
include
professor
larry
clark
and
dr
don
mcmillan
who's.
M
M
A
shared
hierarchical
database
engine
integrations
to
support
tight,
incremental,
optimization,
unified,
executable,
easy
to
use
tickle
or
python
scripting
and
and
a
lot
more
so
open
road
scope
includes
all
of
digital
layout
generation,
as
shown
here
from
the
idea,
program's
original
definition
in
darpa's.
You
know
broad
agency
announcement,
as
it's
called
in
the
past
year,
we've
taken
on
the
database
task
of
the
idea.
Digital
flow,
including
advanced
node
support.
You
know,
left
5,
8
and
more
and
arizona
state's
asap
project
is
a
new
base
technology
task
in
open
road.
M
M
So
at
the
right
is
a
gf12
single
core
black
parrot
soc
in
university
of
washington's
pad
frame.
Our
database
has
seen
a
lot
of
improvement
that
asap
7
research.
Pdk
was
open
sourced
in
mid-december
we've,
added
to
the
team,
released
an
extraction
tool
and
turned
our
focus
to
ppa
power,
performance
and
area
along
with
a
growing
set
of
users.
M
So
the
architecture
of
open
road
software
has
also
evolved
substantially
for
quality,
maintainability
and
development.
Velocity
there's
now
just
one
repo,
with
only
one
sub-module
logging,
ci
dashboards
and
metrics
collection,
all
support
our
bring
up
of
intelligence
and
automation,
which
is
our
ultimate
goal,
and
this
is
a
picture
from
e-fabulous
showing
their
mpw-1
shuttle
in
sky
130.
M
And
here's
a
gallery
of
some
test
cases
you
can
see
macros
or
with
and
without
macros,
in
12
and
65
nanometer.
These
have
open
road
generated,
fill
they're
clean
on
all
timing,
drc,
lvs,
erc
and
antenna
checks,
and
the
validations
are
by
our
project's
internal
design,
advisors
team
with
commercial
sign-offs,
as
mentioned
in
the
slide.
M
So
phase
one
focused
on
automated
rtl
to
tape
out
clean
gds,
but
ppa
is
our
focus
in
our
current
phase.
2A
that's
year,
3.
Basically,
the
main
vectors
include
synthesis
placement,
clock,
tree
synthesis
and
optimization
in
our
resizer
plus
learning
and
insight
that
we
get
from
metrics
collection,
infrastructure
and
large
designs
of
experiments.
M
M
Improving
some
levers
like
sync,
clustering
and
cts,
and
simply
starting
to
aim
for
better
f
max
and
density,
already
show
some
significant
improvements,
and
these
are
the
green
numbers
relative
to
the
past
october's
black
numbers,
and
you
can
see
improved
wire
length
and
skew
and
a
36
improvement
of
effective,
f
max,
and,
let
me
say
a
bit
about
one
of
our
ppa
vectors
in
clock
tree
synthesis.
This
is
just
an
example.
M
M
M
We
can
collect
thousands
of
synthesis
place
and
route
run
data
points
in
a
day
for
synthesis
with
eosis
and
abc.
We've
studied
e-fabblis's
recipes
alongside
our
default
recipe,
which
comes
from
the
synthesis
experts
who
have
newly
joined
our
team,
and
this
is
a
rapidly
moving
area
actually
in
the
project.
M
We
also
use
big,
does
to
study
trajectories
of
qor
and
uncover
flow
issues.
So
the
upper
right
picture,
that's
being
shown,
shows
benefits
of
higher
utilization.
The
lower
right
shows
how
our
platform
run.
Script
might
stack
up
against.
You
know
many
possible
settings,
so
it's
the
yellow
circle,
which
has
pretty
good
slack
and
area
properties
and
the
colorings
show
how
post
cts
slack
on
the
x-axis
is
an
early
indicator
of
router
failure,
and
this
kind
of
experiment
allows
us
to
ratchet
up
the
baselines
for
our
test
cases.
D
M
Our
tools
now
or
all
engines
now
use
the
same
logging,
api
and
nomenclature,
and
we've
been
evangelizing
our
metrics
naming
convention
and
approach
to
both
researchers
and
industry,
whether
si2
or
the
ieee
council
on
electronic
design.
Automation,
because
right
now,
there's
no
standard
platform
out
there
for
eda
and
its
users
and
in
open
road.
This
infrastructure
serves
many
purposes
from
dashboards
to
analytics.
M
So
this
supports
metrics
collection
and
now
I'd
like
to
switch
gears
a
bit.
Also,
this
is
the
transition
to
tom
who'll.
Take
take
this
talk
the
rest
of
the
way,
I'd
like
to
remind
that
open
road
development
has
to
achieve
critical,
mass
critical
quality
maximum
velocity
maximum
openness
has
to
support
clean
foundry
tape,
out
automation
and
the
needs
of
early
adopter
users,
which
is
why
our
project,
which
aims
for
no
human
in
the
loop,
has
a
very
capable
gui,
and
so
let
me
sign
off
with
a
video
from
matt
liberty.
D
The
open
road
gui
serves
the
dual
purpose
of
allowing
users
of
open
road
to
investigate
their
designs
and
developers
of
the
open
road
application
to
investigate
their
algorithms.
Here
is
a
design
which
the
user
can
zoom
in.
They
can
pan.
They
can
select
individual
objects
for
further
exploration.
The
selection
here
is
showing
what's
been
selected.
D
E
E
E
E
And
there's
a
lot
more
and
it
isn't
easy
to
extend
architecture
so
as
more
people
contribute
to
the
project,
people
may
come
up
with
ideas
for
what
they
want
to
see.
Visualized
or
especially
visualizations,
like
map
showed
of
the
algorithms
running
themselves
for
debugging
purposes,
is
turning
out
to
be
really
helpful.
E
E
E
Timing
characterization
flow
using
cadence
liberate,
is
in
progress
now
and
register
files.
Roms,
cams
and
tcams
are
also
in
progress,
and
we
see.
Asap7
is
a
great
platform
for
open
collaboration
and
system
exploration
and
including
this
vibrant,
open
source
hardware.
Community
people
could
do
designs
with
this
and
it
looks
like
a
real
process.
It's
also
going
to
be
great
for
us
to
have
regression.
E
E
Asap5
will
also
be
open
sourced
in
the
future
and
we'll
use
horizontal
nanowire,
transistors
and
the
ground
rules
track
boundaries,
advanced
node
scaling
boosters
such
as
single
diffusion
break
and
contact
over
active
gate,
a
6.5
track
cell
library
and
physical
verification
are
well
underway
at
the
bottom.
Here
you
can
see
a
d
latch
layout
and
an
sram
cell
array.
E
The
figure
here
shows
main
inputs,
verilog
signal,
mapping,
footprint,
io
library,
and
that
the
footprint
file
can
be
automatically
extracted
from
a
previous
layout
depth.
If
there
is
one
here
are
some
screenshots
in
gf12
lp,
staggered
pads,
as
well
as
flip
chip
and
also
another
screenshot
from
sky
water,
130.
E
E
One
thing
that
I
would
like
to
highlight
is
that
open
road
is
unique
in
that
it's
a
partnership
between
eda
academic
research
and
industry
veterans.
You
saw
from
andrew's
introduction
that
we
have
team
members
from
several
universities
performing
core
research,
large
industrial
semiconductor
companies,
providing
guidance
and
priorities,
and
industry
consultants
with
extensive
eda
experience
performing
key
development.
E
This
unique
this
unique
project
and
blend
of
expertise
is
focused
on
breaking
new
ground
in
terms
of
automation,
of
rtl
to
gds2
and
also
creating
a
robust
industrial
quality
piece
of
software.
So
it
can
be
a
basis
for
industry,
relevant
research
and
usable
for
important
target
users
like
the
defense
industrial
base.
E
A
Thanks
both
for
an
excellent
update
and
information
on
the
open
road
project,
I
think
it's
a
very
exciting
what
the
team
has
been
doing
and
providing
to
the
industry
and
certainly
helps
illustrate
to
many
the
complexities
involved
in
the
physical
implementation
and
analysis
space.
I
have
one
question
here
from
the
audience,
which
is:
are
you
guys
working
on
in-memory
compute
or
doing
any
collaboration
for
it
on
sram
or
flash
using
open
road.
M
Well
time
was
thomas
talking,
but
at
a
high
level,
not
specifically
in
memory
compute,
but
we
do
see
folks
trying
highly
tiled
aiml
architectures,
which
are
extremely
sram
dominant
and
one
example
would
be
with
performers
in
the
real-time
machine
learning
program
and
we
do
think
about
front-end
soc
support
or
the
you
know,
support
for
front-end
chip
planning
and
even
design
path.
Finding
like
architecture
exploration
quite
a
bit,
but
not
in
memory
compute
per
se.
A
E
I
guess
I
could
take
that
one.
So
we
do
have
a
few
users
and
we
actually
have
three
users.
You
know
you
saw
evapolis
and
all
the
tape
outs.
You
know
if
you
lump
that
all
into
one
which
is
really
40
different
users,
but
we
do
have
some
users
in
who
are
modifying
the
code
modifying
creating
their
own
scripts.
E
You
can
see
that
the
fabulous
put
open
lane
together,
which
is
a
recipe
which
is
very
targeted
at
sky
130,
so
we
definitely
do
have
people
creating
their
own
recipes
and
we
try
to
collect
the
best
of
those
recipes
and
put
them
into
open
road.
If
somebody
is
doing
something
complicated
with
the
script,
we
try
to
pull
that
into
the
application
and
make
it
a
command.
E
E
A
E
That
type
of
process
and
application
of
those
resources,
usually
customer
driven.
So
I
hope
that
that
will
happen
in
the
future.
We
haven't
seen
that
yet,
but
as
we
get
users
using
open
road
to
tape
out
to
various
boundaries
and
the
boundaries
see
that
there
is
a
demand
there,
then
I
think
that's
something
that
would
be
very
helpful
to
push
for.
A
M
I
think
it's
a
difficult
question
to
answer.
Yes,
I
I
mean,
if
you
look
at
the
history
of
how
asap
7
and
was
developed
by
asu
and
arm
even
the
sort
of
clean
room
approach,
that
everything
had
to
be
publicly
sourced.
That
went
into
the
technology
definition
and
the
ground
rules.
Definition
is
a
really
high
bar
and
there
are
the
free
pdk,
45s
and
15s
they're.
M
You
know
I
think
people
have
kind
of
mentally
moved
on,
and
so
it's
unlikely
in
my
opinion
that
you
know
people
will
invest
a
lot
of
volunteer
effort
to
to
bring
up,
let's
say,
an
equivalent
asap
22,
for
example,
but
that's
my
personal
opinion
everything's
solvable
with
resources
and
incentives.
So
that's
up
to
the
term.
I
suppose.
A
E
A
B
Great
all
right
well
good
morning
or
good
afternoon,
everybody
I'm
brian
faith,
the
ceo
of
quick
logic
and
the
last
time
I
spoke
with
the
chips
alliance.
It
was
around
the
fact
that
we
had
taken
this
big
step
to
into
open
source
fpga
tooling,
coming
from
a
proprietary
tool's
past,
and
so
this
presentation
is
sort
of
the
next
step
in
the
journey
along
those
lines,
and
so
for
those
of
you
that
don't
know,
quicklogic
is
a
fabulous
semiconductor
company.
B
We
started
as
an
fpga
company,
and
today
we
have
discrete
fpgas.
We
have
mcu
plus
embedded
fpga
socs,
and
then
we
have
an
embedded
fpga
ip
business
as
well.
So
programmable
logic
is
sort
of
the
root
of
everything
that
we
do,
and
so
it's
it's
fun
to
talk
about
this
in
the
open
source
context.
So
when
I
started
quicklogic
25
years
ago,
everything
that
we
did
was
proprietary.
B
We
didn't
necessarily
do
it
all
ourselves.
Sometimes
we
partnered
with
other
companies,
but
every
element
of
the
tool
chain
was
was
in
fact
proprietary
and
so
starting
as
an
application
engineer,
one
of
my
jobs
was
to
build
out
schematic
macro
libraries.
That
would
then
go
into
the
schematic
tool
and
write
verilog
simulation
models
that
would
go
into
simulators
and
then
have
to
validate
all
of
these
different
design
flows
from
different
vendors
for
verilog
and
vhdl,
and
schematic
capture
with
folks
like
mentor,
graphics
and
cadence
and
synopsis.
B
And
then,
of
course,
all
that
sort
of
comes
into
the
proprietary
place
and
route
tool
in
the
middle
there
in
the
brownish
colors
to
create
a
net
list
for
a
customer.
So
they
could
actually
program
a
part.
So
there's
lots
of
moving
parts
there,
many
of
which
are
not
ours
and
all
of
which
were
proprietary.
B
And
it
was
interesting
because
I
actually
taught
a
programmable
logic
class
at
santa
clara
university,
probably
about
20
years
ago,
and
I
can
tell
you
that
most
of
the
time
spent
creating
the
curriculum
for
the
class
and
the
labs.
And
so
on
was
really
about
how
to
take
the
same
design
and
run
it
through
several
different
vendors
tools.
And
if
you
think
about
that,
that's
really
not
a
value
add
for
the
student.
B
B
B
Change
is
definitely
painful
and
changes
risk
and,
if
you
think
about
engineers
that
are
building
products
and
putting
them
into
systems
that,
like
flight
control
of
airplanes
or
industrial
equipment,
you
don't
want
to
take
a
lot
of
risk
on
something
that
you
may
not
know,
and
so
the
fpga
vendor
in
the
world
for
the
entire
existence
and
there's
been.
You
know
over
60
of
these
companies
that
have
come
and
gone
in
the
last
30
years
in
this
area.
B
It's
really
that
this
robust
software
that
we
have
and
there's
no
incentive
really
for
the
fpga
vendors
to
change,
because
the
the
notion
of
this
proprietary
tool
chain
really
is
that
walled
garden,
and
so
people
get
accustomed
to
it
again.
They
don't
like
change,
and
so
it
just
sort
of
perpetuates
the
that
walled
garden
approach.
B
So
the
last
time
that
I
presented,
as
I
said
earlier,
it
was
really
about
this
first
step
that
we
had
taken
in
an
open
source,
tooling,
support
of
our
devices
and
as
I've
credited
many
times
I'll.
Do
it
again
here
publicly.
You
know
tim
ansel
and
his
persistence
in
convincing
myself
in
quick
logic
that
this
was
the
right
thing
to
do
is
why
we're
presenting
the
slide
today
and
many
of
the
folks
over
at
micro,
helping
take
our
architecture
and
and
bring
that
into
the
open
source,
tooling
domain.
B
So
today,
in
this
this
particular
chip
showing
here,
we
have
a
a
microcontroller,
an
embedded
fpga
block.
It
has
simple
flow
support.
It
has
renowned
support
and
it
has
a
variety
of
real-time
operating
systems
that
run
on
the
arm
core,
so
zephyr
and
then
free
r
toss,
and
we
had
a
little
dev
kit
up
there
in
the
the
upper
right,
so
that
was
a
year
ago.
So
what
sort
of
happened
in
the
last
several
months
is
the
the
tool
chain
is
starting
to
get
filled
out.
B
B
It
was
closed
and
proprietary
and
now
we're
starting
to
see
this
virtuous
cycle
of
people,
starting
with
things
that
are
on
github
and
then
adding
to
that
and
improving
importing
new
tools
on
top
of
tools-
and
I
know
several
people
on
this
caller-
are
part
of
that-
and
I'd
like
to
express
my
gratitude
to
the
community
for
making
that
happen.
But
you
can
see
now
brian
yeah.
B
B
This
was
the
slide
on
why
vendors
resist
walled
garden.
These
are
the
tools
from
a
year
ago,
as
I
said,
the
the
simplified
support
for
the
embed
fpga
reno'd
for
the
whole
chip,
the
real-time
operating
system,
support
in
the
arm
core
and
then
today
really
get
that
getting
fell
out
further
with
tensorflight
and
mygen
and
micropython.
So
now
you
can
really
start
seeing
this
virtuous
cycle,
I'm
happening
which
is
sort
of
exactly
what
tim
ansel
talked
about
and
it's
it
is
happening.
B
Getting
this
into
the
curriculum
now
in
iit
hyderabad
in
india,
and
when
you
think
about
like
what
that
opens
up
the
capabilities
now
where
somebody
could
literally
take
a
a
10
dev
kit
with
open
source
software
and
start
doing
fpga
design
with
their
android
phone,
which
you
know
so
many
people
in
the
world
have
an
android
phone
or
raspberry.
Pi
really
opens
up
and
and
truly
democratizes
the
capability
to
use
this
technology.
For
for
cool
and
interesting
and
learning
purposes.
And
to
me,
that's
just
that's
so
powerful
and
it's
so
neat
to
watch.
B
That
kind
of
thing
happen.
So
I
think
this
is
just
going
to
start
and
perpetuate
further
bringing
it
back
to
quick
logic.
We
have
our
own
road
map
and
you
know
the
previous
ship
was
around
arm
and
this
next
one
is
around
risk
five,
and
so
in
this,
there's
already
renowned
support
for
this
and
simplifies
support
for
the
embedded
fpga.
B
If
we
wanted
to
do
proprietary
tools
only
in
working
with
proprietary
synthesis,
vendors
specifically
we'd
have
to
go
and
take
a
lot
of
time
and
a
lot
of
money
just
to
try
little
different
changes
in
the
fpga
architecture
that
they
would
then
have
to
map
to
or
infer
blocks
for
and
then
see
what
the
net
result
of
that
was,
and
so,
with
with
this
open
source
tools.
That's
sort
of
in
within
our
control
now
or
a
much
stronger
degree
of
influence
to
do
that.
B
Architectural
exploration
and
optimize
the
architecture
for
the
algorithm
versus
the
other
way
around.
And
so
this
is
a
I
think.
Again.
It
just
speaks
to
the
power
of
of
open
source
and
so
just
sort
of
wrapping
it
up
on
this
whole
thing,
and
I
think
a
lot
of
this
sort
of
comes
down
to
changing
our
mindset-
and
I
know
for
us-
it
took
like
a
year
of
that
talking
with
tim
to
to
get
to
that
point
of
of
having
this
different
mindset,
but
for
fpga
companies
in
general.
B
There's
a
massive
nih
factor
here
of
trying
to
say
that
proprietary
tools
are
are
not
as
good
as
open
source
tools,
and
so
I
don't
know
how
we
overcome
that,
but
I
think
there's
a
lot
of
work
to
be
done
there,
just
in
general
to
to
convince
people
of
that
and
it
convinced
them
that
there's
more
upside
than
downside.
I
think
any
time
you
have
a
walled
garden
when
you
start
thinking
about
breaking
down
those
walls,
that's
viewed
as
risk
and
so
how
people
can
view
this
as
more
gain
than
pain.
B
B
It
just
takes
more
persistence
and
creativity
from
the
community
to
to
do
that,
so
we're
on
board
we've
completely
switched
completely
switched
from
our
proprietary
tool
to
open
source
tools,
which
I'm
really
happy
about,
and
that's
allowed
us
to
do
things
like
these
devices
that
I
just
showed
you
the
roadmap
devices
for
our
embed,
fpgi,
p
cores.
We
can
very
quickly
spin
up
software
support
for
new
core
that
a
customer
of
ours
may
want.
B
We
were
able
to
participate
in
the
the
efabus
google
skywater
130
openmpw
project
as
well,
which
we
would
not
have
been
able
to
do
without
the
open
source
tools.
That
was
the
really
the
enabler
for
us
to
quickly
participate
in
that
project,
which
I'm
pretty
excited
about
so
anyway.
I
think
the
future
is
right.
A
B
I
would
say
that
contribution
wise,
there's
been
more
from
the
community
as
far
as
improving
the
tools
and
it's
not
because
we
don't
want
to
it's
just
because
we're
still
shifting
the
mindset
and
the
skill
set
from
the
proprietary
development
to
open
source,
but
we're
definitely
making
contributions
in
that
area
and,
like
I
said,
every
every
new
device
or
core
that
we
do
today
is
in
open
source
tool
support.
We
are
not
we're
not
doing
any
more
proprietary
development
in
that
area.
B
Yeah
we
have
on
our
github
repo.
We
have
a
whole
section
on
user,
I
don't
forget
the
name
of
it.
It's
a
quick
start
user
examples
that
you
can
actually
take
the
flows,
download
them,
install
the
packages
and
and
there's
reference
code
or
designs
that
you
can
take
through
the
flow,
and
we
actually
have
a
lot
of
webinar
videos.
Now
that
we've
been
recording
over
the
last,
I
would
say
month
and
a
half
almost
like
one
a
week
to
give
people.
B
A
B
I
remember,
I
think
dave
shaw
was
presenting
some
results
on
place
and
route
and
how
he
was
tracking
to
proprietary
tools,
and
that
was
one
of
the
data
points
that
we
used
to
make
the
decision
to
go
into
this
whole
thing.
As
a
with
respect
to
our
architecture,
our
devices
for
reference
tend
to
be
on
the
smaller
side
of
you
know
the
mainstream
fpga
market,
so
we're
talking
about.
You
know
thousands
of
luts,
as
opposed
to
millions
of
luts
and
so
for
designs
of
that
size.
B
The
tools
that
we
have
access
to
to
the
open
source
tools,
they're
on
par
with
the
proprietary
tools.
In
fact,
I
think
it
was
like
plus
or
minus
10,
or
less
variance
to
that,
depending
on
the
design.
So
that
was
one
of
the
data
points
also
that
made
us
comfortable
that
we
no
longer
had
to
do
proprietary
tools.
So
we
use
the
bundle,
precision,
synthesis
from
mentor.
Graphics
are
now
siemens,
and
we
no
longer
do
that,
because
the
the
yosis
and
symbol
for
flow
are
very
good
from
a
quality
result.
A
B
Well,
we
sell
fpgas
in
ip
cores,
so
I
don't
support
competitors
products,
but
these
tools
do
so
simpleflow
and
the
next
presenter
is
tim
mansell
who's.
Very
you
know
he
knows
simplefoe
better
than
anybody.
I
think
he
could
probably
comment
on
that.
Support
for
xilinx,
but
quick
logic
itself
does
not
support
xilinx
neural
terror.
G
A
F
A
N
N
N
I
also
want
to
say
that
I'm
a
software
engineer,
I'm
not
a
hardware
engineer
I
self-identify
as
a
software
engineer,
and
I'm
only
a
newcomer
to
this
hardware,
design
space,
I'm
not
a
newcomer
to
open
source
I've
been
doing
open
source
since
1995
back
when
linux
was.
You
know
this
fresh
new
thing
that
was
battling
these
old,
traditional
unix
vendors
of
which
very
few
still
exist,
and
I've
been
at
google
for
a
long
time
as
well.
N
I
think
it's
actually
almost
up
to
13
years
now,
and
one
of
the
things
that
I
know
about
google
is:
it
runs
on
computers,
google
kind
of
pioneered
this
idea
of
using
lots
and
lots
of
computers
to
do
distributed,
especially
commodity
off
the
shelf
computers,
and
it
uses
a
lot
of
them.
You
know
this
is
probably
a
smaller
of
the
data
center
type
pictures.
N
But
tpu
is
a
really
great
example
of
being
able
to
scale
to
the
growing
demand
for
ml
compute,
which
was
growing
at
you
know,
rates
of,
like
10
000
x,
to
keep
up
with
the
demand
by
using
specialized
hardware,
and
they
the
team
who
does.
This
has
done
an
absolutely
impressive
job,
but
they
have
definitely
felt
the
fact
that,
as
the
tpu
design
has
gotten
more
complicated
verification
costs
and
design
costs
have
gone
up.
N
I
was
very
interested
in
understanding
if
these
parts
had
open
equivalents
and
it
turns
out
for
a
long
time
there
has
been
actually
quite
a
thriving
open
source,
ip
library
ecosystem
and
the
recent
success
of
risk.
Five
has
actually
made
that
explode
massively,
there's
now
a
really
big,
thriving
ecosystem
of
fully
open
source
ip.
N
If
you
think
about
what
a
pdk
is,
it's
all
the
kind
of
low
level
details
needed
to
actually
create
a
device
and
like
since
you
want
to
actually
create
a
device.
This
data
is
really
really
important
and
when
we
looked
at
what
open
source
pdks
existed,
there
was
a
whole
bunch
of
stuff
that
exists,
but
it
was
non-manufacturable
and
it
frequently
had
restrictive
licenses.
N
When
I
wrote
this
slide,
a
step
7
was
under
a
restrictive
license,
but
now
that's
under
a
fully
open
source
license,
and
I'm
really
glad
andrew
managed
to
do
that.
But
it's
still
a
non-manufacturable
pdk
and
as
a
consequence,
if
you
look
at
like
e-fabulous,
they
created
a
open-source
design
called
ravina
which
had
fully
open
source
rtl
used
fully
open
source
tools,
but
because
they
used
the
xfab
180
pdk,
which
was
not
open
source.
N
What
I
believe
is
the
first
fully
open
source,
130,
nanometer,
manufacturable
pdk
and
when
I
say
fully
open
source,
I
mean
it's
licensed
under
apache
2
license,
you
can
just
go
to
github
and
you
can
clone
the
repo
and
all
the
data.
Is
there
there's
no
ndas
to
sign?
There's
no
lawyers
to
be
involved.
N
It's
hosted
on
read
the
docs
using
syncs.
This
is
kind
of
what
the
documentation
looks
like
and
it's
publicly
available
and
searchable
with
google.
Here's
some.
You
know
information
about
the
various
design
rules
you
have
to
comply
with,
and
these
are
kind
of
the
low
level
details
about
exactly
what
is
and
isn't
manufacturable.
N
You
know,
there's
stack
up
diagrams
but
that
by
itself
isn't
enough.
So
there's
also
digital
standard
cells,
there's
io
and
periphery
cells.
There's
a
full
set
of
base
primitives
and
drc
rules,
there's
analog
rf
primitives
and
there
should
be
a
sram
and
flash
build
space
anytime.
Real
soon
now
that's
been
pending
a
while
taking
a
lot
longer
than
I
had
hoped
to
get
released,
but
that's
definitely
coming
and
we've
already
seen
certain
things
be
released
there.
N
We
have
a
lot
of
different
standard
cell
libraries,
which
have
quite
a
comprehensive
list
of
cells,
and
you
can
kind
of
see
how
the
different
standard
cell
libraries
are
optimized
for
different
use
cases
and
the
high
voltage
one
is
obviously
optimized
for
high
voltage
and,
like
I
don't
have
to
be
scared
about
showing
you
this
gts.
This
is
a
cell
from
skywater.
I
have
no
idea
what
the
cell
is,
but
I'm
sure
all
you,
you
know
asic
designers.
N
There
can
tell
me
what
that
is,
but
I
can
just
share
it
with
you,
and
you
know
this
is
the
sram
fit
cell?
Both
you
know
in
single
port
and
dual
port
vera
variants,
and
you
can
see
that
it's
significantly
smaller
than
the
d
flip-flop
cell
on
the
sky
water
process
and
the
thing
is
you
need
to
build
a
full
memory
out
of
this,
and
so
I'll
talk
a
little
bit
about
that.
N
You
can
now
have
a
fully
open
source
ethic
and
I
think
that's
a
pretty
cool
achievement
and
so
that
had
a
lot
of
contributions
from
a
whole
bunch
of
different
partners.
But
what
I
really
care
about
is
the
ecosystem,
and
you
know
how
do
we
grow
the
ecosystem?
Well,
we
started
out
by
taping
out
some
chips
to
prove
that
you
could
do
this.
We
also
did
a
a
talk
series
which
currently
consists
of
seven
talks,
but
I
also
launched
a
fully
open
source
shuttle
program.
N
This
is
not
your
average
shuttle
program.
We're
taking
a
very
different
philosophy
here:
we
want
your
prototypes
to
be
considered
throwaway
and
not
uniquely
precious.
This
kind
of
thing
where
currently,
when
you
get
back
your
prototypes
from
an
mpw
run,
you
know
you
mount
a
couple
on
a
board
and
they
become
the
most
precious
things
on
the
planet.
You
let
none
of
the
interns
near
it
because
you
know
if
they
spill
coffee
on
it's
the
end
of
the
world.
N
Your
design
has
to
be
open,
source
and
there'll,
be
roughly
40
slots
per
design
and
you
go
to
fabulous
and
you
submit
the
design
and
there's
a
common
harness
which
allows
us
to
have
a
standard
packaging
system
and
also
to
give
you
a
lot
of
functionality
like
an
in
ic
logic.
Analyzer.
You
still
get
plenty
of
space,
10,
millimeters
squared,
and
our
aim
is
to
get
you
back.
100
packaged
ready-to-go
ics.
N
If
you're
paying
attention,
you
might
notice.
That
november
is
in
the
past,
and
so
we
had
40
designs
go
out
on
mpw1
and
they
come
from
a
wide
variety
of
different
types
of
designs.
We
had
processors,
we
had
crypto
miners,
we
had
radio
receivers,
a
whole
bunch
of
analog
whole
bunch
of
fpgas,
and
so
that
was
really
really
cool.
But
I
think
one
of
the
coolest
things
was
60
of
designers
had
never
done
an
asic
before
had
no
experience
doing
an
asic
and
the
mbw
one
was
their
first
asic.
N
N
N
You
know,
roughly
200
new
people
every
two
weeks
download
the
pdk
who
have
never
downloaded
it
before
and
that's
pretty
amazing
to
me
and
like
we're,
seeing
you
know,
1
700
or
you
know
about
800
downloads
every
week
of
the
pdk,
and
so
this
is
definitely
very
different
to
what
people
have
previously
said
as
possible.
So
I
highly
recommend
that
you
join
our
mailing
list
enjoy
in
our
slack
and
get
involved,
and
we've
removed
one
of
the
roadblocks
that
I
believe
was
preventing
a
lot
of
new
innovation.
N
My
ic
cad
paper,
though
identified
four
roadblocks
that
were
discovered.
So
if
you
go
and
read
my
paper,
you
can
understand
all
four
roadblocks
but
to
quickly
go
through
them.
One
of
the
big
things
was
place
and
route
tooling
and
we've
been
collaborating
very
heavily
with
the
open
road
project
to
improve
the
quality
of
the
tooling
and
make
it
work
really
well
on
sky
130..
N
N
N
The
big
problem
with
bag
is
that
it
still
requires
a
few
closed
source
components,
we're
hoping
to
work
with
bora
to
fix
that
in
the
future.
But
I'm
also
excited
that
our
collaboration
with
fa
sock
has
resulted
in
fa
sock
running
on
top
of
open
road.
So
the
fa
stock
approach
to
fully
open
analog
generation
is
now
fully
open
source
with
no
dependent
on
dependency
on
closed
source
tools,
and
I
think
this
is
a
really
interesting
milestone
that
medi,
who
has
been
the
main
driver
behind
this,
has
achieved.
N
So
again,
if
you
want
to
get
all
the
details,
go
and
look
at
my
ic
cad
20
paper
and
to
get
notified,
join
the
mailing
list
and
join
the
slack
workspace
and
I'm
excited
to
see
all
these
chips
alliance
projects.
You
know
working
with
the
sky,
water,
pdk
and
also
hoping
that
we
can
do
even
more
in
the
future,
and
I
think
I
went
five
minutes
over
time,
but
it's
hard
to
cover
all
the
exciting
things
that
are
happening
in
this
space
in
only
15
minutes.
A
N
Yes,
that's
a
simple
answer:
I
have
no
idea
if
it's
there
or
not.
I
hope
it's
there.
As
I
said,
I'm
not
a.
I
come
from
a
software
background,
so
I
don't
know
you
know
what
is
there
at
the
moment?
If
it's
not
there,
I
would
love
to
have
it
at
it.
It's
mainly
driven,
though,
by
people
contributing,
as
I
said,
there's
a
lot
of
things
happening
and
I'm
responsible
for
a
lot
of
them.
N
N
A
N
N
My
group
is
very
strongly
focused
on
the
open
source
aspect
of
stuff.
We
don't
prevent
people
from
using
the
sky
water
pdk
with
the
proprietary
tools
like
synoxis
and
cadence,
but
they're,
not
a
high
priority
for
us,
and
people
have
been
slowly
adding
and
improving
support
there.
But
it's
not
a
high
priority
for
us,
I'm
very
supportive
of
it
happening
and
I
do
think
the
closed
source
tools
aren't
going
anywhere.
I
think
they
have
a
a
long
future
ahead
of
them.
N
N
On
the
first
mpw,
I
don't
know
exactly
how
that
was
done.
I
just
know
it
was
done
and
I
know
that
microwatt
from
ibm
was
taked
out
on
sky
130
and
microwatts
is
vhdl,
so
there's
definitely
a
ability
to
take
vhdl
designs
and
get
them
onto
an
inter
open
lane.
But
I'm
not
the
right
person
to
ask
the
technical
details
of
how
to
do
that.
N
N
So
if
you
know
anybody
at
ibm
go
and
nag
them
to
join
the
chip,
clients
and
nag
them
to
support
open
source
bhdl
tooling,
I
would
love
to
see
some
corporate
members
stepping
up
to
help
fund
the
vhdl
language.
At
the
moment,
it's
entirely
driven
by,
I
believe,
community
and
academic
contributions,
so
it
could
be
supercharged
by
having
you
know,
people
invest
in
it.
N
So
definitely,
I'm
looking
for
boundary
number
two
to
release
a
another
pdk
in
the
kind
of
180
130
110
nanometer
space,
I'm
also
working
with
skywater
to
get
their
90
nanometer
process
fully
open
sourced,
like
the
130
process
has
been
open
sourced
and
you
know
I
want
to
see
a
growing
ecosystem.
I
want
to
see
multiple
foundries
supported.
I
want
to
see
foundries
from
the
us.
I
want
to
see
boundaries
from
asia.
I
want
to
see
foundries
from
europe.
N
I
also
want
to
make
it
really
easy
that
people
can
use
the
right
foundry
for
their
job.
You
know
skywater
specializes
in
doing
a
lot
of
custom
things
to
your
system
that
most
other
foundries
aren't
willing
to
do,
and
so
sky
water
has
a
lot
of
ability
to
do
things,
but
that
does
drive
up
the
price
a
bit
and
being
based
in
the
u.s
does
drive
up
the
price
a
bit
and
some
of
the
foundries
in
asia
offer.
N
Right,
like
your
chip,
might
take
advantage
of
these
advanced
capabilities
or
cost
might
be
that
what
you
want
to
optimize
for
and
so
giving
people
the
flexibility
to
move
between
these
designs
and
like
foundries
and
move
designs
between
foundries
much
more
easily
is
one
of
the
key
aspects
that
I
want
to
see
happen
here,
and
you
know
I
worked
very
heavily
with
skywater,
but
they
know
that
they
are
just
trailblazers
here.
I
definitely
want
other
groups
to
be
involved
and
you
know
there's.
No.
N
This
is
kind
of
a
rising
tide
lifts
all
boats.
Here
we
want
to
see
the
industry
grow,
you
know
not
10x
or
100x,
but
like
a
thousand
x,
and
so
all
the
foundries
in
the
world
are
going
to
be
super
busy.
If
we
succeed-
and
so
I
don't
think
it's
going
to
be
a
problem
that
there
are
multiple
foundries
supported
and
I
would
like
to
say
one
answer,
one
more
question
which
is
yes:
the
fabrication
is
fully
free
for
the
mpw
program.
N
N
The
cost
is
the
same,
whether
you're
a
hobbyist,
an
academic
or
a
commercial
company.
The
only
thing
you
need
to
make
sure
of
is
that
your
design
is
fully
open
source.
So,
if
you're
an
open
source,
startup
you're
perfectly
fine.
If
you
want
to
be
close
source
in
some
way,
you'll
need
to
talk
to
epablis
about
going
through
their
paid
shuttle
program
where
you
don't
have
to
open
source
everything.
N
N
Full
stop
whether
they're,
proprietary
or
open
source-
and
I
think
open
source
can
help
build
out
a
lot
of
these
common
stuffs
that
everybody
needs
allowing
people
to
concentrate
on
just
the
one
thing
they
think
they
can
innovate
on.
And
this
will
dramatically
increase
the
number
of
things
we
could
try.
N
N
You
know
if
you're
in
china
smick
there's
like
lots
of
others
that
I'm
probably
forgetting,
if
I'm
forgetting
you
it's
not
because
I
don't
want
to
talk
to
you,
it's
just
that.
You
know
I
have
a
terrible
memory
and
I
would
love
to
see
everyone
open
source
their
process
technology
and
enable
a
new
wealth
of
users
to
start
doing
designs
on
your
process
like.
N
If
your
process
is
a
useful
thing
to
exist,
then
people
are
going
to
want
to
use
it
and
open
source
enables
people
to
use
it
much
more
efficiently
and
quickly.
Anytime,
I
have
to
talk
to
lawyers.
You
know
my
excitement
for
doing
the
project
dramatically
goes
down
and
when
there's
an
nda
involved,
I
have
to
talk
to
lawyers,
and
so
you
know,
open
source
makes
a
lot
of
this
go
away.
I
can
just
go
to
github
and
start
doing
stuff.
I
don't
need
to
worry
about.
N
A
A
Thank
you,
so
I
want
to
thank
all
the
presenters
for
their
time
and
effort
to
put
the
presentations
together
today.
I
thought
it
was
excellent
material
and
also
to
the
audience
for
their
time
and
interest
and
the
questions
I
received,
and
also
special
thanks
to
brian
warner,
for
helping
him
helping
me
put
this
all
together
and
orchestrating
all
the
slides.
So
thank
you
very
much.