Model checking in the cloud --
Cloud computing where computing is provided as a utility is finally a reality. This new paradigm is shaping the way hardware and software is designed. One of the main attractions of the cloud is its elasticity. This empowers users with the ability to dynamically change their hardware requirements by paying for resource usage by the hour. Compute-intensive applications such as model checking can potentially benefit from such an infrastructure. In this panel, we will address the following questions:
- How can model checking leverage the advantages of distributed and multi-core systems in the cloud?
o Is this new paradigm suitable for model checking?
o What are possible solutions beyond an “embarrassingly parallel” approach of running a single property per core?
o Is there a specific subset of properties that might be more suitable to this form of analysis?
- What is needed from the research and engineering community to achieve adoption within the next 5 years?
- Would a drive to model checking in the cloud increase the industry’s adoption of formal technology?
- What issues need to be addressed for design houses to adopt this technology and will the current license model of EDA tools change to adapt to the new requirements?
5. Distributed
Model
Checking
• Parallelism
has
many
flavors
• In
pracDce:
MIMD
– Network
of
machines
– Distributed
memory
with
mulDple
cores
• Model
checking
– LTL,
CTL,
etc
– State
exploraDon
TM
CLOUD-AIDED SILICON DESIGN
6. Explicit
State
ExploraDon
• Explore
state
one
by
one
– DFS
or
BFS
state
exploraDon
– Need
to
recognize
visited
states
– Mostly
memory
limited
• ParallelizaDon
– ParDDon
state
space,
and
assign
each
parDDon
to
a
node
of
the
grid
– ParDDon:
hashing,
windowing
TM
CLOUD-AIDED SILICON DESIGN
7. Implicit
State
exploraDon
• BDD-‐based
– BFS
state
exploraDon
– Mostly
memory
limited
• ParallelizaDon
– ParDDon
variables,
and
assign
each
parDDon
to
a
node
of
the
grid
– ParDDon
made
of
consecuDve
variables
– BDD
node
management
is
breadth-‐first
– Distributed
hash-‐tables
for
BDD
operaDons
caches
TM
CLOUD-AIDED SILICON DESIGN
8. Bounded
Model
Checking
• SAT-‐based
– Unroll
model
k
Dmes
– Mostly
Dme
limited
• ParallelizaDon
– ParDDon
Boolean
space
(assume
some
variables
have
some
constants
values)
– Conflict
clauses
need
to
be
shared
TM
CLOUD-AIDED SILICON DESIGN
10. Cloud
Models
• Public
cloud
configured
by
EDA
vendor
– Synopsys
(logic
simulaDon
in
AWS)
EDA
vendor
configure
TM
10
CLOUD-AIDED SILICON DESIGN
11. Cloud
Models
• Cloud
pla`orm
configured
and
managed
by
a
3rd
party
– Xuropa
(SW
evaluaDon
in
AWS,
used
by
Synopsys,
Cadence,
and
Xilinx)
– Plunify
(FPGA
synthesis
in
AWS)
– SiCAD
EDA
vendor
Pla`orm
EDA
vendor
EDA
vendor
EDA
vendor
TM
11
CLOUD-AIDED SILICON DESIGN
12. Challenges
• Legal
– SLA
– Liability
in
case
of
data
loss
or
breach
– Geographical
locaDon
of
data
– Cloud
provider
origin
• MulD-‐party
agreement
– MulDple
EDA
vendors,
design
house,
foundry,
cloud
provider
• Business
model
– SW
needs
a
pay-‐as-‐you-‐go
model
– Risk
to
cannibalize
TBL’s
revenue
for
EDA
vendors
TM
12
CLOUD-AIDED SILICON DESIGN
13. Challenges
• Technical
– Scalability
of
applicaDon
– Fast,
fault-‐tolerant,
compute
grid
provisioning
and
setup
– Volume
of
data
transfer
• 10GB
@
30Mbps:
44mn
• 10GB
@
1Gbps:
1mn20sec
• Security
– Highly
sensiDve
data
(design,
SW,
and
IP)
• Data
confidenDality
–transmission,
at
rest
• Data
integrity
–e.g.,
disaster
recovery
• Data
availability
–upDme,
latency
• Data
disposal
–data
removal
and
storage
disposal
– Customer
may
want
to
keep
its
SW
usage
confidenDal
TM
13
CLOUD-AIDED SILICON DESIGN
14. Rethink
for
distributed
in
the
cloud
1Gpbs
LAN
Hard
drive
SSD
RAM
0.5ms
latency
datacenter
3-‐10ms
0.1ms
100
ns
roundtrip
bandwidth
128
MB/s
140
MB/s
100-‐600
MB/s
6-‐17
GB/s
capacity
N/A
up
to
8TB
256GB
-‐
1TB
4-‐64GB
cost
free
$0.05/GB
$0.65/GB
$5-‐10/GB
• Writes
are
expensive,
reads
are
cheap
– Once
read,
data
is
cached
– Writes
are
~50x
slower
than
read
• It
might
be
faster
to
move
data
chunks
in
the
LAN
than
reading
it
from
a
hard
drive
• SSD
is
changing
the
way
data
can
be
managed
TM
CLOUD-AIDED SILICON DESIGN
15. Conclusion
• Cloud
compuDng
– Large,
cheap,
readily
available
compute
grid
• Model
checking
– Need
algorithms
that
can
leverage
a
large
distributed
compuDng
network
(100-‐1000+
cores)
– Licensing
needs
to
follow
burst
compuDng
models
– Security
is
a
bojleneck
TM
CLOUD-AIDED SILICON DESIGN