We are starting to experiment with a technique to simulate multicycle paths on the Palladium. Our definition of a multicycle path is a path from flip-flop A to flip-flopB where the timing in the path exceeds one clock cycle as shown by the timing analysis tool. These paths must either be re-designed to meet the one clock cycle criteria, or be assured that the data from flop-flopA will change at most every other clock cycle.There are 3 steps to this process:1. We have defined our system clock to be made-up of 4 qtfclks. One qtfclk is the basic Palladium clock, and is used to defined your clock signals.2. The Palladium has a flip-flop that is clocked the qtfclk. We made up a verilog module that uses six of these flip-flops to produce a 6 qtfclk delay. This delay corresponds to a 1-1/2 clock cycle delay.3 We then instantiate our verilog module in the path from flip-flopA to flip-flopB and run tests on the Palladium.The early result show that we are achieiving the expected delays, and so far the test are running.
Hi Tom,your description is correct and Palladium can handle multicycle paths in the way you described it.However, your step 1) is NOT a prerequisite for enabling multicycle paths. Your design or environment may require a 4 to 1 ratio between fclk and fastest design clock but this would be a very rare case and it is absolutely NOT a requirement to enable multicycle paths. Multicycle paths are also possible with a 2/1 or even 1/1 ratio between fclk and fastest design clock, giving a speedup of up to 4x over your current environment.Also I would suggest to use the qel command breakNet rather than inserting delay-flops. This would allow keeping the RTL as is, rather than modifying it.Off course, when modeling multicycle paths within a 2x or 1x environment, the number of fclk-delays outlined in step 2) need to be reduced accordingly. In 2x mode you would need 2 or 3 fclks delays while in 1x mode you would need 1fclk delay.I write this to make sure nobody misreads the original post.Best regards, Volker