ECE 551 Digital System Design Synthesis Lecture 9

  • Slides: 14
Download presentation
ECE 551 - Digital System Design & Synthesis Lecture 9. 0 - Design Partitioning

ECE 551 - Digital System Design & Synthesis Lecture 9. 0 - Design Partitioning for Synthesis Strategies q q q Partition for design reuse Keep related combinational logic together Avoid glue logic, particularly at top level Register block outputs Partition by design goal Partition by compile technique Keep sharable resources together Keep UDRs (User-Defined Resources) with logic they drive Isolate special functions such as pads, clocks, boundary scan at top level Place large SRAMs and DRAMS at top core level Size blocks based on available computational resources 03/30/03 1

References q Most from section 3 of Design Compiler User Guide (DCUG) q Others

References q Most from section 3 of Design Compiler User Guide (DCUG) q Others from project experience 03/30/03 2

Design Reuse q Partition so that existing designs can be used in your design

Design Reuse q Partition so that existing designs can be used in your design q To permit future reuse: § Define and document interface thoroughly § Standardized interface § Parameterize the code 03/30/03 3

Keeping Related Combinational Logic Together q Reasons: § Default DC cannot move logic across

Keeping Related Combinational Logic Together q Reasons: § Default DC cannot move logic across hierarchical boundaries § Logic optimization cannot cross block boundaries q Group related combinational logic & destination register together § Improves logic optimization potential § Enables sequential optimization 03/30/03 4

Avoid Glue Logic q Glue Logic § Small amounts of logic added to correct

Avoid Glue Logic q Glue Logic § Small amounts of logic added to correct interface mismatch or add missing functionality q Eliminating glue logic § Improves logic optimization potential § Reduces compile time § At top level, simplifies floor-planning 03/30/03 5

Register module outputs q If module outputs are not registered: § long, complex inter-module

Register module outputs q If module outputs are not registered: § long, complex inter-module delay paths can exist • Example § Simulation speed is slower due to sensitivity lists that contain more than clock & reset • Example § Drive strengths on inputs to modules differ 03/30/03 6

Register module outputs (continued) q Negatives § Registering outputs may add clock periods to

Register module outputs (continued) q Negatives § Registering outputs may add clock periods to system delays for function execution § Registering outputs may severely restrict module boundary locations 03/30/03 7

Partition by Design Goal q Design Goals § Area minimization § Delay minimization q

Partition by Design Goal q Design Goals § Area minimization § Delay minimization q By partitioning on design goals: § Allows area constraints on logic without timing issues § Allows timing constraints on logic without area issues § Reduces optimization effort 03/30/03 8

Partition by Compile Technique q Compile Techniques § Forcing Structure (factoring) § Forcing Flattening

Partition by Compile Technique q Compile Techniques § Forcing Structure (factoring) § Forcing Flattening (2 -level logic) q Examples: § XOR-heavy error detection and correction Circuits should be structured § Random logic should be flattened § Therefore, should not be together in module 03/30/03 9

Keep Sharable Resources Together q Only resources within the same always can be shared.

Keep Sharable Resources Together q Only resources within the same always can be shared. 03/30/03 10

Isolating Special Functions Includes pads, I/O drivers, clock generation, boundary scan, and asynchronous modules

Isolating Special Functions Includes pads, I/O drivers, clock generation, boundary scan, and asynchronous modules q The external interface should be at the top level and not placed in modules q Special functions that tie to the interface should be at the next hierarchical level down q Asynchronous functions should be separate modules at an appropriate level of the hierarchy q Example: Figure 3 -10 DCUG (See next slide) q 03/30/03 11

03/30/03 12

03/30/03 12

Place large SRAMs, DRAMS & ROMs at top core level q Relates to physical

Place large SRAMs, DRAMS & ROMs at top core level q Relates to physical design interaction with synthesis q Large memory structures need to be placed in the floorplan independently of logic q Floorplanning is needed to do accurate timing analysis and control q Example 03/30/03 13

Size blocks based on computational resources q Large blocks permit optimization flexibility q Large

Size blocks based on computational resources q Large blocks permit optimization flexibility q Large block may overwhelm workstation in terms of memory, swap space or processing throughput q Large blocks my cause excessive compile times q Thus, need to select workable intermediate size for blocks 03/30/03 14