►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
hello,
everybody,
my
name,
is
rob
maines.
I
want
to
welcome
you
here
to
our
first
edition
of
the
chips
deep
dive
cafe,
I'm
pleased
to
announce
that
we
have
a
carol,
google
from
ant
micro
with
us
today
to
talk
about
different,
open
source
efforts
in
different
contexts,
primarily
fpga
and
embedded
software
he's
going
to
be
chatting
about
his
work
on
sim
scheduling
in
verilator.
A
And
I
want
to
talk
a
little
bit
about
that
brian.
If
you
go
to
the
next
slide,
please
thank
you.
So
you
know.
If
we
look
at
where
industry
has
come,
you
know
we've
kind
of
gone
from
a
soup
to
nut
type
of
environment
that
we've
seen
with
many
of
the
large
companies
over
time.
General
electric
ibm
are
two
examples.
18T,
where
literally
somebody
like
with
ge
would
have
a
foundry
to
pour
the
metal
cast
for
the
turbines
that
they
made
and
then
sold
out
to
utility
companies.
A
A
And
so
what
we're
really
looking
at
in
terms
of
compute
and
design
challenges,
of
course,
is
that
cost
of
hardware
are
increasing
significantly
right.
There's
the
nre
cost
of
actually
building
it
and
designing
it
to
all
the
way
out
to
getting
into
product
and
into
customers
hands,
and
we
also
see
that
innovation
is
often
stalled
at
corporate
infrastructures.
A
So,
in
sum,
if
we
look
at
chips,
it's
really
built
upon
a
number
of
different
things:
it's
open
architecture,
specifications,
implementation
tools,
verification
it's
a
venue
for
collaboration.
Ip
contribution
is
certainly
welcome,
but
it's
not
required
to
join
and
how
much
you
participate
is
really
a
function
of
you
and
your
company,
and
we
have
different
levels
of
participation
that
are
available
as
options
for
people.
So
with
that,
I
want
to
turn
this
over
to
carol.
A
Oh
just
one
of
the
things
I
want
to
mention
is
that
you
know
specifically,
we
are
going
to
be
starting
a
system,
verilog
work
group.
You
know
we're
continuing
to
make
good
progress
on
the
area.
Google
really
is
wanting
to
help
us
move
that
forward
and
also
we
recently
started
an
analog
work
group
as
well.
That
does
starting
to
see
some
different,
interesting
aspects
being
covered
in
in
research
areas,
and
our
next
talk
will
be
on
july
13th
and
that
will
be
by
henry
zeller
on
variable
and
uhdm.
B
Okay,
great
okay,
hi.
All
thanks
for
joining
in
today's
talk,
as
rob
said,
my
name
is
carol
gawa
and
I
would
like
to
tell
a
few
words
to
present
our
it's,
not
mine,
like
rob
said
that
that's
I'm
going
to
I'm
going
to
talk
about
my
work,
but
it's
it's
not
my
per
se
work
and
only
mine.
It's
a
collaborative
work
from
from
quite
a
few
people.
So,
but
I
would
just
like
to
present
it
here:
I'm
I'm
just
a
presenter.
B
I
would
like
to
talk
about
it
in
slightly
brighter
context,
slightly
broader
context
of
the
whole,
like
ecosystem,
the
whole
system,
very
lock
or
testing
ecosystem,
and
that
is
why
I
added
like
a
subtitle
to
my
presentation
so
titans
and
towards
uvm
support
in
open
source
tooling,
which
were
part
of
this
part
of
it,
is
the
work
on
dynamic
scheduling,
very
late.
But
let's
start
from
a
little
bit
of
background,
let's
start
from
who
I
am
and
then
why
I'm
here?
B
So
if
you
read,
if
you
read
the
announcement,
it
said
that
I'm
I
work
for
micro,
I'm
engineering
manager
here
and
micro
is
a
company
private
company
founded
in
2009.
So
it's
quite
a
few
years
quite
a
few
years
in
the
market,
we
are
a
software
driven
company.
We
basically
develop
software.
We
focus
on
on
the
software
side
of
things.
Even
if
we
work
on
hardware,
we
approach
it
as
a
software.
We
always
think
of
software
in
a
software
way.
B
B
B
B
We
focus
on
why
many
different
areas
from
hardware
through
software,
including
tools,
including
fpga
and
asic
development,
all
that
to
combine
like
to
create
like
combine
ecosystem
to
a
complete
ecosystem,
where
we
can
simply
solve
the
problems.
We
just.
We
don't
implement
things,
because
this
is
something
to
implement.
We
solve
problems
with
whatever
needs
to
be
done
to
to
actually
so.
If
you
are
interested
what
we
do,
you
can
always
visit
our
webpage.
B
We
have
like
a
section
called
technology
showcase
where
you
can
simply
see
where
we
publish
articles
and
blog
notes
about
projects
we
do,
and
then
you
can
basically
basically
read
about
them
and
most
of
those
notes.
They
they
link
to
repositories,
and
you
can
even
see
the
code
or
just
grab
the
project
and
start
working
with
it
by
yourself.
B
B
You
will
find
links
to
public
repositories
and
simply
find
whatever
you
you're
interested
in
so
getting
back
to
getting
back
to
our
main
topic.
Why
do
we
actually
need
uvm
and
system
verlock
support
in
in
open
source
tuning?
Why
it
is
so
important?
So,
as
you
probably
noticed,
if
you
are
actively
following
what
is
happening
in
in
modern
software
world,
the
world
is
shifting
towards
open
source
like
in
every
single
area.
It's
clearly
visible
in
areas
like
server
scenarios
like
cloud
computing
in
two
chains.
B
Basically,
if
you
look
at
this
market,
there
is
open
source
everywhere
and,
of
course,
this
shift
is
actually
right
now
happening
in
asic
designs
in
logic,
designs
in
fpga
designs.
There
is
more
and
more
initiatives
in
in
this
area.
Of
course,
chips
alliance
and
we
are,
as
part
of
chips
alliance,
is
actively
actively
working
on
making
happen
and
making
it.
B
Those
new
approaches
allow
us
to
basically
proceed
faster
and
make
better
better
solutions
in
the
end.
The
problem
is
that
we
cannot
really,
you
know,
put
a
line
somewhere
and
say
that
we
stop
using
the
old
solutions,
the
old
things,
the
old
designs
that
are
already
there.
A
lot
of
people
spent
a
lot
of
time
doing
that
and
just
switch
to
a
new
methodologies.
B
The
whole
deal
is
to
create
solutions
that
will
allow
the
whole
market
to
simply
reuse
and
seamlessly
migrate
from
old
methodologies
to
a
new
one,
so
basically
adapt
the
functionalities
adapt.
The
approaches
that
were
that
were
there
and
and
migrated
to
new
approaches
to
the
new,
to
new
way
of
thinking
and
to
new
type
of
new
way
of
designing
things.
So
why
actually
uvm?
B
So
for
verification,
a
lot
of
companies,
a
lot
of
designs,
a
lot
of
engineers
simply
used
uvm,
because
uvm
was
the
best
verification
methodology
available
available
at
the
time
and
right
now,
since
we
have
a
lot
of
tools,
a
lot
of
new
approaches,
a
lot
of
open
source
emerging
in
digital
design,
ecosystem
and
some
of
the
older
designs
like
that
were
existing.
There
are
being
open
source.
B
The
problem
is
how
to
verify
them,
and
there
is
a
lot
of
code
base
that
does
the
verification,
but
it
based
those
verification
technology.
Those
verifications
methodologies
are
based
on
whatever
was
there
and
uvm
was
there,
and
that
leads
to
a
problem
where
we
have
more
and
more
open
source
design,
but
we
cannot
really
build
them.
We
cannot
really
test
them.
We
can
really
verify
them
with
open
source
tools.
B
We
can
use
proprietary
tools
and
those
are
great.
They
do
work.
They
you
know,
allow
you
to
verify
things,
but
what
they
are
missing
is
a
possibility
to
integrate
with
all
those
new
and
better
flaws,
all
those
new
and
better
design
methodologies,
all
those
new
and
and
awesome
open
source
methodologies.
So
you
cannot
really,
you
know,
adapt
something
that
we
know
from
software
world
like
publicly
available
continuous
integration
system,
publicly
available
test
system
or
continuous
deployment
systems
with
uvm
based
verification.
So
it's
not
that
technically.
Is
it
impossible?
B
It's
because
proprietary
tools
don't
allow
you
to
do
that.
Don't
allow
you
to
do
that
because
of
the
licensing.
The
licensing
is
not
it's
not
only
because
it's
like
expensive,
it's
mostly
because
the
way
they
are
licensed
it
makes
it
impossible
to
actually
integrate
that
with
with
open
source
tooling.
B
So,
looking
at
that,
it's
really
important
to
actually
provide
the
community
to
provide
the
whole
market
with
something
that
can
be
integrated
with
this
new
emerging
ecosystem
of
new
emerging
part
of
logic,
design
without
tools
that
will
allow
us
to
use
the
existing
code-based
existing
technologies
and
and
integrate
that
with
with
with
this
new
approach.
So
we
know
what's
the
problem,
we
just
need
to
have
those
tools,
but
what
is
actually
missing
in
the
existing
tools?
B
This
system
is
actually
meant
to
answer
the
question:
what
is
missing,
this
system
is
available
on
github.
You
can
basically
go,
you
can
google
it
and
just
find
this
the
whole
suite
on
github
the
suite
runs
number
of
tests
spanning
from
simple,
I
would
say,
unit
test
testing,
different
system,
vlog
functionalities,
up
to
a
complex
test
covering
functionalities
like
uvm
or
like
a
more
complex
design
like
like
cpus
or
socs,
and
basically
it
answers
the
question
which
tools
support.
What
and
by
just
looking
at
the
dashboard
that
the
system
produces.
B
We
came
to
conclusion
that
one
of
the
biggest
blockers
is:
we
don't
really
have
a
fast
and
reliable
simulator
that
that
can
is
capable
of
running
simulations
that
are
required
by
by
uvm
by
uvm
methodology.
So,
but
also
looking
at
this,
the
results
revealed
one
of
one
things.
There
is
a
very,
very
good
simulator
on
the
market.
There
is
a
very
good
open
source
simulator,
it's
very
later,
the
fastest
available
simulator.
B
The
only
problem
with
that
is
that
the
later
didn't
support
simulation,
the
support,
simulating,
not
non-synthesizable
very
local
system
will
look
cool.
It
wasn't
possible
to
actually
run
that
kind
of
a
simulation
in
the
later
that
that
was
required
by
uvm
library
to
just
run
verification
in
a
way
they
are
implemented
by
many
different
verification,
verification
suites
for
many
different
designs
in
imperial
later,
as
it
was
once
we
started
once
we
approached
once
we
approached
the
project,
the
biggest
missing
part
was
actually
the
way
writer
handled
scheduling.
B
Let
me
tell
a
few
words:
how
link
is
down
in
in
system
develop
so
basically
system?
The
log
follows,
as
usually
called
stratified
is
defined.
Scheduling
is
defined
as
stratified
scheduler,
and
this
is
a
part
of
system
of
log
specifications.
So
if
you,
if
you
grab
a
symbolic
specification,
you
can
read
about
about
this
this
the
way
the
simulation
should
be
handled,
that
the
such
scheduling
in
simulation
should
be
handled
in
very
details,
but
to
just
get
you
a
brief
idea
how
it
works.
I
would
try
to
explain.
B
B
So
it's
divided
into
regions
and
each
statement
in
your
system,
the
lock
of
relic
code
should
be
evaluated
in
certain
regions.
So,
basically,
on
the
right
side
of
my
slide,
you
can
see
you
can
see
a
diagram,
a
graph
presenting
how
different
how
the
how
the
link
was
just
one
side
note.
This
is
not
the
complete
diagram,
it
just
presents
nine
regions
and
actually
the
look
defines
17
regions
and
the
remaining
ones
are
related
to
pli
or
vpi,
which
allows
you
to
remotely
like
access
simulation
from
external
tools.
But
that's
just
aside.
B
So
basically,
if
you
look
at
this
at
this
diagram
here,
this
is
this
flow
or
the
scheduling
flow.
You
see
that
events
from
certain
certain
regions
can
affect
regions
that
were
that
were
that
were
elaborated
before.
So,
if
a
non-blocking
assignment
in
this
in
our
simulation
in
a
certain
time,
slot
activates
some
statement
that
was
evaluated
in
active
in
in
active
region,
we
have
to
go
back
and
reevaluate
everything
again,
so
it's
not
something
that
is
trivial
to
implement.
B
B
Later
scheduled,
everything
statically,
so
basically,
during
the
the
compilation
during
the
verilation
later
compilation
of
the
model,
the
writer
was
solving
resolving
all
the
scheduling
up
front
and
just
putting
things
in
a
way
they
should
be
handed
the
problem
with.
That
is
that,
if
you
have
a,
if
you
have
a
potential
event
that
that
will
force
you
to
go
back
and
re-evaluate
everything
or
events
that
are,
you
know,
cross-dependent
between
different
parallel
sections,
parallel
sections
of
the
code,
you
cannot
really
evaluate
them
with
the
way
verita.
B
B
B
The
later
handles
handles
the
simulation
so
right
now,
every
single
process
that
can
take
place
in
your
simulation
in
your
system,
vlog
simulation
is
found
as
a
separate
thread
like
a
standard,
cpas
plus
thread,
and
the
processes
communicate
that
the
threads
spawn
threads
communicates
communicate
with
each
other,
with
a
standard
c
plus
plus
mechanism
and
mortixes
with
signals
and
condition
variables
and
so
on.
So
we
didn't
really
have
to.
We
didn't
really
have
to
re-implement
this
mechanism
from
scratch.
We
just
used
whatever
was
there?
B
Also,
we
didn't
really
have
to
implement,
implement
the
the
scheduling
mechanism
for
the
threads,
because
we
simply
use
whatever
operating
system
gives
us
the
name.
Dynamic
scheduler
comes
from
the
different
approach
than
that
it
was
before
previously.
As
I
said,
the
later
was
setting
everything
at
a
compile
time
at
the
verilation
time.
Right
now
we
evaluate
we
evaluate
the
scheduling
the
the
way
we
should
process
the
statements
in
the
simulated
design
dynamically
during
the
runtime
during
the
evaluation
itself
during
the
sorry,
the
simulation
itself.
B
So,
if
you
look
at
this
diagram,
we
have
like
a
free
processes
from
coming
from
a
systemveloc
code
process
can
be.
I
will
actually
tell
about
about
those
processes
later,
so
we
can.
We
have
a
processes
coming
from
from
the
from
the
simulation
from
the
evaluated
from
the
simulated
circuit
and
we
simply
translate
them
into
threads
from
our
from
our
fretboard.
We
relocated.
B
So
if
you
look
at
the
threads
on
the
right
side,
you'll
see
how
the
process
and
tasks
from
the
processes
are,
basically,
you
know,
put
into
into
different
threads
and
how
they
can
communicate
with
each
other.
In
this
particular
example,
we
can
see
even
process
a
communicates
with
process
b
with
with
events,
a
single
simulation
step
looks
more
or
less
like
that.
B
So
basically
we
become
from
a
previous
lens
previous
time.
Slope
run
all
the
processes
they
evaluate
all
the
of
all
the
statements
that
they
have
to
whatever
is
in
their
in
the
list.
Then
we
perform
all
the
non-blocking
assignments
and
we
get
back
to
running
all
the
processes
if
necessary,
if
that
one
triggers,
if
any
non-blocking
assignment
evaluation
triggers
a
new
triggers
an
event
that
has
to
be
revaluated
again.
Yes,
so
we
can
get
back
to
something
that
we
already
evaluated
once
everything
everything
is
done.
B
So
with
all
those
things
implemented,
what
it
gives
us,
what
what
actually
what
functionalities
is
it
enables
what
is
possible
right
now,
so
one
of
the
things
that
are
now
possible
and
wearing
previously
is
handling
delays.
So,
if
you
look
at
the
right
side,
there
is
a
code
slip.
That's
a
verilog
code,
snippet
that
simply
spawns
a
forever
like
never
ending
process
which
sets
a
clock
signal
to
zero.
Then
it
delays
it
for
one
time
slot
and
sets
it
to
one
and
again
the
list
for
one
timeslot.
B
So
previously
the
scheduler
that
the
static
scheduler
that
was
in
the
later
that
kind
of
a
code
wasn't
really
really
possible.
It
couldn't
generate
a
clock
from
a
simulated
design.
The
clock
was
has
to
be
always
provided
from
from
a
c
plus
plus
test,
so
basically
that
that
that's
one
of
the
features
that
are
right
now
possible.
Ending
those
delays
handling
those
forever
tasks,
which
is
you
know,
pretty
pretty
cool,
because
right
now
you
can
have
part
of
your
design
that
actually,
you
know,
generates
different
various
clocks
for
for
your
desk.
B
The
next
thing
that
the
change
in
in
this
in
the
scheduler
enabled
is
even
variables
and
spawning
a
few
processes
and
and
communicating
with
events
between
them.
So
basically,
in
this
example,
you
can
see
two
different
two
different
processes
found
and,
and
basically
they
do
ping
pong
between
them.
So
one
the
first
process
is
actually
waiting
for
pink
and
then
it
delays.
B
If
it
receives
this
event,
it
delays
the
execution
for
one
time
slot,
and
then
it
sends
a
punk
event
to
to
the
other
fret
and
the
other
thread
does
more
or
less
the
same,
but
it
just
waits
for
punk.
Beside
those.
This
notation
beside
this
and
and
arrow
notation,
we
also
handle
event
dot,
triggered
notation
and
also
those
events
can
be
placed
in
a
sensitivity
list
of
of
different
processes.
So
you
can
use
those
those
functionalities
to
synchronize
the
execution
synchronize,
this
relation.
B
So,
for
example,
you
can
have
a
process
that
waits
for
for
a
certain
signal
like
it
may
start
monitoring
some
kind
of
some
kind
of
variables
once
the
other.
The
other
part
of
the
simulation
just
to
sends
a
signal
that
you
know.
Data
has
been
sent,
for
example,
something
like
that
yeah.
Otherwise
we
can
simply
wait
for
for
that
kind
of
event.
Besides
that
we
also
support
forks.
So,
basically
you
can
spout.
You
can
spawn
a
bunch
of
parallel.
B
Processes
in
the
system
that
do
some
kind
of
a
logic
like
in
this
example.
It's
pretty
simple
example:
we
just
display
a
forked
process
and
a
number,
but
of
course
you
can,
you
can
implement
a
way
more
complex,
more
complex
logic
here
and
on
the
left
side,
you
can
see
a
possible
example
output
of
this
process,
since
we
don't
really
have
we
don't
really
have
any
delays
there
and-
and
you
know
we
don't
have
a
control
of
and
basically
the
the
standard
system.
B
Specific
stability
specification
doesn't
really
say
which
process
should
be
spawned
one
and
101.
You
can
have
like
a
random
output
of
those
threes
depending
on
on
how
they
were
scheduled.
So
you
can
have
like
this,
this
possible
output,
where
first
you
get
a
print
from
a
second
process
and
then
from
the
first
and
third,
that's
just
depends
on
how
they
were
how
they
were
scheduled
in
the
system.
B
So
you
can
also,
you
know,
spawn
a
bunch
of
forkbunch
of
processes
and
simply
simply
wait
for
any
of
them
is
finished
or
don't
wait
at
all
and
just
proceed
with
the
simulation.
So,
basically,
we
can
spawn
things
like
waters
of
certain
states
of
the
simulated
design
or
or
things
like.
Whatever
comes
first,
whatever
you
know,
interface
reacts
first
and
the
simulation
with
proceed
with
next
thing.
Next
step
or
whatever
you
you
implemented
in
your
verification,
verification,
test
branch,
next
really
cool
feature
is
a
wait
statement.
B
So,
basically,
with
that
one,
you
can
block
the
execution,
you
can
block
the
simulation
until
certain
condition
is
met,
and
here
in
this
example,
we
have
we
spawn
our
process.
We
spawn
an
initial
process
that
that
simply
delays
the
execution
by
one
one
time
step
sets
some
variables.
Then
again,
delay
sets
some
other
variables
and
so
on
so
on
and
the
other
thread,
the
other
process
simply
blocks
the
execution
by
on
certain
conditions.
B
Yes,
so
this
this,
you
know,
allows
you
to
create
a
simulation
where
you
simply
block
and
wait
for
certain
even
quite
complex
conditions
like
like
in
this
example,
you
can
have
the
third
one.
Is
it's
not
the
simplest,
not
the
most
obvious
one,
one
additional
very,
very
nice
feature
we
added
during
this
work-
maybe
not
certainly
we're
not
strictly
related
to
to
scheduling
itself,
but
really
useful
in
in
design.
Verification
and
and
extensively
used
in
uvm
methodology
is
a
constrained.
Randomization
constraint.
B
Randomization
basically
allows
you
to
create
a
test,
create
a
verification
test
bench
that
will
try
to
cover
as
big
as
as
big
space
as
big
test
space
as
possible,
without
actually
necessity
of
running
a
very
long
and
very
extensible
tests
on
every
single
possible
test
case.
So
if
you
provide
a
very
good,
you
know
random
constraints,
you
can
possibly
explore
all
the
recorders
of
the
simulations
by
space
without
really
going
into
into
into
a
problem
of
simulating
every
single
possible.
You
know
input
value
or
checking
every
possible
output
value.
B
B
But
right
now
we
we
support
some
basic
basic
basic
constraints
like
the
ones
you
can
see
on
the
right
side
and
it's
called
snippets
like
just
choose
something
from
available
or
just
randomly
just
something
from
from
some
kind
of
like
some
kind
of
a
range
or
something
like
that.
So
those
are
those
are
right
now
supported
and,
as
I
said,
we're
working
on
on
adding
real
solver
and
and
being
able
to
to
solve
any
constraint
that
that
user
can
provide.
B
B
And,
besides,
you
know
just
codes
there.
We
also
have
a
public
ci
that
that
runs
those
simulations
and
presents
the
results.
So
if
you
are,
if
you
want
to
use
it,
you
can
simply
go
there
and
check.
You
know
the
results
of
of
the
ci
or
just
clone
the
repository.
Follow
the
readme,
follow
the
documentation
and
and
simply
run.
It
would
be
great
if
you,
if
you
do
that,
if
you
have
like
use
cases
for
those,
please
do
please.
B
Please
start
using
that
and
report
all
the
issues
you
find
and
then
you
know
that
will
be
really
helpful
to
make
the
software
better
and
make
it
more
usable
and
and
actually
something
that
that
can
be
integrated
into
into
various
test.
Suites
and
verification
suites.
So
it
all
sounds
great,
but
it
as
you
probably
you
may
assume
that
it
doesn't
cover
everything
that
is
required
to
to
to
handle
your
vm.
B
Otherwise
I
would
name
my
presentation:
there
is
an
open
source,
uvm
available,
just
go
there
and
grab
it,
but
but
it's
we're
not
there.
Yet
there
is
still
some
work
to
be
done
and,
first
of
all,
we're
still
working
on
the
stuff
that
I
just
presented.
So
it's
it's
already
there.
It
is
usable,
you
can
grab
it
start
using
it
report
some
issues
test
it
that
will
be
very
helpful,
but
still
we
still,
we
need
to
make
it
better.
We
need
to
find
the
bugs
we
need
to
optimize
it.
B
B
The
next
very,
very
important
thing
is
merging
the
existing
code
to
mainline
right
now.
It
is
all
done
in
a
fork,
it's
all
done
in
independently
on
on
main
line.
However,
we
discussed
that
with
with
the
later
maintainers,
so
it's
not
like
nobody
knows
about
this
work,
but
it's
still
not
yet
in
mainline.
B
We
don't
want
to
force
people
to
use
these
new
functionalities
in
every
single
in
every
single
design,
every
single
simulation.
What
we
want
to
do.
We
want
to
give
people
a
chance
to
just
introduce
some
kind
of
optional,
some
kind
of
an
option
that
that
will
allow
users
to
choose
if
I
want
to
go
with
a
static
scheduler,
which
is
faster,
and
it's
good
enough
to
to
run
all
those
simulations
that
that
all
those
simulations
that
one
where
we
just
want
to
simulate
a
synthesizable
verilog
code.
B
B
The
very
er,
besides
beside
merging
the
code,
to
to
trying
too
much
to
do
upstream,
we
already
identified
some
missing
features
that
are
required
by
uvm
they're
required
to
run
the
uvm
simulations,
and
some
of
them
are
listed
here
in
the
slides.
It's
like
talking
blocks
assertions
I
mean
like
full
support
for
software
sessions,
class
parameters,
park,
strokes
and
then
so
on.
So
that's
still
missing
and
that's
those
parts
are
what
we
know
of.
B
B
Evaluated
syntheloc
designs
from
between
parser
and
and
other
tools
and
the
next
talk
in
the
series
will
be
from
hana
from
google,
and
he
will
actually
talk
about
this
and
and
the
effort
on
this
front
and,
as
I
said,
that's
one
of
the
goals
here,
one
of
the
future
goals
to
just
integrate
to
converge
all
those
efforts
together
and
and
make
the
whole
ecosystem
more
complete
and,
of
course,
the
long-term
goal.
Our
holy
grail
here
is
to
provide
full-blown
uvm
support
in
open
source
tooling.
B
So
designs
like
the
designs
like
open,
titan
or
swerve
that
may
have
some
uvm
tests
with
uvm
verification,
suites
will
be
able
and
those
projects
will
be
able
to
run
those
tests
publicly
and
and
openly
in
repositories
and,
of
course,
enable
a
number
of
users,
a
number
of
external
contributors
to
simply
run
the
simply
contributed
to
the
repositories
and
get
their
new
code.
The
new
features
to
be
verified,
validated
and
and
possibly
merged
together.
Of
course,
it's
not
limited
to
those
two
projects.
B
A
Thank
you
carol.
I
really
appreciate
your
presentation
today
and
I
found
it
extremely
informative.
I
enjoyed
it
very
much
so
we
do
have
a
couple
of
questions.
Let
me
go
to
the
q
a
so
I
think
you
answered
this
question,
but
I
will
put
it
forth
anyway,
relative
to
the
work
that
you've
done
in
dynamic
scheduling,
which
I
think
is
an
interesting
software
development
problem.
That's
my
or
my
own
curiosity,
but
the
question
was:
is
from
tudor
timmy.
Does
this
mean
verilatel
verilator
will
be
slower
with
dynamic
scheduling.
B
B
We
decided
to
implement
it
that
way,
because
it
was
simply
faster.
We
were
able
to
just
focus
on
implementing
a
stratified
scheduler
as
as
the
spec
requires
and
just
leave
the
rest
to
like
whatever.
Is
there,
whatever,
like
scheduling
itself
scheduling
those
those
threads
due
to
operating
system?
Right
now,
once
we
know
that
the
functionality
is
there,
it
works.
B
A
Thank
you.
So
the
next
question
is
from
rodrigo
malio.
I
apologize
if
I'm
not
pronouncing
that
correctly.
Last
name
correctly
with
the
changes
verilator
can
be
used
as
a
sv
simulator
without
the
need
of
the
c
c
plus
plus
code.
There
is
documentation
for
that
guide
tutorial
or
only
the
provided
examples
on
the
repo.
B
So
you
still
need,
like
a
very,
very,
very
little
of
c,
plus
plus
code.
That's
mostly
because
ventilator
generates
a
class
that
that
you
know
that
models
the
simulated
design,
so
we
still
need
to
at
least
main
function
that
we
instantly
disclose
and
that
that's
all
you
need
right
now
and
and
the
rest
can
be
done
in
in
a
system
there
looked
as
much
that's
true
you
can
generate
clocks.
B
You
can
generate
all
the
all
the
rest
of
the
inputs
of
the
rest
of
the
of
the
signals
in
the
simulation
in
from
this
code.
I'm
of
that
there
is
a
like
step
of
documentation,
we're
still
working
on
making
better.
That's
always
the
hardest
part
for
for
every
engineer
and
like
we
can
write
like
20
hundred
thousand
lines
of
codes,
but
when
it
comes
to
writing
documentation,
it's
like
yeah
I'll
write
it
later.
So
that's
that's
the
hardest
thing
here.
B
A
Thank
you.
The
next
question
is
from
simon
davidman.
He
states
interesting
presentation
on
slide.
Two,
you
state,
proprietary
licensing
of
existing
commercial
tools
makes
it
hard
to
build
scalable
reproducible
ci's,
and
you
said
it
is
not
price,
but
licensing
restrictions.
Can
you
please
explain
this
further.
B
So,
for
example,
we
can
run
like,
let's
say
10
instance
of
a
tool
and
with
with
our
ci
system,
you
cannot
really
tell
how
many
jobs
you
possibly
try
to
you
possibly
have
to
handle,
because
if
you
have
like
a
publix
public
repository
and
public
testing,
you
may
get
like
one
day.
You
can
have
like
a
single
request
and
the
other
day
you
can
have
like
a
100
request,
because
people
were
were
extremely
active
during
that
day.
B
So
and
then
you
have
a
few
options
like
try
to
somehow
schedule
the
runs
or
you
know,
create
a
queue.
But
if
there
is
a
lot
of
a
lot
of
builds,
you
may
end
up
in
a
situation
where
your
build
will
be
run
like
in
a
week
or
something
because
you
know
it
may
just
take
time.
So
we
cannot
really
spawn
as
many
instances
as
you
want,
and
we
just
want
that
to.
A
B
So
the
whole
code,
the
whole
effort-
is
this
done
publicly
on
github.
So
I
think
the
easiest
way
is
to
simply
you
know
fork
whatever.
Is
there
write
your
code
and
open
pull
requests?
It's
either
you
can?
You
can
open
if
you
want
to
contribute
directly
to
this
dynamic
scheduling
you
can
you
can
grab
this
code
if
you
want
to
make
ventilator
better,
you
can
you
can,
you
know
fork
up
through
the
later
and
then
contribute
there.
A
Thank
you.
I
was
just
going
to
ask
I
you
know
I
just
my
question.
For
my
own
side,
I
was
impressed
with
the
usage
of
multiple
processes
and
threading
and
I'm
just
curious
kind
of
related
to
the
just
the
last
question.
But
how
difficult
would
you
say
it
is
for
a
a
new
person
to
learn
the
internals
of
verilator
and
also
doing
development
with
multiple
threads
and
processes.
B
So
answering
the
first
question:
it's
you
know,
I
wouldn't
say
it's
like
really
really
hard.
Relator
is
a
big
project
and
extremely
optimized,
so
the
code
is
not
always
the
easiest
one
to
read
but,
as
I
said
wilson,
the
original
author
is
super
helpful
in
that.
So,
if
you,
if
you
just
just
ask
a
question,
you
will
have
the
answer
and-
and
it's
really
helpful
to
just
get
you
know
some
additional
information
on
that
and,
to
be
honest,
is
pretty
pretty
well
documented.
B
B
B
Maybe
the
the
hard
problem
here
is
that
you
kind
of
variety
generates
cpas
pass
code,
then
that
you
later
build
and
run
so,
if
you
have,
you
may
have
bugs
in
generator
or
boxing
generated
code,
probably
because
of
generator
yeah.
So
you
kind
of
have
to
learn
how
to
correlate
the
generated
code
box
to
to
whatever
generator.
Does
that's
something
that
you
learn
during
the
process?
Okay,.
A
B
If
this
new
approach
can
make
it
faster,
how
to
tell
I'm
sure
we
have
to
optimize
it
because
right
now
we
spawn
way
too
many
threads
and
just
just
handling
those
makes
it
makes
it
slower
and
you
know,
handling
those
like
synchronizing
the
threads
and
then
communicating
between
them
makes
it
slower.
So
I'm
pretty
sure
this
this
has
to
be
optimized,
but
if
it
will
be
faster,
then
whatever
currently
is.
If
you
enable.
A
A
B
Think
I
kind
of
explained
that
when
we
when
I
was
answering
the
previous
question,
so
the
overhead
is
that
we
spawn
a
bunch
of
threads
and
we
have
to
synchronize
them.
So
that's
always
overhead
because
you
have
to
system
scheduler
has
to
has
to
handle
them,
has
to.
You
know,
give
access
to
those
threats
to
to
resources
like
cpu
memories
and
all
that
stuff
plus
we
have
to
synchronize
them.
B
B
A
B
Actually,
we
did
at
it
some
time
ago,
the
standards
I
mean
we
started
this
work
some
time
ago
with
also
western
digital
and
with
stephan
ventovitz
from
fossil
foundation
on
when
we
were
working
on
adding
support
to
coco
tb,
basically
to
adding
enabling
the
later
to
be
used
with
coco
tb
and
coco
tb
uses
vpi
to
communicate
with
that.
So
some
support
is
already
there,
if
not
like
even
more
than
we
need
right
now.
A
B
So,
as
I
said
in
the
in
the
slide
right
now,
it's
pretty
basic
so
right
now
it
allows
you
to
just
do
random
very
basic
randomization,
but
we
are
actually
right.
Now
we
are.
We
are
looking
at
integrating
those
libraries,
the
crave,
libraries
and
then
solver
that
will
allow
us
to
use
full
blown
randomization
and
full-blown
functionality
of
that
one.
A
B
It
does
support
stratified
scheduler
as
specified
in
in
a
spec.
So
the
answer
is,
I
suppose.
Yes,
here,
okay
and
the
last
question,
should
cadence
or
synapses
concert
about
new
development
of
open
source?
Actually
we
should
ask
cadence
or
synopsis.
I
I
don't
feel
you
know.
I
can
answer
this
question.
A
I
I
I
can
just
comment
a
little
bit
since
I
have
you
know
experience
from
my
professional
career
at
different
points,
so
I
think
what
I
would
like
to
see
is
actually
invitations
to
eda
partners.
In
fact,
we
actually
have
an
eda
partner,
who
is
a
member
of
chips
alliance
and
to
work
in
a
collaborative
fashion
on
different
applications
and
to
invite
participation
of
the
open
source
community.
A
There's
you
know
what
I've
learned
in
my
short
time
with
chips
alliance,
but
in
general,
is
that
there's
a
lot
of
smart
people
out
there
and
providing
a
venue
for
others
to
contribute
to
different
complex
problems.
I
think
would
be
a
real
benefit
and
I
I
would
hope
that
you
know
they
would.
You
know,
come
to
to
the
table
in
that
sense
and
participate
with
us.
I
think
there's
a
real
business
opportunity
for
all
participants
and
also
for
open
collaboration
so
anyway,
so
carol.
Any
closing
comments
from
your
side.
A
Well,
thank
you
carol
and
thank
you
everyone
for
joining
us
today.
I
I
truly
enjoyed
the
the
in-depth
presentation
on
your
work
and
I
found
it
to
be
very
informative.
So
I
look
forward
to
our
next
event,
which
I
mentioned
will
be
on
the
13th
of
july,
and
we
will
get
that
out
there
for
folks
to
sign
up
for
it
by
hunter
zeller.
So
thank
you
again
and
take
care
everyone.