Home > Community > Forums > Hardware/Software Co-Development, Verification and Integration > Simulating multicycle paths on the Palladium

Email

Recipients email * (separate multiple addresses with commas)

Message *

 Send yourself a copy

Subscribe

Intro copy of the newsletter section here, some intro copy of the newsletter. Instruction of how to subscribe to this newsletter.

First Name *

Last Name *

Email *

Company / Institution *

 Send Yourself A Copy

Simulating multicycle paths on the Palladium

Last post Wed, Apr 11 2007 3:37 PM by archive. 1 replies.
 Started by archive 11 Apr 2007 03:37 PM. Topic has 1 replies and 1630 views
• Wed, Apr 11 2007 3:37 PM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,930
Simulating multicycle paths on the Palladium
 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.Originally posted in cdnusers.org by tom paulson
• Post Points: 0
• Thu, Apr 19 2007 12:05 AM

• archive
• Joined on Fri, Jul 4 2008
• Posts 88
• Points 4,930
RE: Simulating multicycle paths on the Palladium
 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, VolkerOriginally posted in cdnusers.org by volker.wegner
• Post Points: 0