Forum Discussion

SKinz's avatar
SKinz
Icon for New Contributor rankNew Contributor
6 years ago

Clock, PLL, driver placement

I have a design that places plls and clock drivers with a little bit interface planning in Quartus 18.0.1. But, Quartus 18.1 fails to find a placement solution on the same design. Using the interface planner doesn't help and often seems to hurt. It appears to me the placement algorithm changed and now the tool places a clock driver then complains that another clock driver must be placed in the same site. It seems that maybe clock routing density might be driving 18.1 to not resolve a placement solution. Any ideas on what is actually happening?

Thanks

Skip

4 Replies

  • SKinz's avatar
    SKinz
    Icon for New Contributor rankNew Contributor
    6 years ago

    BTW, this is an Arria 10 design in the biggest part and I'm using Quartus Pro in both cases.

  • Rahul_S_Intel1's avatar
    Rahul_S_Intel1
    Icon for Frequent Contributor rankFrequent Contributor
    6 years ago

    May I know the below.

    From the above you mean to say the design pass on Quartus 18.0.1 and fails on Quartus 18.1 .

    If the above statement is correct may I get the below details

    Which Quartus verion ( Pro or std)

    Error Message

    Device,

    If possible sample design

  • SKinz's avatar
    SKinz
    Icon for New Contributor rankNew Contributor
    6 years ago

    As I said, I'm using Quartus Pro 18.0.1 and Quartus Pro 18.1. The error message is that the planner fails to place all clock buffers. In this design I have 6 10GE interfaces (Altera IP), two 40GE interfaces (altera again) a PCIe interface, and two custom Infiniband interfaces. One the same side there is a Uniphy QDRII memory interface. The other side of the device is used by two 12-channel Interlaken interfaces. Yes, the design is pretty dense. Now, I would expect if clock density were an issue it would have shown up in Quartus 18.0.1 Pro first. Since a clocking solution was resolved we thought everything was OK. But quartus 18.1 is complaining that it's having issues with SCLK Splines, placing a clock buffer on a regional clock net then trying to place another transmit clock in the same buffer as if it failed to consider both buffers at the same time or forgot about the first one it placed.

    The next time I run it in 18.1.1 I'll grab the report file. Since this design contains custom IP I'll need to see if I can send it to you. Note that if I start stripping out interfaces things are fine so it's the entire design or nothing to get the issue to occur.

    Skip