Get Started

Empowering your ASIC design process
through optimal generation and verification
of timing constraints. Accelerating your ASIC design process
with automated timing constraint
generation and verification. Streamlining your ASIC design
workflow through intelligent timing
constraint generation and verification.

ASICSERVE

RTL To Sign-Off – Preparing RTL to be SDC friendly.

  • When designing RTL for ASIC implementation, the quality and maintainability of your timing constraints are strongly influenced by how you structure your RTL code.
  • "SDC-friendly" RTL makes it easier to write accurate, complete, and verifiable timing constraints while reducing the risk of constraint errors that could lead to silicon failures.
  • The relationship between RTL and SDC is bidirectional. While SDC describes timing requirements for the design, the RTL structure determines how complex those constraints need to be. Poor RTL choices can make constraints fragile, difficult to verify, and prone to errors during design changes. Well-structured RTL, on the other hand, makes constraints more intuitive, easier to maintain, and simpler to formally verify.
  • Mode signals that control operational states should be cleanly separated from data paths. These signals are typically targets for set_case_analysis commands, so, making them explicit and well-named simplifies constraint generation.
  • Clock generation and distribution should follow regular patterns. Generated clocks should use simple, identifiable divider or multiplexer structures. Avoid creating clocks through complex combinatorial logic that makes it difficult to trace clock relationships. When you need frequency division, use explicit counter-based dividers rather than combinatorial logic, as these are much easier to constrain with create_generated_clock commands.
  • Mode Systematic naming conventions make constraint targets easier to specify and maintain. When constraints reference specific signals or paths, those references should remain stable across design revisions. Use hierarchy intentionally - group related logic into modules in ways that align with timing domains and constraint boundaries. This allows you to write constraints at appropriate hierarchical levels rather than needing to specify every individual path.
  • Consider how your RTL will be verified against SDC. If you're using formal verification tools, structure your design to make mode-dependent behaviour explicit. Clearly separate logic that operates under different timing requirements. Make it obvious which signals should be static during particular operating modes, as these will need set_case_analysis or set_static_net declarations
  • A clock multiplexer should use a glitch-free mux structure that's easily recognizable, with clear select signals that can be constrained with set_case_analysis. Multi-cycle paths should arise from obvious architectural choices - like processing stages that take multiple clock cycles by design – rather than from accidental timing relationships that are hard to document. False paths should be structurally obvious, such as paths through logic that’s gated off in certain modes.
  • RTL designed with SDC in mind leads to constraints that are easier to write, more maintainable, and far more likely to be correct. When your constraints are clear and verifiable, you dramatically reduce the risk of timing closure issues late in the design cycle or, worse, timing failures in silicon. The modest additional thought required during RTL design pays dividends throughout the entire implementation flow.

RTL To Sign-Off – Designing RTL for multi-mode SDC.

  • Modern ASICs rarely operate in a single configuration. Power modes, functional modes, test modes, and configuration options create designs that must meet different timing requirements under different operational conditions. Designing RTL to support clean, verifiable multi-mode timing constraints requires forethought about how mode signals propagate, how they affect timing paths, and how they can be formally verified.
  • Multi-mode designs present a fundamental constraint complexity: the same hardware must be described by different timing requirements depending on operational state. A path might be single-cycle in high-performance mode but multi-cycle in low-power mode. Clock frequencies might change between modes. Entire functional blocks might be clock-gated or logically disabled in certain configurations. Your RTL structure directly determines whether these mode-dependent timing requirements can be expressed clearly in SDC and, critically, whether they can be verified to be correct.
  • The foundation of multi-mode SDC starts with how you define and distribute mode control signals. These signals will become targets for set_case_analysis commands that tell timing tools to analyse specific operational scenarios. Mode signals should be registered at a high hierarchical level, ideally at the top of your design or within a dedicated configuration control module. They should have clear, descriptive names that make their purpose obvious: low_power_mode, test_mode, performance_config rather than cryptic abbreviations.
  • Avoid deriving mode states through complex combinatorial logic scattered throughout your design. When mode determination logic is buried deep in the hierarchy or spread across multiple modules, it becomes nearly impossible to identify which signals need case analysis. Instead, decode all mode states explicitly and early, then distribute the resulting mode indicators as simple registered signals. This makes it trivial to identify exactly which signals control mode-dependent behaviour.
  • When different modes require different timing characteristics, structure your RTL so that mode-dependent paths are clearly separated from mode-independent logic. If a datapath takes two cycles in mode A but three cycles in mode B, don't hide this inside a module with complex control logic. Instead, make the mode dependency explicit at the architectural level where it can be easily identified and constrained.
  • Consider a design where operation speed depends on a configuration mode. Rather than sprinkling mode checks throughout pipeline stages, centralize the mode-dependent behaviour. Create distinct paths or use explicit pipeline control that clearly shows where timing differs between modes. This allows you to write mode-specific multi-cycle path constraints that accurately describe each scenario without complicated path filtering.
  • As you design multi-mode RTL, simultaneously develop your multi-mode verification plan. Document which modes require formal verification, what set_case_analysis settings define each mode, and what timing characteristics distinguish each mode. This plan should be part of your design specification, not an afterthought. By thinking through verification requirements during RTL development, you'll naturally structure your design to be verifiable.
  • Be wary of mode proliferation. If you have five independent binary mode signals, that's potentially 32 different modes to verify. This quickly becomes impractical. Consider whether all mode combinations are truly legal and necessary. Can some mode dimensions be made mutually exclusive? Can some modes be composed from a smaller set of base modes? Thoughtful mode architecture reduces verification complexity without sacrificing functionality.
  • When formal verification reveals mismatches between SDC and RTL behaviour in specific modes , treat these as opportunities to improve your multi-mode RTL methodology. Why was the discrepancy mode-dependent? What about the RTL structure made it hard to identify the correct timing requirements? What changes would make similar issues more obvious in future designs?
  • Multi-mode RTL design is about creating structures that make mode-dependent behaviour explicit, verifiable, and constrainable. The goal is not just RTL that functions correctly, but RTL that can be formally proven to meet timing requirements in every operational configuration. This requires thinking about constraints and verification from the very beginning of the design process, not as activities that happen after RTL is complete.

RTL To Sign-Off Automatically Promoting/Demoting IP’s SDC.

  • In hierarchical ASIC design, reusable IP blocks come with their own timing constraints that describe internal timing requirements and interface specifications. These block-level constraints must be integrated into the top-level design, but they cannot simply be copied verbatim. The hierarchical paths, clock names, and port references that make sense at the block level need translation to match the integration context. Automating this "promotion" from block to top level, and conversely "demotion" from top to block level, is essential for maintaining constraint accuracy and efficiency in large designs.
  • When an IP block is instantiated in a larger design, every constraint reference must be updated to reflect the new hierarchical context. A block-level constraint referencing get_ports data_in must become get_pins u_my_ip/data_in at the top level. A clock defined as create_clock -name clk [get_ports clk_in] at the block level might need to become a generated clock or reference an existing top-level clock. Port-to-port timing constraints at the block level become pin-to-pin constraints through the instance. This translation is systematic but tedious and error-prone when done manually.
  • Promoting IP SDC means transforming block-level constraints into equivalent top-level constraints that apply to the instantiated block within the larger design. This involves hierarchical path prefixing, converting port references to pin references, translating clock definitions, and potentially merging block clocks with existing top-level clocks. The promoted constraints must preserve the timing intent of the original block constraints while fitting correctly into the top-level constraint framework.
  • Promotion also involves deciding which constraints should actually be promoted. Some block-level constraints, particularly internal implementation constraints like set_max_fanout or set_max_transition, might not need promotion if the top-level design has its own methodology for these attributes. Other constraints, particularly interface timing and generated clocks, are essential to promote to maintain correct timing across the hierarchy.
  • Demotion is the reverse process: taking top-level constraints that affect a specific block and translating them into block-level constraints for standalone block analysis or verification. This is valuable when you want to verify a block independently, perform block-level timing analysis, or use the block in a different integration context. Demotion requires identifying which top-level constraints apply to a particular instance, extracting the relevant portions, and translating hierarchical references back to block-level port and internal signal names.
  • Manual promotion and demotion don't scale. For designs with dozens of IP blocks or designs where IP gets reused in multiple contexts, automation becomes mandatory. Several approaches exist, each with different complexity and capability trade-offs. Mature design flows often develop sophisticated infrastructure around constraint promotion and demotion. This might include databases of block-to-top clock mappings, libraries of promotion rules for different block types, automated constraint validation suites, and integration with the overall build system so that constraint promotion happens automatically during top-level assembly.
  • The investment in this infrastructure pays dividends as designs scale and IP reuse increases. What starts as simple scripting for a few blocks evolves into a comprehensive constraint management system that ensures consistency, catches integration errors early, and makes hierarchical design practical for large teams.
  • When automated promotion produces incorrect constraints, investigate why was the block SDC ambiguous about hierarchical context? Were clock naming conventions inconsistent? Were interface timing specifications incomplete? Each promotion failure reveals opportunities to improve both the automation and the underlying constraint methodology. Over time, your promotion tools should become more robust and your block-level SDC should be written with promotion in mind.
  • Automatically promoting and demoting IP constraints is not just about convenience - it's about maintaining constraint accuracy and consistency across hierarchical design flows. Manual translation introduces errors; automation, when properly implemented and validated, ensures that block-level timing intent is correctly preserved in integrated designs.