HI,

I am using the I2C controller core. The current test bench for this core has an example
for usage of a single master.

I am looking for an example on the multi master usage.

If any of you have any pointers or example on this please let me know.

Thanks,
Vijay Kirpalani

vijaykirpalani@gmail.com

adding more information on the query...

In the testbench.sv there are 2 master modules that are instantiated...
(1) i2c_top and
(2) i2c_top2

Now, there is only one wisbone interface created that is
wb_master_model #(8, 32) u0

Now when i want do an I2C read/write - i use the wishbone interface using the
u0 module instantiation - like given below
u0.wb_write(1, TXR,{iSlaveAddr,WR} );

Here there is no way to distinguish the master you are using to drive the slave address on
the bus.

How do you distinguish one master from another ?

Do i need to create another wishbone interface ?

Please let me know.

Thanks,
VIjay

Create I2C arbiter

What I mean
There is I2C-bus
There are devices on the bus. Some of them masters, same of them slaves
When the bus is busy then it is busy
You can create a I2C-bus Sniffer: It'll say who and what sen(d|t) and when some master can take the bus.
If you have the slave's src, then you can improuve it to a sniffer

Hi,

My query is specific to the test bench that already exists today and how to
extend it to a multi master scenario....re-posting the query with details...below

In the testbench.sv there are 2 master modules that are instantiated...
(1) i2c_top and
(2) i2c_top2

Now, there is only one wisbone interface created that is
wb_master_model #(8, 32) u0

Now when i want do an I2C read/write - i use the wishbone interface using the
u0 module instantiation - like given below
u0.wb_write(1, TXR,{iSlaveAddr,WR} );

Here there is no way to distinguish the master you are using to drive the slave address on
the bus.

How do you distinguish one master from another ?

Do i need to create another wishbone interface ?

Please let me know.

Thanks,
VIjay

In the I2C protocol, there's no way for the slave to distinguish which master is driving it.

Instead, the master should be able to tell that another master's commands collided, and should back off in this instance.

The magic lies in the pull-up resistors on board.

Dan

Hi,
Thanks for your response, I was not asking about the slave side.
At the master end...
There is a wishbone interface that is used to interface with the I2C core (master).
Since there are 2 masters, i was not sure if the same wisbone interface will be used
for both the masters in a multi-master case ?

To write data, one uses the wishbone interface to write to the I2C core registers.
Now when writing, how to distinguish between the 2 cores.

Hope my query is clear.

Thanks.
VIjay

In I2C you have only two wires (I do not take in a count Vcc and Gnd)
You can attach to them (two wires) any number of clients (masters or slaves) (in a theory. -fanout)
Who occupy the wires?
When several masters knock to I2C in the same time you obtain a collision.
I think the main question is how to except the collision of several masters?
Your master device must employ an arbiter who tell you
'The Bus is busy, sir!'
or
'The Bus is free, sir!'
Inside of the chip you can do wishbone anythin

Hi,

My understanding is that the Open Core I2C already implements arbitration logic.
It also exposes a bit in the Master register map to indicate if arbitration is
lost by the given master.

There query is related to on how to write to the registers in a multi master scenario.
There are 2 masters created by the open core test bench. i2c_top and i2c_top2.

I am able to write and read from I2C_top through the wishbone interface. How to
write and read registers in I2c_top2 ?

If anyone is familar with I2C core from open core, please respond to my query.

Thanks,
VIjay Kirpalani

I have not looked at the test suite, but if there is two top level designs in the test suite then there likely is two separate wishbone busses with their own set of periperials, one per top level design.

The i2c core is a wishbone periperial, and you can instanciate several of them in the same wishbone bus at different addresses and different I/O pins. But for a test suite it makes more sense to have them on separate busses to eleminate any risk of digital crosstalk in the test design, more closely resembling two different systems trying to use the same i2c bus.

I also do remember the core having arbitration support for multimaster i2C busses, but it is possible there may be some bugs in that area as it is a condition which is not tested very often. Most i2c busses only have one master by design.

Unfortunately it was several years since I last looked at the i2c core in detail. Once the design is done it just kind of sits there and does it's job hidden behind software drivers.. so my memory is a little vague.

Thanks in advance for your response :-) if you could look at the details below,
it will help me to resolve this query and move forward with my test coding.

The test bench creates 2 masters but creates wish bone interface only for one of the masters like this given below. I tried creating a second wishbone and it did not work, basically i am not
clear on how i associate it with the second master. In the inputs given to the creation of the wishbone interface, i don't see any fields that are distinguishing its association with the first master.

What do you think ? which field shd be changed for associating it with the second master ?



wb_master_model #(8, 32) u0 (
.clk(clk),
.rst(rstn),
.adr(adr),
.din(dat_i),
.dout(dat_o),
.cyc(cyc),
.stb(stb),
.we(we),
.sel(),
.ack(ack),
.err(1'b0),
.rty(1'b0)
);

wire stb0 = stb & ~adr[3];
wire stb1 = stb & adr[3];

assign dat_i = ({{8'd8}{stb0}} & dat0_i) | ({{8'd8}{stb1}} & dat1_i);

// 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_out),
.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_out),
.sda_pad_o(sda1_o),
.sda_padoen_o(sda1_oen)
);