Re: regarding I2C protocols

Discussion in 'VHDL' started by rickman, Jun 23, 2003.

  1. rickman

    rickman Guest

    Tauno Voipio wrote:
    >
    > "rickman" <> wrote in message
    > news:...
    > > Tauno Voipio wrote:
    > > >
    > > > "y_p_w" <> wrote in message
    > > > news:...
    > > > > Hi-
    > > > >
    > > > > I'm currently in the process of creating a synthesizable Verilog
    > > > > F/S I2C slave, but have little experience with I2C in the real
    > > > > world.
    > > > >
    > > > > I'm reading the specs, and I feel I'm getting a pretty good
    > > > > understanding. If I'm getting this right, the SDA line will only
    > > > > change when the SCL line is low - except when the master is
    > > > > indicating a START or STOP command.
    > > > >
    > > > > So the question I have for those who have really done this is -
    > > > > in the real world, could a master (or series of masters) issue
    > > > > a STOP command followed by a START command - all on the same
    > > > > SCL high period. The latest I2C spec doesn't explain whether
    > > > > or not this could happen.
    > > > >
    > > > > This is key to me, since I'm trying to create an I2C slave that
    > > > > runs solely off the SDA and SCL signals. Whether or not I have
    > > > > to deal with START and STOP on the same SCL high period will
    > > > > impact the design choice I make.
    > > > >
    > > >
    > > > AFAIK, that's normal when the bus is idle in the meantime.
    > > >
    > > > The idle bus has all drivers loose and both lines up. When the master

    > ends a
    > > > transmission, the last thing is the STOP condition: SCL up, then SDA up.
    > > > When the next transmission starts, the first thing is the START

    > condition:
    > > > SCL still up, SDA down.

    > >
    > > I think he means the other way around, a START followed by a STOP with
    > > no clock transitions inbetween. In essence, this would be an "empty"
    > > frame.
    > >
    > > I have not worked with I2C before, so I don't know the answer. But I am
    > > interested since I will be making one as well.
    > >
    > > I have not checked opencores.org, but it seems likely that they would
    > > have a core for this. It might be a bit larger than you would want to
    > > use however.
    > >

    >
    > An empty frame is expressely forbidden in the specs. However, the logic must
    > still not hang up if such a condition should happen.
    >
    > Tauno Voipio
    > tauno voipio @ iki fi


    I guess that is the answer then. The condition should not occur, but if
    it does due to a defect in one component, it should not cause a problem
    in another component.


    To the OP,

    How does this change your design? I would think an empty frame would be
    handled like one that is not addressed to your device, no?

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
    rickman, Jun 23, 2003
    #1
    1. Advertising

  2. rickman

    y_p_w Guest

    rickman <> wrote in message news:<>...
    > Tauno Voipio wrote:
    > >
    > > "rickman" <> wrote in message
    > > news:...
    > > > Tauno Voipio wrote:
    > > > >
    > > > > "y_p_w" <> wrote in message
    > > > > news:...
    > > > > > Hi-
    > > > > >
    > > > > > I'm currently in the process of creating a synthesizable Verilog
    > > > > > F/S I2C slave, but have little experience with I2C in the real
    > > > > > world.
    > > > > >
    > > > > > I'm reading the specs, and I feel I'm getting a pretty good
    > > > > > understanding. If I'm getting this right, the SDA line will only
    > > > > > change when the SCL line is low - except when the master is
    > > > > > indicating a START or STOP command.
    > > > > >
    > > > > > So the question I have for those who have really done this is -
    > > > > > in the real world, could a master (or series of masters) issue
    > > > > > a STOP command followed by a START command - all on the same
    > > > > > SCL high period. The latest I2C spec doesn't explain whether
    > > > > > or not this could happen.
    > > > > >
    > > > > > This is key to me, since I'm trying to create an I2C slave that
    > > > > > runs solely off the SDA and SCL signals. Whether or not I have
    > > > > > to deal with START and STOP on the same SCL high period will
    > > > > > impact the design choice I make.
    > > > > >
    > > > >
    > > > > AFAIK, that's normal when the bus is idle in the meantime.
    > > > >
    > > > > The idle bus has all drivers loose and both lines up. When the master

    > ends a
    > > > > transmission, the last thing is the STOP condition: SCL up, then SDA up.
    > > > > When the next transmission starts, the first thing is the START

    > condition:
    > > > > SCL still up, SDA down.
    > > >
    > > > I think he means the other way around, a START followed by a STOP with
    > > > no clock transitions inbetween. In essence, this would be an "empty"
    > > > frame.
    > > >
    > > > I have not worked with I2C before, so I don't know the answer. But I am
    > > > interested since I will be making one as well.
    > > >
    > > > I have not checked opencores.org, but it seems likely that they would
    > > > have a core for this. It might be a bit larger than you would want to
    > > > use however.
    > > >

    > >
    > > An empty frame is expressely forbidden in the specs. However, the logic must
    > > still not hang up if such a condition should happen.
    > >
    > > Tauno Voipio
    > > tauno voipio @ iki fi

    >
    > I guess that is the answer then. The condition should not occur, but if
    > it does due to a defect in one component, it should not cause a problem
    > in another component.
    >
    >
    > To the OP,
    >
    > How does this change your design? I would think an empty frame would be
    > handled like one that is not addressed to your device, no?


    Well - here's my concerns and thinking:

    1) It seems that the preferred method is to have a STOP condition
    (SDA rising when SCL=1) on the same SCL high period as a START
    period (SDA falling when SCL=1). This would look like this:
    _________________________
    SCL ___| |_____
    _________________
    SDA _______| |_________

    2) As far as I can tell the spec says nothing about SCL changing
    between a STOP and START. I wouldn't see any advantage to it,
    but I couldn't sense it was illegal. I would suppose any
    clock toggling before a START should just be ignored until a
    START is detected.

    3) I was worried about whether a master could "change its mind"
    after issuing a start if it was suddenly occupied with something
    considered more important. Fortunately, this doesn't seem to
    be a problem.

    4) Most of what I'm planning is a straightforward FSM clocked on
    the negedge of SCL. The START and STOP logic I'm planning on
    using isn't as straightforward. This was the part that would
    have been messed up if I had to account for multiple START or
    STOP methods. I wanted to create a START detected signal, and
    use that to tell the FSM when to start monitoring SDA.

    5) I could possibly use a high-speed internal clock. However -
    the goal is a low-power design, and I was told that just
    toggling the clock tree would create unnecessary power
    consumption.
    y_p_w, Jun 24, 2003
    #2
    1. Advertising

  3. rickman

    rickman Guest

    y_p_w wrote:
    >
    > Well - here's my concerns and thinking:
    >
    > 1) It seems that the preferred method is to have a STOP condition
    > (SDA rising when SCL=1) on the same SCL high period as a START
    > period (SDA falling when SCL=1). This would look like this:
    > _________________________
    > SCL ___| |_____
    > _________________
    > SDA _______| |_________
    >
    > 2) As far as I can tell the spec says nothing about SCL changing
    > between a STOP and START. I wouldn't see any advantage to it,
    > but I couldn't sense it was illegal. I would suppose any
    > clock toggling before a START should just be ignored until a
    > START is detected.
    >
    > 3) I was worried about whether a master could "change its mind"
    > after issuing a start if it was suddenly occupied with something
    > considered more important. Fortunately, this doesn't seem to
    > be a problem.
    >
    > 4) Most of what I'm planning is a straightforward FSM clocked on
    > the negedge of SCL. The START and STOP logic I'm planning on
    > using isn't as straightforward. This was the part that would
    > have been messed up if I had to account for multiple START or
    > STOP methods. I wanted to create a START detected signal, and
    > use that to tell the FSM when to start monitoring SDA.
    >
    > 5) I could possibly use a high-speed internal clock. However -
    > the goal is a low-power design, and I was told that just
    > toggling the clock tree would create unnecessary power
    > consumption.


    I have not given this a lot of thought, but I believe you can use two
    FFs (with resets) to detect the start/stop conditions and maintain a
    state of disabled/enabled.

    The start FF is clocked on the falling edge of SDA with SCL on the D
    input. This FF will be set on a start condition. The stop FF will be
    clocked on the rising edge of SDA with SCL on the D input. This FF will
    be set on the stop condition. The start FF being off will hold the stop
    FF in reset. The stop FF being set will reset the start FF. So the
    sequence will be;

    1) both FFs clear
    2) on start, the start FF is set and the rest of the circuit is enabled
    3) on stop, the stop FF is set which clears the start FF
    4) the start FF being cleared also clears the stop FF

    The only issue I can see with this design is that the stop FF will
    generate a reset pulse determined by the time it takes to reset both FFs
    plus the routing. Some people would object to this saying it may
    violate the timing requirements of your logic. If so, you may want to
    use the LUT or the OR array with the FF to add some extra delay. In
    general this should work ok since it is basically self timed logic.

    On the other hand, using a synchronous design should not consume much
    power. Unless you are going for power below 100 uA, a low power CPLD
    (like the coolrunner) should be able to run at 1 MHz (fast enough for
    most I2C chips at 400 kb/s) with power at that level.

    --

    Rick "rickman" Collins


    Ignore the reply address. To email me use the above address with the XY
    removed.

    Arius - A Signal Processing Solutions Company
    Specializing in DSP and FPGA design URL http://www.arius.com
    4 King Ave 301-682-7772 Voice
    Frederick, MD 21701-3110 301-682-7666 FAX
    rickman, Jun 24, 2003
    #3
  4. rickman

    Tauno Voipio Guest

    "CBFalconer" <> wrote in message
    news:...
    (-- most clipped, TV --)

    >
    > I know nothing about the actual details of this protocol, but it
    > seems to me that something is off the rails. Just the signal
    > names suggest SerialData and SerialClock. Some edge of SCL must
    > capture the state of SDA. The above protocol suggests that SDA
    > can only change while SCL is high, However that conflicts with
    > the idea that particular transitions on SDA during SCL high are of
    > special significance, such as message framing.


    In actual data transmission it's not allowed to change the data when the
    clock is high. The start and stop conditions are distinguished from normal
    data bits by breaking the data transfer protocol here.

    > I seem to vaguely recall that I2C is a collision detection and
    > backoff system with priority determined by addresses, operating at
    > baseband.


    Yes - the contention is taken care by the open-drain/collector nature of the
    bus. The master seeing its output clamped down by another master has to
    backoff.

    There is a similar method to synchronise the clocks: any station feeling
    that the things are going too fast is allowed to extend the clock-down time
    by clamping it. The sending station has to honour the clock clamp and wait.

    HTH

    Tauno Voipio
    tauno voipio @ iki fi
    Tauno Voipio, Jun 24, 2003
    #4
  5. rickman

    y_p_w Guest

    rickman <> wrote in message news:<>...
    > y_p_w wrote:
    > >
    > > Well - here's my concerns and thinking:
    > >
    > > 1) It seems that the preferred method is to have a STOP condition
    > > (SDA rising when SCL=1) on the same SCL high period as a START
    > > period (SDA falling when SCL=1). This would look like this:
    > > _________________________
    > > SCL ___| |_____
    > > _________________
    > > SDA _______| |_________
    > >
    > > 2) As far as I can tell the spec says nothing about SCL changing
    > > between a STOP and START. I wouldn't see any advantage to it,
    > > but I couldn't sense it was illegal. I would suppose any
    > > clock toggling before a START should just be ignored until a
    > > START is detected.
    > >
    > > 3) I was worried about whether a master could "change its mind"
    > > after issuing a start if it was suddenly occupied with something
    > > considered more important. Fortunately, this doesn't seem to
    > > be a problem.
    > >
    > > 4) Most of what I'm planning is a straightforward FSM clocked on
    > > the negedge of SCL. The START and STOP logic I'm planning on
    > > using isn't as straightforward. This was the part that would
    > > have been messed up if I had to account for multiple START or
    > > STOP methods. I wanted to create a START detected signal, and
    > > use that to tell the FSM when to start monitoring SDA.
    > >
    > > 5) I could possibly use a high-speed internal clock. However -
    > > the goal is a low-power design, and I was told that just
    > > toggling the clock tree would create unnecessary power
    > > consumption.

    >
    > I have not given this a lot of thought, but I believe you can use two
    > FFs (with resets) to detect the start/stop conditions and maintain a
    > state of disabled/enabled.
    >
    > The start FF is clocked on the falling edge of SDA with SCL on the D
    > input. This FF will be set on a start condition. The stop FF will be
    > clocked on the rising edge of SDA with SCL on the D input. This FF will
    > be set on the stop condition. The start FF being off will hold the stop
    > FF in reset. The stop FF being set will reset the start FF. So the
    > sequence will be;
    >
    > 1) both FFs clear
    > 2) on start, the start FF is set and the rest of the circuit is enabled
    > 3) on stop, the stop FF is set which clears the start FF
    > 4) the start FF being cleared also clears the stop FF


    I had something a little different, but not far off from your suggestion.
    Think masking off one signal with the other.

    > The only issue I can see with this design is that the stop FF will
    > generate a reset pulse determined by the time it takes to reset both FFs
    > plus the routing. Some people would object to this saying it may
    > violate the timing requirements of your logic. If so, you may want to
    > use the LUT or the OR array with the FF to add some extra delay. In
    > general this should work ok since it is basically self timed logic.
    >
    > On the other hand, using a synchronous design should not consume much
    > power. Unless you are going for power below 100 uA, a low power CPLD
    > (like the coolrunner) should be able to run at 1 MHz (fast enough for
    > most I2C chips at 400 kb/s) with power at that level.


    I won't go into the proprietary details, but I'm doing this work for an
    SoC design that might be battery powered in some applications. My boss
    is keen on reducing power consumption during a standby mode.

    I also apologize if I don't get into specifics about my planned design
    that might explain my problems. As with many in these NG's, I work at
    a large company that considers the product I produce confidential. If
    this works well, I (personally) wouldn't be averse to submitting this
    as an open source Verilog block. However - I'd have to make sure this
    is OK with my employer.

    Yu-Ping Wang
    Berkeley, California
    y_p_w, Jun 24, 2003
    #5
  6. rickman

    kryten_droid Guest

    Opencores and Xilinx have VHDL I2C code that might be of use.
    Though of course there is no warranty on its correctness.
    kryten_droid, Jun 24, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. carel harmsen

    Re: regarding I2C protocols

    carel harmsen, Jun 23, 2003, in forum: VHDL
    Replies:
    0
    Views:
    2,152
    carel harmsen
    Jun 23, 2003
  2. Wolfgang Denk

    Re: Q: regarding I2C protocols

    Wolfgang Denk, Jun 23, 2003, in forum: VHDL
    Replies:
    0
    Views:
    2,374
    Wolfgang Denk
    Jun 23, 2003
  3. y_p_w

    Re: regarding I2C protocols

    y_p_w, Jun 24, 2003, in forum: VHDL
    Replies:
    1
    Views:
    3,145
    Gerard
    Jun 24, 2003
  4. kryten_droid

    Re: regarding I2C protocols

    kryten_droid, Jun 24, 2003, in forum: VHDL
    Replies:
    0
    Views:
    2,028
    kryten_droid
    Jun 24, 2003
  5. yamadora1999
    Replies:
    2
    Views:
    470
    yamadora1999
    May 25, 2005
Loading...

Share This Page