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

  • How to Use This Course
  • The NanoSoC Tour
  • Reading Path
  • SoC Glossary10
  • SoC Metrics Reference
  • SoC Cheatsheet
  • What SoC Integration Is12
  • Architecture and Budgets21
  • Memory Maps and Address Decode26
  • Interconnect and Bus Fabrics26
  • Clock and Reset Architecture24
  • Power Architecture21
  • Interrupts, DMA and Peripherals15
  • Memories, Boot and Security21
  • IP Integration and Handoff21
    • IP Collateral and Versioning
    • Wrappers and Adapters
    • Integration Lint and Connectivity Checks
      • Connectivity Tables as the Source of Truth
      • A Python Connectivity Checker
      • Port Widths, Tie-Offs and Unconnected Ports
    • Top-Level SDC and Constraint Merge
    • DFT Integration
    • Debug Infrastructure
    • Safety and Fault Architecture
  • Top-Level Verification and Bring-up21
  • Package, Pads and I/O18
  • Chip Signoff and Tapeout18
  • SoC Interview Prep16
  • Capstone: Integrate NanoSoC14
Loading lesson

←IP Integration and Handoff
  1. Topics
  2. SoC Design
  3. IP Integration and Handoff
  4. Integration Lint and Connectivity Checks

Part 9 of 14Part 9 of 14/IP Integration and HandoffAll levels

Integration Lint and Connectivity Checks

Structural checks at the top: connectivity tables as the source of truth, a Python checker, widths and tie-offs.

  • 3topics
  • 3lessons

Simulation finds bugs one stimulus at a time; lint finds whole classes before the first test runs. This topic is the integrator's daily tool: the connectivity table that states every connection once, the checks that run over the top level without a testbench, and the tie-off and width discipline that keeps silent defaults out of the chip. The other courses do not teach chip-level connectivity checking, so it is covered in full here: tables first, then the checker, then the ports and ties the checker polices.

Lesson

After it you can...

Connectivity Tables as the Source of Truth

Write the connection table and prove every master reaches its slaves.

A Python Connectivity Checker

Run width, driver and tie checks over a top-level netlist description.

Port Widths, Tie-Offs and Unconnected Ports

Audit every tie and every unconnected port, including the reserved interrupts.

Suggested order: top to bottom. The table first, because the checker consumes it; then the checker, which is the lesson to run rather than read; then the port discipline that explains why the checker's tie rules are strict. For CDC-side interface rules see Interface and IP Rules with IP and Macro Boundaries and Documenting Crossings.

Check yourself Why is the connectivity table the source of truth rather than the schematic or the RTL?

Because it is the one artifact written to be checked: every row states driver, load, width and intent in one place, and the checker diffs it against the RTL. A schematic is read by eyes; the table is read by a script on every build.

Expect to describe your personal top-level checklist: what you check before the first simulation. Connectivity, widths, ties, clocks, resets and protection sidebands, each with the tool that checks it.

PreviousNext: Connectivity Tables as the Source of Truth

Up next

Up nextConnectivity Tables as the Source of Truth

Sign in to save progress

Practice this lessonPrevious lessonReport an error

See also

  • IP Collateral and Versioning
  • Wrappers and Adapters
  • Top-Level SDC and Constraint Merge