cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
10,148 Views

implementing vhdl I2C MUX in CPLD VHDL

hi all , 
i need to implement i2c mux that consists of:
4 i2c masters 
8 i2c slaves

external hardwre can configure with master is going to be connected to one of the 8 slaves.

The problem is that I2C signal ( SDA) is bidirectional, which makes 
I2C mux within an CPLD hard to implement. 

thans

0 Kudos
Reply
8 Replies
Guide
Guide
10,144 Views
Registered: ‎01-23-2009

I have very simple advice for you - DO NOT ATTEMPT THIS!

 

I have basically answered this question in this post.

 

By the way - just as a note, the SCL is "bidirectional" too, since slaves can do clock stretching...

 

Sorry...

 

Avrum

Anonymous
Not applicable
10,139 Views

hi Avram, this is our customers requirements.

and i need to implement this module for them,

i konw is is not  going to be esay, 

but still, i whould like to get some guidelines and/or ref designs,

 

thanks, or shoshani

0 Kudos
Reply
Guide
Guide
10,133 Views
Registered: ‎01-23-2009

Shoshani,

 

I can't stress enough how much you do NOT want to do this. Find ANY other way to do this outside of "conventional" digital logic

  - use dedicated I2C MUXes

     - you could probably use four 8-channel I2C MUXes (like NXP PCA9548ABS)

         - use one per master, and tie all the outputs together (one output of each of the 4 MUXes tied together is the slave channel)

  - Use pass transistors on the board and control them from the CPLD

      - would require 64 pass transistors

 

Without pass transistors, this becomes a nightmare. The I2C bus is specifically designed to be a physical connection from master to slave (or, at most, through a pass transistor), so that either side can pull the wire down. Without this ability you have to try and de-construct the I2C operation into any possible time that once side can influence the other.

 

One of the biggest challenges is clock stretching. Any time the master brings the clock down, the slave has the ability to hold it down to prevent the clock from rising, and hence pace the operation. Some slaves do this only at defined times (like at the end of the address cycle), but, according to I2C, a slave can do this on any cycle.

 

Without pass transistors, how does this work?

 

Lets say the master pulls the clock low. Your FPGA detects this and pulls the slave low. Now, it is possible that the slave will hold the slave side low, so the FPGA has to hold the master side low just in case. Now what? The FPGA is now holding both sides low. It can't tell if the slave is really holding it low until it releases the slave side. But if it does this, and the master hasn't already released its side, you have a situation where the master side is still low, but the slave side is high...

 

IF you know the longest amount of time the master can hold the clock low, then this can be solved by first driving the master to the slave, then holding both low for a while then driving the slave to the master... (or something like that, I forget the details). But, if the master can hold the clock low for any amount of time, I don't think this is a solvable problem.

 

And that's only one of the bajillion cases you need to deal with. Every one of them needs to be considered, and designed around. Restrictions need to be examined and determined to be acceptable for the master and slave devices you are going to be using. The number of requirements build up, and the state machine to control all of this gets incredibly convoluted. Mess something up and you stall the bus and can't get out of it.

 

And then you have the question of multiple masters on the same slave bus (which I don't know if you have to deal with) - at which point the I2C bus ownership resolution function kicks in...

 

Honestly - I did this once (so it is doable, with a fair number of restrictions). But, it is the only design I have ever done that still gives me nightmares all these years later.

 

Find another way...

 

Avrum

Tags (2)
Professor
Professor
10,122 Views
Registered: ‎08-14-2007

I've actually done a subset of this in an FPGA.  My case only required one master connecting to one of 4 slaves via 4 separate I2C buses.  In my case the switching was automatic, because I only needed the 4 slave side buses to deal with slaves that had the same address.  My design used two of the address bits to do this using a combination od inverted and noninverted pass-through.

 

This design has some serious challenges.  If you try to deal with the bidirectional nature of the bus by detecting current drive at each side, you can easily end up in a locked up state.  For SDA, you can decode the protocol to determine the direction of data transfer.  For SCL, clock stretching is an issue.  The chips sold by NXP and others that do this sort of switching all have special receivers that can detect if a port is being driven low without needing to allow the port's driver to turn all the way off.  In my case I knew the I2C masters' timing parameters and this allowed me to cheat:

 

1) When the master drove SCL low, I started a timer.  Once started I held both master and slave SCL low until the timer expired (8 microseconds in my case).  This effectively gave a minimum stretch.

 

2) When the timer expired I released the drive on the slave side SCL.  Master SCL from that point on was driven by the state of the slave SCL.  This allowed slave clock stretching.

 

Why is this cheating?

 

What if the master had an open-ended time that it could assert SCL low?  Then if it was still low after 8 us, and I released the slave's SCL, the slave would latch the data on the bus too soon.

 

The problem is how to know when the master would have released SCL without stretching.  If instead of holding the master SCL low, I waited for it to go high and then started to drive SCL based on the slave SCL, the master might see that high-going glitch on its own SCL and proceed on to the next clock cycle, screwing up the state.  This is the sort of thing that the dedicated chips can handle by detecting the drive current on the input pins.

 

You might possibly be able to mimick the operation of the dedicated chips using an external transistor and two CPLD pins per SCL line.  On the other hand, why wouldn't you just go to NXP or TI or whomever and buy a chip that does what you want?

-- Gabor
0 Kudos
Reply
Historian
Historian
10,096 Views
Registered: ‎02-25-2008


@Anonymous wrote:

hi Avram, this is our customers requirements.

and i need to implement this module for them,


You need to educate your customer.

 

Hopefully, this was their requirement, and not something you suggested you do before doing a feasibility study.

----------------------------Yes, I do this for a living.
0 Kudos
Reply
Teacher
Teacher
10,081 Views
Registered: ‎09-09-2010

Maybe I am being *really* stupid, but why - for a bus standard that is designed to be multi-master and multi-slave - is a mux needed?

------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos
Reply
Instructor
Instructor
10,079 Views
Registered: ‎07-21-2009

The natural applications for an I2C muxes are

  • electrically divide a large 'ecosystem' for signal integrity purposes (reduce loading)
  • multiple slave devices with matching or overlapping addresses
  • avoids arbitration between masters

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Reply
Historian
Historian
10,071 Views
Registered: ‎02-25-2008


@rcingham wrote:
Maybe I am being *really* stupid, but why - for a bus standard that is designed to be multi-master and multi-slave - is a mux needed?

Because some designs need more things hanging on the bus than I2C was intended to support. 

 

Remember that the initial version of I2C had only a 7-bit address space, and the limiting factor was more the total bus loading (capacitance) than the number of slaves one might want to address. One way to work around these limits is to use bus muxes, which both isolate some segments (reducing loading) while increasing the number of devices one might wish to address.

 

Having said all of that, if you require such crazy bus muxing, you should probably rethink your architecture. Maybe go with a different sort of link between segments, with a micro managing both the link between segments as well as the "local" I2C devices.

----------------------------Yes, I do this for a living.
0 Kudos
Reply