A Sum of Part(ition)s

InTime

A Sum of Part(ition)s

Altera FPGA users need no introduction to Partition Merge, a step in the Altera Quartus-II ("Quartus") design compilation process that combines multiple netlists (post-synthesis or post-fit) into a single, complete netlist. Quartus triggers this step automatically whenever it detects any design partitions in a project.

Will Quartus always run Partition Merge? If not, why?
Quartus tries to detect partitions in your design and only runs Partition Merge if there is at least one partition.

For example, if you import a Quartus Exported Partition File (.qxp file) into your project and designate it as a partition, Quartus will run Partition Merge during the compilation process.
However, if you simply import the same .qxp netlist as a source file but neglect to designate it as a partition, Quartus will NOT run Partition Merge automatically.

Okay, so what?
Working with a customer, we found that timing results improved significantly (see Table 1 below) when Partition Merge was run versus when it was not run.

Arria 10 design Without Partition Merge
(.qxp as source file)
With Partition Merge
(same .qxp as a partition)
Total Negative Slack (TNS)
-1533.727 ns
-387.006 ns
Worst Slack (Setup / Hold)
-0.807 ns
-0.516 ns

Table 1: Timing results with and without Partition Merge

Intuitively, the above results seem logical because Partition Merge performs optimizations such as resource sharing, thus affecting timing performance. The "gotcha" here is that one might think that importing a netlist automatically triggers Partition Merge, but no -- you would have to explicitly declare it as a partition before things work as expected.

How we found this 'bug' was actually rather interesting -- InTime exported a result for a customer and the customer proceeded to reproduce the same result in Quartus, but obtained a much worse result (exactly what you see in Table 1 above). After banging our heads against the wall for a couple of days, we finally found the cause of the differences and documented it here in case someone else runs into a similar predicament.

At the end of the day, what matters is that you should be getting the best timing performance that your FPGA tool can produce, with minimal fuss.

Leave a Reply