Skip to content
DenseChip
Learn
PracticeCode labInterview

DenseChip

Navigate

Menu

LearnPracticeCode labInterview

Tools

All toolsSV editorCode repoResume
DenseChip

Practice, courses, and chip-design tools in one focused workspace.

LearnPracticeCode labInterviewToolsLearning paths

© 2026 DenseChip

AboutRoadmapCareersInternshipsFAQContactPrivacyTerms
Skip to lesson

Course contents

  • RTL Foundations36
  • Combinational Design25
  • Sequential Design27
  • FSM & Control27
  • Timing & Clocking39
  • Reset & CDC34
  • Memory & Buses57
  • Advanced RTL28
    • Parameterization and Generate Hub
    • Top-Level Integration Hub
      • Top-down vs bottom-up integration
      • Port list discipline
      • Parameter propagation across hierarchy
    • Synthesis Intent Hub
    • Style and Static Checks Hub
    • Assertions in RTL Hub
    • Formal Verification Basics Hub
    • Reusable SystemVerilog for RTL
  • Senior & Interview76
  • Glossary and Notation
Loading lesson

←Advanced RTL
  1. Topics
  2. RTL Design
  3. Advanced RTL
  4. Top-Level Integration Hub
On this page

    Part 8 of 9Part 8 of 9/AdvancedAdvanced

    Top-Level Integration Hub

    Top-level RTL that stays reviewable: clear hierarchy, disciplined ports, and parameters from one source.

    • 3topics
    • 3lessons

    Topics in this section

    1. 1Top-down vs bottom-up integration1 lesson
    2. 2Port list discipline1 lesson
    3. 3Parameter propagation across hierarchy1 lesson

    A top level connects proven blocks with clear contracts. Hierarchy, port discipline, and parameter flow decide whether that top stays reviewable as block count grows.

    The example benches are finite digital checks. Timing and implementation signoff remain separate obligations.

    The running hierarchy as nested blocks: soc_top owns the dimensions, the fabric passes them by name, and the fifo receives them; top-down work starts at the outer box, bottom-up work at the inner one

    Read the boxes from the outside in. Every boundary is a port list and a parameter list, which the lessons below cover one at a time.

    • Top-down starts at the outer box and fixes its contracts before the leaves exist.

    • Bottom-up starts from a verified inner box and checks its assumptions against the outer ones.

    • Parameters cross every boundary downwards, by name, from one owner at the top.

    Lessons in this topic

    3 lessons, about 12 min

    1. 1Top-down vs bottom-up integrationYou can choose top-down, bottom-up or a blend for a given situation, list a leaf's input assumptions before reuse, and fix a broken one in the integration shell.5 min
    2. 2Port list disciplineYou can write a grouped port list with direction suffixes, connect by name, and say when `.*` is acceptable.3 min
    3. 3Parameter propagation across hierarchyYou can pass one set of dimensions from the top through two levels by name, and check that each descendant received the value that was requested.4 min
    Check yourself A leaf hard-codes WIDTH as 32 while the top assumes 16. What breaks?

    The boundary mismatches: a 16-bit unsigned input connection is zero-extended into the 32-bit leaf; its 32-bit output is truncated on connection to a 16-bit receiver. Signed extension depends on the source expression's signedness. These are deterministic conversions, not automatically floating bits, and can mask a missing override. Pass parameters by name and make width lint diagnostics fatal.

    Likely question: how does a top level stay reviewable as block count grows? Answer with grouped ports, named connections, single-source parameters, and ownership of clocks, resets, and handshake timing at each boundary.

    Revision sheet

    The whole topic on one page, taken from each lesson's Remember box. Read it before an interview, or print it.

    Top-down vs bottom-up integration

    • Top-down fixes the boundary contracts first; bottom-up composes proven leaves and must check their assumptions.

    • A leaf's passing testbench shows what was driven, not what is required: write pulse/level, clock and reset rules beside each port.

    • Fix a broken assumption at the boundary the top owns, not inside the verified leaf.

    Rule of thumb: unowned timing at a boundary becomes an integration bug.

    Port list discipline

    • Group ports by interface; clocks and resets lead. Use _i and _o, and n for active-low: clk_i, rst_ni.

    • Connect by name, and make missing-port lint diagnostics fatal.

    • Use .* only where every name already matches in width and intent.

    Rule of thumb: keep the port list to production signals; probe internally and do not freeze debug ports into the contract.

    Parameter propagation across hierarchy

    • Keep one source of truth for each dimension at the top, and pass it by name down every level.

    • A narrower-to-wider connection is zero-extended and a wider-to-narrower one is truncated; treat width lint as an error.

    • Test with non-default values and compare each descendant's actual parameters.

    Rule of thumb: a copy of a dimension in a leaf agrees on the day it is written and diverges on the next edit.

    Practise it

    • Mini project: a reusable FIFO IP with package, interface, assertions and a formal check

    • Interview: run a mock interview on this topic

    PreviousNext: Top-down vs bottom-up integration

    Up next

    Up nextTop-down vs bottom-up integration

    Sign in to save progress

    Practice this lessonPrevious lessonReport an error

    See also

    • Parameterization and Generate Hub
    • Synthesis Intent Hub
    • Style and Static Checks Hub