I'm trying to simulate the I2C controller using the code I just downloaded from CVS. I'm getting many timing violations specifically setup on the start condition (SDA falling to SCL falling is 4.2us instead of 4.7us). Also getting SCL width errors (3.6us instead of 4.0us). The expected numbers in the timing checks agree with the published I2C spec. Has anyone else had problems with the timing of this core? It's going into an ASIC very quickly and I'm a little concerned. I've changed the prescaler to run at 85KHz instead of 100KHz and this seems to fix most of the violations (I'm still getting 1 setup violation). Are these "real" issues I need to fix, or are they not an issue with the I2C parts on the market today? Any input would be appreciated. Thanks, Jeff P.S. Here's the violation I see at 85KHz... # status: 187062600 generate 'start', write cmd 20 (slave address+write). Check invalid address # ** Error: i2c_slave_model.v(342): $setup( negedge sda &&& scl:1881 us, negedge scl:1885200 ns, 4700 ns ); # Time: 1885200 ns Iteration: 1 Instance: /tst_bench_top/i2c_slave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20050202/58264ee3/attachment.htm

You're the first user to report these violations. I can imagine that you get these when your resolution is too small. The prescalers are simple counters that scale the system clock down to 5x the scl clock. It would be best if you send me information about the system clock, and your prescale register settings. Cheers, Richard _____ From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Jeff Hanoch Sent: Wednesday, February 02, 2005 4:05 AM To: cores at opencores.org Subject: [oc] I2C test bench timing violations? I'm trying to simulate the I2C controller using the code I just downloaded from CVS. I'm getting many timing violations specifically setup on the start condition (SDA falling to SCL falling is 4.2us instead of 4.7us). Also getting SCL width errors (3.6us instead of 4.0us). The expected numbers in the timing checks agree with the published I2C spec. Has anyone else had problems with the timing of this core? It's going into an ASIC very quickly and I'm a little concerned. I've changed the prescaler to run at 85KHz instead of 100KHz and this seems to fix most of the violations (I'm still getting 1 setup violation). Are these "real" issues I need to fix, or are they not an issue with the I2C parts on the market today? Any input would be appreciated. Thanks, Jeff P.S. Here's the violation I see at 85KHz... # status: 187062600 generate 'start', write cmd 20 (slave address+write). Check invalid address # ** Error: i2c_slave_model.v(342): $setup( negedge sda &&& scl:1881 us, negedge scl:1885200 ns, 4700 ns ); # Time: 1885200 ns Iteration: 1 Instance: /tst_bench_top/i2c_slave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20050202/ad648576/attachment.htm

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: clk_en_detail.jpg Type: image/jpeg Size: 81779 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20050202/48a0e769/clk_en_detail.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: rscl_delaytoZ.jpg Type: image/jpeg Size: 78875 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20050202/48a0e769/rscl_delaytoZ.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: state_machine_scl_width.jpg Type: image/jpeg Size: 116730 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20050202/48a0e769/state_machine_scl_width.jpg -------------- next part -------------- A non-text attachment was scrubbed... Name: state_machine_sda2scl.jpg Type: image/jpeg Size: 103180 bytes Desc: not available Url : http://www.opencores.org/forums.cgi/cores/attachments/20050202/48a0e769/state_machine_sda2scl.jpg

Can u give me the testbench file of yours? I think it's maybe useful to
me.

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://www.opencores.org/forums.cgi/cores/attachments/20050207/d39d661c/attachment.pgp

I'm running the tst_bench_top.v code from CVS. Here's the lines from that file showing the prescaler values: // program internal registers u0.wb_write(1, PRER_LO, 8'hfa); // load prescaler lo-byte u0.wb_write(1, PRER_LO, 8'hc8); // load prescaler lo-byte //u0.wb_write(1, PRER_LO, 8'hea); // load prescaler lo-byte u0.wb_write(1, PRER_HI, 8'h00); // load prescaler hi-byte $display("status: %t programmed registers", $time); The "c8" value is the default value used as downloaded from CVS. I'm using the default clock as well... looks like 100MHz to me as follows: // generate clock always #5 clk = ~clk; yep 100MHz Looking at the i2c_master_bit_ctrl.v, the state machine transitions are enabled by a signal called clk_en. This signal goes high for a single clock cycle when the cnt downcounts to zero. So clk_en is going high every 2.01us. Looking at the state machine in this file, the SDA falls as c_state transitions from start_c to start_d. Then SCL falls as c_state transitions from start_e to idle. This is 2 clk_en periods which would total 4.02us. This setup time is spec'd at 4.7us. If the real I2C devices really don't have a problem with 4us instead of 4.7us, then maybe the easy solution would be to modify the parameter in the slave model to just make it work. The Philips spec does specify 4.7us and that's what the parameter should be. In my simulations it shows up as 4.2us and, strictly speaking, this would be a violation of Philips' specs. However most i2c chips released are compliant to the fast spec, which is waay more relaxed. I don't foresee an issue. However is you need to be 100% sure, add another state. As I mentioned, I'm also seeing width violations on the SCL line. Apparently the slave_wait signal is holding off the external SCL causing it to be too short. It's high for 3.6us which is short of the 4.0us in the spec. ftp://hanochnet.org/pub/state_machine_scl_width.jpg shows this. Yeah, well there's not a lot the core can do here. This is caused/generated by the slave. Another simulation issue I'm seeing is a huge delay after the first command is given... it seems that the rscl signal on the tst_bench_top level is not going HiZ until 1.2us into the simulation. This is caused by a simulation issue. I have a fix for this. Philips' spec says the max line delay is 600us. I tried to simulate this, but I used the wrong statements. I will update the testbench and fix this. Cheers, Richard Thanks, Jeff On Wed, 2005-02-02 at 17:09 +0100, Richard Herveille wrote: You're the first user to report these violations. I can imagine that you get these when your resolution is too small. The prescalers are simple counters that scale the system clock down to 5x the scl clock. It would be best if you send me information about the system clock, and your prescale register settings. Cheers, Richard _____ From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of Jeff Hanoch Sent: Wednesday, February 02, 2005 4:05 AM To: cores at opencores.org Subject: [oc] I2C test bench timing violations? I'm trying to simulate the I2C controller using the code I just downloaded from CVS. I'm getting many timing violations specifically setup on the start condition (SDA falling to SCL falling is 4.2us instead of 4.7us). Also getting SCL width errors (3.6us instead of 4.0us). The expected numbers in the timing checks agree with the published I2C spec. Has anyone else had problems with the timing of this core? It's going into an ASIC very quickly and I'm a little concerned. I've changed the prescaler to run at 85KHz instead of 100KHz and this seems to fix most of the violations (I'm still getting 1 setup violation). Are these "real" issues I need to fix, or are they not an issue with the I2C parts on the market today? Any input would be appreciated. Thanks, Jeff P.S. Here's the violation I see at 85KHz... # status: 187062600 generate 'start', write cmd 20 (slave address+write). Check invalid address # ** Error: i2c_slave_model.v(342): $setup( negedge sda &&& scl:1881 us, negedge scl:1885200 ns, 4700 ns ); # Time: 1885200 ns Iteration: 1 Instance: /tst_bench_top/i2c_slave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.opencores.org/forums.cgi/cores/attachments/20050209/8b9cdfba/attachment.htm

sorry , just deleted Richard's mail by mistake. finger trouble :(

I don't agree that a timing violation caused by the slave giving itself
wait time by holding scl low is something the master has no control over.

Surely having the master start timing the requisite SCL high pulse
after the slave releases the open drain SCL line would be the
appripriate solution?

john

That's what I am doing .....
The high time count is started after SCL goes high, which is once all
masters and slaves agree to assert SCL high.

Richard, I was trying to use the cordic transformer available in OC which has been developed by you. I was reading the pdf dcoument in it. there for the rectangular to polar conversion block you mention the outputs as begin "16 bit integer and 4 bit fractional". Does this apply to both the Rout and Aout?? If I want the Aout to be b/w -pi to pi in 2's complement form, can I just use the given Aout as it is or do I have to modify the format?? I appreciate any help for the above two questions. thanks, Hemanth ----------------------------------------- Stay ahead of the information curve. Receive EDA news and jobs on your desktop daily. Subscribe today to the EDA CafeNews newsletter. [ http://www10.edacafe.com/nl/newsletter_subscribe.php ] It's informative and essential.

I'm getting a timing violation when I run as close to 100 kHz SCL rate as
possible (33.33MHz system clock, prescale=0x42). I have translated
your testbench into VHDL. The only violation that I get is at the
repeated start when reading from the I2C slave model (tSU;STA), but
my application would be capable of violating the tL_SCL as well.

for "start", and insert an 'e' state for the other conditions, and adjust the outputs in these states accordingly, and adjust the prescale value to be 6x SCL. This should provide a little extra margin, especially for tH_SCL and tSU;STO, which currently have zero slack at exactly 100kHz SCL rate. However, I have not tried this yet, and there may be details that I don't see yet. What resolution do you run your simulation at? Thanks, Joe ----- Original Message ----- From: Richard Herveillerichard at h...> To: Date: Wed Feb 2 17:09:50 CET 2005 Subject: [oc] I2C test bench timing violations?

Your fix is ok. I have to admit that for (repeated) start the timing is not 100%. However I haven't seen any device yet, nor did I receive any reports, that devices can't handle the reduced timing margin. Richard -----Original Message----- From: cores-bounces at opencores.org [mailto:cores-bounces at opencores.org] On Behalf Of joseph_gassman at agilent.com Sent: Friday, June 30, 2006 11:34 PM To: cores at opencores.org Subject: Re: [oc] I2C test bench timing violations? I'm getting a timing violation when I run as close to 100 kHz SCL rate as possible (33.33MHz system clock, prescale=0x42). I have translated your testbench into VHDL. The only violation that I get is at the repeated start when reading from the I2C slave model (tSU;STA), but my application would be capable of violating the tL_SCL as well. for "start", and insert an 'e' state for the other conditions, and adjust the outputs in these states accordingly, and adjust the prescale value to be 6x SCL. This should provide a little extra margin, especially for tH_SCL and tSU;STO, which currently have zero slack at exactly 100kHz SCL rate. However, I have not tried this yet, and there may be details that I don't see yet. What resolution do you run your simulation at? Thanks, Joe ----- Original Message ----- From: Richard Herveillerichard at h...> To: Date: Wed Feb 2 17:09:50 CET 2005 Subject: [oc] I2C test bench timing violations? _______________________________________________ http://www.opencores.org/mailman/listinfo/cores