►
From YouTube: Apache TVM Community Meeting, March 18, 2021
Description
Apache TVM Community Meeting Topics:
Status update on µTVM
Status update on Project Generator API for µTVM
A
A
A
I
work
for
octo
ml
as
the
developer
advocate
for
apache
tvm,
and
so
I'm
here
to
help
do
things
like
like,
like
run
the
community
meetings,
try
to
help
write
some
docs
and
you
know
just
kind
of
like,
hopefully
make
it
make
make
using
and
being
making
make
using,
tvm
and
being
part
of
the
tvm
community
an
easier
and
better
experience
for
everybody.
So
welcome
to
the
meeting
everyone.
B
C
B
D
A
E
A
D
A
A
Community,
okay,
so
with
with
with
the
with
the
introductions,
completed
whoops
we're
going
to
move
on
to
some
announcements,
the
so
the
apache
tvm
community
recognizes
people
who
are
contributing
to
the
project
with
with
different.
You
know,
with
different
status
of
you
know,
as
a
reviewer
or
as
a
committer,
and
so
over
the
last
month,
we've
we've
promoted.
A
Two
members
of
the
community,
so
we'd
like
to
welcome
andrew
royce,
is
as
a
as
a
new
committer
to
the
tvn
project,
as
well
as
dmitry
smirnov
as
a
new
reviewer
to
the
project.
So
a
big
round
of
applause
to
them,
and
thanks
for
all
of
the
work
that
they've
done
on
the
project,
all
of
the
all
of
the
work
that
they've
done.
A
I
don't
know
if
there
are
any
other
announcements
from
the
community
that
people
might
want
to
make
like
if
there
are
are
there
if
there
are
any
talks
or
any
any
presentations
or
anything
that
that
you'll
be
any
papers.
You
publish
with
tvm,
but
we'd
also
love
to
hear
about
those
here
too,
so
that
we
can
get
the
word
out
to
everyone.
C
G
Cool
yeah
thanks
so
much
for
organizing
chris
and
yeah,
I'm
andrew
royce.
I
work
on
micro,
tvm
yeah
for
those
of
you
who
don't
know
me
and
yeah.
So,
let's
see
maybe
I
could
share
my
screen
because
I
think
just
wanted
to.
I
don't
have
anything
super
formal
put
together,
but
I
thought
it
would
be
a
good
time
to
walk
through
our
m2
roadmap,
which
is
kind
of
what
we're
centering
all
of
our
work
on
actually
sorry,
chris,
could
you
enable
the
participant
screen
sharing
yeah?
G
I
just
I
just
turned
it
on
okay,
cool
thanks,
great
cool,
so
kind
of
the
way
we
are
planning
on
micro,
tvm
kind
of
at
a
high
level.
Is
we
use
these
road
maps
to
decide
all
the
different
projects
that
are
active
at
one
time
and
so,
like
our
previous
one?
We
linked
here,
which
was
a
standalone
micro,
tvm
roadmap,
and
each
roadmap
has
goals,
and
things
like
that.
So
last
year
we
you
know
tried
to.
G
So
we
want
to
be
able
to
right
now
we
support
zephyr,
fairly
tightly,
and
so
we'd
like
to
add
more,
I
guess,
rtos
or
platforms
or
other
ways
of
running
models
on
on
devices
we'd
like
to
also
support
extend
that
idea
of
environments
to
also
mean
other
architectures.
So
you
know
we
have
arm.
We
have
risk
five.
There
are
other
micro
architectures
out
there
that
you
could
imagine
adding.
G
So
we
just
wanna
sort
of
you
know,
prove
out
our
flexibility
there,
as
well
as
consider
architectures
that
are
kind
of
emerging
like
support
for
accelerators
on
socs,
which
are
sort
of
becoming
increasingly
close
to
reality,
these
days
in
the
microworld
and
okay.
So
then,
the
next
one
we
want
to
do
is
we
were
looking
to
build
a
an
integration
with
some
command
line
tool
for
tvm
and-
and
we
have
kind
of
some
initial
work
on
on
a
tool
called
tvmc
and
that's
actually
packaged
with
tvm.
G
The
last
thing
we
wanted
to
do
is
was
provide
a
little
bit
better
estimates
from
the
tbm
side
on
kind
of
the
model
footprint,
how
much
ram
how
much
code
space
are
we
going
to
be
using
on
on
your
device
before?
Hopefully,
before
you
run
your
firmware
compiler,
at
least
on
the
ram
size,
it
should
be
possible
to
estimate
that
a
little
bit
better
and
so
those
are
kind
of
our
goals
and
then
and
then
to
those
goals.
G
So
I
thought,
maybe
just
as
a
start
for
the
micro
tv
update,
we
could
just
go
through
the
projects
that
we
that
I
know
of
that
are
in
progress
and
if
anyone's
working
on
any
of
these
projects-
and
I
haven't
heard
about
it
yet
I'd
love
for
you
to
speak
up
and
give
us
an
update
I'll
start
with
the
first
one,
which
is
the
library
generator
and-
and
this
was
also
a
model
library
format.
So
I
have
a
couple
of
the
rscs
pulled
up
here.
G
G
Maybe
I'll
just
share
my
whole
desktop.
Let's
see,
can
everyone
see
that
same
window
now?
Can
everyone
see
finder
yep
that
looks
good,
okay,
great
yeah,
so
model
library
format?
I've
got
a
little
example
here.
I
don't
know
if
this
is
too
small
for
people
but
effectively.
This
is
a
set
of
output
files
that
we
think
kind
of
closely
reflects
the
output
of
tdm
relay
build
and
just
to
come
back
over
here.
That's
this
function
here,
that's
kind
of
our
core.
G
G
Here
you
see
the
graph
json
which
you
saw
before
we've
got.
I
guess
at
the
top
level.
We've
got
a
summary
of
the
model
here,
so
you
can
see.
This
is
a
super
simple
model.
I
don't
know
if
everyone
can
read
this
very
well,
but
in
here
you
can
see
we're
just
adding
two
tensors
of
size,
one
by
two
together.
So
this
is
a
really
simple
example,
just
intended
to
kind
of
make
sure
that
things
are
kind
of
working
for
another
demo
I'll
do
a
little
bit
later,
there's
a
metadata
file
at
the
top
level.
G
That
kind
of
gives
an
idea
of
the
memory,
the
different
tensors
that
we
need
to
allocate
in
memory,
and
so
you
can
see
here
like
for
this
simple
example:
we've
got
a
a
tensor
for
a
a
tensor
for
b
and
then
a
tensor
for
the
product.
Basically
or
sorry
the
the
sum
of
a
and
b,
you
can
also
learn
about
the
target
that
was
used
to
compile
this.
G
Then,
looking
to
the
actual
code,
we've
got
a
codegen
directory
underneath
the
codegen
directory.
This
host
target
here
is
is
in
the
host
directory.
Here
is
intended
to
group
together
all
of
the
code,
that's
intended
to
run
on
the
host
cpu,
and
if
you
were
compiling
a
model
into
some
sort
of
heterogeneous
scenario,
you
may
have
another
directory
here
that
would
contain
code,
that
would
run
say
on
an
accelerator
on
a
gpu
that
kind
of
a
thing.
So
the
intent
is
to
accommodate
that
here.
G
Inside
of
host
we've
got
src
and
you
can
also
have
a
live
directory.
If
you
were
compiling
with
the
llvm
backend,
and
here
you
can
see
our
two
source
files
we
produce
here.
One
of
them
contains
a
function
registry,
which
is
for
the
c
runtime
when
doing
remote
code
execution
and
the
other
one
is
just
the
implemented
edition
here.
So
so
that's,
hopefully
a
whirlwind
tour
of
oh,
I
guess.
The
last
thing
I
should
say
is:
there's
also
a
very
small
parameters
file
and
that
contains
the
third
output
from
tvm
relay
build.
G
So
that's,
hopefully,
a
very
small
whirlwind
tour
of
what
we've
got
for
model
library
format
right
now.
This
format
is
not
set
in
stone.
We
put
a
version
number
there
on
purpose
and
you
know
we
intend
to
kind
of
expand
it.
One
one
known
issue
that
I've
discovered
is
that
we
don't
currently
support
producing
this
from
just
plain
tvm.build,
which
is
kind
of
a
function
we
use
to
build
single
operators,
and
so
we'll
have
to
look
at
that.
G
G
So
that's
that
project
next
we
have
auto
tuning
support
and
I've
actually
got
a
pr
for
this
up
and
it's
a
little
bit.
It's
it's
close
to
ready
to
merge,
but
it
it
has
a
there's
a
little
bit
of
a
a
problem
where
it
expands
the
set
of
tvm
dependencies
that
are
are
required,
and
so
I
was
kind
of
letting
this
one
sit
for
a
moment.
While
I
work
on
the
product
generator
api
and
as
we'll
discuss
later,
that's
kind
of
meant
to
resolve
this
problem.
G
Nevertheless,
you
can
run
this
if
you,
if
you
pull
this,
commit
and
and
see
how
it
works.
So
that's
kind
of
the
support
the
status
there,
the
ahead
of
time,
runtime.
I
know
that
we've
got
this
rfc
here
from
giuseppe
and
I
believe,
there's
been
some
implementation
done
there.
I
don't
know
if
you
guys
are
interested
in
giving
a
short
status
update
or
we
can
kind
of
leave
it
at
that
for
now
and
and
get
a
more
comprehensive
one.
You
know
at
a
later
date.
D
H
H
G
We've
kind
of
discussed
here
like
some
of
the
different
you
know:
high-level
accounts
aren't
implementation
and
you
know
as
you're
working
through
an
rfc.
It's
kind
of
nice
to
you
know
to
get
some
high
level
feedback
and
then
go
and
and
make
a
pr
that
people
can
look
at
more
in
detail,
and
so
I
think
we're
definitely
in
that
phase
of
things
where
you
know
just
good
to
have
more
more.
I
F
I
A
H
Yeah,
so
basically
there
is
this
glt
memory,
which
we
basically
we
basically
borrowed
from
from
the
graph
run
time
memory
management
we
we
are
not
touching.
We
are
sort
of
reusing
we're
sort
of
using
that
for
now
the
memory
still
needs
to
be
specified
as
a
sort
of
a
a
constant
in
the
in
the
runtime
but
yeah
once
the
once.
The
work
is
is
done.
That
is,
it's
gonna,
be
very
easy
to
to
to
have
something
a
bit
better
than
that
yeah.
G
Definitely,
I
think,
also
from
our
side
we,
we
kind
of
see
the
memory
management.
I
assume
what
you're
asking
about
michael
is
is
kind
of
the
need
to
remember
the
desire
to
remove
kind
of
this
dynamic
memory
allocation
from
the
from
the
runtime,
and
we
kind
of
see
that
as
a
little
bit
separate
from
the
aot
runtime,
the
aot
runtime,
you
know
we
want
to
focus
on.
G
H
H
A
H
Producing
a
sort
of
tier
model,
so
this
this
function
that
then
we
show
in
this
tbm
run
func
is
generated
through
tier,
so
we
will
have
a
tvm
run,
function
function
and
so,
once
you
have
here,
everything
is
steer
and
then
basically
you
can.
You
can
do
a
sort
of
unified
memory
planning
we
want
so
yeah.
That's.
H
J
Hi,
my
name
is
ramana.
I
also
work
at
arm.
I
think
one
of
the
other
ways
of
saying
that
is.
We
see
the
static
memory
planning
or
the
aot
memory
planning
as
a
key
part
of
enabling
micro
tvm
on
embedded
systems,
and
we
are
also
very
interested
in
that
from
the
point
of
view
of
supporting
cortex
and
the
cortex-m
architecture,
as
well
as
the
ethos.
U
micro,
npu,
that
we
are
working
on
so
so
this
is
so.
J
G
G
G
There's
another
one
in
here:
this
tpm
device,
alec
data
space,
and
so
these
are.
This
is
used
for
the
inter
operator
memory.
So
that's
like,
if
you
have
an
operator
that
produces
a
tensor,
it
uses
this
call
and
and
then,
if
you
have
a
if
you
want
to
to
get
a
temporary
working
area
from
within
operator,
we
have
this
other
call
here:
tbm,
backend,
allocary
space,
so
you'll
see.
One
of
these
is
in
the
back
end,
see
back-end.
G
Api
tvm
expects
the
c
back-end
api
to
be
implemented
just
to
run
operators,
because
any
of
these
functions
are
legal
to
be
called
from
operators.
Meanwhile,
this
tvm
runtime
api,
the
device
alec
data
space
that
one
we
use
from
sort
of
nd
array
and
from
our
our
graph
runtime.
I
believe
to
allocate
these
inter
tensor
memories
and
so
for
micro
tvm.
It
all
goes
to
the
same
place.
G
It
goes
to
this
tvm
platform
memory,
but-
and
that's
that's
what
giuseppe
is
saying,
but
but
we
do
still
have
this
sort
of
bifurcated
concept
at
the
at
a
higher
level
here
and
so
pursuing
this
compile.
Engine
refactor
will
create
a
sort
of
fuse
tir
function.
What's
the
right
way
to
say
this,
while
we're
compiling
a
relay
function,
we
partition
the
function
into.
I
guess
what
I
would
say:
ta
are
our
tasks.
G
These
are
kind
of
individual
units
that
you
can
auto
tune
and
at
the
end
of
that
process,
we
don't
ever,
I
believe,
assemble
a
sort
of
a
glue
function.
That
then
represents
the
call
graph
in
tir
again
once
we
partition
that
call
graph.
We
don't
we
don't
have
a
good
way
to
to
visit
it
with
look
like
your
traditional
compiler
visitor
architecture.
So
this
remove
compile
engine
change
is
sort
of
the
first
step
to
to
fusing
the
back
together
the
graph.
G
At
the
end
of
the
compile
compilation
step,
we
think
that
will
number
one
enable
a
bunch
of
interesting
optimizations
with
kind
of
graph
level
optimization,
but
also
too.
I
think
this
will
allow
us
then
to
run
the
graph
memory
planner
over
the
entire
original
relay
function
and
as
it's
implemented
in
here,
and
so
that
will
allow
us
to
do
memory
planning
across
the
entire
graph.
So
does
that
kind
of?
I
guess
maybe
that
hopefully
that
clarifies
your
kind
of
where
we're
going
with
that
michael.
D
F
D
G
Separated
and
the
idea
is
to
make
that
appear
as
if
they're,
combined
in
in
the
visitor
logic,
but
I
don't
hold
me
to
that,
because
I
haven't
actually
read
this
change
as
much
as
I
should.
So
I
think,
if
you
have
an
opinion
on
that,
there
will
certainly
be
plenty
of
time
for
youtube
to
voice
your
opinion,
yeah
sure,
yeah
and
and
with
changes
like
this.
You
know
it's
worth
pointing
out
to
the
community
that
you
know
as
we
develop
these
changes.
G
We
we
always
want
to
go
through
an
rfc
process
to
make
sure
people
are
are
okay
with
these
changes
and-
and
this
particular
change
is
like
I'm,
showing
you
kind
of
like
a
early
look
at
our
kind
of
our
proof
of
concept
work
and
especially
as
you're
writing
an
rfc.
It's
really
helpful
to
just
do
a
proof
of
concept
to
make
sure
that
you're
what
you're
writing
the
rfc
kind
of
matches
with
reality
and
that
you
aren't
sort
of
talking
past
yourself.
G
I
guess
that
makes
sense,
and
so
you
know
at
some
point
when
we
actually
come
to
a
point
where
we
want
to
merge
this
we'll
develop
an
rfc
and
release
that
on
the
discuss
forum,
and
so
especially
for
a
change
for
for
points
like
this.
I
think
that's
a
great
place
to
bring
that
up.
It
certainly
doesn't
you
know
just
because
we
finished
the
rfc.
The
proof
of
concept
doesn't
mean
that
the
rfc
is
too
late
to
ask
for
things
like
that.
So
cool,
okay.
H
H
G
G
G
I
don't
know
that
that
much
has
been
done
on
this
yet,
but
we'd
still
like
to
to
work
on
this
zephyr
has
a
couple
of
boards
to
find
for
risk
five
and
I
think
the
easiest
way
to
kind
of
start
tackling
this
would
be
just
to
work
with
that.
Actually,
I
will
walk
that
back
a
little
bit
and
I
think
there
was
a
forum
post
on
this
last
month.
I
want
to
say
that
someone
had
worked
through
this.
I
need
to
revisit
that
before.
G
I
could
give
you
a
summary
of
exactly
where
that
was,
but
I
think
it
did
get
some
traction,
so
some
work
being
done
there
comprehensive
memory.
Planner
is
what
we
just
discussed.
That's
the
idea
that
we
have
these
two
different
ways
of
allocating
memory
from
the
compiler's
perspective
and
we'd
like
to
be
able
to
at
least
see
all
of
them
in
the
memory
planner,
whether
or
not
things
get
moved
sort
of
fused
into
a
single
back-end
call
or
whatever
that's
sort
of
up
for.
G
I
think
that'd
be
another
question
project
level.
Api
we'll
discuss
that
after
we're
finished
with
going
through
this
milestone
roadmap
list,
but
just
to
give
you
kind
of
a
a
taste
of
this,
because
I
wanted
to
talk
a
little
bit
about
what
it
means
for
the
next
one
here.
The
the
current
way
we
implement
we
integrate
with
with
platforms
and
rtos
are
by.
G
G
But
one
of
the
I
guess
upsides
of
doing
this
is
that
especially
of
the
the
interface
cleanup
is
that,
as
we
discussed
earlier,
we
want
to
start
building
these
command
line
tools
for
tbm
tbmc
is
for
building
towards
and
tbmc.
We
want
to
be
able
to
do
things
like
take
it,
take
a
a
relay
model
or
some
some
onan
x
model
or
any
of
the
formats
that
tvm
can
import
from
compile
that
into
c.
G
Build
generate
a
firmware
project,
build
the
firmware
project,
flash
the
firmware
project
and
sort
of
drive,
remote
execution
on
on
a
device,
and
one
of
the
so
so
doing
all
that
is
kind
of
in
the
domain
of
the
project
level
api.
But
then
that
allows
you
to
also
add
those
features
to
the
tbmc
command
line
tool
so,
rather
than
having
these
python
scripts
that
you're
kind
of
running
that
have
a
bunch
of
code.
I
wonder
if
I
had
put
up
an
example
of
that
so,
rather
than
having.
G
So
a
lot
of
our
our
demo
code
looks
like
this
right
now,
it's
sort
of
a
bunch
of
python
and
you
have
to
write
sort
of
custom
python
to
match
your
workload
and
and
and
drive
the
entire
compile
build
flash
toolchain
from
here.
That's
a
lot
of
a
big
ask
for
a
developer
who's
just
coming
to
tvm,
to
try
to
add
a
machine
learning
model,
particularly
if
they've
got
a
bunch
of
other
project
specific
stuff
already
set
up.
G
B
G
G
Regions
kind
of
depends
on
the
situation,
but
you
know
that's
kind
of
future
work
that
we're
hoping
to
get
into
in
the
next.
Maybe
in
a
month
or
two
footprint.
Estimation
comes
directly
from
that.
Once
you
can
do
that,
then
you
should
be
able
to
say
that
you
need
a
certain
amount
of
ram.
That's
kind
of
it's
almost
comes
for
free
from
pin
memory.
G
G
G
I
think
I
just
posted
it
yesterday,
so
I'll
do
a
little
bit
of
an
intro
and
maybe
show
you
a
demo
of
that,
just
to
show
you
sort
of
the
proof
of
concept,
but
just
wanted
to
stop
for
a
second
and
see
if
anyone
has
any
questions
or
things
they
wanted
to
bring
up
or-
or
you
know
hey.
Why
aren't
you
working
on
this?
That
kind
of
a
thing.
G
G
Just
briefly
show
the
compiler
interface
so
right
now
the
way
that
tvm
integrates
with
well
okay,
maybe
it's
a
good
idea
to
back
up
and
talk
a
little
bit
about.
Why
do
we
even
care
about
compiling
code
from
from
tvm
shouldn't?
We
just
generate
code
and
be
done
with
it,
because
you
know
in
some
sense
for
for
from
our
projects.
G
You
know
the
exact
c
code
that
you're
running
on
your
microcontroller,
particularly
when
you
know
it
may
be
that
in
in
a
first
cut
of
your
implementation,
it
turns
out
that
the
memory
that
you
give
it
is
kind
of
off
in
the
weeds
and-
and
maybe
one
of
these
ad
instructions
triggers
a
hard
fault.
So
how
could
you
debug
that,
if
you
know
we're
sort
of
generating
this
binary
blob
right,
it's
kind
of
nice
to
be
able
to
have
some
level
of
this
code?
So
you
can
point
your
debugger
at
it.
G
So
why
should
tvm
even
think
about
building
and
compiling
code?
And
this
you
know-
comes
back
to
basically
tvm's
optimization
strategy,
which
is
search,
and
so
you
know
at
some
level
in
order
to
to
get
good
performance.
We
have
to
go
through
this
sort
of
test
loop,
where
we,
we
have
a
high
level
description
of
your
model
and
we
break
that
up
into
tasks.
This
is
the
auto
tvm
process
and
then
for
each
task.
G
We
sort
of
try
many
different
ways
of
implementing
the
task
on
device,
so
things
like
reordering
for
loops
things
like
changing
the
stride,
I
guess
of
a
computation
unrolling
for
loops.
That
kind
of
a
thing,
and
so
we
we
do
that
we
basically
generate
a
bunch
of
different
candidate
operators
and
then
the
next
thing
we
want
to
be
able
to
do
is
time
those
operators
well
for
that.
That
means
that
we
need
to
be
able
to
build
flash
and
run
code
on
a
microcontroller.
G
So
this
is
why
we
even
care
about
integrating
with
compiler
full
chains
and
right
now,
starting
from
this
project.
Api
kind
of
our
integration
is
quite
tight.
I
would
say
so.
We
have
this
tv
microcompiler
class,
just
jump
over
here,
real
quick
to
show
it
to
you,
it's
an
interface.
So
it's
you
know
it's
meant
to
be
implemented
and
we
have
a
couple
different
implementations
in
the
repo,
but
tbm
expects
to
compile
like
a
library,
very
separately
and
and
then
a
binary,
and
why
do
we
do
this?
G
Well,
that's
because
for
auto
tvm
there's
several
pieces
that
don't
ever
change
the
rpc
server,
the
all
these
common
memory
allocation
functions
that
you
saw
before
and
then
there's
kind
of
the
one
changing
piece
between
iterations,
which
is
like
the
different
operator
implementation
and
to
start
with.
You
know
when
I
started
when
I
started
writing
this
project.
G
It's
worth
saying
that
a
lot
of
these
build
systems
have
an
initial
spin
up
like
when
we're
building
for
x86
you
just
kind
of
launch
gcc
or
g
plus
plus,
and
then
let
it
do
its
thing
and
build
a
dotto
file,
and
it
doesn't
have
very
much
overhead.
But
when
you're,
for
example,
launching
zephyr,
it
wants
to
do
a
bunch
of
board
specific
discovery
to
figure
out.
You
know
which
module
should
be
enabled,
how
much
ram
do
you
have
and
and
that
process
actually
takes
considerable
time.
G
So
when
you're
doing
this
one
time
for
each
library
or
binary
implementation,
you
get
a
lot
of
overhead
here.
So
all
that
kind
of
came
together
to
make
me
sort
of
want
to
reevaluate
the
project
api
that
we
introduced.
So
we
have
this
compiler,
flasher
and
transport
classes
that
we
were
kind
of
using
to
model
the
whole
compilation
flow.
G
And
that's
not
sorry.
Let
me
go
back
here.
That's
not
exactly
I
mean
if
I
was
an
embedded
developer.
I'd
start
with
this
and
say:
okay
well,
first
we'd
want
to
generate
a
firmware
project
that
had
everything
in
it
and
we
just
want
to
run
a
sort
of
build
step.
Not
don't
worry
about
library
or
binary.
Just
build
the
project
then
program
the
project
on
device
and
then
you
know
somehow
drive
the
execution.
G
J
G
Ambition
here,
yes,
the
main
and
well,
I
would
say
that
is,
I
would
say
I
would
almost
say,
that's
the
primary
goal.
I
think
the
secondary
goal
of
this
is
that
we
we
get
a
if
you
want
to.
You
can
also
use
this
as
a
project
generator
for
for
projects
that
don't
just
run
auto
tvm,
but
the
primary
goal
is
to
sort
of
enable
this
auto
tvm
build
flash
or
generate
build
flash
execute
workflow.
G
G
Yeah
I
mean,
I
think,
that
that's
basically
a
big
question
and
I
think
one
of
the
challenges
we
have
with
the
current
system
is
that
right
now,
if
we
want
to
look
for
a
particular
compiler
implementation,
we
look
in
tv
and
micro
contrib
and,
if
we're
you
know,
signing
up
to
maintain
one
we're
putting
it
all
in
here-
and
you
know
this
was
non-trivial
even
just
to
get
zephyr
working
it.
It
meant
that
we
had
to
check
in
well
it's.
G
It
meant
that
we
had
to
create
like
a
new
ci
container,
and
none
of
this
work
is
like
particularly
unexpected.
But
I
think
what
you're
getting
at
here
is
like
what
I
was
seeing
with
the
tvm
repo.
How
much?
How
much
work
is
it
going
to
be
to
maintain
the
cross
product
of
these
things,
especially
in
the
sense
that
they're
occupying
the
same
virtual
environment
and
occupying
the
same
ci?
G
Every
project
evolves
in
its
own
right
exactly
exactly
so.
I
kind
of
see
this
as
tvm
putting
a
a
line
in
this
hand
of
here's.
Here's
kind
of
the
api
around
which
we
expect
the
product
to
to
build,
and
it's
it's
a
very
loose
api.
So
it's
not
something
that
you
need
to.
You
know
really
tightly
integrate
with
your
with
your
platform.
You
know
these
generate
build.
Flash
steps
are
are
very
high
level
steps
that
almost
every
platform
is
gonna
to
implement.
G
J
G
Right,
let
me
talk
a
little
bit
more
about
where
I
see
this
like
living
and
then
maybe
maybe
I
I
actually.
This
is
a
really
good
point
to
bring
up,
because
this
is
one
of
the
things
I
wanted
to
one
of
the
areas
of
feedback
I
wanted
to
solicit
about.
This
was
like
there
are
some
sort
of
implications
of
doing
this,
that
sort
of
mean
it
will
change
where
code
lives,
so
maybe
just
to
quickly
go
through
the
rest
of
this
implementation,
and
then
we
can
come
back
to
this.
G
Oh,
no,
no,
no
problem!
No!
I'm
thanks
for
bringing
this
up.
It
was
a
great
great
question.
Ask
so
you
start
with
this
template
project
and
underneath
that
template
project
you
have
let's
say
you
want
to
implement
this
server
in
python.
You've
got
a
microtubule
api.
Server.Py
tvm
will
look
for
this
file
and
just
run
it
if
it
if
it
finds
it
in
order
to
start
the
server.
G
The
other
thing
you
can
do
is
you
can
have
a
shell
script
that
launches
the
server
it'll
run
that
instead
this
template
project.
The
idea
is
that
it
has
kind
of
the
the
the
generic
glue
that
you
need
to
actually
run
computation
on
the
device,
so
src
main
would
be.
This
is
very
similar
to
sort
of
our
template.
G
Okay,
so
you've
done
that
and
then
what
you
would
do
is
is
in
the
generate
step.
You'd.
You
tell
this
api
server
to
generate
another
project,
point
out
a
directory.
It
would
create
a
very
similar
directory,
but
with
you
know
the
model
library
format
inside
of
that
directory,
as
well
as
and
then
sort
of
expand
that
model
library
format,
maybe
copy
source
files
around.
However,
however,
it
needs
to
set
up
the
generator
project.
G
At
this
point,
then
you've
got
this
artifact
that
you
can
interact
with
just
like
any
other
saved
effort
project
that
you're
familiar
with
in
the
past,
so
you're
creating
a
project
on
disk,
that's
standalone
for
micro
tvm.
You
can
build
it
with
the
zephyr
west
tool.
You
can
flash
it
with
that
tool
and
and
debug
it
just
like
any
other
firmware
project
you're
used
to
so
that
kind
of
solves
one.
Big
pain,
point
of
development
developing
with
tbm
right
now,
which
is
that
debugging
is
kind
of
very
integrated
with
tvm.
G
The
next
thing
is
that
we
want
to
be
able
to
have
this
api
server
live
in
a
separate
virtual
environment
from
tvm,
and
so
in
order
to
to
facilitate
that,
that
means
we
need
to.
We
can't
just
import
this
python
api
we'd,
like
we,
we
have
to
define
an
rpc
system
that
sends
commands
and
receives
commands.
I
wrote
a
little
summary
of
kind
of
options
I
picked
here
and
I'd
love
to
hear
feedback
if
others
prefer
other
options.
G
A
A
G
Yeah,
in
fact,
I
think,
maybe
that's
enough
to
kind
of
drive
any
sort
of
initial
discussion
people
wanted
to
have.
I
think
the
idea
with
this
is
that
we
would
be
moving
zephyr
support,
at
least
outside
of
the
python
directory
and
in
the
tbm
repo,
if
not
maybe
to
its
to
another
repo
with
that
said,
I
don't
want
to
drop
support
for
testing
zephyr
in
the
ci,
and
so
this
is
sort
of
a
this
is,
I
would
say
this
rfc
is
like
I
mean
I
just
posted
it
yesterday.
G
I
think
that
the
the
rpc
protocol
and
api
is
versioned,
so
that
is
one
tool
we
can
use
to
help
us
here,
but
I
think
that
we
do
need
to
think
a
little
bit
through
how
if
we
have
multiple
implementations,
how
and
when
we
would
test
those
implementations-
and
it
may
be
that
as
we
get
closer
to
sort
of
a
more
rapid
release,
cadence
that
answer
changes
as
well.
So,
okay,
that's
kind
of
what
I
wanted
to
say.
G
A
A
What
I've
seen
in
the
past
is
just
there's
a
there's,
a
test
matrix
that
is
run
with
some
some
regularity
where
it
it
it
just.
You
know,
there's
a
there's,
a
separate
job
that
goes
and
and
and
builds
like
you
know,
say
tvm
with
the
with
the
third
party
code
and
and
runs
a
suite
of
tests
on
that
you
know
a
set
of
dedicated
integration
tests
so
that
everybody
knows
like
these
are
the
tests.
We
need
to
pass
to
be
able
to
conform
to
how
the
project
works.
A
K
G
This
is
probably
a
little
bit
confusing,
because
the
existing
rpc
tracker
and
server
mechanism
relies
on
having
a
tbm
runtime
on
the
other
side
of
that
rpc
link,
and
here
we're
just
we're
really
just
trying
to
connect
to
a
script
and
drive
some
basic
function
calls.
So
this
is
a
separate
rpc
from
that
we're
not
expecting
to
kind
of
place
the
tvm
rpc
server
inside
of
each
of
these
projects.
G
A
G
For
coming-
and
I'm
really
sorry
we-
I
talked
for
a
long
time,
so
I
I
meant
to
have
a
little
bit
more
time
for
open
discussion,
and
I
just
like
to
encourage
everyone
to
please
post
up
more
in
the
discuss
forum.
If
you
want
to
to
engage
with
us
a
little
bit
more,
I
I
want
to
do
this
with
community
support
and
buy-in.
So
it's
not
something
I
want
to
like.
You
know
dictate
from
from
our
position
at
all.
So
so
please
do
post
up.
We
don't
have
to
do
this.
A
Those
yeah
and
and
looking
forward
to
more
of
the
meetings.
I
think
that
we're
going
to
try
to
structure
more
of
the
topics
around
rfcs
that
are
coming
up.
You
know
and
try
to
try
to
have
this
kind
of
synchronous,
community,
engagement
and
and
discussion
over
the
rfcs,
and
so
as
rfcs
move
in
we're
going
to
be
driving
the
community
meetings
more
towards
that,
and
I
think
that
there's
also
been
an
interest
in
in
possibly
there's
a
there's,
a
community
calendar
that
lists
all
the
community
meetings
right
now.
A
That's
that's
the
only
thing
that's
on
it,
but
possibly
opening
up
the
community
calendar
to
to
some
of
the
more
more
of
the
sub
project
leaders
so
that
they
can
schedule
some
meetings
for
a
larger
discussion
and
have
those
appear
on
the
public
calendar
so
that
we
can
have
larger
discussions
like
this,
especially
around
subtopics
like
like
micro
tvm.
You
know-
and
you
know,
but
but
also
do
so
in
a
way
that
is
public
and
makes
everyone
feel
engaged.