[SOLVED] race condition in SPI

Status
Not open for further replies.
A

alphus

Newbie level 6
Joined
Apr 21, 2014
Messages
14
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Visit site
Activity points
105
Hello.
I'm trying to synthesize the SPI slave in RC Compiler. After synthesis occurs race conditions between SPI_CLK and system clock (clk):
Code: 
 always @(posedge clk)
    spi_clk_r <= spi_clk;

How to avoid the race conditions in this case?
 
Last edited:

barry said:
Not nearly enough information.

Maybe you need a synchronizer?
Click to expand...



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.
 

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.
 

Code: 
//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.
 

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
 

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
Click to expand...
No generated clocks should be involved with synchronizer FFs, just false pathes.
 

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
 
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:
Code: 
always@(posedge clk) begin
   flop0 <= spi_clk;
   flop1<= flop0;
end

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


thanks
 

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
 


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
 
Reactions: alphus

    A

    alphus

    Points: 2
    Helpful Answer Positive Rating
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.
 
Reactions: alphus

    A

    alphus

    Points: 2
    Helpful Answer Positive Rating
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.
 
Reactions: alphus

    A

    alphus

    Points: 2
    Helpful Answer Positive Rating
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.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…