Stratix 10 UCID IP bug: partition conflict

[roeekalinsky]

If the S10 UCID IP is used and its clock input comes from a sector clock gate, Quartus errors out during the fitter stage with the following message:

Error (19732): Sector clock gate s10clkctrl_ip_i|stratix10_clkctrl_0|clkena_inst drives to auto_fab_0|alt_sld_fab_0|alt_sld_fab_0|mboxfabric|command_0_reset_handler_0|state[2] which is in a different partition. Sector clock gates and their destinations must be in the same partition.

What appears to be happening, big picture, is that Quartus is doing some behind the scenes "magic" to implement the UCID IP, and then trips over itself downstream.

More specifically, during synthesis Quartus automagically creates a bunch of interface logic to bridge the UCID IP's interface to the SDM, and it takes the liberty to create a dedicated partition called "auto_fab_0" for this auto-generated interface logic. Then later, during the fitter process, Quartus rightly complains about the fact that this interface logic is not on the same partition as the sector clock gate that feeds it.

Attached is a trivial design example that demonstrates this problem.

[YuanLi_S_Intel]

Sorry just to clarify, what is UCID IP?

[roeekalinsky]

Hi @YuanLi_S_Intel,

Sorry for the ambiguity.  "UCID" is an older Altera abbreviation for "Unique Chip ID", and "Stratix 10 UCID IP" in my post refers to the Altera-provided IP module used for reading the unique chip ID in a Stratix 10 device.

The proper name of this IP module is "altera_s10_chip_id", and it is available in Quartus. When a Stratix 10 project is open in the Quartus GUI, see IP Catalog > Library > Basic Functions > Configuration and Programming > Chip ID Intel FPGA IP.

You can also see it instantiated in the trivial design example I provided that demonstrates the issue I reported.

Thanks,
-Roee

[YuanLi_S_Intel]

From the error messages, it seems like the clock input cannot be fitted. Can you change another clock source?

[roeekalinsky]

---

@YuanLi_S_Intel wrote:

From the error messages, it seems like the clock input cannot be fitted.

---

The error message doesn't indicate that there is any physical or architectural reason why it can't be fitted.  The problem it's complaining about is the different logical partitions, which Quartus itself created earlier in the flow.

---

@YuanLi_S_Intel wrote:

Can you change another clock source?

---

That's beside the point, but to answer your question:  In my real world design where this issue came up, suffice it to say there are good reasons why I'm using sector clock gating.  Yes, I could potentially work around this issue by changing the clocking scheme, but it would come at a cost of increased resource utilization and power consumption and reduced attainable timing performance. That's undesirable.

I'm not looking to you to suggest design alternatives. I'm looking to you to please directly address the apparent self-inflicted incompatibility in Quartus between the Stratix 10 chip ID IP and sector clock gating.

Thanks,
-Roee

[YuanLi_S_Intel]

Yes, the error is indicating that the clock is in different logical partitions and thus quartus is not able to fit the design. What i am suggesting is selecting different CLK input from the pin planner.

I have tried to duplicate the design by connecting the Clock Control IP's output to S10 Chip ID, no issue on it.

[roeekalinsky]

---

@YuanLi_S_Intel wrote:

Yes, the error is indicating that the clock is in different logical partitions and thus quartus is not able to fit the design. What i am suggesting is selecting different CLK input from the pin planner.

My experimentation didn't show any dependence on pin location. Only the logical partition problem, which seems to be independent of physical location.

---

@YuanLi_S_Intel wrote:

I have tried to duplicate the design by connecting the Clock Control IP's output to S10 Chip ID, no issue on it.

---

Can you please post your design files, so I can see what's different from mine?

Thanks,
-Roee

[roeekalinsky]

Hi @YuanLi_S_Intel,

Can you please post your design files, so I can see what's different from mine?

Thanks,
-Roee

[roeekalinsky]

Hello, @YuanLi_S_Intel ?

[YuanLi_S_Intel]

As stated in private message, we are still investigating with internal team on this. Cheers

[roeekalinsky]

Thank you, @YuanLi_S_Intel.  Just to clarify, for the record, I had posted that last forum message (Nov 11) before hearing back from you by private message (Nov 16).  Anyhow, I'll continue to look forward to hearing the resolution of your investigation with your internal team.

Thanks and happy new year,
-Roee

[YuanLi_S_Intel]

Hi Roee,

Sorry for being late, here is the finding from the discussion:

The error is valid and it relates to a limitation with sector-level clock gates and partitions. With distributed sector-level clock gating setting, you are physically creating a unique clock signal in each sector (although they functionally act the same). If a sector-level clock gate is connected to a partition, this can break partition port semantics since if that partition spans multiple sectors, multiple versions of the clock would need to be routed into the partition although the partition interface defines only a single clock port.

Possible workaround here include:

-Change the sector-gating type to Root Level. In this mode there is physically only one clock gate and so no issue with partition semantics.

-Connect the chip_id clock to inclk instead of outclk. It isn't obvious to me why the chip_id clock would benefit from being gated.

[roeekalinsky]

Hi @YuanLi_S_Intel,

Thanks for the response.

Your explanation of the issue matches my understanding of it as I described in my original post, where the problem emanates not from any physical limitation in the clocking architecture, but rather merely a semantic limitation resulting from having a partition boundary that Quartus creates there of its own volition.

I'm intimately familiar with the clock distribution architecture of the Stratix 10, and there were good reasons why I was using a gated clock, and specifically sector clock gating as opposed to root clock gating (reasons I can't get into here as they pertain to proprietary aspects of my broader design). Nevertheless, seeing that a quick resolution to this issue would not be forthcoming, I've modified my design to use a non-gated version of the clock instead for the chip ID interface. An unfortunate workaround.

Still, for future occurrences of similar scenarios where one would like to use sector clock gating with the chip ID interface, other than "don't do that", will there be any resolution coming from Altera/Intel to elimintate this limitation?

It seems to me that the obvious solution would be simply for Quartus to not create a partition boundary there, a partition boundary that doesn't serve any apparent purpose. If it didn't automatically create that partition boundary, this problem wouldn't exist.

-Roee

[YuanLi_S_Intel]

For now, there is no any resolution for this limitation. Error message will be shown if there is any violation. But anyway, i will feedback this to internal team.