EEGN-494 HDL Design Principles for VLSI/FPGAs

1. EEGN-494HDL Design Principles for VLSI/FPGAs Khurram Kazi Kazi Fall 2006 EEGN 494

2. Fundamental Steps to a Good design • If you have a good start, the project will go smoothly • Partitioning the Design is a good start • Partition by: • Functionality • Don’t mix two different clock domains in a single block • Don’t make the blocks too large • Optimize for Synthesis Kazi Fall 2006 EEGN 494

3. Partitioning Kazi Fall 2006 EEGN 494

4. Recommended rules for Synthesis • When implementing combinatorial paths do not have hierarchy • Register all outputs • Do not implement glue logic between block, partition them well • Separate designs on functional boundary • Keep block sizes to a reasonable size • Separate core logic, pads, clock and JTAG Kazi Fall 2006 EEGN 494

5. Avoid hierarchical combinatorial blocks The path between reg1 and reg2 is divided between three different block Due to hierarchical boundaries, optimization of the combinatorial logic cannot be achieved Synthesis tools (Synopsys) maintain the integrity of the I/O ports, combinatorial optimization cannot be achieved between blocks (unless “grouping” is used). Kazi Fall 2006 EEGN 494

6. Recommend way to handle Combinatorial Paths All the combinatorial circuitry is grouped in the same block that has its output connected the destination flip flop It allows the optimal minimization of the combinatorial logic during synthesis Allows simplified description of the timing interface Kazi Fall 2006 EEGN 494

7. Register all outputs Simplifies the synthesis design environment: Inputs to the individual block arrive within the same relative delay (caused by wire delays) Don’t really need to specify output requirements since paths starts at flip flop outputs. Take care of fanouts, rule of thumb, keep the fanout to 16 (dependent on technology and components that are being driven by the output) Kazi Fall 2006 EEGN 494

8. NO GLUE LOGIC between blocks Due to time pressures, and a bug found that can be simply be fixed by adding some simple glue logic. RESIST THE TEMPTATION!!! At this level in the hierarchy, this implementation will not allow the glue logic to be absorbed within any lower level block. Kazi Fall 2006 EEGN 494

9. Separate design with different goals reg1 may be driven by time critical function, hence will have different optimization constraints reg3 may be driven by slow logic, hence no need to constrain it for speed Kazi Fall 2006 EEGN 494

10. Optimization based on design requirements • Use different entities to partition design blocks • Allows different constraints during synthesis to optimize for area or speed or both. Kazi Fall 2006 EEGN 494

11. Separate FSM with random logic • Separation of the FSM and the random logic allows you to use FSM optimized synthesis Kazi Fall 2006 EEGN 494

12. Maintain a reasonable block size • Partition your design such that each block is between 1000-10000 gates (this is strictly tools and technology dependent) • Larger the blocks, longer the run time -> quick iterations cannot be done. Kazi Fall 2006 EEGN 494

13. Partitioning of Full ASIC • Top-level block includes I/O pads and the Mid block instantiation • Mid includes Clock generator, JTAG, CORE logic • CORE LOGIC includes all the functionality and internal scan circuitry Kazi Fall 2006 EEGN 494

14. Synthesis Constraints • Specifying an Area goal • Area constraints are vendor/library dependent (e.g. 2 input-nand gate, square mils, grid etc) • Design compiler has the Max Area constraint as one of the constraint attributes. Kazi Fall 2006 EEGN 494

15. Timing constraints for synchronous designs • Define timing paths within the design, i.e. paths leading into the design, internal paths and design leading out of the design • Define the clock • Define the I/O timing relative to the clock Kazi Fall 2006 EEGN 494

16. Define a clock for synthesis • Clock source • Period • Duty cycle • Defining the clock constraints the internal timing paths Kazi Fall 2006 EEGN 494

17. Timing goals for synchronous design • Define timing constraints for all paths within a design • Define the clocks • Define the I/O timing relative to the clock Kazi Fall 2006 EEGN 494

18. Constraining input path • Input delay is specified relative to the clock • External logic uses some time within the clock period and i.e. • TclkToQ(clock to Q delay) + Tw (net delay) ->{At input to B} • Example command for this in synopsys design compiler: • Dc_shell> set_input_delay –clock clk 5 (where 5 represents the input delay) (This command is Synopsys centric) Kazi Fall 2006 EEGN 494

19. Constraining output path • Output delay is specified relative to the clock • How much of the clock period does the external logic (shown by cloud b) use up? • Tb + Tsetup; The amount to be specified as the output delay Kazi Fall 2006 EEGN 494

20. Timing paths Kazi Fall 2006 EEGN 494

21. Combinatorial logic may have multiple paths • Static Timing Analysis uses the longest path to calculate a maximum delay or the shortest path to calculate a minimum delay. Kazi Fall 2006 EEGN 494

22. Schematic converted into a timing graph Kazi Fall 2006 EEGN 494

23. Calculating a path’s delay Kazi Fall 2006 EEGN 494