Herveille, Richard

I2C controller core

I noticed in my test bench that 'tip' bit is not set when issuing a STOP command, only during read/write commands. This might give the impression the bus is free when it is busy.

I fixed this by changing
    tip      <= (rd | wr);
to:
    tip      <= (rd | wr | sto);

In the top level class. It can take hundreds of cycles for the tip bit to be cleared by 'done' depending on the pre-scaler value.

TIP bit not set when generating STOP condition

It is useful to generate a flag that is asserted when no slaves acknowledge.

No Acknowledgment

I have tried to use Prescaler = 0 to use a clock exactly 5 times the sclk. I can see it is not working.

Prescaler

In the code , I found that the signal sda_o is always set to '0'. WHY? 
The  signal sda_oen is an enable signal ,but  it is set to be equal  to 'din';
In  my opinion , the 'din' should be set to zhe 'sda_o'. 
Why do the  code  be   written in the  example?

about  zhe code

In the tilte of ./bench/verilog/i2c_slave_model.v, there is a sentence

WISHBONE rev.B2 compliant synthesizable I2C Slave model

But it fail to compile using design compiler

The expression in the reset condition of the 'if' statement in this 'always' block can only be a simple identifier or its negation.

	// generate statemachine
	always @(negedge scl or posedge sto)
	  if (sto || (sta && !d_sta) )
	    begin
	        state <= #1 idle; // reset statemachine
 
	        sda_o <= #1 1'b1;
	        ld    <= #1 1'b1;
	    end
	  else

i2c_slave_model is not a synthesizable code

tst_bench_top.v
Is it a copy/paste error?

	// hookup wishbone_i2c_master core
	i2c_master_top i2c_top (
 
		// wishbone interface
		.wb_clk_i(clk),
		.wb_rst_i(1'b0),
		.arst_i(rstn),
		.wb_adr_i(adr[2:0]),
		.wb_dat_i(dat_o),
		.wb_dat_o(dat0_i),
		.wb_we_i(we),
		.wb_stb_i(stb0),
		.wb_cyc_i(cyc),
		.wb_ack_o(ack),
		.wb_inta_o(inta),
 
		// i2c signals
		.scl_pad_i(scl),
		.scl_pad_o(scl0_o),
		.scl_padoen_o(scl0_oen),
		.sda_pad_i(sda),
		.sda_pad_o(sda0_o),
		.sda_padoen_o(sda0_oen)
	),
	i2c_top2 (
 
		// wishbone interface
		.wb_clk_i(clk),
		.wb_rst_i(1'b0),
		.arst_i(rstn),
		.wb_adr_i(adr[2:0]),
		.wb_dat_i(dat_o),
		.wb_dat_o(dat1_i),
		.wb_we_i(we),
		.wb_stb_i(stb1),
		.wb_cyc_i(cyc),
		.wb_ack_o(ack),
		.wb_inta_o(inta),
 
		// i2c signals
		.scl_pad_i(scl),
		.scl_pad_o(scl1_o),
		.scl_padoen_o(scl1_oen),
		.sda_pad_i(sda),
		.sda_pad_o(sda1_o),
		.sda_padoen_o(sda1_oen)
	);

copy/paste error?

Hi,

I went through your code for bit_controller state machine.
I am not able to comprehend why have you used scl_oen and sda_oen instead of scl_o or sda_o as them outputs of the state machine. scl_o and sda_o are the actual outputs, scl_oen, sda_oen are just the enable signals.

Sinppet from code:
                    wr_c:
                    begin
                        c_state <= #1 wr_d;
                        scl_oen <= #1 1'b1; // keep SCL high
                        sda_oen <= #1 din;
                        sda_chk <= #1 1'b1; // check SDA output
                    end


why are we using sda_oen ? we need to put data on sda_o.

Also, I have a query - 
why should sda_o and scl_o be always=1 ?

bit_controller state machine o/ps

Hi Richard,

On Documentation Rev 0.8 page 3, you describe VHDL code for inserting the output buffers for I2C lines. The last line, scl_pad_i <= sda; has to be changed into sda_pad_i <= sda;

regards
Andreas

Documentation of VHDL for output buffers

hi, all

i don't know how to read from status register 
(command register and status register have the same address)how to read or write on these registers

how to read from status register

The filter_cnt code in i2c_master_bit_ctrl is
different between the VHDL version and Verilog versions.
In Verilog the counter is only started when ena = 1, in the 
VHDL version the counter starts after reset and 
one has to wait 0x4000 master clk cycles before I2C communication can begin correctly.

Init filter_cnt

In file i2c_master_bit_ctrl.vhd, line 320, change:
sSDA <= (fSDA(2) and fSDA(1)) or
        (fSDA(2) and fSDA(0)) or
        (fSCL(1) and fSCL(0));

into
sSDA <= (fSDA(2) and fSDA(1)) or
        (fSDA(2) and fSDA(0)) or
        (fSDA(1) and fSDA(0));     <----------- !!!!

wrong copy/paste

use ieee.std_logic_arith.all; is missing in i2c_master_top.vhd, therefore unsigned type is not recognized.

Missing Library

Hi Richard,
I have implemented an I2C core with success on an Actel FPGA.
Now I'm facing with a problem which arises when the I2C bus is heavy loaded with several devices and meters of cable.
the master core, after putting the SDA line at logic 1, reads a 0 on the line itself, due to the slow SDA positive signal edge.
This asserts an arbitration lost, which isn't the case.
I see two possible solutions:
1) inhibit arbitration on I2C core (losing specs compliance)
2) delay sda_chk to case c_state wr_c only...
what do you suggest?
regards
-Antonio-

Arbitration problem

Such 24LC32A to 24LC512, whose internal address need 2 byte transmit

The core DO NOT support large i2c slave?

In i2c_master_bit_ctrl.v
line 205 to line 207
	always @(posedge clk or negedge nReset)
	  if (!nReset) slave_wait <= 1'b0;
	  else         slave_wait = (scl_oen & ~dscl_oen & ~sSCL) | (slave_wait & ~sSCL);

mix with both blocking and non-blocking assignments to slave_wait, synthesis tool will give warnings.
line 373
"case (c_state) "
used the full_case synthesis attribute in a Case Statement that does not contain all possible state values or a Default Statement. The full_case synthesis attribute directs Analysis & Synthesis to treat unspecified state values in the Case Statement as Don't Care values. Analysis & Synthesis implemented the full_case synthesis attribute; however, in doing so, Analysis & Synthesis may have created synthesized logic for the current design with functionality that differs from the functionality when simulating for the design.

blocking and non-blocking

Im using the I2C core on a 100MHz Wishbone bus implemented on ALTERA cycloneII with Quartus 7.2 compiler and I observed a problema in SCL frequency output.
The I2C slave here is a simple PCF8574 device.

I try to set 100KHz SLC clock and ss from your documentation I set:

prescale = 100MHz/(5*100KHz) -1 = 199 (dec) = C7 (hex) 

The measured frequency of the scl on the oscilloscope is around 1.5KHz

There is any limit in the implementation related the Wishbone frequency I use that can explain the SCL behaviour ?

regards

I2C core and  Max Wishbone frequency

The Wishbone bus interface as implemented in the IIC module will capture write data twice because of the bus wait state introduced by the register generating the wb_ack signal. If the wb_cyc_i and wb_stb_i are valid before the first rising edge of the wb_clk_i in a bus transaction then a valid wb_wacc will be generated to allow the IIC control registers to capture the write data from the WISHBONE bus. Because the WISHBONE bus cycle is forced to be two cycles long wb_cyc_i and wb_stb_i will remain active for another wb_clk_i cycle allowing the IIC control registers to be written again on the second rising edge of wb_clk_i. This means that for correct bus operation all of the the signals, wb_cyc_i, wb_stb_i, wb_we_i, wb_adr_i, and wb_dat_i must be valid on the same rising edge of wb_clk_i. If the designer allows wb_adr_i and wb_dat_i to be multi-cycle paths, because they are heavily loaded, durning synthesis the wrong data may be captured to the wrong register in the physical circuit. Consider the timing diagram below: At "IIC REGISTER CAPTURE POINT" "1" the data "D1" is captured in error to the register at address "A1" but because the address is allowed time to stabilize into the second clock cycle of the bus transaction a second correct capture of data "D2" at address "A2" occurs.

wb_clk_i _____|''''''''''''''''''''|____________|''''''''''''''''''''|____________|''''''''''''''''''''|____________|
wb_cyc_i ________________|'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''|_______
wb_stb_i ________________|'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''|_______
wb_wacc  _________________|''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''|______
wb_acc_o _______________________________|'''''''''''''''''''''''''''''''''''''''''''''''''''|____________
wb_adr_i AXAXAXAXAXAXAXAXAXA1A1A1A1A1A1A1A1A1A2A2A2A2A2A2AXAXAXAXAXAX
wb_dat_i DXDXDXDXDXDXDXDXDXD1D1D1D1D1D1D1D1D1D2D2D2D2D2D2DXDXDXDXDXDX
IIC REGISTER CAPTURE POINTS............1.................................2..................

There are two ways to handle this problem:
1) Over-constrain the  timing so that all inputs are valid before the first wb_clk_i rising edge. This wastes the bus wait state forced by the wb_acc_o register and the correct data still gets latched to the correct address twice. If the single cycle timing constraint can be met then the wb_acc_o register could be removed and wb_acc_o could be generated combinationaly if it's single cycle timing constraint could also be met.
2) Add wb_acc_o from the register output as a qualifier to the signal wb_wacc. This gives the most timing latitude because the write data will only be latched in the final clock cycle when it is ack'ed with wb_acc_o.

WISHBONE Bus captures write data twice.

After a communication (write) failure with just a master(I2C controller Core) and a slave on a bus, I scoped the SCL and SDA signals and counted 10 SCL ticks with the second byte out (first data byte). There seems to be a tick before the data comes out. The other 9 ticks align with the data. And of course the slave fails to ACK this second byte.
I also scoped scl_padoen_o so I know the core is generating the extra pulse.

I am using an Altera CycloneII Nios Dev board and Quartus 9.0

stu

extra SCL tick

Hello Richard,

We updated our code to the latest available on the web:
i2c_master_bit_ctrl (vhdl) 1.17

However, it appeared that arbitration is going wrong.
We have a test case where 2 instantiations from the i2c_master tries to access the same serial eeprom.
The master that starts first, aborts with an AL error at the moment that the second master is accessing the bus.

We switched back to version 1.14, and arbitration is OK now.
The second master aborts due to an AL conditions, and the first master can finish the access properly.

If you wish, I can send you the waveform.

Regards,
Arjen Wijsmuller

Arbitration error in (vhdl) version 1.17 of the i2c_master_bit_ctrl

If you experience strange behaviors in this core (like reads turning into writes or different I2C regs being read/writen or so) take a logic analyzer and check the I2C lines to look for strange SCLK patterns (varying duty cycles, incomplete I2C operations,...).

This is what happened to me in a single master/slave I2C bus. After thoroughly studying the I2C controller core's code I've found the problem in the triggering of the arbitration lost signal in the bit controller (amazing because there is only one master!). This is due to a stop condition being detected at random places. To avoid this, I changed line 315 of the i2c_master_bit_ctrl.vhd from:
ial <= (sda_chk and not sSDA and isda_oen) or (sto_condition and not cmd_stop);
to:
ial <= (sda_chk and not sSDA and isda_oen);
Strangely enough, in the comments over this process it says: "-- 2) stop detected while not requested (detect during 'idle' state)" but this stop is being detected in all the states but the stop one, not only during the idle one. Anyways, as far as I know about the I2C bus, it is enough with checking this condition: "1) master drives SDA high, but the i2c bus is low" to trigger an arbitration lost.


This way everything runs perfect. My findings lead me to believe that the problem is in the sto_condition signal generation in the same file by line 269: sto_condition <= (sSDA and not dSDA) and sSCL;
The problem is that this is checked every clock cycle, that is if your system runs at 50 MHz, the I2C lines which should run at around 400 KHz will be treated like a fast line, and the slow transitions in these lines (slow slew rate) may create a false stop condition that would trigger an arbitration lost.

My recommendation: put slew rate fast in the I2C lines and change line 315 as said above.

This core is good and well documented, the code is clean and easy to read. I will continue to use it as, after making this changes, everything goes fine now.

Browse

I2C controller core