OPENCORES.ORG

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. <snip> 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: attachment.htm 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: attachment.htm

Reference Author

[oc] I2C test bench timing violations? Jeff Hanoch