CHAPTER 1 Introduction: the challenge of system verification
1.1.1. SoC: A definitio n … for this book at least
1.2. The economics of SoC design
1.2.1. Case study: a typical SoC development project
1.3. Virtual platforms: prototyping without hardware
1.3.1. SDK: a very common prototyping environment
1.3.2. FPGA: prototyping in silicon … but pre-silicon
1.3.3. Emulators: prototyping or verification?
1.3.4. First silicon as a prototype platform
1.4.1. Prototyping for architecture exploration
1.4.2. Prototyping for software development
1.4.3. Prototyping for verification
1.5. User priorities in prototyping
1.6.1. Miniaturization towards smaller technology nodes
1.6.2. Decrease in overall design starts
1.6.3. Increased programmability and software
1.6.4. Intellectual property block reuse
1.6.5. Application specificity and mixed-signal design
1.6.6. Multicore architectures and low power
CHAPTER 2 What can FPGA-based prototyping do for us?
2.1. FPGA-based prototyping for different aims
2.1.1. High performance and accuracy
2.1.3. Hardware-software integration
2.1.4. Modeling an SoC for software development
2.1.5. Example prototype usage for software validation
2.2. Interfacing benefit: test real-world data effects
2.2.1. Example: prototype immersion in real-world data
2.3. Benefits for feasibility lab experiments
2.4. Prototype usage out of the lab
2.4.1. Example: A prototype in the real world
2.5. What can’t FPGA-based prototyping do for us?
2.5.1. An FPGA-based prototype is not a simulator
2.5.2. An FPGA-based prototype is not ESL
2.6. Summary: So why use FPGA-based prototyping?
CHAPTER 3 FPGA technology today: chips and tools
3.1. FPGA device technology today
3.1.1. The Virtex®-6 family: an example of latest FPGAs
3.1.3. FPGA memory: LUT memory and block memory
3.1.5. FPGA clocking resources
3.1.8. Built-in IP (Ethernet, PCI Express®, CPU etc.)
3.1.10. Summary of all FPGA resource types
3.2. FPGA–based Prototyping process overview
3.3. Implementation tools needed during prototyping
3.3.2. Mapping SoC design elements into FPGA
3.3.3. Synthesis and the three “laws” of prototyping
3.4. Design partitioning flows
3.4.1. Pre-synthesis partitioning flow
3.4.2. Post-synthesis partitioning flow
3.4.3. Alternative netlist-based partitioning flow
3.4.4. Partitioning tool example: Certify®
3.5. FPGA back-end (place & route) flow
3.5.1. Controlling the back-end
3.5.2. Additional back-end tools
3.6.1. Design instrumentation for probing and tracing
3.6.2. Real-time signal probing: test points
3.6.3. Real-time signal probing: non-embedded
3.6.4. Non real-time signal tracing
3.6.5. Signal tracing at netlist level
3.6.7. Summarizing debugging tool options
4.1. A getting-started checklist
4.2. Estimating the required resources: FPGAs
4.2.1. How mature does the SoC design need to be?
4.2.2. How much of the design should be included?
4.2.3. Design blocks that map outside of the FPGA
4.2.5. How big is the whole SoC design in FPGA terms?
4.2.6. FPGA resource estimation
4.2.7. How fast will the prototype run?
4.3. How many FPGAs can be used in one prototype?
4.4. Estimating required resources
4.5. How long will it take to process the design?
4.5.1. Really, how long will it take to process the design?
4.5.2. A note on partitioning runtime
4.6. How much work will it be?
4.6.1. Initial implementation effort
4.6.2. Subsequent implementation effort
4.6.3. A note on engineering resources
CHAPTER 5 Which platform? (1) build-your-own
5.1. What is the best shape for the platform?
5.3.1. Matching clock delays on and off board
5.3.2. Phase-locked loops (PLL)
5.3.3. System clock generation
5.4. Clock control and configuration
5.6. Power supply and distribution
5.6.1. Board-level power distribution
5.6.2. Power distribution physical design considerations
5.7. System reliability management
5.7.1. Power supply monitoring
5.7.2. Temperature monitoring and management
5.10. Global start-up and reset
5.12. Adopting a standard in-house platform
CHAPTER 6 Which platform? (2) ready-made
6.1. What do you need the board to do?
6.2. Choosing the board(s) to meet your goals
6.4. Flexibility: interconnect
6.5. What is the ideal interconnect topology?
6.6. Speed: the effect of interconnect delay
6.6.1. How important is interconnect flight time?
6.7. Speed: quality of design and layout
6.8. On-board support for signal multiplexing
6.9.1. Supply of FPGAs governs delivery of boards
CHAPTER 7 Getting the design ready for the prototype
7.1. Why “get the design ready to prototype?”
7.1.1. RTL modifications for prototyping
7.2. Adapting the design’s top level
7.2.2. Handling top-level chip support elements
7.3.1. Problems of clock gating in FPGA
7.3.2. Converting gated clocks
7.4. Automatic gated-clock conversion
7.4.1. Handling non-convertible gating logic
7.5. Selecting a subset of the design for prototyping
7.5.1. SoC block removal and its effect
7.5.2. SoC element tie-off with stubs
7.5.3. Minimizing and localizing RTL changes
7.5.4. SoC element replacement with equivalent RTL
7.5.5. SoC element replacement by inference
7.5.6. SoC element replacement by instantiation
7.5.7. Controlling inference using directives
7.7. Handling instantiated SoC RAM in FPGA
7.7.1. Note: RAMs in Virtex®-6 FPGAs
7.7.3. Advanced self-checking wrappers
7.8. Implementing more complex RAMs
7.8.1. Example: implementing multiport RAMs
7.8.2. Example: bit-enabled RAMs
7.8.3. NOTE: using BlockRAM as ROMs
7.9. Design implementation: synthesis
7.9.1. Note: using existing constraints for the SoC design
7.10. Prototyping power-saving features
7.11. Design implementation: place & route
7.12. Revision control during prototyping
CHAPTER 8 Partitioning and reconnecting
8.1. Do we always need to partition across FPGAs?
8.1.1. Do we always need EDA partitioning tools?
8.2. General partitioning overview
8.2.1. Recommended approach to partitioning
8.2.2. Describing board resources to the partitioner
8.2.3. Estimate area of each sub-block
8.2.4. Assign SoC top-level IO
8.2.5. Assign highly connected blocks
8.2.7. Assign remaining blocks
8.2.8. Replicate blocks to save IO
8.2.9. Multiplex excessive FPGA interconnect
8.2.11. Iterate partitioning to improve speed and fit
8.4. Improving prototype performance
8.4.1. Time budgeting at sequential boundaries
8.4.2. Time budgeting at combinatorial boundaries
8.5. Design synchronization across multiple FPGAs
8.5.1. Multi-FPGA clock synchronization
8.5.2. Multi-FPGA reset synchronization
8.5.3. Multi FPGA start-up synchronization
8.6.1. What do we need for inter-FPGA multiplexing?
8.7.1. Schemes based on multiplexer
8.7.2. Note: qualification criteria for multiplexing nets
8.7.3. Schemes based on shift-registers
8.7.4. Worked example of multiplexing
8.7.5. Scheme based on LVDS and IOSERDES
8.7.6. Which multiplexing scheme is best for our design?
8.8. Timing constraints for multiplexing schemes
8.9. Partitioning and reconnection: summary
CHAPTER 9 Design-for-Prototyping
9.1. What is Design-for-Prototyping?
9.1.1. What’s good for FPGA is usually good for SoC
9.2.1. Integrate RTL team and prototypers
9.2.2. Define list of deliverables for prototyping team
9.2.3. Prototypers work with software team
9.3. Integrate the prototype with the verification plan
9.3.2. Documentation well and use revision control
9.3.3. Adopt company-wide standard for hardware
9.3.4. Include Design-for-Prototyping in RTL standards
9.4.1. Follow modular design principles
9.4.2. Pre-empt RTL changes with ‘define and macros
9.4.4. Avoid long combinatorial paths
9.4.5. Avoid combinatorial loops
9.4.6. Provide facility to override FFs with constants
9.5. Guidelines for isolating target specificity
9.5.2. Make source changes as low-impact as possible
9.5.3. Maintain memory compatibility
9.5.4. Isolation of RAM and other macros
9.5.5. Use only IP that has an FPGA version or test chip
9.6. Clocking and architectural guidelines
9.6.1. Keep clock logic in its own top-level block
9.6.2. Simplify clock networks for FPGA
9.6.5. Synchronize block boundaries
9.6.6. Think how the design might run if clocked slowly
9.6.7. Enable bottom-up design flows
CHAPTER 10 IP and high-speed interfaces
10.2.2. What if the RTL is not available?
10.2.3. IP as encrypted source code
10.2.4. Encrypted FPGA netlists
10.2.5. Encrypted FPGA bitstreams
10.2.7. Extra FPGA pins needed to link to test chips
10.3.1. Replacing instantiated soft IP
10.3.2. Replacing inferred soft IP
10.3.3. Replacing synthetic soft IP
10.3.4. Other FPGA replacements for SoC soft IP
10.4.1. Use mode 1: prototype the IP itself
10.4.2. Use mode 2: prototype the IP as part of an SoC
10.4.3. Use mode 3: prototype IP for software validation
10.5. Use of external hard IP during prototyping
10.6. Replacing IP or omitted structures with FPGA IP
10.6.1. External peripheral IP example: PCIe and SATA
10.6.2. Note: speed issues, min-speed
CHAPTER 11 Bring up and debug: the prototype in the lab
11.1. Bring-up and debug–two separate steps?
11.2. Starting point: a fault-free board
11.3.1. Filter test design for multiple FPGAs
11.3.2. Building a library of bring-up test designs
11.4.1. Reuse the SoC verification environment
11.4.2. Common FPGA implementation issues
11.4.4. Improper inter-FPGA connectivity
11.4.5. Improper connectivity to the outside world
11.4.6. Incorrect FPGA IO pad configuration
11.5. Introducing the design onto the board
11.5.1. Note: incorrect startup state for multiple FPGAs
11.6. Debugging on-board issues
11.6.3. Logic debug visibility
11.6.4. Bus-based design access and instrumentation
11.6.5. Benefits of a bus-based access system
11.6.6. Custom debug using an embedded CPU
11.7. Note: use different techniques during debug
11.8. Other general tips for debug
11.9. Quick turn-around after fixing bugs
11.9.1. Incremental synthesis flow
11.9.2. Automation and parallel synthesis
11.9.3. Incremental place & route flow
11.9.4. Combined incremental synthesis and P&R flow
11.10. A bring-up and debug checklist
CHAPTER 12 Breaking out of the lab: the prototype in the field
12.1. The uses and benefits of a portable prototype
12.2. Planning for portability
12.2.1. Main board physical stiffness
12.2.2. Daughter board mounting
CHAPTER 13 Prototyping + Verification = The Best of Both Worlds
13.3. Hybrid verification scenarios
13.4.1. Interfaces for co-simulat ion
13.4.2. Interfaces for transaction-based verification
13.4.5. SCE-MI 2.0 implementation example
13.4.7. Physical interfaces for co-verification
13.5. Comparing verification interface technologies
13.6. Use models – more detail
13.6.1. Virtual platform re-using existing RTL
13.7. Virtual platform for software
13.7.1. Virtual platform as a testbench
13.7.2. Virtual and physical IO (system IO)
13.9.1. USB OTG System overview
13.9.2. Integration use models
13.9.4. Innovator and CHIPit or HAPS
CHAPTER 14 The future of prototyping
14.3. Prototyping future: mobile wireless and consumer
14.4. Prototyping future: networking
14.5. Prototyping future: automotive
14.6. Summary: software-driven hardware development
14.7. Future semiconductor trends
14.8. The FPGA’s future as a prototyping platform
15.1. The FPMM approach to FPGA-based prototyping
15.2. SoCs are larger than FPGAs
15.3. SoCs are faster than FPGAs
15.4. SoCs designs are FPGA-hostile
15.5. Design-for-Prototyping beats the three laws
APPENDIX A: Worked Example: Texas Instruments
A1. Design background: packet processing sub-system
A2. Why does Texas Instruments do prototyping?
A3. Testing the design using an FPGA-based prototype
APPENDIX B: Economics of making prototype boards
B1. Prototyping hardware: should we make or buy?
B2. Cost: what is the total cost of a prototyping board?
B4. Direct cost: equipment and expertise
B5. Direct cost: material and components
B6. Direct cost: yield and wastage
B7. Direct cost: support and documentation
B10. Business cost: opportunity