amitk3553
Advanced Member level 4
- Joined
- Jul 20, 2012
- Messages
- 117
- Helped
- 2
- Reputation
- 4
- Reaction score
- 2
- Trophy points
- 1,298
- Location
- DELHI, INDIA
- Activity points
- 1,982
I think this helps
http://www.asic.co.in/DesignGuidlinesRTLcoding.htm
Do not design, with other modules, signals that combinatorially bounce from once module, back to another, then back again.
WHY: Ping-Pong signals create long layout-dependent timing paths.
It means absolutely nothing to anybody with even a little bit of experience in design. Don't bother researching 'ping pong' and RTL...you would get far more benefit from playing a game of ping-pong. Not trying to be rude, just trying to save you time that can be better spent.Please tell me what does mean by ping pong in RTL compilation.
It means absolutely nothing to anybody with even a little bit of experience in design. Don't bother researching 'ping pong' and RTL...you would get far more benefit from playing a game of ping-pong. Not trying to be rude, just trying to save you time that can be better spent.
Kevin Jennings
That's a bold statement to claim benefit from something you know nothing about. No matter how many exclamation points you use, it will not change reality.we need to register all Outputs(Means output should come from registers) to prevent ping-pong effects!!!!!!!!!
As I said, it means absolutely nothing. Design is all about function, performance and reliability. Anyone using the term 'ping pong' in the context of RTL doesn't know much about RTL or design in general that would be worth learning.So want to know exactly what is ping ponging in RTL which we have to prevent form ping ponging to achieve good synthesis results.
There is no concept to learn so you would be better off spending your time elsewhere. Apparently you are unwilling to accept this.I think I cannot understand this concept by just playing game of ping pong!!!
Simple designs where there is no flow control can typically be made to have outputs that are either clocked or not clocked as the designer may choose.Register module outputs, problem solved. The end.
An example is Avalon or Wishbone memory mapped interface where
a slave device receives a 'read' or 'write' command input.
The slave device responds with a 'wait' output that must be combinatorial because/.../
Kevin Jennings
But only at the rather high cost of giving up half of the performance of the interface except for certain constrained conditions. Likely only acceptable in limited circumstances.an Avalon slave can keep wait high 'by default' and drop wait low when read data ready / write data written; so wait can be registered
I wonder if "ping-ping signal" is something like regional technical slang, brought up by someone in India (may be a professor) that hasn't yet become known in the digital design world?Minimize Ping-Pong Signals
Do not design, with other modules, signals that combinatorially bounce from once module, back to another, then back again.
But only at the rather high cost of giving up half of the performance of the interface
except for certain constrained conditions. Likely only acceptable in limited circumstances.
always @(posedge av_clk)
if ( !(av_read || av_write) ) av_wait <= 1'b1;
else if (write_done || read_done ) av_wait <= 1'b0;
The above code will always have a one clock cycle latency on the wait. Zero clock cycle latency is faster than one.Code:always @(posedge av_clk) if ( !(av_read || av_write) ) av_wait <= 1'b1; else if (write_done || read_done ) av_wait <= 1'b0;
I don't think an async. control of 'av_wait' will work faster then the example above;
j.a
Consider this as a practical example (or counter-example) -- module A presents a fifo-like interface to module B. The "fifo empty" signal is (for this example) a combinatorial output of module A. Module B uses this signal to generate "fifo read" which is then sent back to module A. This is a path where there is combinatorial logic on A's output to B, and then there is additional combinatorial logic on B's output back to A.
With a combinatorial path that goes into a module and then back out, the layout of this interface strongly becomes part of a possible longest path. Had there been register stages on the outputs/inputs, it would be easier to design because the possible longest paths would be internal to each module, or on just one part of the path between them. Now the longest path includes the logic for "fifo empty", the path from A to B, the path from this input on B through the logic for "fifo read", the path from B back to A, and then the path from this input on A to any affected logic.
You haven't thought through this example fully. If you add registers on the interface, consider the following:
- The empty signal out of a FIFO typically already is registered so there would be absolutely no timing improvement
- If you registered fifo empty before it leaves component A, then component B will not be presenting valid status and could start a read when the FIFO first goes empty. You would then need to compensate by adding additional logic. That additional logic would use additional resources and likely gobble up any potential timing improvement that you think you are getting.
- Nothing about this example has really anything to do with signals in different modules. Nothing would change if all of what you described was in the same 'module'.
Kevin Jennings
sounds slightly beter then:The above code will always have a one clock cycle latency on the wait.
Zero clock cycle latency is faster than one.
and much better then:But only at the rather high cost of giving up half of the performance
of the interface except for certain constrained conditions.
Likely only acceptable in limited circumstances.
I was not going to argue what solution is the best;Delaying 'wait' by clocking it will result in a non-functional system.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?