Honored Contributor
Honored ContributorWhat's your incoming data doing? If a,b,c,d,etc. have new data every other clock cycle, then Case 3 just ignores every other bit of data coming in and therefore ignores every other calculation you want done. So yes, it is correct in that the paths multicycled all hold their data every cycle, but wrong for how your design should work.
If the data doesn't change every clock cycle and holds its value for two cycles, then Case 1) or 2) should work. Other ideas: - Assuming the logic changes every cycle, you could add a parallel path of multipliers that do the same thing and feed every other value into each path, using an enable to hold the value for two cycles. Then on the output mux the two paths back together. This is a lot of extra logic though, but one way to hand the high data rate. - Multicycles are similar to just pipelining the path. Rather than multicycling it at all, add a register stage into the middle of path. The reason multicycles are sometimes preferred is that you don't have to "find the middle of the path" and add a register. For example, if you clock period were 10ns and you had a data path that was 19.5ns long, you would have to exactly find a mid-point to add a register such that the new path to this register and from it are less than 10ns in length. This can be difficult and not an issue with multicycles. But if you can do it, I think adding registers is often better in that all the misunderstandings and gotchas of multicycles disappear, the design works as coded and toggles data on every clock cycle. (Plus you can run your data at the full throughput. Multicycles like what you're doing assume you are not). - One last point, it is recommended not to use multicycles like this in Stratix 10 and instead register the path. The beauty with S10 is that the registers added are basically free, and you don't have to find the midpoint of the path since retiming can push the registers to the midpoint. There are other benefits beside that.
