A hard macro arrives as a black box: structural analysis sees its boundary pins but not the flops inside. Any crossing buried in the macro is invisible to the integrator's checks, which means the integrator is trusting the provider's verification for every one of them.
Question | Why it is asked |
|---|---|
Which clocks and resets does the macro need, and what are their relationships? | Every boundary signal inherits a domain pair from this answer. |
Which boundary signals cross domains inside the macro, and by what protocol? | These crossings never appear in the integrator's structural report; this list is the only record of them. |
What does the macro assume about input timing (minimum pulse widths, setup to its clocks)? | The integrator must drive the pins in a way the internal synchronisers can actually sample. |
What synchroniser latency should the integrator budget on each path? | Handshake and FIFO depths at the boundary depend on it. |
What was the macro verified with (structural analysis, formal, metastability-injected simulation)? | Trust scales with evidence; an unverified macro gets boundary synchronisers on the integrator side instead. |
Where the answers are missing, put the synchronisers on the integrator side, in logic the tools can see, even if the macro claims to handle them. Two synchronisers in series (one claimed inside, one visible outside) cost latency and are honest; one invisible synchroniser costs certainty.
The same rule applies to any boundary where hierarchy hides structure: a third-party block, a mixed-signal macro with a digital wrapper, or a block delivered as a netlist. Visibility decides placement.
Every answer above goes into the crossing inventory as rows owned by the integrator, plus a pointer to the provider's evidence. A row that says “handled inside the macro” without that pointer is an open item, not a closed one.
No. The synchroniser output is on clk_in only if the synchroniser itself runs on clk_in, and the provider's statement covers the macro side, not the board side. A visible synchroniser at the boundary is exactly the safe default.