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

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 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 1605 views
Page 1 of 1 (2 items)
Sort Posts:
  • Wed, Apr 11 2007 3:37 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    Simulating multicycle paths on the Palladium Reply

    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
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: Simulating multicycle paths on the Palladium Reply

    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


    Originally posted in cdnusers.org by volker.wegner
    • Post Points: 0
Page 1 of 1 (2 items)
Sort Posts:
Started by archive at 11 Apr 2007 03:37 PM. Topic has 1 replies.