ContributorHi
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 ?
Super ContributorAssuming 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:
ContributorOK
Thanks
Super ContributorYishay,
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.
ContributorHi
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 ?
Super ContributorSuper ContributorYishay,
May I know if there is any update or other concern?
ContributorHi
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
ContributorHi
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
Super ContributorAgain, 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.
ContributorGreat
Now everything is clear
Thank you
Super ContributorI’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.
