The Performance of Negative-edge vs Positive-edge Registers

--- Quote Start ---

My question is simple. When I change a RAM module, in my big design, from positive edge triggered to negative edge triggered the fmax degrade exactly by half.

What can be the problem. is there any way that I can constrain the design to prevent this from happening.

--- Quote End ---

When you only allow one half of a clock cycle for things to occur, you give up half of your clock performance...usually this is a very sub-optimal approach.

Solution: Use only one clock edge...that's the way synchronous designs work.

--- Quote Start ---

To let you know, I needed to change the RAM module to be negative edge triggered because in modelsim functional simulation some signals do not arrive exactly at the rising edge (e.g., WE). Thus, they arrive at the negative edge of the clock before the next rising edge

--- Quote End ---

Either make the write enable signal come a clock cycle earlier or delay the data by one clock cycle.

Kevin Jennings

--- Quote Start ---

Either make the write enable signal come a clock cycle earlier or delay the data by one clock cycle.

--- Quote End ---

My question here is why all signals arrive at the clock edge except the (WE) while I'm asserting them all at the same time.

You need to track the source of WE.

Is WE internal to your design or does it come from the testbench?

Does it have a delay? Maybe it's coming from a falling edge flip-flop?

--- Quote Start ---

My question here is why all signals arrive at the clock edge except the (WE) while I'm asserting them all at the same time.

--- Quote End ---

- Nothing should be changing right at the clock edge.

- In a synchronous design, signals change after the clock edge. Even in a simulation environment you'll see this. If the clock changes at t=xx ns, then the signals clocked by clock will change at t= xx ns + 1 delta cycle.

Could be your testbench has a problem. You haven't posted enough information for anybody to anything but guess.

Kevin Jennings

--- Quote Start ---

You need to track the source of WE.

Is WE internal to your design or does it come from the testbench?

Does it have a delay? Maybe it's coming from a falling edge flip-flop?

--- Quote End ---

Originally, all flip-flops in my design are rising edge. all signals comes from the top level RSMMU.sv. All signals arrive at RAM1PORT.sv as expected except (RT_WE/we ) it is not seen by RAM1PORT module right after the rising clock. However, it can see it a while after the rising edge, e.g., the falling edge.

the code is attached.

Thank you for your help

--- Quote Start ---

I needed to change the RAM module to be negative edge triggered because in modelsim functional simulation some signals do not arrive exactly at the rising edge (e.g., WE). Thus, they arrive at the negative edge of the clock before the next rising edge.

--- Quote End ---

The only surprizing point is that this happens in a functional simulation. In real design operation, signals arrive at any time before the next clock edge, by nature of synchronous logic design. Keeping the setup and hold time, in other words no signal arriving exactly at the clock edge, is the basic requirement.

Possible reasons for getting unexpected signal timing in functional simulation:

- the signals are derived from external signals, e.g. test bench stimuli of possibly inappropriate timing

- they are caused by# delay expressions in your code

- they are generated by gating signals with the system clock. This shouldn't be done.

--- Quote Start ---

Originally, all flip-flops in my design are rising edge. all signals comes from the top level RSMMU.sv. All signals arrive at RAM1PORT.sv as expected except (RT_WE/we ) it is not seen by RAM1PORT module right after the rising clock. However, it can see it a while after the rising edge, e.g., the falling edge.

the code is attached.

Thank you for your help

--- Quote End ---

I don't know Verilog...but it appears that the write enable to the ram is generated by the following logic without a clock.

assign RT_WE = (avs_ctrdata_in_write && DataTargets.LocalRegs && RT_State==MemoryAccess);

Since avs_ctrdata_in_write is an input to the module then it suggests that the module inputs are not being generated properly relative to clk. Do you have a testbench generating the inputs or are you using force statements? In either case, inspect how you are generating those inputs to the design. They should not be changing just prior to or simultaneously with clk...like every other signal they should be changing after clk changes.

Symptoms that you describe are always caused by one of two things:

- Generating inputs simultaneous (or even slightly before) the edge of the clock

- Delaying the clock (which does not appear to be the case here)

Kevin Jennings

Thank you all for you support. I learned from you some tips toward better design.

here is my test-bench

Thank you all, I solved the problem by following your guidelines towards good synchronous design. I rewrote the test-bench accordingly and the simulation result was as expected.

Thank you again. :)