[SOLVED] race condition in SPI

[alphus]

Hello.
I'm trying to synthesize the SPI slave in RC Compiler. After synthesis occurs race conditions between SPI_CLK and system clock (clk):

 always @(posedge clk)
    spi_clk_r <= spi_clk;

How to avoid the race conditions in this case?

 

[barry]

Not nearly enough information.

Maybe you need a synchronizer?

 

[alphus]

Not nearly enough information.

Maybe you need a synchronizer?

I want detect rising edge of SPI_SCK, but when SPI_CLK and system_clock edges occur simultaneously data corrupted.
The same thing happens with signal SPI_SS.

 

[FvM]

You don't show how the SPI clock is actually processed in your design, this can't be guessed from the two lines you have posted.

State-of-the-art logic design requires a two FF synchronizer and synchronous edge detection. Please show meaningful code.

 

[alphus]

//synchronize async input (SPI_CLK) with system clock
always@(posedge clk)
   spi_clk_r <=spi_clk;

//save the value to generate pulse
always@(posedge clk)
   spi_clk_prev <= spi_clk_r;

//and detect rising edge of synchronized spi_clk (pulse).
//it used for data capturing
assign rising_spi_clk =  ~spi_clk_prev & spi_clk_r;

Undefined state occurs in first FF ( spi_clk_r = 1'bX), therefore data partially damaged.

 

[rahul.achates]

since you are generating a clock using master clock , this is fine and should work.

what are the constraint you are providing to the tool ?

you need to define master clock as
create_clock ...

and then you need to define generated clock as

create_generated_clock -source ... <> - destination <>

this will help tool to understand the relationship between 2 clocks.

If this doesn't work then provide more information about both clock ... how you are generating and how you are using them in design ..

Rahul

 

[FvM]

//synchronize async input (SPI_CLK) with system clock
always@(posedge clk)
   spi_clk_r <=spi_clk;

//save the value to generate pulse
always@(posedge clk)
   spi_clk_prev <= spi_clk_r;

//and detect rising edge of synchronized spi_clk (pulse).
//it used for data capturing
assign rising_spi_clk =  ~spi_clk_prev & spi_clk_r;

Undefined state occurs in first FF ( spi_clk_r = 1'bX), therefore data partially damaged.

Two comments.

- You are only using a single level synchronizer, the metastability MTBF might be a bit low.
- The "undefined state" point seems to refer to a pure simulation problem

P.S.:

and then you need to define generated clock as

No generated clocks should be involved with synchronizer FFs, just false pathes.

 

[rahul.achates]

This is bit tricky .. and yes , DC will report a race condition because you are using a data signal as a clock.

As Logic designer , I would have go for different path.


For your spi_clk_r , Is there any clock in that domain ?

If yes then you can have a pulse enable signals detecting rising edge and use it as enable signal. That way you will not get race condition from tool.

Rahul

 

[alphus]

No, i'm don't use a data signal as a clock. spi_clk is interface signal (SPI_CLK).

Now i'm trying to use 2-FF synchroniser. First flip-flop transmits X to second flip-flop.
My synchroniser:

always@(posedge clk) begin
   flop0 <= spi_clk;
   flop1<= flop0;
end

I'm using ncSim. Is it a simulation problem?


thanks

 

[rahul.achates]

I am sorry but I still dont have full picture what you are trying to do ..

can you tell me what is clk and spi_clk , and what is the communication happen between two clock domain.

Rahul

 

[ads-ee]

No, i'm don't use a data signal as a clock. spi_clk is interface signal (SPI_CLK).

Now i'm trying to use 2-FF synchroniser. First flip-flop transmits X to second flip-flop.
My synchroniser:

always@(posedge clk) begin
   flop0 <= spi_clk;
   flop1<= flop0;
end

I'm using ncSim. Is it a simulation problem?
View attachment 104531

thanks

Your picture doesn't have the same names as the behavioral code. Is this picture from a netlist simulation? The behavioral code shouldn't result in an X on the flop0 output signal. This will happen if you are simulating a netlist with actual library cell simulation models, which will check for setup and hold violations.

As it's been close to a decade, since I last worked on ASICs and used library models I don't recall what we did to circumvent this problem. I'm pretty sure there was some switch we used to turn off the setup/hold checks on our synchronization flops.

Regards

- - - Updated - - -

Yes, you can and should disable the timing checks on the synchronizers...

Take a look at this thread on the subject.
https://www.edaboard.com/threads/127857/
If you're using incisive (ncsim) then this might help.
https://www.cadence.com/rl/Resources/white_papers/Gate_Level_Simulation_WP.pdf

 

[FvM]

The simulator flags a signal that violates the setup- and hold requirements. The design is prepared for possible timing violations by inserting a synchronizer. The clock edge will be either detected in one or the other clock cycle, but clearly detected in both cases.

I presume there's a way to verify correct synchronizer operation in the simulation.

 

[rca]

As spi_clk is considere as asynchrone versus clk signals, the first flop which sample spi_clk should have the timing check in the netlist simulation disabled.
For the synthesis, the constraint on spi_clk is a false_path to the first flop, as it is asynchronous, and you could add a max/min delay to avoid a huge latency on this path from the pad to the first flop which sample spi_clk with clk.

 

[alphus]

Thank you all for answers!
I have successfully synthesized a netlist. I have disable timing check in my 2-FF synchronizer module using cadence timing file (ncelab -tfile).
Simulation netlist completed successfully.

 

[rahul.achates]

Good to know it is resolved !!