cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
hasaney
Adventurer
Adventurer
9,572 Views
Registered: ‎03-06-2011

Effect of falling_edge/rising_edge on Max Frequency

Jump to solution

Hi All,

 

Nowadays, I am dealing with a design that consists of a block ram and a circuit in front of block ram that includes multiplexers and a state machine to control the multiplexers. There are many sources to BRAM and muxes selects each source depending on the state of the FSM. The circuit could run slower than I expected

 

In the state transition code when I changed the clock event as rising edge speed increases to 724 Mhz. In the falling_edge, it was 362 Mhz.

 

 

Is there any meaningful exploanation? 

 

Thanks a lot.

 

This code shows the state transition of the FSM 

process(CLK_BRAM)
	begin
	if rising_edge(CLK_BRAM) then -- when changed to rising_edge, speed doubles
			if (RST='1') then
				state <= READ01;
			else
				state <= next_state;
			end if;
		end if;
	end process;

 RISING_EDGE

Minimum period: 1.380ns (Maximum Frequency: 724.900MHz)
Minimum input arrival time before clock: 1.790ns
Maximum output required time after clock: 4.129ns
Maximum combinational path delay: No path found

 

FALLING_EDGE

Minimum period: 2.759ns (Maximum Frequency: 362.450MHz)
Minimum input arrival time before clock: 1.790ns
Maximum output required time after clock: 4.129ns
Maximum combinational path delay: No path found

 

0 Kudos
1 Solution

Accepted Solutions
gszakacs
Professor
Professor
14,004 Views
Registered: ‎08-14-2007

"If I use the rising edge for state transition, all inputs to the BRAM would change at the same time with BRAM sampling time of input signals. For this reason I have to use falling edge for state transitions."

 

That's not really true.  All outputs of a flip-flop change just after the clock edge, and sample their

inputs at the clock edge.  So in fact the BRAM would see the input changes after the sampling

point.  You should see this behavior in simulation (you did simulate your design?).

 

The tools make sure that all data paths on the same clock edge meet hold time at the destination.

If this were not true you could never make anything as simple as a shift register or counter without

using both clock edges.

 

Now from your timing report:

 

  Clock period: 2.759ns (frequency: 362.450MHz)
. . .
  Source Clock:      CLK_BRAM falling
  Destination Clock: CLK_BRAM rising
. . .
    Total                      1.380ns (0.704ns logic, 0.675ns route)

Note that the data path delay is only half of the clock period (within 1 ps).  This is due to the

use of both clock edges, and this is what slows down your design.  You're generally best off

using the rising edge of the clock for all logic elements in the design.  Let the tools do their

job and handle the clock distribution and prevention of setup/hold time issues.

 

-- Gabor

-- Gabor

View solution in original post

8 Replies
gszakacs
Professor
Professor
9,560 Views
Registered: ‎08-14-2007

You didn't mention which device family you're using, but in most cases the RAM should

be able to run just as fast on either edge.  Since the numbers seem to reflect approximately

2:1 performance difference, my guess is that you have other parts of the design that run on the

rising edge of the clock and the critical path is crossing from one edge to the other.  You can

look at the timing analysis section of the report where it shows the worst case path (the

one used to determine the maximum frequency) and see if it is going from one clock

edge to the other in the falling_edge case.

 

-- Gabor

-- Gabor
0 Kudos
hasaney
Adventurer
Adventurer
9,557 Views
Registered: ‎03-06-2011

Thanks for the reply Dear Gabor,

 

I am using Virtex-5. 

 

I am doing Block RAM operations in rising edge of clock. The inputs to the block RAM can be selected by the state of the system. So if I change the state transition as rising edge, there may be some hold & setup time violations.

 

As an more deeper explanation  this is my vhdl code.

 

type Tstate is (READ01,WRITE01);
signal state : Tstate := READ01;
signal next_state : Tstate;

						
next_state <= 	WRITE01 when state=READ01 else
		READ01 	when state=WRITE01 else
	        READ01;

ADDRB <=  ADDR_R1 when state=READ01 else
	  ADDR_W1 when state=WRITE01 else
	  ADDR_R1;

process(CLK_BRAM)
begin
    if falling_edge(CLK_BRAM) then
	if (RST='1') then
	    state <= READ01;
	else
	    state <= next_state;
	end if;
    end if;
end process;

 

at each falling edge of the clock, state changes to next_state and at the following edge (rising edge) Block RAM makes its operations (reading or writing) depending on the state (different inputs are directed to BRAM depending on the state). For example ADDRB is BRAM address port for B port.

 

If I use the rising edge for state transition, all inputs to the BRAM would change at the same time with BRAM sampling time of input signals. For this reason I have to use falling edge for state transitions.

 

I have added the simmulation report to the attechment.

 

0 Kudos
gszakacs
Professor
Professor
14,005 Views
Registered: ‎08-14-2007

"If I use the rising edge for state transition, all inputs to the BRAM would change at the same time with BRAM sampling time of input signals. For this reason I have to use falling edge for state transitions."

 

That's not really true.  All outputs of a flip-flop change just after the clock edge, and sample their

inputs at the clock edge.  So in fact the BRAM would see the input changes after the sampling

point.  You should see this behavior in simulation (you did simulate your design?).

 

The tools make sure that all data paths on the same clock edge meet hold time at the destination.

If this were not true you could never make anything as simple as a shift register or counter without

using both clock edges.

 

Now from your timing report:

 

  Clock period: 2.759ns (frequency: 362.450MHz)
. . .
  Source Clock:      CLK_BRAM falling
  Destination Clock: CLK_BRAM rising
. . .
    Total                      1.380ns (0.704ns logic, 0.675ns route)

Note that the data path delay is only half of the clock period (within 1 ps).  This is due to the

use of both clock edges, and this is what slows down your design.  You're generally best off

using the rising edge of the clock for all logic elements in the design.  Let the tools do their

job and handle the clock distribution and prevention of setup/hold time issues.

 

-- Gabor

-- Gabor

View solution in original post

hasaney
Adventurer
Adventurer
9,541 Views
Registered: ‎03-06-2011

Thanks Mr Gobar,

 

I am dealing with low level VLSI design for this reason I tried to make everything on my own (hold, setup times) and don't rely on behavioral simulation because it gives no information about metastability (http://www.programmableplanet.com/author.asp?section_id=2142&doc_id=245812). Thanks to Xilinx, it manages this.

 

Thanks again,

 

Best regards.

0 Kudos
bassman59
Historian
Historian
9,509 Views
Registered: ‎02-25-2008

@hasaney wrote:

 

If I use the rising edge for state transition, all inputs to the BRAM would change at the same time with BRAM sampling time of input signals. 

 


That sentence shows a fundamental misunderstanding of how synchronous digital logic operates.

----------------------------Yes, I do this for a living.
0 Kudos
bassman59
Historian
Historian
9,507 Views
Registered: ‎02-25-2008

@hasaney wrote:

Thanks Mr Gobar,

 

I am dealing with low level VLSI design for this reason I tried to make everything on my own (hold, setup times) and don't rely on behavioral simulation because it gives no information about metastability 


That's because functional/behavioral simulation is not interested in metastability. It is interested in whether the logic design is correct.

Metastability is a timing/circuit implementation issue. And with modern FPGAs, it is only interesting at the FPGA pins and when you are crossing clock domains.

Otherwise, it's something with which you need not worry.

----------------------------Yes, I do this for a living.
0 Kudos
hasaney
Adventurer
Adventurer
9,494 Views
Registered: ‎03-06-2011

Thanks for additional knowledge. When we look at the behavioral simulation, metastability is unavoidable (signal changed at the same time with clock pulse and sampling). There is no FF with 0 hold and setup time.

 

For this reason, I have planned to use PSL (Propoerty Specification Language) against metastability cases. However I learned that (thanks to Gabor),  in FPGA CAD tools, it can be handled easily. 

0 Kudos
gszakacs
Professor
Professor
9,482 Views
Registered: ‎08-14-2007

Thanks for additional knowledge. When we look at the behavioral simulation, metastability is unavoidable (signal changed at the same time with clock pulse and sampling). There is no FF with 0 hold and setup time.

 

1) Metastability has nothing to do with behavioral simulation.  It happens only in real hardware.  Only timing simulation can predict whether metastability is possible (i.e. setup and hold time constraints are not met).  Behavioral simulation shows zero propatation delay from the clock to the flip-flop outputs in a waveform view, but there is a "delta" delay internal to the simulation which guarantees that other flip-flops always sample the value at their inputs from before the clock edge.  This effectively guarantees that there are no hold time issues for behavioral simulation.

 

2)  I agree that no flipflop has both 0 setup and hold time, but no flip-flop has 0 propagation delay either.  It would be a totally useless FPGA whose flip-flops  did not meet hold time requirements under almost any condition.

 

Regards,

Gabor

-- Gabor
0 Kudos