I2C Questions

Question: What is the maximum distance of the I2C bus?

This depends on the load of the bus and the speed you run at. In typical applications, the length is a few meters (9-12ft). The maximum capacitive load has been specified (see also the electrical Spec's in the I2C FAQ). Another thing to be taken into account is the amount of noise picked up by long cabling. This noise can disturb the signal transmitted over the bus so badly that it becomes unreadable.

The length can be increased significantly by running at a lower clock frequency. One particular application - clocked at about 500Hz - had a bus length of about 100m (300ft). If you are careful in routing your PCB's and use proper cabling (twisted pair and/or shielded cable), you can also gain some length.

If you need to go far at high speed, you can use an active current source instead of a simple pull-up resistor. Philips has a standalone product for this purpose. Using a charge pump also reduces "ghost signals" caused by reflections at the end of the bus lines.

Question: I'd like to extend the I2C bus. Is there something like a repeater for I2C?

Yes indeed this exists. Philips manufactures a special chip to buffer the bi-directional lines of the I2C bus. Typically, this is a current amplifier. It forces current into the wiring (a couple of mA). That way you can overcome the capacitance of long wiring.

However, you will need this component on both sides of the line. The charge pump in this devices can deliver currents up to 30mA which is way too much for a normal I2C chip to handle. With these buffers you can handle loads up to 2nF. The charge amplifier 'transforms' this load down to a 200pF load which is still acceptable by I2C components.

Question: Are there stand-alone I2C controllers available?

Yes indeed. There is a special chip to do the I2C interfacing. The PCD8584 or PCF8584 incorporate a complete I2C interface. These chips are designed in such way that they can interface to almost any microcontroller around.

Question: Can I abort an ongoing I2C bus transmission?

Is it okay to abort an on-going transmission any time.

According to the specification, this should work. It depends on the layout of the component. A real I2C compatible IC will be able to handle this. It might make sense to test this before you use it.

Usually, when a START or STOP condition is detected, the internal logic of the chip is forced into a certain state. Internally, the logic that detects START and STOP is different from the logic that does all other processing. The START together with the address register is to be considered as a functional unit inside the chip.

When a START is detected, all internal operations are cancelled and the chip will compare the incoming data with its own address.

When a STOP is detected, ALL chips on the bus will reset their internal logic to IDLE mode except for the START detector (this is also used to cut power consumption). Therefore, when a start condition is issued on the bus, the START detector will 'wake-up' the rest of the internal logic.

Question: Do I need to generate an ACK in read mode on the last byte? My chip starts sending data and occupies the bus...

This is a somewhat puzzling question. Indeed this is a bit strange. Usually, if you have read the last byte in a chip and generate an ACK, the chip should do nothing anymore, so the bus should be clear for you to create a STOP condition. Apparently, there are some chips that start transmitting data again. One such chip is the PCF 8574 I/O expander.

Though not always desirable, this feature can come in handy. If you need to sample incoming data fast, then you just continue reading from the chip. This prevents that you lose 'arbitration' of the bus in a multi-master environment.

It also speeds things up. You don't have to address the chip over and over again so you save the time for START, Address, ACK and STOP stage for every next byte read. This can lead to a more than doubled transfer rate.

Question: Why does the SCL line have to be bi-directional?

The clock line needs to be bi-directional when using a MULTI-MASTER protocol and when using the synchronization protocol.

When you are using only one Master then this is not required since the clock will always be generated by this device. If you run Multi-master then this changes. One master must be able to receive data from another master. At that time it must be able to receive clock information via the clock line also.

Question: How can I monitor the I2C bus?

There are a few commercial I2C monitor / debuggers around that can do this. Information on these devices can be found here.

There is another possibility to do this: By using the stand-alone I2C controller PCF8584 from Philips. This chip has a certain mode in which it does not take part in the real I2C action but only records what is going on. It listens to all addresses, but does not generate any acknowledge. Using some software routines and a MCU you could build a universal I2C data logger.

Question: How can I test / debug the I2C bus?

There is no general way to debug an I2C bus. However, a few guidelines might help to get it running.

First thing is to check the levels on the bus. You should see a clear signal that has a low level that is lower then 0.8 volt and a high level which is at least 3.5 volts.

If the high level is not high enough or does not rise fast enough then you can try to lower the value of the pull up resistor. You must take care however not to surpass the maximum allowable current in the I2C driver stage. The minimum allowable resistor for a 5 volt driven I2C bus is 5 V / 3mA = 1600 Ohms. A typical value of 4700 ohm should work fine.

Make sure the bus is not 'stuck' to '0'. This could be the result of a bad power supply (chips go into latch up during power-on) or a bad chip.

There are a few commercial I2C monitor / debuggers around. Information on these devices can be found here.

Question: Which microcontrollers do have an on-chip I2C interface?

A LOT of MCU's have a real I2C interface implemented in hardware, but this should not restrict the use of the I2C bus on other MCU's. ANY MCU can be made to talk to I2C using some small software routines.

There are microcontrollers with on-chip I2C modules as well as stand-alone I2C bus peripherals.

To list all the devices here would be impossible. A good overview can be found here: http://www.embeddedlinks.com/chipdir (search for keyword I2C)

Question: What bus speeds are available with I2C?

The bus speed for I2C was increased over the years. The following modes are available:

  • Standard mode, with a bit rate up to 100kbit/s
  • Fast-mode, with a bit rate up to 400 kbit/s
  • High-speed mode (Hs-mode), with a bit rate up to 3.4 Mbit/s

more questions

1. Given 2 4 bit nos, A= 1001, b= 1100
  • HOW DO YOU ExOR THEM using minimum number of gates?
  • how do you nand them?
  • how do your or them?
2. given a 4:1 functional generator how do you resolve a 5:1 functional generator using only 4:1 funtional generators? what happens to the unused inputs?

3. using a 4:1 mux how many 4:1 mux do you need to design a 8:1 mux?

Mux out of an XOR

Here is some background and a step to solve the problem:

A set of {+, . , '} is functionally complete because every function can be expressed by operations from this set.

By Demorgan's law can be shown that {+, '} is also functionally complete.
x . y = (x' + y')'

Same holds for {., '} because x + y = (x' . y')'

It can be shown that (x nor y) is also functionally complete:
x nor y = x' x' = x'
(x nor y) nor (x nor y) = (x'y') nor (x'y') = x + y

It can be shown for xor that: x' = x xor 1 , so the inverter is O.K., we need to show that (x + y) or even (x.y) can be built from xor. If we can do that then we are done. I have not found a way to do it yet, so the answer can be Not possible.

proof with new approach.

The question "can a mux be built from XOR only" is the same as "can an arbitrary logic function be implemented with XOR only", given that mux is universal. So, we only need to show that some simple function cannot be implemented (as a counterexample). Let's try AND.

Suppose x.y could be implemented with XOR only. Then x.y would be the output of some XOR gate in the circuit. Let's call the inputs of this XOR gate f(x,y) and g(x,y). The truth tables for f and g will look like:

x y f g
0 0 a a
0 1 b b
1 0 c c
1 1 d d'

If you expand this truth table to the 16 possible cases, you will see that either f or g will be an AND or OR function in each case. OR is basically an AND with complemented inputs and output; so, effectively, an AND function is needed to synthesize AND. This will go on ad infinitum, so the task is impossible. So, a mux cannot be built with XOR gates only.

Some recent interview questions

1.) You are adding 8 10-bit numbers. How many bits do you need for the result?
2.) You are adding two 2's-complement numbers together. One is 8 bits, the other is 4 bits. How do you handle the fact that the two numbers are not the same width?
3.) You have a free running clock. How would you design a divide by 3 circuit, duty cycle is not an issue.
4.) Describe the design of a FIFO circuit.
5.) Describe the design of a bus arbiter circuit.

Glitch in a combinational circuit and the way to avoid that.

A glitch resistive transition means, it is not possible to have any intermediate momentary values during output transition.

Consider the final logic gate in the below design, which is driving the output "O", "D" ns is propagation delay of the gate

d1 _____________
I1 -------| Final Logic |
|| Gate |--------- O
I2 -------|_____________|
logic & routing delay of I1 = d1
logic & routing delay of I2 = d2
Say d1 > d2; Skew d = d1-d2

Case 1:
No skew between the inputs I1 & I2 (d1 = d2)
* There will not be any GLITCHES at output.
* Output will be ready after D ns from an input change.

Case 2:
There is a skew "d" ns between the inputs I1 & I2 (the difference in logic and routing delay from the driving point cause the skew) (d1 != d2)
* Output will be settled after "d+D" ns from an input change.
* Outputs at "D to d+D" ns from an input change can have momentry unwanted vales (GLITCHES)

Solution 1
Keep the skew between the inputs as zero (no skew) for the output driving logic gate (Similar to Case 1).
Solution 2
Register the combinational output, so that the stable output can sample and hold it until an another stable output comes.
Register "O" with a sampling period "T" ns such that {d1 + D + Tsetup(of flip flop)} < T

Why "FOR LOOP" is not advisable

Why "FOR LOOP" is not advisable to code in RTL eventhough it is synthesizable?

I agree with this explanation. The thing you MUST remember when coding any RTL for synthesis is that you are designing logic, not running software on a processor. Way to often I see individuals treating RTL like it is serially executed code running on a processor. This type of code usually results in very poor synthesis and timing results. When I am given code like this to work on, usually after someone has designed something poorly, it usually gets thrown in the trash and redesigned. So, even though a software like construct exists in RTL and it "may" be synthesizable and simulate the desired function, that does not mean one should use it.

When coding RTL, you should really think about what you are trying to design in hardware, not necessarily how to code a function using the software constructs of RTL. After you know what the desired hardware function is, then code the RTL to implement that function. What you should do to answer your question is ask yourself what hardware am I trying to create, and will this for loop create it. I recommend an excellent book that covers a lot of coding techniques for various hardware functions in VHDL and Verilog. It is "HDL Chip Design. A practical guide for designing, synthesizing and simulating ASICs and FPGAs using VHDL or Verilog" by Douglas J. Smith. I consider this book a must have for front end design. It has many examples of good and bad code.

though synthesizable but it is not too friendly in terms of resources as well as synthesis time. If it is a small loop it may be ok, but if it is a big one..or loop inside loop then syntheis tool first have to unroll the whole logic and do the implementation..which may not always provide good quality of result both in terms of timing + area. Thats why "for" loop is preferred only for Testbench and not for RTL..but at the same time it is used for selective cases in RTL too.

Setup Time & Hold Time - By popular demand

a) Generally speaking SETUP fixing is always DIFFICULT. This can be resolved by inserting buffers (as you mentioned) only in cases where
the SETUP violation is because of large load/slew violations which causes huge delays in combinatorial blocks. say there is an AND gate which is driving much more loads than it should and you see A to Y delay for that 3ns. Now this load violation can be fixed by adding a buffer after the AND gate and you may see now the AND gate has aonly 1.5ns and BUFFER added 0.3ns. Thus you gain 1.8ns in data path. To see if load/slew violations are causing your SETUP failure see report_timing with -cap -tran (assuming you annoate set_load or SPEF file also while doing STA). But if load/slew is NOT the culprit..then it is indeed tough to fix SETUP and you may need to revisit the logic structure between the flops.

b) HOLD fixing is comparatively far easy. Simply by adding buffers in the data path. There are lots of automated scripts and even DC can do that with -fix_hold. This is generally done at the last stage after the CLK routing has been done.

c) I would say both are equally IMPORTANT and any one of them is sufficient enough to cause a RESPIN :-(

Finally MOST important thing to remember always is SETUP is frequency dependent..while HOLD is NOT!

Note: This is generally true if you use only +ve edge clocking. If you mix both +ve and -ve edges in your design, then hold time also has a frequency dependency.

Logic Density

Find the resource elements consumed during design stage that is before RTL coding.Is it necessarily needed to draw the low level gate elements to calculate the logic gate consumption..I don't think designers go for detailed low level diagrams to calculate the resource utilisation. Then how to approximately find the resources used in design?
Ans: The main purpose of this exercise is generally to find the number of Flops (or the synchronous elements) in the logic. Even before RTL coding one can get some basic ideas about the flops by guessing state elements, number of registers for counters, retime blocks etc. Then based on the type of circuitry we try to guess how much combinatorial logic will be there between per flops (eg for pipeline design , it will be
less) thats again some percentage of sequential elements. At this stage we dont try to include buffers/inverters for load or different fanouts. etc. They can be all part of the combinatorial logic.

At last an approximate number can be inferred giving the number of gates (depending upon technology library) for the RTL module.

Negative hold time

Negative hold time is generally seen where a delay is already added in the data path inside the flop. This is usually done by the library vendor.

Assume the flop which foundry gives us as a library part that has ports named as CLK-port, Data-port. Now, in essence this is wrapper and should be treated as one. Inside this we have the actual flop whose ports are CLK-in, data-in. CLK-port is connected directly to CLK-in, Data-port goes through some delay element (either buffer or routing net) to Data-in. So even if the actual flop has hold requirement of say 0.2ns, if the data delay element value is 0.5ns, the library will give spec as -0.3ns HOLD requirement for the above flop. This signifies that even if the data changes 0.3ns before CLK, it can still be latched and as for the actual flop(inside the wrapper) it will still meet 0.2ns HOLD. (data changes after 0.2ns from clk change).

The biggest advantage is less iteration after layout...
Easy and less painful synthesis (else HOLD fixing can be an iterative process)

We pay the cost in bigger setup times for above flops.