cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Visitor
Visitor
272 Views
Registered: ‎11-25-2019

PR: constraints when clock sources cross RM/SM boundary in both directions?

Hi there, hope someone can help please.

Ultrascale device, Vivado 2019.2

SM with RP. RP has multiple RMs.

Each RM contains common MMCM but different set of Serial GTs (i.e. PR used to select different serial interface). MMCM is controlled differently for each RM via common DRP bus.

The RM receives a clock from the SM which, along with most other boundary IO, is passed through a PR Decoupler IP.  The IO for the serial GTs (REFMGT, *_P/N) connects directly to the RM withouth going through the Decoupler.  The MMCM clock output is used within the RM but also output to the SM.

How do I correctly constrain both SM and RMs to take account of clock sources and IO that is on the other side of the boundary? e.g.

How in the SM constraints do I 'create_(generated_)clock' for the RM's MMCM output such that I can synthesize the SM with reference to it?

Likewise in the RM constraints, for the REFMGT IO Primary clocks in the SM, that the GTs in the RM should take their clock from?

 

As per Project Flow guidance; SM is being synthed standalone with phys/timing XDC;  RMs are being synthed OOC with common phys/timing XDC (i.e. MMCM LOC, clock?) and RM DCPs and RM-specific XDCs (GT LOCs, clocks?) imported for initial SM Implementation and subsequent configuration child runs.

Can the RM-specific XDCs be 'top-level' aware (i.e. reference the SM)?  Is this the first point at which the clocks can actually be defined with valid parameters?

Also, how do I actually apply the RM-specific constraints for each configuration using Project Flow?  Do I have to manually read_xdc -cell before launching each child run (and doesn't that then prevent parallelisation of the child runs)?.

Finally, I'm aware that 'set property HD.CLK_SRC' should be in use for the SM->RM clock. Is it also required for the RM->SM clock?

Many thanks in advance,

Dave

0 Kudos
Reply
0 Replies