- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I would like to ask what is them meaning of "bypassed ALM register "
You can see below the schematic & data path :
According to this reports , Quartus use this FF as a combinatorial element like LUT
Why ? the timing tool should calc setup & hold data path from FF to FF
Why there is byapss on this FF ?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Assuming this is a Hyperflex based device (Stratix 10 or Agilex), a bypassed ALM register means the hyper-retimer bypassed that ALM register and enabled a hyper-register in the fabric to improve performance. The pink registers in the tech map viewer represent the hyper-registers. Here's a good overview:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yishay,
Let me know if there is any other concern on this.
For hyperflex device, yes the Quartus will make use of hyper-register instead of alm reg to achieve better timing and faster frequency during hyper-retiming, thats the reason you alm reg is bypassed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
According to the intro of Hyper-Retiming :
the tool have the option move the FF after the LUT :
when something like this happens - we have another value ?
because before the retiming the FF dout is same value like the previos FF ,but after retiming the dout value is changed according to LUT output
how do you keep the functionally equivalent ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yishay,
May I know if there is any update or other concern?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I still dont understand ,
According to your traing - the Hyper-Retiming tool keep the state
Meaning - if the previous state was 3 FF between input -> output it will stay in the same num of FF - the Hyper-Retiming can't add or remove FF in order to keep the functionlity
I dont understant it - lets see the top figure for example - when I probe by signal tap the value after the second FF I will get spesific value (after 3 LUT's) but after the retiming the value after second FF will get another value (only 2 LUT's instead of 3 LUT's )
So , when I try to debug my system I will get unexpect value .
please advice
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
I wrote it again, more clarify
I still don't understand,
According to your training - the Hyper-Retiming tool keep the functionality
Meaning - if the previous state was 3 FF between input -> output it will be same num of FF after the Hyper-Retiming action it will be 3 FF between input -> output
The Hyper-Retiming can't add or remove FF because the tool should keep the functionality
But still there is another implementation - this is effect the debugging
For example, let’s see the figure above -
Left side (red arrow) - when I probe the value after the second FF (by signal tap) I will get specific value (after 3 LUT's)
But after the retiming - right side (green arrow) the value after second FF will be get another value (only 2 LUT's instead of 3 LUT's)
So, when I try to debug the FPGA I will get unexpected values. I have mismatch between my code and the implementation
this situation disturbs me to debug the FPGA
please advice
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Again, the functionality is not changed when retiming. If you had added Signal Tap to a design, it would actually prevent retiming moves like this to maintain the same functionality so you would see the correct signaling, but you would not have the most optimized design. This is why when you finish debugging a design you want to remove all debugging hardware and recompile to optimize.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page