►
From YouTube: Renode co Simulation
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
C
C
Folks,
why
don't
you
go
ahead
and
get
seated?
We
will
wrap
up
our
technical
sessions
here.
B
I?
Guess
it
does,
because
the
icon,
okay,
so
I'll,
just
start
like
ignoring
the
fact
that
people
aren't
sitting
I'll,
try
to
make
my
presentation
shorter,
just
because
we're
massively
behind
schedule
so
I
so
on
micro
is
actually
a
software
company.
B
So
what
we're
doing
at
a
hardware
conference
you
could
say,
but
it
obviously,
in
the
previous
days,
software
companies
more
or
less
bought
Hardware,
which
was
just
magically
appearing
on
the
market,
and
then
you
had
to
adopt
your
software
to
whatever
was
invented
by
the
hardware
people,
that's
a
let's
say
a
simplification,
but
it
was
more
or
less
like
that
for
most
of
software
Engineers,
even
when
you
were
studying,
you
were
like
assuming
that
the
hardware
is
just
like
it's
progressing
over
time,
it's
Moore's
law,
but
who
does
the
mystical
Hardware?
B
Nobody
knows
you
just
program
on
it,
you
maybe
you
can
be
a
kernel
developers,
you
can
you
have
to
figure
it
out,
but
still
you
you
get
a
fixed
set
of
things
and
you
have
to
adapt
to
it,
but
that's
changing
and
the
the
problem
is
that
software
Engineers
like
to
basically
move
fast
and
break
things
and
and
that's
the
opposite
of
Hardware,
so
to
speak.
So
how
can
you
develop
new
CPUs
and
at
the
same
time
develop
software
in
a
way
that
soft
engines,
like
so
the
presentations?
B
The
title,
is
about
the
mpw,
but
I
will
try
to
talk
about
that
in
a
broader
sense.
Let's
sense,
let's
say
so.
Also
I
will
give
some
concrete
examples
on
how
you
can
use
that
right
now
with
other
things,
not
just
the
mpw
shuttles
but
yeah.
So
so
that's
that's
what
I
just
said
that
chip
making
is
typically
very
slow.
So
by
the
time
you
have
your
chip,
let's
say
designs
and
you
even
send
it
to
a
Fab.
B
There
is
months
of
waiting
and
if
you're
lucky
it
works
to
even
figure
out
it
works.
You
have
to
bring
it
up.
So
people
talk
a
lot
like.
Oh,
we
got
the
chips,
but
we
don't
know
yet
if
they
work
or
maybe
they
don't
work
because
we
can
fix
it,
maybe
they
don't
work
because
they're
dead
and
we'll
have
to
do
something
to
fix
them.
So
software
Engineers
have
to
wait
or
find
some
ways
to
go
around
it
and
be
able
to
to
develop
software
while
the
hardware
is
not
ready.
B
So
there
is
something
called
press
silicon
development
very
well
known
for
software,
Engineers
that
let's
say
Implement
things
like
drivers
or
operating
systems
Etc.
So
you
actually
have
to
develop
a
lot
of
software
before
you
have.
The
hardware
will
be
running
on
and
it
can
sometimes
be
very
difficult
because
once
you
get
the
harder
you
realize
that
you
are
not
even
halfway
down
the
done,
even
though
you
thought
you
are
so
I,
don't
micro,
we're
thinking
how
to
how
to
fix
that,
and
we
have
one
project
running
with
Google
research.
B
That
Michael
actually
gave
a
talk
yesterday,
so
it's
recorded
so
but
it's
a
flow
where
actually,
while
you're
developing
the
chip,
all
will
be
open
source
parts
of
it
is
already
parts
of
it
will
be
open
source
soon.
The
idea
is
that
while
you're
developing
the
chip
you're
also
developing
the
software
and
then
you're
improving
the
chip
and
then
once
you
are
happy
with
it,
you
tape
it
out.
So
actually
the
thing
that
you
will
tape
out.
B
It
fits
exactly
with
your
software,
which
in
this
case
is
very
specialized,
so
you
actually
want
to
do
something
very
specific.
So
it's
not
a
generic
CPU
like
it
typically
was
in
the
past
that
you
just
got
a
CPU
that
can
do
anything
and
then
you
can
write
any
software,
but
here
you
actually
want
to
run
as
a
specific
workload,
and
you
don't
know
yet
what
the
workload
will
be
so
you're
implementing
it
and
you're
refining
your
CPU,
so
you
have
a
theoretical
candidate
to
produce,
but
you're
not
producing
it.
B
Instead,
you're
using
simulator
is
to
to
figure
out
whether
that's
a
good
or
a
bad
chip,
and
once
you
feel
that's
the
right
spot,
let's
say
you
make
a
tape
out
and,
and
this
way
you
can
iterate
quicker,
because
the
problem
with
physical
chips
is
obviously
that's.
That's
taking
a
lot
of
time.
B
So
so
that's,
let's
say
one
practical
practical
example
of
using
such
a
flow
but
yeah
to
do
that,
you
have
to
somehow
find
a
way
to
assimilate
that,
and
the
problem
of
simulation
is
that,
despite
what
Michael
talked
in
the
previous
it's
a
couple
talks
ago,
which
feels
like
ages,
violator
is
quite
fast,
but
it's
quite
fast
for
gate
level
simulation.
So
it's
still
super
slow
for
software
Engineers.
This
is
ridiculous.
It's
as
if
we
were
compiling
something
and
you
had
to
come
back
three
days
later,
to
get
your
binary.
B
So
by
that
time
you
even
forget
your
train
of
thoughts,
that's
very
inconvenient
for
software
development,
so
you
have
to
find
a
way
to
both
be
able
to
get
something
that
resembles
your
chip,
because
in
the
end
you
want
to
produce
something
real,
but
also
something
that
can
run
your
software
in
a
way
that
you
will
get
results
quickly.
So
you
have
to
somehow
partition
Your
Design
between
gate
level,
simulation
and
behavioral
simulation,
something
that
behaves
as
your
chip,
but
actually
has
some.
B
Let's
say
trade-offs
inside
that
you
don't
care
as
a
software
engineer
or,
for
example,
you
will
not
care
for
it
for
the
most
of
the
time
and
then
once
in
a
while,
you
actually
run
or
in
the
background
you
run
the
full
simulation
and
you
you
get
the
results
in
the
end.
So
for
that,
so
so
we're
thinking
about
doing
that
for
Sky,
130,
so
obviously
Sky.
One
Friday
is
very
it's
a
very
good
candidate
because
it's
very
well
partitioned
it
has
you.
B
Could
you
could
say
it
has
a
system
on
chip
like,
even
if
you
had
a
blank
design,
it
would
ship
as
a
CPU
right.
So
there
is
a
risk
high
for
aircraft
car.
There
is
some
spy
uart
like
a
typical,
tiny
microcontroller
and
would
be
usable
right,
and
the
idea
of
the
of
the
program
is
to
put
your
design
the
user
area,
and
the
designs
sometimes
have
nothing
to
do
with
the
so-called
management
core.
B
But
there
is
the
possibility
to
connect
it
to
the
bus
right
and,
if
you
so,
if
you
design
something
like
that,
you
will
create
effectively
something
that
for
software
Engineers,
it
will
be
called
a
peripheral
or
a
device
that
you
know
for
kernel
developers.
That's
the
thing
where
you
will
Implement
your
drivers.
B
So
there
is
this
special
use
case
where
you're
extending
this
this
system
on
chip,
which
is
an
interesting
example.
So
we
looked
at
some
of
the
applications
that
so
so
obviously
there's
a
huge
amount
of
designs
and
some
of
them
actually
follow
this
idea.
So
they
add
a
particular
accelerator
to
the
to
the
core,
so
they're,
not
putting
another
car
so
that
you
have
a
car
inside
your
car.
But
instead
you
just
add
the
peripheral
and
you
assume
the
risk.
B
5
is
just
there
and
the
thing
is:
if
you're
designing
this
peripheral,
you
don't
care
about
the
risk.
Five
part
you're,
not
really
changing
it
right,
so
you
assume
it
will
work
like.
We
know
that
in
practice
it
might
not
be
the
case,
but
it's
not
the
part
that
you
are
caring
about.
So
you
care
about
your
IP,
but
you
also
want
to
run
some
software,
so
you
have
to
first
of
all
write
the
software
to
be
able.
B
B
While
we
designed
the
chip
and
for
that,
you
need
tools
and
we're
using
two
tools:
one
is
renode:
that's
an
open
source
project
that
micro
created
and
that's
a
fast
simulator.
That
is
a
behavioral
simulator.
So
it's
not
on
the
gate
level,
but
it
behaves
as
if
it
was
a
CPU
that
was
in
your
Asic.
So,
for
example,
in
this
case
it's
a
it
can
be
a
risk
five.
In
practice,
we
have
a
lot
of
different
architectures
and
it's
very
easy
to
extend
it.
B
So
so
the
idea
is
that
if
you
happen
to
pick
something
standard
risk
five,
you
more
or
less
get
that
off
the
shelf.
If
you
want
something
custom,
you
have
to
create
this
behavioral
model
of
your
CPU,
and
then
we
obviously
use
very
later
for
oh,
no,
the
slides
are
slow
but
not
as
slow.
You
can
use
very
later
to
basically
simulate
your
IP.
You
have
to
obviously
glue
it
together,
so
there
is
some
magic
going
on.
There
is
the
peripheral
that
is
running
in
a
very
later
and
the
wishbone
layer.
B
Let's
say
that
glues,
the
the
gate
level
wish
ball
to,
let's
say
abstract
Wishbone
API,
that
Renault
can
talk
to
and
and
this
way
from
renal
perspective,
we're
just
writing
and
reading
on
the
bus
or
there
is
an
interrupt
or
we
want
to
maybe
progress
time
so
that
the
the
simulator
can
control
the
IP
and
talk
to
it
and
from
the
from
your
part
of
the
design
it
feels
as
if
there
was
a
wishbone
bus
and
everything
works
as
if
you
were
estimating
the
whole
design.
B
So
you
can
do
all
the
things
that
very
later
allows
you
to
do.
You
can
gather
waveforms
Etc,
but
at
the
same
time
you
can
run
software
at
a
reasonable
speed
that,
let's
say
resembles
work
with
a
real
Chip.
So,
instead
of
starting
a
simulation
waiting
for
for
first
character
to
pop
up,
you
can
get
a
reasonable
performance,
even
though
part
of
a
design
is
being
simulated
from
the
gate
level
and
depending
on
how
complicated
this
design
is.
Obviously
speed
suffers.
Now
you
can
obviously
always
take
a
faster
computer.
B
You
can
try
to
paralyze
things
so
there's
like
because
it's
all
simulated
on
a
computer,
you
have
some
ways
to
speed
it
up,
yeah
now,
so
so
in
mpw,
there's
Wishbone,
but
we
have
a
lot
of
other
buses.
We
have
axi.
Actually
we
started
with
axi.
I
will
show
a
little
bit
later
on
how
actually
that
was
originally
created.
So
mpw
is
just
let's
say,
repurposed
use
case,
but
in
general,
even
if
you're,
using
some
bastard,
we
don't
support.
You
just
have
to
implement
the
glue
code
to
connect
it.
B
B
So
in
terms
of
mpw,
let's
assume
that
the
user
project
is
just
a
single
verlock
file,
we
more
or
less
use
very
later
to
to
get
the
C
plus
plus,
compile
it
to
a
library
that
we
note
can
talk
to
it's
compiled
together
with
the
the
bus
so
with
the
model
of
the
bus
and
then
Reynold
can
talk
to
it
then
Reynold
loads,
the
test
software
and
the
platform
description,
which
also
includes
the
risk
5..
B
In
this
case,
and
then
we
can
run
our
test
software
and
and
see
the
results
as
if
we
had
a
chip,
so
so
in
practice,
the
mpw
I
was
assuming
that
Muhammad
will
talk
about
mpw
before
me,
because
he
was
supposed
to
talk
now.
But
I
guess
we'll
hear
about
mpw
in
great
detail
later,
but
we
had
already
a
couple
of
talks,
so
everyone
knows
more
or
less
what
it
is.
B
We
actually
picked
an
as
core,
so
so
we
take
it
unmodified
from
just
a
public
repo
and
the
idea
of
the
tester
is
that
it
can
basically
eat
this
repo
and
run
it
in
this
flow.
B
Obviously,
it's
a
hand-picked
example
where
it's
actually
using
the
wishbone
and
there's
this
assumption
that
that
the
CPU
is
being
used
and
also
this
contributor
created
software,
so
which
is
interesting
because
there's
some
projects
that
also
follow
this
rule,
but
they
have
no
software
I
guess
they
didn't
have
the
flow,
so
they
could
like
they're
waiting
for
the
chip
which,
like
is
very
often
that's
the
problem
that
a
year
later,
you
don't
have
the
software,
because
you
don't
have
the
chip,
so
we
were
able
to
actually
verify
and
even
prove
that
the
software
is
correct
so,
which
is
I,
think
pretty
pretty
cool
for
this
particular
design.
B
It's
all
on
GitHub,
it's
possible
to
to
play
with
it
a
little
bit
on
like
how
you
connect
it.
So
that's
the
glue
code
for
the
wishbone,
it's
also
on
GitHub.
So,
let's,
let's
maybe
dive
into
that
in
terms
of
Reno.
The
platforms
are
more
or
less
described
like
that,
so
just
a
small
config
file
that
describes
where
the
things
are
connected.
B
In
this
case,
there
is
a
a
very
related
peripheral
that
is
just
a
so
a
double
word,
peripheral,
so
something
that
you
can
write
with
32-bits
or
read:
32-bit
values
from
it's
mapped
on
a
bus,
so
more
or
less,
and
then
some
info
on
how
where
to
find
actually
the
the
gate
level
model.
So
so
the
very
related
code
Android
note,
will
load
it
automatically
and
behave
as
if
it
was
a
native
reload
model.
B
Then
we
so
the
Assumption
in
renote
is
that
you
can
use
it.
Let's
say
just
as
a
as
a
tool
to
develop
something
on
your
computer,
but
it's
really
powerful
when
you
do
it
in
the
CI.
So
we
allow
people
to
write
tests
in
many
Frameworks,
including
one
that
we
use
internally
for
testing
renote,
which
is
Robot
Framework.
So
you
write
a
simple
test.
B
You
basically
include
the
design
start
simulation
wait
for
Align
in
a
log
that
shows
that
software
wrote
something
at
something
somewhere
and
the
whole
script
on
GitHub
shows
like
there's
some
magic
value
and
some
magic
address
that
this
software
happens
to
be
writing
to
to
actually
show
the
result
of
the
computation.
So
we
can
check
if
the
computation
is
correct.
B
It's
it's
already
there
connected
to
GitHub
actions,
so
you
can
go
there
open
the
the
green
tick
and
then
go
to
run
test
and
see
if
the
test
passed
and
what's
the
expected,
let's
say
value
and
if
it
matches
so
so
it's
basically
possible
to
connect
it
to
your
repo
and
then,
when
you
change
stuff,
you
can
get
a
tick
or
obviously,
if
you
fail,
you
know
immediately
that
doesn't
work.
B
You
can
do
it
locally,
it's
pretty
simple,
just
obviously
in
inside
those
scripts,
some
things
are
happening
and
you
have
to
download
a
few
tools,
but
more
or
less
you
can
do
it
with
those
free
commands.
B
There's
also
like
them
that
I'm
not
going
to
do,
because
that
maybe
would
be
a
stupid
idea
because
we're
out
of
time,
but
anyone
can
just
open
it
and
because
Google
research
is
providing
Google
call
up
for
free,
which
is
basically
compute
in
the
cloud
that
you
can
just
open
in
your
browser
and
it
will
magically
give
you
a
computer.
You
can
run
all
this
demo
just
in
Google
collab,
by
checking
the
QR
code
or
clicking
on
the
link.
I
guess
we'll
publish
the
slides
later
or
you
can
come
to
me.
B
I
can
show
you
yeah
and
so,
but
let's,
let's
talk
about
some
use
cases
that
are
maybe
interesting
because
that's
the
mpw
is
let's
say
a
special
case
because
we
have
all
the
RTL.
So
somebody
could
say:
let's
just
use
very
later,
simulate
everything
maybe
fix
few
bucks
and
wear
later
so
that
it
works
100.
But
why
would
we
need
this
type
of
division?
But
the
problem
is
that
very
often
we
don't
have
the
code
for
lots
of
the
AP
that
we
have
or
like
it's
for
some
reasons
impossible
to
simulate
it.
B
It
could
be
licenses
Etc,
and
this
is
also
a
place
where
we
can
use
a
simulator
like
that.
So
we
can
write
the
behavioral
model
of
something
we
don't
care
that
we
let's
say
buy
and
it's
pre-verified
and
we
know
that's
not
the
part
we're
changing.
So
we're
not
like
there
are
no
knobs
that
we
are
playing
with,
but
there's
some
other
IP
that
we
have.
That
we're
working
on
that
we
want
to
test.
B
So
that's
that's
one
use
case
and
I
would
say
a
quite
popular
one,
and
very
often
it's
combined
with
the
fact
that
the
IP
that
we're
using
is
also
let's
say,
very
complex.
It
could
be
I,
don't
know
an
arm
core
that
that
you
bought
and
you
you're
just
putting
it
in
and
then
you
want
to
add
your
peripherals,
so
you're
not
actually
customizing
the
arm
core
you're
customizing
the
peripherals.
So
so
that's
that's
one
use
case.
Another
use
case
is
actually
why
we
originally
created.
B
It
was
Zinc,
which
is
an
interesting
I,
would
say,
metaphorically
speaking,
very
similar
to
npw,
because
there's
also
a
CPU,
that's
already
there,
and
you
also
have
your
space
that
happens
to
be
an
fpga
which
is
slightly
better
than
a
tape
out,
because
if
you
have
a
buggy
bit
stream,
you
can
always
just
change
it.
You
can
even
do
it
on
the
fly,
so
it's
like
much
better
in
terms
of
iteration,
but
still
if
you're,
for
example,
writing
a
dma
driver
and
zinc
is
actually
the
let's
say
if
you're
doing
something
on
on
zinc.
B
B
So
you
you
have
to
test
this
this
dma
somehow
and
to
test
it.
You
have
to
boot
a
lot
of
software
so
so
like
there's
a
huge
software
stack
that
you
have
to
that.
You
don't
change
at
all.
You
want
to
only
test
your
your
dma,
so
you
have
this
layers
of
layers
of
software
that
ideally
would
be
able
to
test.
B
You
could,
of
course,
in
theory,
just
write
bare
metal
software
to
test
your
dma
and
say
yeah,
it's
great
now,
let's
give
it
to
Kernel
developers
now
they'll
re-implement
it
in
Linux,
and
then
there
will
be
a
bug
and
people
just
be
saying:
oh
it's
those
guys
fault,
but
here
you
can
actually
boot
Linux.
Have
this
one
dma
simulated
very
later
test
your
driver
and
find
all
the
bugs
so
iron
out
all
the
bugs
and
then
pass
it
on
real
Hardware.
B
When
you
are,
let's
say
more
confident
that
at
least
on
a
digital
level,
it
works
because
there
is
like
I
would
say
there
are
bugs
that
are
more
tricky.
But
there's
a
lot
of
bugs
I
was
at
95.
Percent
of
bucks
are
just
normal,
bugs
it's
not
that
your
compiler
is
wrong
or
you
might
there's
a
bug
in
the
hardware.
It's
more
like
it's
it's
problem
with
software
or
some
obvious
problem
that
you
just
have
to
see
and
to
be
able
to
see
it.
You
have
to
be
able
to
run
it.
B
So
the
reality
is
that's
very
simple
in
normal
computers,
but
very
hard
and
embedded.
So
that's
why
we
we've
created
it.
I
think
mpw
is
very
similar,
so
we
actually
have
a
dma
that
we
were
verifying
this
way
and
we
fixed
a
lot
of
bugs
like
even
when
we're
using
it.
There
were
some
use
cases
where
it
turned
out
that
when
you
do
this
or
that
it
doesn't
work
or
we
open
source
it
and
then
some
other
people
started
using
it,
they
found
even
like
more
ways
to
break
it.
B
So
it's
very
interesting
to
see
how
many
Bucks
you
can
have
in
an
IP
which
proves
the
point
that
it's
important
to
test
and
that
such
work,
such
tools
are
really
important
and
I
do
think
that
in
fpga,
like
probably
contrary
to
Asic
design,
because
the
price
of
making
a
mistake
in
Asic
is
really
high.
And
probably
if
somebody
makes
us
a
stupid
mistake,
it
will
be
like
so
swept
under
a
rug,
but
in
fpga
is
the
quality
of
Ip
varies
because
as
long
as
it
does
the
thing
it's
supposed
to
do,
it's
okay.
B
So
there's
like
endless
amount
of
you,
know
spy
controllers
and
weird
things
that
were
only
implemented
because
somebody
had
to
talk
to
One
chip.
So
it
can
only
do
this
one
chip
and
it
doesn't
really
work
and
obviously
it's
a
good
idea
if
you're
doing
it
once,
but
then
you
end
up
having
10
spy
controllers,
because
if
it's
not
good
enough,
maybe
even
within
the
company,
nobody
will
use
it
because,
like
Engineers,
who
always
say,
oh
I
can
just
you
know,
re-implement
it
in
a
day.
B
B
So
summing
up
it's
on
GitHub,
we
want
to
enable
it
to
for
all
future
mpw
shuttle
submissions,
those
at
least
that
follow
this
pattern
of
something
collected
over
a
bus,
so
that
people
can
write
software,
because
this
is
I
think
currently
kind
of
like
a
missing
link
and
also
it's
very
hard
to
figure
out
even
what
those
projects
do,
whereas
if
you
could
just
run
them
before
the
chips
are
shipped,
you
could
play
with
those
cars
and
see
what
they
do,
which
I
think
would
be
very
cool,
there's,
maybe
some
ways
this
could
be
used
that
we
don't
see,
so
it
would
be
great
to
talk
and
discuss.
B
Hopefully
we
can
scale
it
up
to
also
Global,
foundries
and
and
other
processes.
The
fact
is
that
this
is
not
really
dependent
on
that,
so
it
should
just
work
out
of
the
box.
It's
more
about
the
idea
of
having
the
designs
done
in
a
way
that
we
can
automatically
just
eat
them
and
know
where
the
things
are
so
like.
Currently,
that's
also
a
little
bit
of
a
problem.
B
The
structure
might
be
different
and
we
have
to
find
all
the
things
to
test,
but
we
have
this
example
of
of
this
one
car
and
there's
another
example.
So
so,
and
none
of
those
people
knew
that
we're
doing
it.
So
in
a
way
we
we
had
to
adapt
yeah.
So
that's
it.
B
An
instruction
set
simulator,
so
it's
instruction
accurate.
B
The
time
flow,
like
the
Assumption
of
the
time
flow,
is
that
every
instruction
moves
the
time
by
some
specific
fraction
of
time
that
you
define,
you
can
potentially,
let's
say,
make
it
work
in
a
way
that
different
instructions
might
take
different
amounts
of
time,
so
you
could
make
it
slightly
more
accurate.
But
in
this
sense
the
assumption
is
that
it's
when
you
say
there
is
100
instructions
per
second,
that
will
be
the
time
flow.
I
say.
B
Yes,
but
it
you
can
add
as
many
CPUs
as
you
want,
and
also
those
ecpus
don't
have
to
be
in
one
device
so
and,
and
the
time
is
virtual,
so
no
matter
how
many
CPUs
you
have
and
if
they
are
sharing
a
bus
or
not
the
time
flow
will
be.
Obviously
the
things
will
be
slowing
down
more
and
more,
but
they
will
be
synchronized
and
it
will
be
reproducible.
So
the
idea
is
that
it's
reproducible
and
the
time
flow
is,
is
the
same
each
run
and
there
is
a
seed.
B
It
would
be
very
similar
to,
however,
later
is
integrated,
so
that's
doable,
I,
don't
see
any
reason.
Why
not.
C
What
level
of
detail
does
it
get
to
you
mentioned
like
if
you
have
several
CPUs
on
a
bus?
Is
there
does
it
into
arbitration?
If
you
have
a
certain
literacy
requirement
or
starve
out
requirement,
does
it
get
to
that
level
of
emulation
or
no
or
it's.
C
See
and
then
how
many,
how
many
mips
do
you
get,
or
you
know
some
sort
of
speed
estimation
compared
to
it's.
B
A
hard
question,
so
the
how
it
works
is
it
translates
the
let's
say:
Target
assembly
to
host
assembly
so,
depending
on
you
know
how
lucky
you
are
in
terms
of
what
you're
translating
to
what
it's
faster
or
slower
and
also
depends
on
the
workload.
But
you
could
like,
for
let's
say
one
machine
on
a
normal
computer.
B
You
could,
you
could
get,
let's
say
native
performance
for
for
some
kind
of
an
embedded
CPU
like
couple
hundreds
megahertz
type,
then
obviously,
if
you
add
more,
it
will
get
slower
but
still
like
much
much
faster,
that
we'll
get
with
with
gate
level
simulation
for
obvious
reasons
and
with
the
CPU
simulation.
It's
not
in
the
presentation.
B
Obviously,
because
it's
a
little
bit
like
a
side
thing,
but
I
think
Michael
mentioned
it
in
his
presentation
yesterday
we're
allowing
other
CPU
simulators
or,
let's
say
core
simulators
to
be
glued
into
to
renote.
So
so
Google
has,
for
example,
an
experimental
core
simulator.
B
So
so
then,
obviously
you
can
try
to
optimize
them
for
speed
for
your
particular
architecture,
because
I
guess
hours
like
we
support,
arm
risk
five
and
Power
PC
and
some
other
architectures,
whereas
you
could
think
about,
for
example,
just
a
specific
optimized
use
case.
B
We
have
an
experimental,
for
example,
support
for
dromajo
from
Esperanto,
just
like
to
prove
that
we
also
can
have
an
interpreter,
yeah
and
and
then
like
from
renal
perspective.
It
just
looks
exactly
the
same,
but
we
have
to
glue
it
to
Reno.
So
there
are
some
modifications
that
we're
probably
going
to
Upstream.
A
Hi
Michael,
it's
my
understanding
that
renode
is
very
plugable
and
in
things
like
the
cfu
playground,
you've
been
able
to,
you
know
just
add
single
op
codes
and
things
like
that
to
the
simulator.
Could
you
talk
a
little
bit
more
about
that
yeah.
B
So
the
idea
of
the
whole
simulator
is
that
you
can
basically
take
a
peripheral
and
then
depend
on
the
other
extra
features,
so
you
can
basically,
instead
of
every
time
you
slightly
modify
something
you
have
to
write
from
scratch.
You
just
take,
let's
say
a
risk
five,
and
then
you
can
add
more
instructions
on
top
of
that,
and
you
can
do
it
like,
depending
on
on
the
let's
say,
expected
speed.
B
You
can
try
to
do
it
in
C,
but
you
can
also,
for
example,
do
it
in
Python,
so
you
can
experiment
really
quickly,
which
we
feel
is
very
often
more
important.
So
it's
more
important
that
you
can
extend
it
quickly
than
squeeze
out
the
performance,
because
that
you
can
do
later
once
you.
You
know
that
is
the.