Model checking in the cloud
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?
More Related Content
What's hot
What's hot (20)
Similar to Model checking in the cloud
Similar to Model checking in the cloud (20)
More from Olivier Coudert
Recently uploaded
Recently uploaded (20)
Model checking in the cloud
- 1. FMCAD Panel: Model Checking in the Cloud Olivier Coudert SiCAD Inc. October 25th, 2012 TM 1 CLOUD-AIDED SILICON DESIGN
- 2. Topics • Cloud compuDng • Distributed model checking • Challenges TM CLOUD-AIDED SILICON DESIGN
- 3. Cloud CompuDng Promises • On-‐demand compuDng resources • No upfront costs – pay as you go • Scalable – 100’s of cores assembled in a compute grid – TB’s of storage – 1Gbps LAN, 10Gbps HPC • Expand geographic reach TM CLOUD-AIDED SILICON DESIGN
- 4. Performance Scaling Wall %me (sec) 100000 10000 1000 10 100 1000 #cores • Cluster setup Dme : 10-‐15mn • ApplicaDon: physical verificaDon • 10 cores: 13h42mn • 768 cores: 17mn TM 4 CLOUD-AIDED SILICON DESIGN
- 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
- 9. Cloud Models • Private cloud managed by EDA vendor – Aldec (logic simulaDon) – Nimbic (3D simulaDon) – Tabula (FPGA synthesis) – Cadence (reference flow) use EDA vendor configure TM 9 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