Stats

  • Locked Locked
  • Replies 1
  • Subscribers 48
  • Views 14055
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Simulating multicycle paths on the Palladium

archive

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
  • archive

    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

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.