Re: Trying to constrain I2C interface

Altera_Forum · ‎09-21-2011

I am designing an I2C serial interface, but I'm running into confusion setting up the timing constraints for it.

module Test
(
    input wire scl_in,
	 input wire sda_in,
	 output reg sda_out
);
reg start_det;
reg stop_det;
reg  sreg;
always @(negedge sda_in)
    start_det <= scl_in;
	 
always @(posedge sda_in)
    stop_det <= scl_in;
always @(posedge scl_in)
    sreg <= { sreg, sda_in };
	 
always @(negedge scl_in)
    sda_out <= (sreg == 8'hA5);
endmodule

The basic period is 1uS, and in general SDA will transition near the middle of the SCL low time. The only time this isn't true is when SDA is driven low at the falling edge of SCL

create_clock -name "scl" -period 1000.000ns  -waveform {0.000 500.000}
create_clock -name "sda" -period 1000.000ns  -waveform {250.000 750.000}

For a repeated start condition, SCL is high a minimum of 260nS before the falling edge of SDA. (Tsu;sta)

For a start condition, SCL is held high at least 260nS after the falling edge of SDA. (Thd;sta)

For a stop condition, SCL is high a minimum of 260nS before the rising edge of SDA. (Tsu;sto)


set_input_delay -clock "sda" -max 740ns  
set_input_delay -clock "sda" -max 740ns  -clock_fall
set_input_delay -clock "sda" -min 260.000ns  -clock_fall

For data input, SDA must be valid 50nS before the rising edge of SCL (Tsu;dat) and held for 0nS after the falling edge of SCL.


set_input_delay -clock "scl" -max 950ns  
set_input_delay -clock "scl" -max 550ns  -clock_fall

So, does this look right?

Also, (at the risk of tldr) the second attachment (tsu.jpg) shows th measured from the rising edge of the clock, but tsu measured back from the Falling edge of the clock. Shouldn't both of them be measured from the same clock edge?

Thanks

Altera_Forum · ‎09-21-2011

From my experience, when you are doing I2C, it is much better to over sample the inputs rather than use them as a clock. We have seen multiple clocks due to the slow rise rate of IIC lines. In the past we got around that by using a schmidt trigger on the inputs to get rid of the bounce, but currently we are just using oversampling.

But, if you are to do it this way, and it isn't just an assignment to figure it out but real world application, all of the timing values are so slow you can just cut the paths and not worry about it.

Altera_Forum · ‎09-21-2011

--- Quote Start ---

From my experience, when you are doing I2C, it is much better to over sample the inputs rather than use them as a clock. We have seen multiple clocks due to the slow rise rate of IIC lines. In the past we got around that by using a schmidt trigger on the inputs to get rid of the bounce, but currently we are just using oversampling.

--- Quote End ---

The goal is to turn off the clock when the FPGA isn't used, so I need an asynchronous I2C interface. I've never had a problem with bouncing on the inputs, but I'm coming from an ASIC background so we always had schmitt inputs with the 50nS glitch filter available. I'll definitely add it to the list of things to check for this project.

--- Quote Start ---

But, if you are to do it this way, and it isn't just an assignment to figure it out but real world application, all of the timing values are so slow you can just cut the paths and not worry about it.

--- Quote End ---

You are probably right, but I've got the time to do it now and incomplete specs for the rest so it seems like a good project to work on.

Knug · ‎04-30-2021

I have the same query. How to properly constrain bidirectional I2C SCL/SDA lines ?

Added this at the moment BUT I also have to generate the Output SCL clock

#I2C 100KHz clock (standard mode)
create_clock -name {fpga_i2c_scl_clk} -period 10000.000 -waveform { 0.000 5000.000 } [get_ports {FPGA_I2C_SCL}]

Need to constrain SDA wrt different conditions listed above too. Please advise

Any updates on this will be appreciated.