Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

Force stall-free shift register synthesis as hyperregisters

LennartVH
New Contributor I
406 Views

Hi there,

I'm looking to conserve ALM resources by making sure that a hyperpipe is synthesized as hyperregisters. These pipelines takes up a significant amount of resources. (About 20% of my ALMs are used for these hyperpipes. ) The thing is that these pipes are about 3-8 stages, switching to MLAB memory for these pipes gives only very small improvements and significantly reduce my FMax.

Is it possible to synthesize directly to hyperregisters? And is it possible to do this via an assignment (altera_attribute)? I feel like hyperregisters would be a (almost) free source of such delay elements.

Kind regards,
Lennart

0 Kudos
1 Solution
sstrell
Honored Contributor III
386 Views

I am presuming you are targeting Stratix 10 or Agilex because those are the only device families with hyper-registers currently.

The short answer is no.  Assuming you have the hyper-retimer enabled, the hyper-registers would get used automatically as needed to meet your timing requirements.  If that is not the case, something in your design is preventing the hyper-retimer from retiming registers into hyper-register locations, such as the use of asynchronous resets, the preserve synthesis attribute, SDC timing exceptions, etc.  Run a Fast Forward compilation analysis to see what's going on and make adjustments to allow the hyper-retimer to do its thing.

View solution in original post

0 Kudos
1 Reply
sstrell
Honored Contributor III
387 Views

I am presuming you are targeting Stratix 10 or Agilex because those are the only device families with hyper-registers currently.

The short answer is no.  Assuming you have the hyper-retimer enabled, the hyper-registers would get used automatically as needed to meet your timing requirements.  If that is not the case, something in your design is preventing the hyper-retimer from retiming registers into hyper-register locations, such as the use of asynchronous resets, the preserve synthesis attribute, SDC timing exceptions, etc.  Run a Fast Forward compilation analysis to see what's going on and make adjustments to allow the hyper-retimer to do its thing.

0 Kudos
Reply