cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Scholar
Scholar
2,161 Views
Registered: ‎06-23-2014

Unsupported PLLE2_ADV connectivity vs Out-of-Context Synthesis

I'm using Vivado 2017.1

 

I have a project that was building just fine (synthesizing, implementing, and generating bitstream).  I just tried changing ALL of my IP uses Synthesis Options from Global to Out of context per IP.  This included two PLL's.

 

Well, while things worked fine before, now I get error "[DRC REQP-1712] Input clock driver: Unsupported PLLE2_ADV connectivity.  The signal MyProject/CL_CLK_PLL/inst/clk_in1 on the MyProject/CL_CLK_PLL/inst/plle2_adv_inst/CLKIN1 pin of MyProject/CL_CLK_PLL/inst with COMPENSATION mode of ZHOLD must be driven by a clock capable IO."

 

The relevant source is:

    wire CL_CLK_PLL_IN;
    BUFG cl_clk_pll_buf_in (.I(clk),.O(CL_CLK_PLL_IN)) ;

    CL_CLK_PLL CL_CLK_PLL(
        .clk_in1(CL_CLK_PLL_IN),  
        .clk_out1(CL_CLK), 
        .clk_out2(CL_CLKx3p5), 
        .clk_out3(CL_CLKx0p5), 
        .clk_out4(CL_CLK60),
        .clk_out5(CL_CLK60x3p5), 
        .clk_out6(CL_CLK60x0p5),
        .reset(rst0),
        .locked(cl_clk_lckd)
     );

where "clk" is the clock coming into this module MyProject.

 

0 Kudos
4 Replies
Highlighted
Moderator
Moderator
2,120 Views
Registered: ‎01-16-2013

@helmutforren,

 

Changing synthesis from OOC to Global shouldn't result in error. Can you please share the archive project to debug the issue? 

I have sent you private message containing ftp link. 

 

--Syed

---------------------------------------------------------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.

Did you check our new quick reference timing closure guide (UG1292)?
---------------------------------------------------------------------------------------------
0 Kudos
Scholar
Scholar
2,106 Views
Registered: ‎06-23-2014

Thanks.  Please see my private response.

 

Do please note that the change was from Global to OCC.  Does that direction make a difference in your response?

 

-Helmut

0 Kudos
Highlighted
2,023 Views
Registered: ‎03-27-2014

@syedz,

 

I agree, but he did the opposite

 

@helmutforren,

 

I have had issues when experimenting with the "OOC" work flow when it came to placement and constraints:

  • I found it very complicated to have local constraints (tied to the "IP core") properly defined (you may have to inquire about how to order you constraint files and have them declared 'OOC'))
  • some global constraints (tied to the entire project) were not applied properly (IO placement for instance)

So I pretty much dropped out the idea of using the OOC work flow. My understanding is "OOC" will only buy you compilation time (especially in large projects) because you only synthesize the part of the design you are working on. Does not mean my projects aren't large at all.. some of them are very large (2/3H compilation time).. but for me, OOC will not buy me enough (~30mins of implementation time maybe?) to struggle for days trying to set it up properly

 

Note: I tried this up until 2016.4 which is the latest version I have used so far, this may have changed with v2017

gw.
Embedded Systems, DSP, cyber
0 Kudos
Highlighted
Scholar
Scholar
1,999 Views
Registered: ‎06-23-2014

@guillaumebres , yep!  This is the position I've fallen into:  Don't do the "OCC" work flow.

 

However, I am thinking about making all my many instantiated IP's (mostly FIFOs) as OCC, while keeping all of my own modules in context (global).  I did not have any problem with that first phase of trying to convert to OCC.  It reduced an example build time from 34 minutes to 23 minutes.  What do you think?

0 Kudos