►
From YouTube: CHIPS Alliance - Analog Working Group - 2021-06-08
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
B
Actually
rob
going
forward,
I've
been
yes.
B
Whenever
I
can,
but
this
is
an
analog
working
group
and
right
that
is
correct,
and
so
what
are
you
looking
for
from
open
road
as
a
soc
integration
back
plane?
Or
I
mean
how
do
you
want
open
road
project
and
team
members
to
participate
in?
Because
this
seems
you
know
very
analog,
focused.
A
That
is
correct.
It
is
an
analog,
focused
work
group.
What
I
have
seen,
at
least
in
my
experience,
but
I
you
know
I'd
like
to
have
like
marijuana
comment
or
if
thomas
from
infineon
can
join
us
too,
but
that
increasingly,
the
crossover
between
analog
and
digital
design
or
methodology
from
digital
is
creeping
into
the
analog
space
right,
and
so
you
know,
I
think
at
least
what
I
was
seeing
in
my
waning
days
at
oracle.
A
If
you
will
was
that
in
particular,
like
the
sram
design,
the
more
that
could
be
done
in
a
digital
fashion
or
digital
type
methodology,
the
sooner
the
design
tasks
could
be
completed
similar
for
certies
for
sure.
So
I
think
you
know
certainly
there's
portions
of
methodology
that
could
be
used
or
incorporated
with
open
road
now,
whether
that
requires
you
know,
participation
of
you
know
of
your
time,
because
I
know
your
time
is
extremely
valuable.
No
just.
B
Wanting
to
know
how
to
help
best
really
that's
the
time
is
not
an
issue.
A
I
appreciate
that
yeah
in
part.
That's
what
I
wanted
to
discuss
today
and-
and
I
guess
we
might
as
well
get
started-
is
five
after
the
hour,
but
you
know
was
to
you
know.
I
know:
we've
had
we've
had
two
different
presentations,
one
from
michigan
and.
A
For
david
from
ut
austin
right
and
what
I
wanted
to
do
was
to
try
to
see
if
we
could
kind
of
outline
a
a
road
map,
straw,
man
or
effectively
a
a
soft
road
map,
and
I
kind
of
broke
that
you
know
so.
A
We've
had
two
great
university
presentations,
but
I
kind
of
wanted
to
see
if
we
could,
you
know,
look
at
where
we
want
to
try
to
go,
and
some
of
this
was
related
to
the
questions
andrew
that
you
raised
last
week,
and
I
also
want
to
start
by
saying
I
apologize
for
the
meeting
today
being
a
bit
off
cadence
relative
to
what
we've
been
trying
to
do.
I
have
a
conflict.
Next
tuesday,
myself.
B
A
A
You
know
what
what
needs
to
be
done
in
that
in
that
arena
and
some
of
that's
design
methodology,
some
of
that's
eda,
tooling
as
well-
and
there
are.
There-
are
challenges
with
both
aspects,
and
so
I'm
interested
in
hearing
about
you
know
kind
of
what
the
methodology
approach
that
they
might
use
for
ams
type
of
design,
whether
that
be
certies,
a
sram,
a
ddr4
controller,
sram
other
types
of
things.
A
What's
done
in
terms
of
functional
verification,
you
know
what
type
of
circuits
are
used,
some
of
the
other
major
challenge
areas,
and
then
what
goes
in
with
that?
You
know,
I
think,
is
what
andrew
you
were
getting
at.
Was
you
know,
providing
some
different
representative
circuits
for
figurative
merit,
type
of
test
cases
right
and
what
type
of
benchmarks
you
know
that
could
be
collaboratively
shared
in
that
space?
So
is
that
kind
of
a
line
along
the
lines
of
the
question
you
were
asking
last
week
in
the
chat
there.
B
B
Question,
I
forget
all
three
of
my
questions,
but
but
that
was
one
and
is
there
any
sort
of
common
back
plane
that
they
would
plug
into
as
part
of
going
beyond
july
or
summer
of
next
year?
And
then.
D
B
B
So
that
was
the
genesis
of
my
questions
and
I
I
think
I'll
shut
up
and
you
should
conduct
your
meeting,
but
you
know
the
backdrop:
is
you
know
how
can
open
road?
I
see
mehdi
on
on
the
call,
so
that's
great
because
he
he's
obviously
in
both
worlds,
but
aside
from
eddie,
is
there
any
particular
type
of
open
road
project
member
that
you'd
like
in
these
meetings
to
what
end?
A
Okay,
that's
fine
yeah!
No!
No.
I
appreciate
that.
I
think
relative
I'll
just
comment.
I
think,
relative
to
participation
of
a
particular
open
road
member.
Perhaps
maybe
it's
just
an
awareness
thing
I
don't
know,
and
that
could
be
based
upon.
You
know
bandwidth
from
the
open
road
teams
side
and
then
also
particular
interest
from
different
participants
and
not
to
not
to
pick
on
anyone,
but
you
know
marijuana.
A
Maybe
you
could
comment
a
bit
what
you'd
like
to
see
from
possibly
from
open
road
or
in
terms
of
some
of
the
questions
relative
to
the
work
group
and
how
it
moves
forward.
E
You
know
first
circuit
to
clean
the
back
flow
that
we're
using
and
we're
thinking
now
in
what
direction,
not
not
just
thinking
but
like,
let's
say,
making
concrete
steps
to
make
it
really
functional.
Let's
put
it
like
that,
so
for
me,
for
me,
it
will
be,
for
instance,
interesting,
like
these
two
presentations
that
we
have
at
like
regarding
magical,
but
also
there
is
like
this
align
everything
kind
of
funded
with
this
idea:
electronic
resurgence
initiative
group
of
projects.
For
me
it
is
interesting
how?
E
Basically,
the
work
that
has
been
done,
you
know
can
be
standardized,
can
be
reused.
So
for
me,
that
is
something
you
know
basically
to
make.
I
wouldn't
say
we
cannot
standardize
everything
but
at
least
to
try
to
develop
in
such
a
way
that
there
is
in
future
some
convergence
point
and
that
you
know
that
the
the
basically
the
the
work
is,
we
could
say
even
shared.
You
know,
because
I'm
we
all
here,
because
we
we
kind
of
favor,
open
source
and
and
would
like
to
go
into
that
direction.
E
So
that
is
this
is
what
I
would
like
to
see.
Maybe
not
the
concrete
answer
but,
as
I
said
more
towards
working
together,
but
also
towards,
like
some
future
plans,
how
we
can,
at
the
end,
really
cover
all
the
bases
so
that
analog
designers
or
layout
analog
designers,
I
wouldn't
say,
be
replaced.
But
at
least
their
work
will
be
ease
up,
especially
in
these
deep
submicrons
multi-pattern
technologies.
C
B
C
If
I
could
just
add,
on
top
of
that,
I
think
you
know,
for
from
my
perspective,
you
know
the
one
of
the
biggest
barriers
to
integration
is
tool
setup,
and
you
know
I
I
heard.
Is
it
marjana?
Is
that
how
you
pronounce
your
name.
E
C
E
E
C
That's
right
got
it
so,
with
the
last
name
wensloff,
I
have
an
appreciation
for
making
sure
I
pronounce
people's
names
right.
So
I
always
ask.
C
Yeah,
I
you
know,
I
think,
just
standardization,
I
think,
is
super
important.
I
think
that's
a
great
point-
and
you
know
from
I
was
just
starting
to
say
from
my
perspective.
C
I
think
what
would
the
biggest
barrier
to
adoption
is
this
tool
set
up
you
know
and
if
there
is
a
standardization
on
how
we
do
that
tool
setup
or
perhaps
how
we
port
to
your
process,
you
know
because
standing
up
the
tools
you
know
in
your
environment
is
gonna
is
gonna,
require
configuring,
your
tools
and
adapting
to
your
process,
and
so
how
do
we
lower
the
barrier
for
doing
that,
because
that
I
think
for
any
analog
design?
That
tends
to
be
at
least
one
of
the
largest
barriers
you
know
before
you
can
start.
C
You
got
to
stand
up
all
these
tools
and
do
all
this
configuration
and
whatnot
and
that's
very
different
than
you
know.
If
I
were
to
just
go
download
somebody's
verilog
for
spi
interface,
you
know
which
you
can
you
can
just
do
open.
You
know,
understand
pretty
quickly
by
reading
the
code
and
then
integrate
that
module
into
other
verilog
and
run
it
through
the
flow.
So
you
know
ver,
in
other
words,
very
low
barrier.
So
I
think
that's
the
that's
the
goal.
C
E
Yeah,
I
completely
agree-
I
mean
for
us
to
test
and
to
try
other
people's
approaches.
That
is
the
biggest
barrier.
We
all
have
limited
amount
of
time,
but
it
is
actually
a
strategic
move
that
we
have
to
make
in
order
to
enable
the
reuse-
and
you
know,
joint
or
at
least
knowledge
transfer
yeah.
I
completely
agree,
I
don't
know
about
others
but
yeah.
I.
A
Think
that
part
of
the
challenge
too
right
so
and
I'm
sure
that
david
and
some
of
the
other
professors
would
agree
that
certainly
trying
to
adopt
any
of
the
university
applications
to
industrial
settings
does
take
time
and
resource,
and
so
in
part
that
comes
back
to
what
I
was
saying
earlier.
I
don't
know
if
everyone
collect
or
heard
the
comments
I
had,
but
you
know
in
terms
of
you
know:
industrial
industry,
players
having
resources
to
help
assign
or
work
with
universities
to
adopt
the
software
to
their
particular
environment.
A
You
know
which
could
include
process
technology,
certainly
if
we
could
come
up
with
a
standardized
mechanism
for
making
that
happen.
That
would
ease
everyone's
life.
So
I
think
that's
a
good
thought,
and
so
I
see
that
we
have
thomas
brander
from
infineon
and
martin
luther
bowden
from
western
digital
here.
So
yes,.
G
I
can
I
can
confirm,
also
emiliano's
and
dave's
statements
that
this
yeah,
you
may
call
it
standardization,
or
at
least
that
that's
the
different
solutions
that
are
by
origin,
academic
and,
of
course,
different
sources
that
they
are
somewhat
yeah,
interoperable
or
so
that
we
also
from
a
from
a
company
point
of
view.
We
don't
expect
that
we
simply
download
it
from
github
and
then
everything
is
running
in
our
environment.
G
This
we
don't
expect
we're
you're,
not
eda
vendors
yeah,
but
but
what
would
be
great
that
we
could
come
to
a
to
a
setup
or
a
standardization
sort
of
where
we
could,
for
instance,
take
one
part
yeah
from
I
don't
know
from
farshock
and
another
part
from
magical
and
so
on,
based
on
our
needs
that
we
can
that
we
can,
but
that
we.
G
Approach
I
mean
you
can
make
call
it
also
standardization
that
you
that
you
can
that
they,
they
are
all
based
on
the
same
sort,
sort
of
framework,
a
very
simple
one,
hopefully,
because
it's
not
academic,
interesting
but
yeah
and,
of
course,
also
linked
to
technology.
That
also
that
when
we
then
switch
from
one
technology
to
the
other,
that
it's
also
then
easy
to
to
to
set
it
up
again
and
again.
G
G
Able
to
to
take
not
the
complete
solution
like
from
magical,
but
for
instance,
if
I
mean
this
is
now
ideal
world
yeah
that
we
say:
okay,
they
did
a
great
job
in
the
in
the
routing
engine.
We
really
would
like
to
introduce
that
one
in
into
our
design
system,
but
for
the
I
don't
know
the
the
more
the
front
end
constrained
entry.
E
G
E
No,
but
you
know,
for
instance,
if
you
have
like
one
module,
it
will
be
good
to
know.
What
exactly
are
you
dealing
as
inputs
and
outputs
and
then
maybe
it
is
easier
to
put
the
wrapper
around
it
to
kind
of
interact
and
communicate
with
the
with
the
piece
that
you're
having
even
that
will
help
and
not.
C
E
Enough
to
say,
for
instance,
if
they,
if
somebody
who
is
developing
that
module,
actually
provides
parts
or
pieces
to
ease
up,
you
know,
at
least
you
know
some
example
to
ease
up
development
of
the
of
the
interface
to
people
who
are
interested.
You
know
to
use
it
with
it
within
their
system
and
and
so.
G
D
I
I
really
I
I
think
thomas
it
sounds
like
you're
much
farther
along
in
adopting
these,
I
mean
we've
been
looking
at,
you
know,
just
even
adopting
digital.
D
You
know,
tools
for
incorporating
digital
things
like
stock
and
we're
just
now
looking
at
these
analog
approaches,
but
you
know
what
we've
found
for
incorporating
these
open
source
tools,
as
though
there
is
a
lot
of
first
off
the
documentation
is
key,
and
second
off
the
idiosyncrasies
of
the
approach
that
the
designer
took
into
account
have
to
be
somehow
laid
out,
and
you
know
what
sort
of
fundamental
assumptions
are
there
yeah.
A
Yeah,
so
I
wanted
to
ask
the
you
know
the
three
of
you
I'll
I'll
call
you
the
industry
representatives.
So
forgive
me
for
that,
but
you
know
it.
A
I
guess
my
question
is
to
the
three
of
you
is.
You
know
in
terms
of
you
know
this
being
a
community
effort.
If
you
will
is
that
something
that
you
think
that
your
companies
would
be
willing
to
help
in
terms
of
working
with
academia
to
try
to
document
some
of
the
the
adaptation
of
the
software
to
an
industrial
setting?
Right,
because
I
know
it's.
C
A
A
You
know
like
when
you
pay,
you
know
how
many
ever
amounts
of
dollars
to
one
of
the
major
eda
players
right.
So
it's
you
know
the
researchers,
that's
what
they're
really
interested
is
working
on
hard
problems,
and
you
know
not
that
adopting
software
into
an
industrial
setting
is
easy
either.
I
I've
done
that
enough
times
myself
right.
So
I
know
I
know
both
challenges,
but
in
terms
of
trying
to
you
know,
establish
a
collaboration
between
the
two
to
help.
You
know
move
these
things
forward.
D
A
D
We
try
to
western
digital
does
have
a
lot
of
interest
in
adopting
open
source
technologies.
Generally
speaking,
for
a
variety
of
reasons,
we,
though,
and
we
have
to
document
this
adaptation
regardless
once
we
adopt
these
things,
we
could
definitely
the
one
challenge
would
be-
is
documenting
it
in
such
a
way
that
it
is
not
it
passes
whatever
screen.
You
have
for
our
internal
processes
right.
D
You
also
have
to
take
the
documentation
and
then
sanitize
it
and
make
it
more
generic
say:
oh
well,
let's
just
assume
you're
in
a
scenario
like
xyz
and
then
you
know
scrub
it
so
that
the
documentation
becomes
more
generic.
I
think
so.
That
would
be
a
small,
incremental
effort,
it's
something
that
would
have
to
be
done,
but
it
would
be
small
compared
to
the
just
the
thing
of
incorporating
it
into
the
general
flow
universally.
G
G
Of
view
it's
true,
and
it's
it's
if
I
think
about
it,
this
is
the
only
way
how
I
can
imagine
that
this
whole
would
work
that
we
also
contribute
to
this
documentation.
Maybe
also,
then
merging
your
point
of
view
how
you
would
document
it
with,
let's
say,
for
instance,
our
point
of
view,
and
then
you
you
converge
to
where
to
this
kind
of
arbitrary
documentation
that
you
then
cover
different
use
cases,
not
only
the
the
view
of
of
one
company.
I
think
this
is
the
only.
G
A
so
I
have
to
admit
that
still
internally,
in
my
let's
say
with
my
manager,
I
still
need
to
convince
some
of
them
that
they
cannot
expect
from
an
open
source
community
simply
that
they
do
it
when
they
could
do
a
good
job
that
you
take,
that
one
and
you
integrate
and
everything
is
running
so
there.
I
have
some
internal
effort
still
to
convince
them
that
we
have
to
do
things
like
that,
yeah,
because
otherwise
it
doesn't
make
sense.
It
will
not
work.
D
I
can
adopt
it
for
my
own
personal
flow
and
my
own
personal
prototypes,
but
then
transitioning
that
to
a
product
flow
is
going
to
be
very
challenging
and
that
so
there'll
be
these
hurdles
where
at
some
sense
for
me,
I'd
be
making
it.
I
mean
this
doesn't
help
anybody,
but
I'm
just
thinking
out
loud
for
me,
I'd
be
making
a
flow
that
would
work
inside
our
environment,
but
then
it
would
still
be
an
r
d
document.
D
I
don't
know
we
could
we
could
we
would
that
the
adopt
adoption,
it's
gonna,
be
a
check
in
the
egg
problem
for
adoption.
Until
it
happens,
smoothly
you're
gonna
get
just
smaller
groups
adopting
it
and
once
it
then
you're
gonna
have
to
then
commit
get
other
groups
to
commit
using
at
the
product
level.
Yeah.
C
I
was
just
going
to
say:
would
it
make
sense
to
bring
in
one
of
the
tool
vendors
as
a
third
party
here
to
intermediate
you
know,
perhaps
you
know
I'll
throw
out
synopsis,
for
example,
if
if
synopsis
would
help
with
the
documentation
for
one,
maybe,
but
just
you
know
the
integration
of
some
of
these
other
tools
with
their
tools.
I'm
not
sure
that
they
would
do
something
like
that.
But
you
know.
F
I
think
that
would
be
a
hell
of
an
uphill
battle
to
get
the
of
all
people
to
synopsis.
C
Well,
not
necessarily,
but
they're
I
mean
cadence
is
part
of
the
idea
program
synopsis,
I
believe,
is
at
least
as
a
subcontractor,
I
think,
to
one
of
the
groups.
So
you
know
these
these
tool.
Vendors
are
part
of
this
open
source
eri.
You
know
initiative,
so
there's
an
opportunity
there.
D
We
actually,
I
think
you
know,
michael,
I
think
we
may
have
had
the
same
conversation
a
digital
group,
but
we're
trying
to
you
know
point
out
that
a
lot
of
the
things
that
we're
making
are
complementary,
not
competitive,
but
I
think
that
attitude
that
that
opinion
or
sense
that
we're
making
as
competitive
to
the
eda
tool
vendors
would
have
to
be
clearly
delineated
like.
How
does
this
benefit
them
right?
You
have
to
make
a
benefit
case.
F
Correct
well,
I
I
think
that
you
know
one
of
the
things
that
could
be
done
in
terms
of
documentation
really.
Is
that
very
often
when
you're
doing
an
open
source
project
you
and
speaking
as
an
industry
representative,
I
hope
it's
not.
F
You
don't
even
know
what
you
need
to
document
from
like
an
open
source
project's
perspective
until
the
potential
users.
Don't
tell
you
about
that,
and
there's
very
little
like
discussion
going
on
in
terms
of
documentation,
specifically
because
we're
all
engineers
and
fuel,
so
so
documentation
is
always
the
the
kind
of
worst
part
of
any
project.
Even
the
best
ones
are
typically
under
documented.
F
So
I
think
that
we
could
potentially
kind
of
think
of
ways
to
facilitate
you
know
documenting
where
we'd
kind
of
clearly
say.
Well,
some
things
are
impossible,
like
we
can't
tell
an
open
source
project
just
go
and
document
everything
in
my
new
detail
according
to
western
digital's
requirements,
and
it
will
allow
us
that's
unrealistic.
Everyone
knows
yeah
right
so
yeah.
F
If
we
set
specific
non-goals,
we
can
kind
of
working
back
from
there
realize
okay,
but
there
are
things
you
can
do
and
perhaps
they
don't
get
you
the
full
way
to
to
the
ideal
situation,
but
they're
a
step
in
the
right
direction
and
for
us
for
our
open
source
projects.
Very
often,
even
the
feedback,
like
hey
guys,
this
specific
part
like
how
do
you
do
x
is
undocumented
right
and,
and
then
it
becomes
from
like
a
general
complaint
about
lack
of
documentation
which,
like
everyone,
always
right,
anyone
calls
you
up.
F
F
C
F
Tells
you
your
project
is
great
and
I
was
trying
to
use
this
and
unfortunately
I
can't
seem
to
find
information
on
that
specific
part.
And
if
you
could
just
like
say
a
few
words
about
that.
That
would
really
help
that's
a
much
more
focused
and
manageable
request
than
just
saying
doomer
documentation,
which
everyone
kind
of
knows
by
now
that
they
should
be
doing
it.
D
Just
a
question
for
michael,
if
you
think
it's
helpful
to
just
have,
even
if
you
don't
have
all
the
documentation
out
there,
just
all
these
different
flows
that
are
imagined
with
to
do's.
I
mean
I've
found
that
you
know
when
using
certain
tools
identifying
that
there's
a
flow,
that's
out
there,
that
the
creators
have
envisioned
and
created,
but
not
documented
and
just
others
to
do.
There
helped
me
point
to
the
person
and
say
like:
could
you
help
me
flesh
this
out?
I
mean
it
doesn't
have
to
be
complete
to
be
useful.
G
Yeah,
but
the
advantage
now
in
let's
say
in
this
in
this
chips
alliance
group
here
could
be
that,
of
course
I
mean
now:
several
companies
could
go
to
now
to
the
to
the
to
the
real
open
source,
coders
yeah
and
say:
okay,
what
was
your
idea
and
then
maybe
a
private
conversation
during
a
private
conversation,
you
get
the
ex
the
explanation
yeah,
but
then
it's
only
for
you
and
maybe
if
we
do
that,
one
in
this
group
here
we
could
then
let's
say,
remember:
okay,
we
are
member
of
the
group
here,
maybe
even
if
I
now
got
first,
maybe
a
private
answer
by
this
guy
here
and
now
inside
this
group.
G
E
I'm
just
listening:
maybe
I'm
totally
off
the
topic.
It
might
happen.
So
you
know
we
are
at
the
moment
we
are
preparing
our
first
generator
to
be
to
give
back
to
bwrc,
because
you
know
we
got
some
generators
initially
in
the
learning
phase
from
them
and
also
to
open
source
generator
was
first
developed
within
style,
but
tape
out.
E
You
know
for
certain,
let's
say
sub
modules,
etc,
and
it
will
be
interesting
to
see
how
you
know
whether
it
will
be
used
or
not.
So
what
I'm
saying
for
me
as
an
early
adopter,
it
is
important
that
I
have
one
bone,
that
I
can
hold
tight
and
maybe
other
things
that
are
kind
of
differential.
You
know
like
because
I
think
for
open
source,
the
the
initial
ramp
up
is
difficult
and
people
quit
there.
E
G
No,
no,
it's
it's
also
linked.
I
mean
you
said,
documentation
helps
for,
for
let's
say
for
initial
usage
for
new
users
and-
and
we
said
martin
and
I
we
said
that
documentation
also
helps
for
experienced
users,
but
then
when
we
have
the
challenge
to
introduce
it
into
our
semiconductor
company,
specific
design
flow.
So
in
both
cases,
documentation.
E
I
have
another
another
thing
to
say
here:
sorry
rob
go
ahead.
I
didn't
meet
anybody
today,
so
you're,
the
first
big
meeting.
That's
all
right
yeah!
So,
regarding
you
know
the
knowledge
exchange.
For
instance,
we
didn't
bag,
we
have
very
small
community
and
we're
using
the
slack
channel
to
kind
of
start
a
bit
technical
questions.
E
So
for
sure
I
I
think
that
that
you
know
beyond
this
first
bone
that
we're
giving
that
is
absolutely
necessary
to
have
some
channel
where
we
exchange
not
I'm
not
seeing
anything
against
animal
work
group,
but
we
we
need
to
kind
of
kind
of
empower
and
provide
a
meeting
place
for
for
people
who
are
interested,
so
maybe
I'm
not
sure,
maybe
stack
exchange
or
something
like
that.
A
D
One
thing
I
will
say
the
slack
channel
sounds
great.
I
was
just
about
to
message,
say
I'd
love
to
get
my
team
on
that
slack
channel.
But,
more
importantly,
there's
also
this
thing
about
persistence.
D
D
You
have
a
paper
trail
of
the
conversation
and
it's
sorted
cleanly
by
issue
or
thread
that
actually
is
really
useful
when
going
back
and
collecting
documentation,
because
the
documentation
user
can
just
do
a
search
for
different
tags
identify
what
people
probably
people
have
had
and
then
add
that
to
list
to
add
onto
their
document
as
they're
building
it
up
so
having
something
persistent.
A
D
A
A
You
know
it's
always
it's
always.
It's
always
good
to
make
assumptions.
It's
particularly
you
know
when
someone's
responsible
for
something
like
myself
at
this
point,
let
me
just
climb
the
call
here,
but
I
think
you
know
relative
to
what
linux
foundation
slash
ships
can
provide.
I
think
what
you
know
you
folks
are
asking.
I
think,
that's
a
reasonable
request
right
relative
to
what
you
know
part
of
what
this
working
group's
goals
are
right,
which
is
to
understand
capability
or
current
research.
A
That's
out
there
and
also
share
challenges
that
different
companies
have
and
then
providing
a
way
to
archive.
If
you
will
or
provide
communication
vehicles
for
participants
to
benefit
from
right.
So
you
know
I
certainly
am
happy
to
look
into
a
research.
You
know
what
you
know
we
can
offer.
As
part
of
this
group
I
mean
michael,
you
know
michael's
on
the
call
here
so
he's
had
quite
a
bit
of
experience
with
chips
aligned
so
far.
I
don't
know
if
he
can
comment
on
that
too,
but
I
understand
what
you're
asking.
D
F
A
question
that
does
pop
up
pretty
pretty
often
it's
not
a
matter
of
preferences
and
resources.
I
think
preferences
is
one
where
we
want
to
use
something
that
people
be
comfortable
using
resources
is
enough.
We
want
something
that
won't
be
able
to
maintain
us
a
relatively
small
group
without
kind
of
ten.
You
know,
iit
support
people
somewhere
that
are
helping
us
and
third.
F
The
third
aspect,
I'd
add
to
that
is
like
preferably
open,
source
or
or
at
least
like
kind
of
friendly
towards
open
source,
so
that
it's
not
some
magical
system
that
can
nobody
knows
how
to
change
and
and
use
and
then
and
we've
been
there
refused.
Five,
for
example,
I
mean
that's
that's
kind
of
probably
the
longest
running
foundation.
Experience
that
I
have.
F
F
F
Are
meant
for
talking,
and
perhaps
you
never
resolve
the
topic
because
you
keep
talking
about
it
and
and
we
could
try
that
right,
like
I
haven't
used
that
feature
much
so
I
won't
lie
that
I'm
an
expert,
but
at
least
it's
on
github
and
we
have
a
github,
but
everyone
has
a
like.
At
least
everyone
that
wants
to
contribute
on
the
technical
side
should
probably
have
a
github
account
if
they
don't
yet
so
discussions
at
least
would
have
this
benefit
where
everyone
has
a
user
most
likely.
F
You
don't
have
to
ask
people
to
create
a
new
account
somewhere,
which
always
fails.
But
another
idea,
of
course,
is
the
mailing
list
like
we
do
have
mailing
lists.
For
for
the
analog
working
group
like
for
every
working
group,
we
have
a
alias
that
we
can
use
and
membership,
and
all
of
this
is
kind
of
governed
through
the
links,
foundation
and
groups
io
and
so
on.
So
that's
like
another
way
to
do
it,
although
I
would
say
probably
a
little
bit
more
old
school
than
github
discussion,
but
either
probably.
D
Well,
I
actually,
I
think,
for
the
things
that
I'm
envisioning
and
these
these
little
documentation
hurdles
where
you're
finding
a
problem.
You
know
someone
identifies
a
specific
case
that
they're
failing
it,
you
open
it.
You
really
do
open
an
issue,
it's
no
longer
part
of
a
discussion.
It
shouldn't
get
lost
in
the
discussion.
It
should
get
forked
out
into
something.
That's
a
standalone
thing.
Someone
has
a
challenge
and
it's
a
thread
all
of
its
own.
That.
F
And
by
the
way
like
when
you
have
those
kind
of
things,
it's
a
little
bit
different
even
like,
if
you
have
a
specific
issue
that
someone's
facing
and
you
could
document
how
to
how
to
resolve
it,
that
problem,
if
it's
a
wide
enough
problem,
if
it's
very
niche,
then
of
course
it
should
probably
just
stay
as
a
issue,
and
if
someone
needs
to
find
just
this
there's
an
issue
that
a
lot
of
people
encounter
right
and
I
think
we're
talking
about
these
kind
of
things-
we're
not
in
the
place
where
everything's
nicely
documented
and
just
the
niche
cases
blow
up
right.
F
It's
more
like
almost
nothing
is
documented,
and
even
if
you
want
to
do
something
simple
like
where
do
you
start?
So
I
basically,
as
you
said
I'll
use
your
words
here.
It's
about
some
kind
of
regime,
some
kind
of
approach
and
and
structure
right.
Sorry,
I
didn't
use
your
words
exactly,
but
you
mentioned
I.
F
Some
kind
of
approach
to
this,
and
I
think
that
what
you
can
do
and
what
I've
found
useful
in
my
team
is
like
we
have
a
question
from
a
customer
regarding
one
of
our
open
source
projects
and
my
people.
F
They
want
to
reply
to
an
email,
and
I
tell
them
write
up
a
documentation
item
and
send
people
a
link
instead
right,
like
don't,
don't
reply,
an
email,
just
kind
of
go
and
fill
this
item
in
the
documentation
because
it
seems
like
we
need
that
and
you'll
you'll
describe
this
for
this
one
person
and
then
that
will
get
lost
somewhere
in
email.
Github
issues
is
better
because
it'll
be
online,
but
it
won't
be
easy
to
define.
F
So
I
would
say
that
if
you
had
this
kind
of
rigor
that
we
mark
specific
issues
as
interesting
and
worthy
of
documenting,
for
example-
and
you
put
a
label
on
it,
you
know
saying
hey.
That
thing
probably
needs
some
documentation
in
the
main
project
documentation.
F
We
could
potentially
process
these
kind
of
items
in
some
way,
tria
help
triage
them
and
kind
of
help.
You
know
I
mean
you
have
things
like:
google,
seasonal,
docs
or
you
have
different
kinds
of
or
internships.
You
know
where
you
could
just
tell
people,
hey
here's
a
bunch
of
things
that
need
documenting,
but
we
already
know
what
right,
because
the
challenge
is
not
just
in
in
doing
the
work,
the
challenges
and
finding
what
work
actually
needs
to
be
done
right.
F
A
A
You
know,
aside
from
the
documentation
issue
or
challenge,
is
you
know
particular
issues
or
problems
that
you
know
a
company
may
have
you
know
when
they're
trying
to
use
university
software
I'd
like
to
hear
from
you
know
from
the
different
professors
who
are
participatory
toward
the
call
here
today
you
know:
what's
the
best
way
for
different
industry
partners
to
communicate
with
you
about,
you
know
different
challenges
they
may
be
having
with
the
tool
and
by
challenges
I
mean,
I
don't
mean
like
simple
usability
issues,
I'm
referring
more
to
you
know.
A
Let's
say
that
a
company's
got
some
type
of
circuit
or
topology
that
they're
trying
to
implement-
and
you
know
you
didn't
you
didn't
think
of
this
or
see
this
in
your
university
work.
You
know
what's
the
best
way
for
that
communication
to
happen,
and
I
realized
that
there's
limitations
on
what
can
be
communicated
from
a
intellectual
property
perspective
for
a
given
company
right.
So,
like
you
know,
one
of
the
topics
I
had
listed
as
possible
interest
for
this
group
to
cover
would
be
different.
A
You
know
methodology
challenges
that
different
companies
are
seeing
in
the
analog
space,
but
I
realized
that
that
may
not
be
fully
disclosable
for
whatever
reason
so,
but
anyway,
I'd
just
like
to
see
what
the
best
way
is
for
go
ahead.
Yeah
dan
from.
H
I
think
what
dave
said
a
few
minutes
ago
is
is
dead
on,
which
is,
I
think,
every
piece
of
software
you're
gonna
hear
about
in
this
forum
is
just
incredibly
difficult
to
transfer
from
one
institution
to
another.
Okay,
you
can
certainly
say
that
for
all
of
the
berkeley
analog
stuff,
I
mean
historically
the
mechanism
for
get
your
company
to
run
the
berkeley
analog
stuff.
H
Is
you
hire
a
summer
intern
and
maybe,
by
the
end
of
the
summer,
it
runs
and
so
having
the
idea
of,
and
I'm
sure
mariana
can
speak
to
their
own
experience
and
how
much
effort
this
has
been,
and
so
the
idea
that
you
know
there
are
a
handful
of
things
in
the
way.
A
lot
of
this
is,
I
think
I
would
turn
this
back
to
folks
from
the
academic
community
on
you
know,
just
how
much
emphasis
do
we
want
to
place
on
the
transferability
of
stuff?
H
I
mean
even
imagining
say,
transferring
these
pieces
of
software
between
each
other.
I
imagine
we
would
find
quite
difficult
the
so
the
the
sort
of
forum
for
communicating
this
stuff
is
related
right.
It
is
in
some
sense
tied
up
in
a
lot
of
the
legal
agreements.
A
lot
of
these
are
built
on
proprietary
tooling,
whether
from
the
major
ega
vendors
and
certainly
a
lot
of
a
lot
of
dependencies
on
the
closed
source
and
heavily
ndaid
process
technologies.
H
So
all
that
is
a
hurdle
that
you
know
we
could.
I
don't
know
if
this
is
a
forum
for
talking
about
how
to
sort
of
cut
through,
but
it's
definitely
one
of
the
problems
as
far
as
we'll
give
them
sure
any
of
the
other
groups
can
speak
to
this,
but
transferring
their
work
to
anyone
else
essentially
requires
replicating
all
of
those
agreements
and
the
sort
of
technical
setup
that
underpins
them.
H
So
until
there's,
I
think
some
realistic
mechanism
for
doing
the
stuff
without,
like
one
of
the
experts
on
the
piece
of
software
working
on
it
for
an
extended
period
of
time,
then
you
know
that
sort
of
debates
on
the
margins
of
how
do
we,
you
know,
get
to
the
nth
layer
circuit,
I
think,
probably
have
to
wait.
B
I
would
say
it's
a
matter
of
will
and
of
being
realistic
and
of
recognizing
innumerable,
but
but
finite
numbers
of
known
blockers
such
as
ip
rights
as
you
mentioned,
or
the
foundry
pdk,
and
who
has
access
to
it,
who
will
exercise
access
in
order
to
bring
up
what
parts
of
the
tool
enablement
for
a
particular
node
and
so
on.
So
I
I
think
these
are
well
understood
and
we
can,
I
guess,
as
a
community,
each
sort
of
marvel
at
the
difficult
the
challenge
or
we
can
write
down.
B
You
know
existence
proofs
or
known
recipes,
or
at
least
the
list
of
known
hurdles
that
need
to
be
overcome
before
even
you
know,
having
conversations
like
this
in
some
sense
right
I
mean
there's
the
money
hurdle
as
well,
and
there's
the
you
know,
reward
or
value
or
value
function
that
that
phd
students
have
or
post-docs
or
faculty,
and
until
all
of
those
are
kind
of
aligned.
B
You
know
I've
seen
20-plus
years
of
these
conversations
basically
die,
and
I
hope
that
this
one
will
live,
but
you
know
the
ip
umbrella
of
something
like
a
linux
foundation.
The
dollars,
a
michigan
student
costs,
a
hundred
thousand
dollars
a
year.
Ucsd
student
costs
a
hundred
thousand
dollars
a
year.
B
These
are
not
small
amounts
of
money
and
that's
just
20
hours
a
week
officially
right
to
because
they
have
a
life
outside
of
their
graduate
research,
assistantship
so
being
real
about.
This
was
something
that
open
road
certainly
had
to
grapple
with,
and
our
solution
basically
was
to
outsource
to
professional
software
engineers,
all
the
all
of
what
makes
openroad
a
semi-nascent
usable
tool
and
and
we're
talking
about
that
gap
right
here
with
bag,
and
you
know
a
line
and
magical
and
fa
sock.
C
Rob
I
I
just
wanted
to
comment
on
your
question
on
communication,
so
we
do
for
our
at
least
for
our
github
repo.
We
have
issue,
we
do
track
issues
so
any
if
any
issues
are
filed
there
we
review
those
weekly
and
then
I
just
turned
on
the
discussions
feature
for
our
fa
stock.
I
didn't
know
about
that.
So
it's
on
now,
so
we'll
experiment
with
that
I'll.
Have
the
students
monitor
we're
we're
from
a
communication
perspective?
C
I
think
you
know
the
way
that
has
the
the
way
that's
been
successful
in
the
past.
Is
it
kind
of
starts
with
an
email
usually
to
me
or
someone
on
the
fa
sock
team,
and
then
it
goes
from
there,
and
you
know
it's
been
a
handful
of
cases
so
far,
but
we've
been
successful
at
integrating
the
tools
into
other
people's
environments.
C
It's
a
hands-on
thing
with
students
and-
and
you
know
we
kind
of
manage
that
it's
manageable.
Now
because
of
the
volume
you
know,
I
I
agree
and
love
hearing
about
all
the
comments
of
you
know
we
should
get
a
more.
We
should
have
a
record
of
all
of
these
communications
so
that
we
can,
you
know
this
can
benefit
other
people
in
the
future.
The
just
the
problem
is
the
proprietary
nature
of
everything
you
know
so.
C
Are
about
you
know,
propriety,
well,
proprietary,
commands
or
functions,
but
from
a
tool
that
we
can't
put
publicly
anywhere
so
so
we've
we
with
the
volume
we've
had
today,
we've
been
managing
that
just
with
the
team
and
we're
we're
I'm
if
anyone
on
this
call
wants
to
reach
out
feel
free.
My
email's
up
on
my
website
contact
me.
You
know
we're
we're
very
eager
to
integrate
these
tools
into
your
flow
so
happy
to
help.
However,
we
can.
B
C
B
And
you
know
there
is
the
question
of
how
do
you
reconcile?
Oh
this?
This
tool
has
really
been
adopted
by
industry,
with
the
fact
that
oh,
it's
used
in
industry
in
production,
so
it
needs
support,
it
needs
bug,
fixes
it
needs
hot
fixes
and,
and
the
students
are
gone
they
don't.
You
know,
no
student
believes
that
they
should
work
for
thirty
thousand
dollars
a
year
in
salary
to
do
what
people
get
paid
five
to
ten
x,
that
in
cadence
to
do
so.
How
do
we,
as
a
working
group
or
community,
reconcile
these
tensions?
B
I
think
that's
kind
of
the
point
of
the
the
paper
I
linked
to
and
I
feel
like
if,
if
there's
no
even
plausible
notion
of
a
solution
to
this
tension,
then
you
know
things
are
going
to
not
look
good.
Let's
say
three
years
from
today
so
yeah,
my
feeling,
you
may
feel
like
the
power
of
open
source
and
community
outweighs
all
of
that,
but.
H
Yeah
yeah
and
that's
the
hope
right.
I
would
really
second
that-
and
I
would
also
note
that
this
actually
kind
of
inverts
the
role
of
open
source
in
a
lot
of
the
rest
of
the
software
community,
like
these
projects,
are
kind
of
harder
to
get
going.
They
require.
You
know
as
andrew
put
it
this
sort
of
unscalable.
H
You
know
you
need
one
of
the
phd
student
authors
to
essentially
stand
it
up,
whereas
you
know
one
of
the
real
boons
of
the
general
open
source
community
and
software
is
just
grab
the
stuff
and
go,
and
we
essentially
have
the
opposite.
You
know
much
much
harder
story
to
provide
industry
partners
and
I
think
it
is
a
sort
of
definitional
question
of
you
know
how
much
of
this
work.
How
much
of
putting
into
you
know.
H
This
is
something
that
people
can
pick
up
without
you
know
dozens
or
hundreds
of
k
worth
of
human
capital
invested
to
use
like
how
much
did
that
work
to
how
much
of
that
legwork
do
we
want
to
build
into
these
academic
projects?
H
And
you
know
it's
great
to
have
that
enthusiasm
to
say
well,
we'll
line
up
the
students,
but
I
think
andrew's
got
a
good
point
in
that.
That's
that
seems
to
have
to
run
dry.
Doesn't
it.
C
Well,
we're
I
can
speak
for
what
we're
doing
for
fa
sock
now,
so
we're
it
doesn't
require
an
intern
we're
actually
we're
working
with
a
government
agency
right
now
to
stand
that
up
remotely
using
their
engineers
just
guiding
them
through
the
process
and
we'll
hopefully
know
more
by
end
of
august.
That's
their
target
to
have
everything,
stood
up
and
and
a
test
chip,
including
fa
stock
tools.
C
But
you
know
it's
a
process.
I
agree
it's
not!
I
I
mean
I
said
at
the
at
the
top
that
this
is
this
model
is
not
scalable,
but
it's
a
starting
point.
You
know
it
starts
getting
adoption
and
then,
if
you
have
people
who
start
contributing
to
the
tool,
ideally
you
know
it
can
start
growing
organically
and
and
have
a
life
of
itself.
I
guess
that's
the
hope,
but
yeah,
but
these
are
the
challenges
right.
These
are
the
challenges
we're
facing
no
good
answer.
F
I
think
that's
you
know.
The
comparison
to
software
these
days
is
a
difficult
one
because,
of
course,
we're
in
a
far
worse
situation,
but
I
think
it's
better
to
compare
you
know
what's
going
on
in
hardware
now
to
the
early
days
of
open
source
software,
where
I
mean,
of
course
the
details
will
be
different.
I'm
not
saying
it's
a
one-to-one
comparison,
but
it's
a
much
more
apples
to
apples.
F
If
you
say
well
we're
in
the
you
know,
kind
of
linus
marvel's
posts
to
the
mailing
list
times
of
software
and
and
then
you
realize
you
probably
also
needed
in
the
storeholds
to
kind
of
boot,
the
first
versions
of
linux,
because
it
didn't
magically
fall
down
from
the
sky.
What
happened
in
open
source
software
was
just
a
matter
of
momentum
and
it
took
years
and
years
for
it
to
change
when
we
started
at
micro
in
2009
on
the
premise
of
let's
use
open
source
issues,
linux
is
in
embedded
and
so
on.
F
You
know
people
are
looking
at
us
as
if
we're
kind
of
dumb
to
to
be
assuming
that
linux
is
the
answer
to
everything
for
for
embedded
systems,
specifically
and
and
of
course,
that
changed
rapidly
because
of
smartphones
because
of
like
server
room
and
all
the
other
things
that
happened,
but
as
late
as
2009,
I
I
don't
mean
for
the
general
purpose.
For
that
you
know,
but
more
like
for
cars,
like
you
know,
automotive
great
linux
is,
is
it's
a
fairly
new
thing
right
or
for
like?
F
F
So,
in
general
this
is
just
a
story
that
falls
and
it
takes
a
long
time
and
I
I
don't
think
it's
an
if
it
is
going
to
happen,
but
it's
a
matter
of
when,
and
hopefully
it
doesn't
take
two
years
and
we
can
learn
some
lessons
from
from
software,
but
we
should
be
learning
from
the
early
lessons
you
know
from
like
what
did
open
source
software
do
to
scale
rather
than
what
does
open
source
software
do
today
now
that
they
have
hundreds
of
thousands
of
developers
already
doing
open
source
software
yeah
we're
not
going
to
be
able
to
replicate
them.
D
Well
and
then
the
early
days
you
know
all
of
that
is
well
taken.
I
mean
the
early
days.
There
were
a
lot
of
people
serving
as
consultants
for
initial
adoption
and
we
still
have
enterprise
support
companies.
Now
so
I
mean
there's
gonna
have
to
be
some
model
that
comes
out
of
this
and
it
is
going
to
grow
slowly.
A
A
So
I
think
it's
a
question
and-
and
I
think
andrew's
points
are
well
taken
relative
to
the
scalability
and
challenges,
and
you
know
people
who
can
delve
into
any
particular
piece
of
code
like
a
detailed
router
or
say
a
statistical
timing,
analyzer
as
two
examples
that
I'm
somewhat
knowledgeable
with
right
that
you
know
they
just
don't
grow
on
trees.
That
doesn't
mean
that
a
community
can't
grow
up
around
that
and
learn.
There's
a
lot
of
smart
and
talented
people
around,
but
it
kind
of
needs
something
to
start
with
and
have
some
degree
of
expertise.
A
And
so
I
think
there
is
potential
business
potential
for
some
companies,
like
ant
micro
as
an
example,
but
there
are
a
few
others
out
there
that
could
help.
You
know
start
this
or
bridge
this
gap,
but
it's
we're
not
completely
there
yet
right,
and
I
think
you
know
participation
from
some
industry
players
like
western
digital
or
infineon
or
silicon
austria
labs,
you
know,
may
be
able
to
help
out
somewhat
and
get
that
going.
But
it's
going
to
take
some
time.
A
A
D
C
G
I
think
intel
is
contributing
a
lot
and
red
hat
is
also
there,
but
not
the
biggest
one.
I
remember
I
read
in
okay.
G
C
E
E
E
My
my
personal
opinion
is
that
some
of
these
problems
can
be
sold
with
a
good
initial
documentation,
as
I
said,
with
the
bone
that
everybody
can
hang
and
and
start
from,
because
you
cannot
expect
students
to
stay
forever.
E
I
mean
there
are
some
students,
especially
from
berkeley,
risk
five,
let's
say
involved
into
that
activity
for
pg
students
for
10
years,
but
we
cannot
expect
that.
But
you
know
we
need
to
provide
continuity
and
and
solid
ground
for
future
work.
Even
if
the
idea
is
finished,
you
know
you,
you
just
give
the
kids
enough
meat
to
to
to
to
make
something
out
of
it.
E
So
I
don't
see
I
don't
see
any
other
solution,
but
networking,
definitely
and
and
working
together,
because
you
know
I
mean
finns,
they
have
very
long
winters
and
I
don't
know
whether
there
will
be
another.
Let's
say
a
person
like
that
to
to
carry
out
the
burden-
I
I
you
know
so
what
I'm
saying
we
need
to
split
and
basically
divide
and
conquer,
but
in
another
sense,
so
that
that
is
my
personal
opinion.
I
don't
know
what
do
you
think
about
it?
Yeah.
H
I
would
really
second
rhianna's
initial
sentiment
there
that
there
is
this
leap
of
faith
required,
and
there
is
the
analogy
to
corporate
contributions
to
linux
requires
this
bootstrapping
phase
in
which
linux
initially
becomes
valuable
to
them,
which
you
know
how
you
get
through.
That
is
more
more
of
the
active
question.
B
F
Right
and
it's
it's
a
combination
that
we
have
leaps
of
faith
on
behalf
of
the
people
that
can
afford
it,
and
hence
we
need
you
know
the
western
digitals
and
the
googles,
and
hopefully
the
infineons
and
and
the
the
you
know,
intel's
of
the
world
by
the
way
we
totally
get
intel
to
participate
here.
They've
expressed
an
interest,
but
we've
been
stupid
enough
not
to
follow
up
so
just
fix
that
during
call.
I.
A
Thought
yeah.
I
thought
david
kellett
said
he
was
going
to
be
here,
but
I
guess
he
couldn't
make
it
good
go
ahead.
Sorry
yeah!
Oh.
E
Sorry,
my
michael
j,
if
I
can
just
add
one
thing
that
could
be
maybe
a
shed
a
bit
of
light
so,
for
instance,
we're
having
this
cooperative
project
with
infineon
they're,
doing
like
back,
let's
say
development
in
their
own
environment
and
definitely
they
cannot
share
that.
On
the
other
hand,
we're
a
research
organization
and
what
we're
doing
at
the
at
the
moment,
we're
planning
back
to
flow
and
we're
gonna.
E
G
G
G
F
A
No,
I
I
think
I
think,
thomas,
I
think
that's
you
know
good
point
that
you
bring
up
relative
to
say,
like
infineon
or
other
companies,
that
they
cannot
necessarily
share
experience
or
work,
whereas
you
know
if
they
go
through,
say
like
silicon,
austria,
lab
or
say
through
ant
micro
or
other
partners
that
then
it
may
be
just
okay.
But
I
can
appreciate
that
anything
that
you
say
yourself
as
part
of
infineon
so
to
speak,
would
be
a
challenge.
A
So
we
are
at
the
hour
here.
Is
there
any
other
things
folks
want
to
cover
today
or
thoughts
on
the
next
meeting
topics?
A
Should
I
look
to
get
to
see
if
I
can
have
the
alliance
folks
come
and
present.
C
G
C
G
E
G
B
A
Or
natural,
not
yet
so
in
the
presentation
outlook
what
I
have
listed
here
is:
I
have
bag,
slash
chip
yard.
Professor
nicholak
did
give
a
presentation
on
chip
yard
at
a
chips
alliance
seminar
back
in
march,
but
you
know
we
certainly
could
ask
for
a
presentation
on
bag
and
or
chip
yard.
I
have
a
line
listed
here
and
then
I
don't
know
if
folks
wanted
to
hear
about
open
road
from
professor
kong
and
his
team,
but
that's
what
I
had
listed
it
for
presentation
outlook
from
researchers.
It.
G
It's
already
helpful
for
us
internally
because
we
start
with
back
I
mean
even
this
decision
was
more
than
one
year
back
and
so
on
at
infinity
internal.
But
now
with
maybe
a
few
of
your
videos
now
I
could
now
already
start
I'd
say
internally,
also
convince
some
managers
or
decision
makers
say:
okay.
First,
we
now
start
with
back,
but
we
should
already
start
mentally
thinking
of
integrating
other
solutions,
stepwise
then
also
into
our
design
system,
and
so
it's
already
helpful.
G
But
europe
any
way
you
ask
for
an
another
conversation
and
there
I
we
could
talk
about
that,
one
in
more
detail
and,
let's
say
further
steps,
let's
say
from
our
membership,
I
suppose,
and
so
on.
Yeah.
You
asked
me
it
for
a
separate
conversation.
We
can
do
that.
Oh.
A
C
So
that's
the
only
part
that's
manual
for
us
is,
is
the
the
standard
cell
or
the
auxiliary
cell
itself,
the
layout
of
the
aux
cell,
and
then
we
slurp
that
into
apr
and
tools
to
do
the
placement
and
routing,
but
we're
we've
now
been
able
to
use
a
line
to
generate
five
different
aux
cells
in
gf12,
so
yeah.
I
I
think
it'd
be
great
to
first
of
all
get
them
in
this
group
as
part
of
the
discussion,
but
also
have
them
present.
A
All
right,
let's
see,
I
know
we're
out
of
time
here-
yeah
the
other.
Just
the
other
thought
here
just
about
is
in
terms
of
trying
to
see.
If
I
can
get
some
foundry
engagement,
you
know
I
did
have
a
conversation
with
tsmc
a
couple
weeks
back.
You
know,
I
know
I
know
cliff
hoe
from
my
work
at
oracle
and
I
met
with
one
of
his
folks
to
talk
about
possible
interests
in
chips
alliance,
so
they're
definitely
interested
in
what
we're
trying
to
do
in
the
open
source
arena.
A
I
think
their
concern
is
just
primarily
that
they
don't
want
to
alienate
any
of
their
their
industrial
partners,
which
you
know
I
I
can
understand
that
argument
so
certainly
stay
in
touch,
and
I
know
michael's
been
having
conversations
with
global
foundries
about
different
possible
collaboration
efforts,
and
so
I'm
going
to
follow
up
with
mark
ireland
from
that
group
too,
to
see
if
I
could
get
them
as
part
of
this.
A
I
know
one
of
the
things
I
talked
with
global
foundries
right
is
about
having
a
way
to
opposificate
some
of
the
pdks,
and
I
know
there's
there's
different
thoughts
about
you
know
wanting
to
have
a
fully
open
pdk
such
as
the
skywater,
130
right
and
there's
a
lot
of
benefit
from
that,
and
I
even
learned
in
the
conversation
yesterday
that
a
person
in
the
open
source
community
actually
fixed
a
deaf
creator,
as
part
of
that
which
I
thought
was
rather
interesting
so
anyway,
but
interesting
from
the
perspective
that
I
wouldn't
think
that
someone
would
necessarily
just
go
do
that,
but
lo
and
behold
they
actually
do
so.
A
I
think
there's
opportunity
there.
You
know
whether
or
not
an
optificated
type
of
pdk
would
be
of
useful
interest
to
the
community.
I
don't
know
effectively
the
way
the
process
works.
My
understanding
is
that
the
creator
create
has
a
mutual
nda
sign-off
process
with
a
fad.
You
know
to
help
protect
ip,
but
you
know
that's
I'll,
just
put
that
out
there.
So
anyway,
we
are
out
of
time.
A
So
I
thank
everyone
for
attending
today
and
also
for
staying
out
a
bit
longer
too,
and
I
will
share
the
link
to
the
the
notes
that
I've
taken
during
the
conversation
today.
So
I
appreciate
everyone's
time
and
thoughts
so
anything
else
before
we
go
right
well,.