Documente Academic
Documente Profesional
Documente Cultură
Community (/S/)
or
tion
1 module Test
2 (
3 input wire scl_in,
4 input wire sda_in,
5 output reg sda_out
6 );
7 reg start_det;
8 reg stop_det;
9 reg sreg;
10 always @(negedge sda_in)
11 start_det <= scl_in;
12
13 always @(posedge sda_in)
14 stop_det <= scl_in;
15 always @(posedge scl_in)
https://forums.intel.com/s/question/0D50P00003yyNG9SAM/trying-to-constrain-i2c-interface?language=en_US 1/4
29/12/2018 Trying to constrain I2C interface
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
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)
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.
So, does this look right?
https://forums.intel.com/s/question/0D50P00003yyNG9SAM/trying-to-constrain-i2c-interface?language=en_US 2/4
29/12/2018 Trying to constrain I2C interface
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
Translate
multiple-attachme…
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.
Translate
Like Reply Link to this Reply
https://forums.intel.com/s/question/0D50P00003yyNG9SAM/trying-to-constrain-i2c-interface?language=en_US 3/4
29/12/2018 Trying to constrain I2C interface
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.
Translate
Like Reply Link to this Reply
Attachments: Only certain file types can be uploaded. If you upload a file that is not allowed, the 'Answer' button will be greyed out and you will
not be able to submit. See our Welcome to the Intel Community (../s/welcome-new-members) page for allowed file types.
For more complete information about compiler optimizations, see our Optimization Notice (https://software.intel.com/articles/optimization-
notice#opt-en).
Use this HTML Editor to add your own markup.
https://forums.intel.com/s/question/0D50P00003yyNG9SAM/trying-to-constrain-i2c-interface?language=en_US 4/4