Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/479 Thanks!
Let's have a big hand for.
David Caplan.
Well, thank you very much, I'm
happy to be here. This presentation
was put together in conjunction with
one of my colleagues, Farhan.
I'm actually going to talk this evening
about real world hardware design.
I do security hardware now is
my day job.
But for this talk, I want to focus
on what goes into
making a real world
excited CPU.
And during this talk, I'm going to go
through some of the practices,
tools and various techniques that
are used in this kind of development
and some of the unique challenges
associated with it.
So starting off, I'm
not sure how many of you have worked with
hardware design before, but hardware
design is very different than software.
For starters, it takes
a long time, especially with the next
city CPU to design
a brand new CPU from scratch
can easily take up to four or five
years of constant development,
with teams of hundreds, if not thousands
of people. It's simply
a very complex beast.
There's a lot that goes into it.
It's also very expensive.
I mean, besides just the cost of hundreds
or thousands of people, it's
doing a fabrication
of silicon is very expensive in
the kinds of process technologies that
modern city chips use
a mask set, as it's called, which
is what's used by the fabrication
facility to actually build the chip that
you've created can cost upwards
of three million dollars.
And that's before, of course, you also
pay for all the special test equipment
and everything else that goes into it.
And another big challenge
is, as we'll see as we go through this
talk, it's very difficult to test
everything in the design before
you send it to that fabrication plant,
and then it can become very difficult to
figure out what happened when it went
wrong afterwards.
And we'll talk about some of the
different techniques that are used to
help mitigate that.
686 CPU's are
especially challenging, in
part because of the complexity of
a modern high performance chip can easily
be around 60 million NAND
gates and the RTL
code, as it's called, which is typically
in a language like very log or VDL
can easily reach a million lines
X. Eighty six cores also run
just ridiculously fast.
It's almost hard to fathom
what that say, a three gigahertz
CPU runs at three billion cycles
a second. That's just
is very difficult and
we'll see how that plays in a minute.
Related to that is that these
chips have to work basically the whole
time. I don't think most of you,
you know, lose sleep at night thinking
about your CPU, having
a bug or a malfunction or something in
your program.
But if it did, that could be
catastrophic.
I mean, the CPU, it has to
be functionally correct for basically
everything in your system to work.
What this means from a harbor development
standpoint is that
you got to have basically
no bugs.
Even if you had a really rare bug.
It occurs one time in a billion.
That's three times a second.
That's that's not going to really work.
So CPU's must be perfect
then? Well, you know, obviously not.
I'm sure many of you are familiar with
some of the infamous CPU
bugs that have been the Pentium divide
bug in the 90s.
There is a AMD Taulbee
bug in 2007,
but there is a lot more than that.
In fact, if you open up the
ratha guide for a modern CPU,
you'll see something like this.
And if you're in the back that says
no fixed plans on the right
side there.
That being said,
these issues are very minor.
You don't have to take my word for it.
In fact, I would encourage that.
You don't I would encourage you to go and
download one of these and read what
the type of Iraheta are
that are in these production systems.
In most cases, these
simply don't really matter,
or there are software workarounds
available, but
there are a lot that still make it into
silicon.
So I want to talk a bit about
the hardware design process then and
how the testing of these chips
is done, C.P.U
development starts with the
design and verification, which is where
the teams write the very blog
or video code.
They do a bunch of testing on it in a
simulation environment that can
take anywhere from one
to about four years, depending on how
much is changing in the design.
Once that's completed, it's sent to
a fabrication facility.
It takes usually at least two to
three months to get any
silicon back from a fabrication facility.
After you do you then still
need to test it.
That validation process, as
I'm calling it here, can easily take up
to a year or more.
So that's where you put this all
together. It can be four
or five years to get
something from concept all
the way into mass production.
So I first want to talk about the
verification or the pre silicon
phase of design and
what is verification, verification
is a discipline within
silicon design that ensures
design, matches the specification.
And it's worth pointing out that when
a hardware and CPU's in particular are
developed, you don't just have a
functional specification of the
functional specification may say what
instruction sets the CPU supports
some things like that.
You would also have a performance
specification of power specification
and those all need to be tested in the
same way. If you build a processor
and it's slower than you were expecting
it to be, it's just as worthless
as if it had a bug somewhere.
And the goal of verification is
to find defects, of course, or bugs.
And like with many things, the earlier
you find the bug in the design process,
the cheaper it is to fix.
So how do we find these bugs?
Well, the standard way is to use
simulation test bench.
And as we're shown here is you're going
to have your hardware design.
So this is your very log code.
That's the block and red and
your first going to have some way of
generating stimulus into that design.
And the typical ways
of that happens is either what's called
directed testing or random
testing. So directed testing, as you've
written a sequence of instructions that
are going to go and execute in
random testing, you
either open it up to some or maybe
all of the instructions space and just
throw stuff at it.
The vast majority of testing that's
done is random testing because
it's great at finding all these weird
corner cases and
is much less time
consuming for humans.
In addition to applying stimulus to
the design, it's also applied to some
kind of checker, if you're working at the
next 36 score level, this means that
you'll probably have some kind of, say,
C++ model of the
86 architecture that is
running in parallel alongside with the
design. And you would send the same
instruction to both of them.
And then when the design is finished,
you'd compare your register output or
your memory output, whatever, and look
for any variance.
Checkers can also be
at much lower levels and the design
and this is a very common practice to
have checkers around
specific blocks and in fact,
often probing directly into those blocks.
And so, for instance, you might have
a cash checker that would
run and make sure that you don't insert
duplicate lines in your cash.
And these sort of things are really
useful because verification
time is so limited.
You want to check for
any discrepancies as early as
you can and get the most
out of your testing cycles.
And so it's very common to have checkers
kind of all the way down into the design.
Another important characteristic
of test benches is that
there's typically some way to measure
coverage and coverage is a very
important metric that's used
in at least Harbor Designs
because it helps determine
how far along your testing is.
And if you are actually hitting
all of the code that you expect and all
the branches you expect to execute,
you absolutely do not want to go in
fabricated design that has untested
code in it.
And coverage is a great tool
that's used to help prevent that.
Now, test benches do not
run very fast, and this becomes
a major issue if you want to simulate
the entire we call SLC
Chip. So this might have multiple cause
and Northbridge, Southbridge, this sort
of thing, you're looking at a speed
of about one hertz, meaning that
you're simulating one cycle for
every wall clock.
Second, that you run this thing,
you cannot get a lot done at one
hertz. And this is
with like top of the line tools,
hardware, all this sort of thing.
So the natural thing is to break things
down into smaller,
smaller levels.
If you are testing just an equity score,
that's about an order of magnitude faster
to simulate, which still really slow.
But it helps
if you break it down even further,
you can get a call multiunit
testing. So this is a typical practice
of combining a few related blocks like an
instruction fetch and a Decode unit
together.
Or you can even go down to
a single unit testing like the decoder
or the load storage unit or something
like that. And you're looking at
in the ballpark of one hundred, maybe two
hundred hertz. So two hundred
cycles per second of simulation.
Now, compare that for a minute
to real silicon,
which runs at three billion cycles per
second. And you'll see this is far
off. In fact, in the very first
second that you power on
a CPU, that's the equivalent
of a nine and a half years of
testing at the system level.
So basically,
as soon as you turn the thing on, it's
already gone through more verification
than it ever did.
Now, there is a way that you can kind
of throw more hardware
and money at this problem, something
called emulation, there are two two
of the major design to a company's
cadence and synopsize make
emulation machines.
And these are special hardware.
I think they're kind of FPGA based things
that allow you to load
a design onto them and
run testing at a faster rate.
And I should point out, this Kaiden
system is way bigger than the picture
makes it. Look, it's a serious box.
One of these boxes is going to set you
back probably close to a million dollars,
but they can run at around
one to one and a half megahertz.
So it's still two
or three thousand times slower than the
real silicon, but it's a million times
faster than simulation.
So they're very useful,
but they are costly as well.
Now, one question that I
often get asked are a myth that I
sometimes see as well,
what about formal verification and formal
methods? And if anyone is not
familiar, formal methods is basically
a mathematical proof of the behavior
of certain design.
And formal verification
is great for some things.
It is really
cool. It's great to get a proof
that says 100 percent, this is how it
worked. The problem is
formal tools, first off really crap
themselves. When you give them a big
design, they're basically sat
solvers.
They can't deal with that.
The second thing is they have to have
something to compare against.
And when you're working
with something like a multiplier or a
divider, it's pretty easy to give
it a multiplier and say make sure
these things are the same.
If you're dealing with an entire CPU,
it's a very different story.
It might even have
to reinflate the entire design so
then you can verify it against something.
And that's that's difficult to do.
So the experience
I have seen is that formal verification
is great for a few of these selected
execution units.
It's a very small piece of the overall
puzzle.
So the
the track that we're in, right, is on on
failures and philosophy, so
one thing I want to talk about is what
is verification fail at?
And we'll start by saying
what is good at verification is good
at finding bugs with your basic
functional behavior.
Does this particular mode of operation
work? Do these exceptions
happen when they're supposed to, that
sort of thing?
Anything you can do formal press for
is also is also good.
And it's also useful for
coverage analysis.
Are there all your instructions executed
or they executed in all the different
modes? Do you get all the different
exceptions, that sort of thing?
But verification doesn't find
other types of bugs.
One big category are a system
level bugs.
And as you remember from a few days ago,
the system level model runs so
ridiculously slow that
you simply don't get a lot of test time
on it. And so those are going to be the
bugs that are most likely to slip through
the cracks.
Those are bugs like two different
components and the design having
some sort of protocol, disagreement where
they end up in
an unknown state because they don't talk
the same language.
The most common thing that I've seen
is that multiple,
seemingly random events seem
to be required to hit these bugs.
So, you know, we're talking things like
you're doing a compare exchange
instruction when you get a cash probe,
when an intercept is pending.
And at the same cycle, the thermal sensor
says the process is too hot.
Right. Things like that are just
difficult to hit all those kind of cases
during testing.
You start running at billions of cycles a
second and they have a way of coming up a
lot more often.
Another thing that's difficult
to find are any long run time events.
So whenever you have a large data
structure, it could be a three cache,
something like that.
Those are difficult to
test some of those cases in
verification.
So you need to be aware of that.
And a final thing I'll just mention that
I've seen is what I'll call statistically
unlikely matches.
And imagine,
for instance, that you have a design
that has some sort of special behavior
when you have two different,
say, memory operations and
the lower 20 bits of the address
match. But the upper bits do not match.
Well, if you're generating all of your
addresses randomly in your random
stimulus, the chance of that happening
is really, really, really small.
And you're not going to get a lot of test
time on it and those
bugs are going to slip through.
Now, it's worth noting some of this you
can kind of fix if you knew that the
design was really sensitive to this case,
were 20 bits match and the upper twenty
eight bits don't.
You could specifically
have stimulus for that.
You could constrain your random address
generator to generate cases like
that. Some of these cases, however, you
can't do a whole lot about multiple
random events.
You do the best you can, but something is
always going to slip through.
Great, so the next thing
that I want to talk about here is
what is done after the silicon
comes back and.
As I'm sure you can imagine, you get your
silicon back from the fab and
it's not going to work perfectly and
you have to debug it.
So how do you debug stuff?
While everyone here, I'm sure, has
debugged things before?
It usually looks something like this.
If you're with software, you
know, you probably investigate the
problem. You run GDB, do some print
of something, you figure out what you did
wrong and fix you change the code,
you recompile.
And that's all great
with hardware. It doesn't quite work like
that.
So first thing is, is what
the what happened in the design?
One common way of figuring this
out is to use something called geotag
interface. I'm sure some of you are
familiar. Geotag stands for Joint Test
Action Group. It's a I Tripolis standard
that you'll see on a lot of hardware
and
modern, say, six processors
have geotag pins.
You can see an example of some of those
here. You have your test data in
test data out test clock and so on.
And the Tripoli spec
dictates how you communicate to these
pins.
Now, I should mention that
these pins are physically there.
They're generally not brought out
in motherboard. So you won't find an easy
way to connect to them. But they're still
physically there on the package, if you
look hard enough.
Processors have to implement certain
geotag commands that are part of the
standard things like bypass
ID code, which are typically used for
verifying that, like Sawad, connections
on a board are valid.
But I probably also left the spec open
to add whatever
other proprietary commands a vendor
wants. And so
you can imagine that if you're debugging
a CPU, you might want to have
your kind of debugger commands write,
read and write, register, stay memory,
single step, these sort of things.
And that can be very
useful for figuring out what happened.
Now, of course, the processor doesn't
magically do this.
You have to design this debugger
into the system.
But in in you're
going to need something like that because
you're going to have bugs.
This sort of thing can be very useful.
I mean, it's kind of like your GDB,
whatever, but it
it doesn't work always.
And in particular, one very common
thing to happen with silicon
designs is the thing will just hang
and it'll just be completely frozen and
there's nothing you can do to it.
So how do you debug that?
The answer is something called a scan
dump. And this is
a feature that is kind of like
a Crashdown. Basically, you take
all of the register state, all
the flip flops on the design.
You dump them all out through the geotag
port so you can go and analyze
it. And the way this works
is that when flip flops are
built into the silicon,
they look something like this.
So you may remember your kind of standard
flip flop from from class.
There's now an extra mux in front
of it that selects either between the
normal data that that flop would store
and something called the scan in data.
These are then connected together
in a chain like so
so the output of one goes to the skin and
for the next, when
you want to dump the flop state,
you assert the Scandinavia's signal that
goes to all the flops.
And then as you clock the design every
cycle, all the flop shift
into each other and the final flop and
the chain is then connected to your
pen. And over time,
and of course not a lot of time,
you can read out all of
the register state in the design.
So this is pretty nice.
You can then analyze it offline,
whatever.
You know, it's not perfect.
One big limitation is you only
get the data that's stored and flops
in the design.
You don't get access to any of
the intermediate signals in the design.
Also, it's a single point of
time thing. It's really like a crash
dump.
It's very likely that the information
you're looking for is no longer there.
One problem with running at the
clock rates that CPAs do is
that if you don't get the
hang right, then there's no way
you can manually stop this thing in time.
Sometimes you have to take a whole bunch
of these and see if you can
get lucky. Sometimes you got
to look at all the kind of invalid
state and the things that are clearly
left over from earlier
iterations.
But these are two examples of
practices that are that are often used,
there are many others
which I can't talk about,
so let's assume
that we've used some methods and we've
figured out what happened.
Fixing it is not exactly a piece
of cake either. You know, the simplest
thing would be to go fix a very long code
and redo the entire
design, which takes two months and three
million dollars.
So the good news is that you don't have
to all the time.
The way that modern ships are built is
that there is something called a base
layer and then metal
layers and modern process technology
has up to about nine different layers.
And to overly simplify
this, because I'm not a process engineer,
the way this works is the base layer has
your logic, gates your and gates your
gates, et cetera, and the metal layers
or the wires that connect those gates
together.
So what that means is if
you need to add new gates in the design,
you got to change the bass player, which
is the most expensive thing, and you've
got to wait the full time.
And that sucks.
If you don't need to do that, you can
just change maybe even one
metal layer in that stack that tends
to be significantly cheaper.
It also means
that it's less of a delay through the fab
because you can kind of intercept their
pipeline because chips are built first at
the base and then the metal layers as
they go up.
So inserting a new metal layer into that
might only cause a few weeks
of delay before you get the results back.
One thing that's common for
physical designers to do is that whenever
they're building a block, if they have
any white space in that area,
they will actually put extra gates
that are not connected anything.
They're just there on the off chance that
there's a bug and you need a new gate and
you want to wire it up.
So it's it's
kind of if you're building the silicon
and why not put some useful things in it?
Now, those are the costly solutions,
that's the only way that you can really
fix an issue,
but there are a lot of things you can do
to work around the issue, and
that might not cost as much as three
million dollars.
So, you know, one thing that we do is
like if there's a problem, you you
know, you go to the lab and
you try to look for one of these and see
if it can rewire your chip for you.
We tend to have the more sophisticated
version, which looks like this.
This is a focused ion beam machine.
It's a cool beast.
It can take a chip that's
already been fabricated and
it has an electron microscope in
there. It actually shoots little ions
into it and it can rewire
small parts of the design.
Can't do major things, but you can do
small things.
This is done
on a per chip basis.
The only issue with this is
you have to do it chip
by Chip. And also the chips have a very
strong tendency to die in about one to
two weeks afterwards.
And that's just because the process is
so destructive, destructive to the chip.
So if you need a prototype something,
it's great.
You can do it in a couple of hours.
You get your results, you can try it out.
But this is not
going to be a production solution and
neither is the cat.
So what else can we do?
Well, one very common practice
is that Harvard designers
will put disabled bits into
the hardware. And I've always heard this
called chicken bits because
the designer is chicken and maybe the
thing won't work.
And these are
very useful.
They are typically used for performance
or power enhancements on a design
so that you could disable a certain
feature and the processor still works
just fine. That's maybe a little bit
slower.
And it's worth noting about this, that
when processors are built,
there are some things that give
you a ton of performance.
I mean, branch prediction, everyone's got
branch prediction nowadays.
But the way the
chips get the new
performance that you see generation on
generation is generally by
a sum of very, very, very small parts.
There will be features that get you
point five percent over here, point
to five percent over here.
You know, maybe there's a big feature,
gets you one percent.
These all stack up and then you get your
10, 15 percent improvement, whatever
you're expecting.
If you need to disable one of those
to fix a critical bug, that's not always
the end of the world.
And there have been cases where that's
that's been the workaround that had to go
out.
You can find some of these in a
document that AMD
publishes called the BIOS and Kernel
Developers Guide.
I'm sure there's an intellectual into
this as well.
In fact, I think we've seen screenshots
of it and other presentations
on Eighty-six.
These sort of bits live in what's called
the model specific registers or Mauser's.
This is an example of one
the DataCash configuration register.
And there's a few bits in here that
are defined that can be used to
disable certain aspects of the Java
Prefecture, which is, of course,
performance enhancement.
There's also a bit to disable
speculative table walk's as
well.
These features are useful not
only for production.
If you have a bug with, say, the Java
Prefecture, they're also very useful
in debugging because you can start
disabling things until you get down to
the root cause.
This does require that designers
kind of think about what failures
they're going to have and what things
they're going to want to disable down the
road. And it's one of these things
where you might as well throw
the kitchen sink at it, because I'd much
rather never set a bit than
have a bug that requires
a three million dollar respin.
Another option that is available
on modern CPU's is something called Micra
code patch MICRA code
is like an on chip firm firmware.
It's used on processors
typically for implementing things
like Complex 686 instructions.
So like IRA at
RSM, there's a whole bunch of
other hardware tasks which things like
that interrupt delivery
and a lot of power management features
and micro code basically breaks
up these complex flows into
a sequence of smaller operations that the
hard work and natively understand.
The way that myCar code is built
is that it's in an ancient ROM
that's physically present in the silicon.
But a very common practice is to put a
small s ram next to that wrong
call patch ram and that patch
ram can then be used to replace some
or maybe even all of the micro code
if needed, to either fix bugs
or work around things in some way.
And so this is useful for
modifying instruction behavior.
So, for instance, if you had to add
a serialization after a C flush,
that's something that that myCar code
could do.
If there is some rare corner case
that you discover there's a bug in the
micro code flow, you can
patch it through that.
There's not a lot of public documentation
on myCar code patches.
The best resource that
you could probably find is going to be in
the Linux kernel.
There's a path to where the micro could
patch letters are. There's one for Intel,
there's one for and
one. One thing I'll say about
this is microcar patches are typically
signed by the vendor.
So I'm sorry, but it's not something
that you can necessarily go off
and write. But
these are a very useful tool
that I'm sure you can imagine would be
applicable to things besides just 66
cores as well for patching
things in the field if necessary.
So putting this all together
when dealing with hardware, we've talked
about geotag, debugging and scan
is two ways that you can help identify
the problem when it comes to fixing
things. I use workaround in there as
well, because sometimes
you've got to get stuff out the door and
you do whatever it takes.
And the line between fix and workaround
becomes very blurred.
But you obviously have silicon spin's,
you have myCar code patch, you have
chicken bits, and if
you need a quick fix, you can always
go and get a fit done.
So since we are
a lot of us are security people,
I felt like I should mention something
about security.
All of the debug interfaces that I've
mentioned here might
be considered more than debug interfaces
to some, and that's something
that can't be ignored.
Debug interface security needs
to be something that's part of the design
and is tested.
Some examples of the security that
I've seen in the past have been, for
instance, to disable
some or all of the geotag commands on
production parts.
A typical way this is done is that
there are fuzes that exist on
the silicon.
Basically one time programable memory.
Once a part is configured for
production, the Fuze has blown those
instructions or disable.
Another another
possibility could be to
ensure the debug access to sensitive
information so there could be platform
secrets like keys or
firmware or something like that is
blocked in production.
You can have some
sort of authentication done to
use a debug interface like geotag.
Obviously, you have to test that.
Having to debug the debug authentication
handshake is a real pain,
but that's certainly
a way that you could
add some security to this and sign
CPU marker code updates are the common
practice nowadays.
So there's some takeaways
I want to leave you with, and
I know that CPU design
may not be the project that you are about
to go and start after
midnight tonight.
But I think a lot of the
techniques here are hopefully still
interesting and hopefully can be applied
to other projects as well.
First off, breaking down large designs
into small chunks seems somewhat
obvious, but that's absolutely
critical, especially when you're dealing
with something that runs as slow as
a CPU does and simulation
using tools to get the most out of your
test. Time is certainly important.
Using coverage tools, using formal tools.
Anything that you can get your hands on
is very useful
just for maximizing the
usefulness out of each compute cycle
you're running. But the biggest thing I
would say is to just think about what the
weaknesses in your testing flow are
and have some way
of addressing those.
One thing you see with CPU designers is
over the years as they work on multiple
projects, they know where the bugs are
going to be. Even though they wrote the
code, they know they're still going to be
bugs in there and they build the design
accordingly.
So try to design for failures
by building in as much
into the original design as possible.
So building and debug features
if you need to, and securing those
debug features, anticipating
what the risk areas are going to be.
And, you know, with hardware,
you never really have
this option except with MICRA code of
just telling your users to go and
download a patch.
I mean, if you actually had to fix
a real hardware bug out in the
field, you'd be shipping silicon
to millions and millions of people in the
world. And that's not a
position anyone wants to be in.
So you have to have these other features
built into the parts so that you can
address areas as they come up with
software
that sometimes can still be the case.
I'm not a software person, so, you
know, take that with a grain of salt.
But I'm sure there are some situations
where just doing a software upgrade
and asking users to download something
may not be a practical solution for
their environment.
And in those cases, it's helpful
to have some way to
deploy updates, especially critical
ones, if necessary.
So that is
what I have here.
I do have some additional links
if people are interested in reading
more about this.
The Boston Kernel Developers Guide
is a great resource.
It's might be a thousand
pages or more, but it's a fascinating
read and it goes through
virtually every register that exists
in 86 processors.
And what those bits do, the
CPU revision guides or the
Arada documents, both Intel and
AMD publish them.
You need to make sure to find the one for
your specific CPU version.
But they're very interesting to see
not only what the bugs are,
but you can also look at revision,
revision and see kind of what bugs are so
unimportant they're never getting fixed.
And if you're interested
in CPU verification,
there's a lot of great resources.
There's some YouTube links here,
to be honest. You can just Google it.
You'll find a lot of stuff.
It's it's an interesting field.
There are plenty there's plenty of work
that's done in optimizing
verification and doing
more formal proofs and more
circumstances, doing
something called power.
Aware verification is very important now
when we're dealing with chips, where
parts of it will be powered down at
different times and you can't use those
parts without powering them up.
So there's a lot of interesting
work being done in that space.
I encourage anyone interested to
go take a look at these.
And with that, I'll take some questions.
One, two.
OK, thank you very much, David.
Can I please add that?
No, I'm sorry.
Would you please cue up on one and three
something, some glitch?
I'm sorry.
OK, first question from the room,
gentlemen.
Number three
things of all. First of all, for the
awesome talk and I don't know if you
know anything about this or if this is
outside your domain, but I'm wondering
how does this sort of layout aspect
come into this? So if I'm programing
FPGA, I just blast my my
design in there and it's laid out
automatically and everything just
happens.
But RCP use actually laid on manually
or how does that look on the sort of
analog side?
Yeah.
A bit of a bit of everything, I would say
there's been a it used to be
that everything was laid out manually and
that was because the tools at the time
were simply not good at designs of that
size recently.
And when I say recently, I mean the last
probably five to 10 years, there has
been much more of a push towards
automated layout and automated synthesis.
And frankly, the modern tools are really,
really good.
And what tends to
happen is that you actually
do best if you take, say,
an entire CPU and just throw it
at the tool and say figure out where
stuff goes. Right.
And in some cases, you don't even
say, here's where I want instruction
fach, here's where I want to multiply or
things like that. You just give it that.
And it has a good way of figuring out
just based on the connections where
things need to be in relationship to each
other. So it's I
would say it's mostly automated, but
with some human input as well.
And, you
know, I think that it's
different from FPGA is
because of the way it's built, obviously,
with ASICs.
But the tools
certainly have some similarities to them.
OK, the gentleman number one,
so modern and support
these Fed into consists of
well, it doesn't include the third one
incased Latz Microsleep
of upper management and of course, an
ex 86 Gulf oil
processing.
And the third call include
in modern spaces, the
secure whatever
you test the whole package
or just individual parts.
So, yes.
So typically
the way it works is that each chip
is built as a collection of what's called
IPS, and the
six core is one i.p.
The power management controller is called
the same you as one IP.
The security processor is called the
platform security processor is one
IP and you have a whole bunch of others
in there. You have memory controllers,
you have Southbridge, etc.
So those do most of their
verification on their own.
But there is a system level verification,
that thing that runs at one hertz that's
done with all of those together and
that is more limited
and because of the speed involved.
But there certainly is verification done
on the whole piece.
We'll have to include
people outside, do we have
a question from the Internet?
Yes.
So where would
where would one actually set those
chicken bits and can it be set in the
operating system?
So, yeah.
So the chicken bits live in model
specific registers.
So they're set using the right MSRA
command.
You need to be at ring zero to do that.
But that's it.
OK, gentlemen.
Number three, you I
am very impressed with your talk because
I'm a security guy and definitely not the
hardware guy, but as a security
guy, I see you I see this process
that's struggling
with keeping out unintentional bugs.
So this process, how susceptible is
it to a person
within your organization trying to
introduce a really hard to detect
intentional bug?
How would you detect such a thing
otherwise, right?
You know, I think that's probably an area
I can't talk too much about,
but I'm trying to think if there's
anything I can say about that,
I would say that,
you know, there there are a lot
of different phases to the design
process. There's a lot of eyes that
see things.
Speaking as myself, I think it'd be
very difficult for someone
to get something through kind
of all the different checks and balances
that there are.
But beyond that,
there's not a whole lot I can tell you.
One thing a little bit related to what
you talk about is that there's
also the whole piece of the fab, right.
Let's say that your company produces a
design that is perfect, whatever.
It may not be, the design that the fab
sends you back.
And that's the whole issue called supply
chain security, which is
certainly something on our radar as well.
It's you know, unfortunately, it can be
very difficult to.
Well, let me say this.
When you get silicone back, you tend
to test for the features that you expect
to be there. It's very difficult to test
for features that are there that you're
not expecting.
OK, thank you, the gentleman.
Number one is California.
Yeah, so we all know the pics of failure
classes of our little monetarists.
We all bought are there are pics of
other classes for CPU's.
And I am able to give you a million
dollars to get a better test c.p.u than I
can buy on Amazon.
No, they're not
they're not failure classes
or anything like that.
The the CPU's
are all functionally the same.
The you know, there can be differences
depending on your bio's version as to
what fixes are applied, like what mycar
code version you're loading,
because unfortunately, you
know, kind of like like Tramel
was talking about, even
if there is a bug and we release,
say, myCar code update for something,
we can't force an
OEM to put in their bios, we can't force
you to download it so that there's an
issue there.
The the only thing I'll mention
about kind of we
call beaning, which is where you test
parts and you figure out what when they
go into is that when we do make
parts, there are not different speed
grades or anything like that.
The way that you get a two gigahertz
versus a two point two versus a two point
four, anything else is just simply how it
came out of the some parts just run
faster than others.
Some parts burn more or less power than
others.
So not one.
You know, you have to get lucky if you
want to fast like whether your part
can run faster or not is often just luck.
Sorry, um, we
got something on the Internet in between,
um, otherwise, all right.
Um, so in in the verification
stage, how do you distinguish design
flaws from, uh, fabrication
issues?
So in the verification
stage, in the verification
stage, the design has not gone through
fabrication yet, so you're just testing
the very long code.
There are mechanisms
for testing when it comes back from the
lab, whether the
part was built correctly or not.
Sometimes, you know, that can be as
simple as reproducing
the same bug on multiple different parts
because chances are they weren't all made
incorrectly.
There's a number of other features we
build in that are under a giant category
of design for test features that
functionally validate whether
all the flip flops in the design are
working, things like that.
That can be another talk.
OK, gentlemen.
Number three, I
would like to know how many
of these design cycles is a typical
excited six processor going through
before it's finished.
So it varies
significantly by how many new features,
of course, were added in a particular
generation.
I would say that sometimes it can
be as little as one or two.
Sometimes it can be,
I would say between five and 10.
One way of kind of tracking this is if
you hear about things like A zero
or B zero or B two parts,
the the first letter is
basically the base layer version and then
the number is the metal layer version.
So like a B two part is
the second version of the base layer and
the third version of the middle layer.
Gentlemen, number one, please
forgive me for asking this, but I'm a
security researcher, so
if you dramatically simplified the
process or by removing all the legacy
and other crap in it, how
are you going?
What are you calling the designs crap?
No, no, I didn't say that.
But how would the testing
change?
So.
There are a lot of legacy features in
next 36.
One interesting thing is that
it would not necessarily make things
simpler. And the reason is that
if you take something out, you have to
take it out of all of your existing tests
and out of all of your random test
generators and out of all of your models
that check things in this sort of thing.
And believe it or not, for some things
that can end up being more work than it
is to just put the darn thing in and
test it again, which I know is a little
counterintuitive, but that's the reality
of it. Unfortunately,
it's really hard to take things out
of 86 because there's so much
software out there.
We we finally got
rid of three of three now.
And I think we're getting rid of a 20,
which has been around since like the 286.
So I think.
But, yeah, it's a
tough battle.
Number three, please.
I actually have two questions.
The first one is you mentioned that
there's a piece of RAM that you can
program to modify microworld
programing after the module
has been manufactured.
Why burn the micro code
into the silicon at all when
there's a piece of RAM that is big enough
to hold the entire set of instructions?
So the RAM is not necessarily
always big enough to hold the
instructions.
The I
would say the primary reason for building
and well, there's there's a few.
The first thing is that RAM is much, much
smaller in silicon than than Ranna's.
So if you are not
going to build a ram that's as big
as everything could be, then you are
going to save area by putting the portion
of it. And Ron, there's also just a major
security advantage to doing that.
You don't have to trust your
loading process as much
and you don't have to.
And of course, that loading process, if
you didn't have any ram or need to be
built completely in hardware, which means
you've got to get it right the first
time, which can be difficult.
So those tend to be the reasons that
falls into RAM and legacy.
And the second
question was, at what point in the design
cycle do you decide which
clock rate the
processor gets marketed under
or like runs
in typical operation?
Right. I mean, is typically part of the
initial design specification that
when you're going to create a design,
you want to have a target performance
envelope for that.
And based on the process
technology that tells you, OK, you need
to have this many gaits per cycle
or something like that.
Now, of course, when you actually
fabricate the design, you test it.
It you know, it could be different.
It depends on how good the early data
was, but it's typically part
of kind of the day one specification.
There's a question from the Internet in
between, I think.
Yes, so if the medical
update is a sign, what is the
CPU check the signatures
against?
So, uh.
A typical implantation
might have a public
key burned into a room that
is used to check the signature, but I
really can't go into too much detail on
that.
Number one, please.
So from the talk, it seems the can
walk up to the mic the other way.
We don't have you on tape
from from your talk shows that this
thing is a huge part of this process
with SPUs becoming more and more complex.
How big will the impact be
of testing?
How much will it delay new CPU
features?
It's a major factor, testing
is the biggest issue with
with CPU's, both in terms of
the amount of time it takes, the amount
of people, the amount of cost associated
with it.
I mean, things
things get slower as you add more stuff
into it.
On the other hand, sometimes new tools
and emulation technologies will pop up to
help mitigate some of that.
But, you know,
when people look around, they say, well,
why is it take so long for the CPU
features to get into things?
You know, even when it comes to security
features, this is kind of the reason
it it's a long process.
And every new feature you add
extends the time before you can start
selling the device and you don't make
money until you start doing that.
Thank you. Uh.
All right, OK,
yeah, I know you guys are
like follow up questions, but maybe a
short answer.
Do you see any new testing methods
on the horizon, something more
revolutionary than simulating
or.
I can't say I do right now, but
I'm not as much of a expert in
kind of what's coming up in that field.
But I think it's there could be new
stuff, certainly, that would be helpful.
OK, thank you.
Number three, please.
OK.
I was wondering if we could double the
amount of space needed on
the silicon to implement
the geotech device, the chicken bits,
all the stuff.
Is it a percent or much?
Much less so the
chicken bits tend to be very, very, very
minor because it tends to be kind of
one register and a disable
wire to some gate
geotag stuff.
I, I couldn't
quantify that specifically.
It's not that big,
I would say, compared to the other stuff
in CPU. If you look at a photo
of things, everything is small compared
to the caches.
So you have that.
But you know, a lot of this logic,
a lot of the logic is not considered
optional in some cases
because and I respect requires that in
some cases it's because if you
you can't debug the part, then
what what good is it at the end of the
day?
OK, thank you, gentlemen.
Number one.
On the scale between the
full simulation and one end
and then the hardware emulator in the
middle and the silicon at the end, do you
also use FPGA
where you basically partition the full
system and stick them into
it?
So there
are some cases where that's useful.
The biggest challenge is FPGA capacity.
Most FPGA is or simply not big
enough to handle designs like this.
And also sometimes
the stuff in them
is designed for more of an easy flow
and won't map into the FPGA as well.
Some of the emulator systems are
based on very large upgrades that
are put together and something like that,
where I'd say with with excess CPUs
I looked at at one time, like trying to
see, you know, could you synthesize the
sort of thing into a Xilinx chip?
And the answer was it was so
big.
I mean, compared to even what the bigger
Xilinx chip was, that there's
just no way you could do it easily.
Not a single chip, but basically if
you have four Falkor on Autocar or
whatever and split them and
partition the mobile multiple
that I've seen that work in some smaller
designs, not in anything as big as a
core.
OK, people, if you're leaving
before the talk ends, which is OK,
can you please do it silently
because there are still people asking
questions.
Can you sort of respect, you know, let's
have some gentleman in number three,
please.
Yeah. You told us about those
in C.P.U debugging features.
Are they all left in the final design
or do you decide at some point all
this damn thing is really expensive,
you should remove it and now's the time
to do it?
Well, we saw how expensive it was to
modify hardware,
so maybe that answers your question.
OK, gentlemen.
Number one, any debug
features for the timing so you
can verify that the
Dybbuk, the clock
does not hit your target if
there's something
to validate, if the part runs
at the speed it's supposed to
and it does not one, that's a speed where
you expect it. One.
Which part is the fault then?
You got to figure that out.
I know. So it's not an area that
I work with personally.
I know that one thing that sometimes used
our lasers that you
can if you shine a laser on
a certain part, it can hit
that part up and make it run,
I think of it faster or something like
that. And so you can use that to kind of
help figure out where the slow path is
and the design. Because, I mean, the
simplest thing is it's supposed to run a
three gigahertz. You run at a two,
three gigahertz and it doesn't work.
So you run a two point nine.
It does work.
And you then kind of
have to figure out what circuit is
causing the problem.
That happens sometimes.
Typically, it's not
not a huge deal because the libraries
that you work with during the development
process are very, very good about
figuring out what the timing is of the
different gates and making sure that you
don't have any issues.
OK, three more questions, please keep
them short and simple because we're out
of time.
Number three, please.
Yes.
I wanted to ask you, a security
specialist.
What's your job when you're designing
and UCP you?
Well, so my current job is actually
working on security
features for the Amte roadmap,
both including C.P.U features as well
as the platform security processor.
And in
that capacity, we work with
the different teams that are involved in
in those security features to help them
develop the specifications and make sure
that they're testing all the cases there
that are necessary.
But I don't get to write code anymore.
OK, did we leave out the Internet or is
there no more questions on the Internet,
which is OK?
OK, gentlemen.
Number three, please.
Um, regarding to the fact that
Cluck's read this, uh, specification, day
one fact, how likely is it to
reduce the clock rate, uh,
for a fix in order to
not have to pay the three
three million mass process
again and reduce it for,
for marketing in order to
fix the design that otherwise
would not run on the target clock rate?
So all I'd say is that's a business
decision.
There you go, yeah.
OK, last question number one,
you were talking about pulmonary pulman
verification said one
of the issues is that you need to get a
model to check against the specification.
So how do you do the normal testing?
How do you make sure that you're actually
testing against the specification?
Because the issue is in the early
hours and days where actually there
wasn't a memory model and also
if you by not doing anything useful.
Right. I mean, the functional checking is
typically done with kind of a golden
model where you say you put instruction
in and you have the registers that need
to be there and everything else.
The issue with formal verification is
that if you're going to apply it to a
design size that the tools can work with,
say you're, you know, apply it to
a scheduling unit or to a load storage
unit. Those blocks are have hundreds
of different Io's that talk to other
blocks. You basically need to have a
formal model not of the architecture, but
of those blocks and exactly how they
behave, which can sometimes
just turn into reimplemented, those
blocks.
So it can it can be a lot of work for
that.
OK, thank you and let's have
a final hand for
David Kaplan, please.
Thank you.