From: y_p_w@hotmail.com (y_p_w) Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Q: regarding I2C protocols Date: 23 Jun 2003 10:37:40 -0700 Organization: http://groups.google.com/ Lines: 23 Message-ID: <591da479.0306230937.42883d68@posting.google.com> NNTP-Posting-Host: 66.134.94.158 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1056389860 20384 127.0.0.1 (23 Jun 2003 17:37:40 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Jun 2003 17:37:40 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29862 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. Thanks in advance. ###### Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga From: Wolfgang Denk Subject: Re: Q: regarding I2C protocols X-Newsreader: NN version 6.5.6 Sender: wd@denx.muc.de (wd) Organization: DENX Software Engineering, Germany Message-ID: References: <591da479.0306230937.42883d68@posting.google.com> Date: Mon, 23 Jun 2003 20:40:11 GMT Lines: 19 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!news.space.net!news.muc.de!denx!wd Xref: chonsp.franklin.ch comp.arch.fpga:29884 y_p_w@hotmail.com (y_p_w) writes: >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. Anything can happen. Please consider combinations of fast CPUs and sudden power-loss or reset in _all_ phases of the protocol. Remember for example the "I2C Edge Conditions" problem. Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de I have often regretted my speech, never my silence. ###### Message-ID: <3EF77D24.605C@designtools.co.nz> From: Jim Granville Reply-To: jim.granville@designtools.co.nz Organization: Mandeno Granville elect X-Mailer: Mozilla 3.0C-XTRA (Win95; I) MIME-Version: 1.0 Newsgroups: comp.arch.fpga Subject: Re: Q: regarding I2C protocols References: <591da479.0306230937.42883d68@posting.google.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 33 Date: Tue, 24 Jun 2003 10:20:20 +1200 NNTP-Posting-Host: 203.96.156.10 X-Complaints-To: abuse@tsnz.net X-Trace: news02.tsnz.net 1056406801 203.96.156.10 (Tue, 24 Jun 2003 10:20:01 NZST) NNTP-Posting-Date: Tue, 24 Jun 2003 10:20:01 NZST Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!enews.sgi.com!news-out.superfeed.net!propagator2-maxim!news-in-maxim.spamkiller.net!news02.tsnz.net!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29880 y_p_w wrote: > > 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. > > Thanks in advance. Since this is also a possible noise condition, then yes, your logic certainly should cope with this. Normally it would, as the Start/Stop have highest priority, and 'the most recent one' would be expected to prevail. -jg ###### From: "Tauno Voipio" Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga References: <591da479.0306230937.42883d68@posting.google.com> Subject: Re: regarding I2C protocols Lines: 39 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <27HJa.326$4q6.117@read3.inet.fi> Date: Mon, 23 Jun 2003 17:51:58 GMT NNTP-Posting-Host: 80.222.87.113 X-Complaints-To: abuse@inet.fi X-Trace: read3.inet.fi 1056390718 80.222.87.113 (Mon, 23 Jun 2003 20:51:58 EEST) NNTP-Posting-Date: Mon, 23 Jun 2003 20:51:58 EEST Organization: Sonera corp Internet services Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!news-stoc.telia.net!news-stoa.telia.net!telia.net!nntp.inet.fi!central.inet.fi!inet.fi!read3.inet.fi.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29853 "y_p_w" wrote in message news:591da479.0306230937.42883d68@posting.google.com... > 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. HTH Tauno Voipio tauno voipio @ iki fi ###### From: rickman Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: Mon, 23 Jun 2003 14:20:43 -0400 Organization: Arius, Inc Lines: 57 Message-ID: <3EF744FB.AF2FB36E@yahoo.com> References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZx3mObFHGnBpphMORcDtXzWLkfayfC+1Q7J/pAS27vJl88mYDBIqUZ X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Jun 2003 18:20:22 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29849 Tauno Voipio wrote: > > "y_p_w" wrote in message > news:591da479.0306230937.42883d68@posting.google.com... > > 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. -- Rick "rickman" Collins rick.collins@XYarius.com 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 ###### From: "Tauno Voipio" Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> Subject: Re: regarding I2C protocols Lines: 58 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: <5LHJa.361$4q6.102@read3.inet.fi> Date: Mon, 23 Jun 2003 18:34:41 GMT NNTP-Posting-Host: 80.222.87.113 X-Complaints-To: abuse@inet.fi X-Trace: read3.inet.fi 1056393281 80.222.87.113 (Mon, 23 Jun 2003 21:34:41 EEST) NNTP-Posting-Date: Mon, 23 Jun 2003 21:34:41 EEST Organization: Sonera corp Internet services Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!news-stoc.telia.net!news-stoa.telia.net!telia.net!nntp.inet.fi!central.inet.fi!inet.fi!read3.inet.fi.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29854 "rickman" wrote in message news:3EF744FB.AF2FB36E@yahoo.com... > Tauno Voipio wrote: > > > > "y_p_w" wrote in message > > news:591da479.0306230937.42883d68@posting.google.com... > > > 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 ###### From: rickman Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: Mon, 23 Jun 2003 17:42:37 -0400 Organization: Arius, Inc Lines: 80 Message-ID: <3EF7744D.1CF9F6D@yahoo.com> References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZrJ4l20AD3H5e7aP2xmRHguh2eyfVzMYBQTkIWN5NS3qIO4Tmz2i/H X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 23 Jun 2003 21:42:37 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.ifi.unizh.ch!news.imp.ch!news.imp.ch!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29892 Tauno Voipio wrote: > > "rickman" wrote in message > news:3EF744FB.AF2FB36E@yahoo.com... > > Tauno Voipio wrote: > > > > > > "y_p_w" wrote in message > > > news:591da479.0306230937.42883d68@posting.google.com... > > > > 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 rick.collins@XYarius.com 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 ###### From: "carel harmsen" Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: Mon, 23 Jun 2003 23:43:29 +0200 Organization: Planet Internet Lines: 96 Message-ID: References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> NNTP-Posting-Host: ipc379ce13.dial.hetnet.nl X-Trace: reader11.wxs.nl 1056401703 8738 195.121.206.19 (23 Jun 2003 20:55:03 GMT) X-Complaints-To: abuse@planet.nl NNTP-Posting-Date: 23 Jun 2003 20:55:03 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!skynet.be!skynet.be!213.51.129.3.MISMATCH!newshub1.home.nl!home.nl!newsfeed.multikabel.nl!newsfeed.wxs.nl!textnews.wxs.nl!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29879 "Tauno Voipio" wrote in message news:5LHJa.361$4q6.102@read3.inet.fi... > > "rickman" wrote in message > news:3EF744FB.AF2FB36E@yahoo.com... > > Tauno Voipio wrote: > > > > > > "y_p_w" wrote in message > > > news:591da479.0306230937.42883d68@posting.google.com... > > > > 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 > > Hi, I have done this with a Lattice 1016 (64 registers) The start condition, SCL high and SDA falling is to put the device in lets call it "address compare mode", if the address (Bit 1-7) matches the device goes into "read or write mode" depending on bit0 , otherwise the "I'm not interested mode", i.e. the "not address compare mode" and "not read read or write mode" This is determined at the rising edge of the 9th SCL pulse. So the start condition is a mode reset command. Note that controllers like the PCF8584 have slow rising and falling signals. Your FPGA will be ways too fast for this, so you will have to register the signals to determine the transitions. Example: clock speed 1Mhz (actual speed) SCL2 = SCL1 = SCL Not_SCL2 And SCL1 = transitionevent Tip: in read/write mode where the 9th SCL pulse is used for ACK generation you can also use the rising edge to generate a read or write pulse to communicate with a device. With this you can have a continuous 8-bit data stream into or from the device. Ideal for a graphical LCD-display (and whenever there is a connection with a high frequency and a low frequency device) Carel Harmsen ###### From: y_p_w@hotmail.com (y_p_w) Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: 23 Jun 2003 16:12:36 -0700 Organization: http://groups.google.com/ Lines: 74 Message-ID: <591da479.0306231512.415e28d0@posting.google.com> References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> NNTP-Posting-Host: 66.134.94.158 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1056409956 31619 127.0.0.1 (23 Jun 2003 23:12:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 23 Jun 2003 23:12:36 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29886 "Tauno Voipio" wrote in message news:<5LHJa.361$4q6.102@read3.inet.fi>... > "rickman" wrote in message > news:3EF744FB.AF2FB36E@yahoo.com... > > Tauno Voipio wrote: > > > > > > "y_p_w" wrote in message > > > news:591da479.0306230937.42883d68@posting.google.com... > > > > 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 Thanks for the answer. I actually re-read the spec, and noticed that a STOP following a START in the same SCL high period is illegal. I'm going to ignore an illegally applied STOP (i.e. illegal STOP ignored). I was also worried about the possibility of repeated STOP/ START/STOP/START sequences. However - as a follow-up question, would it be possible to see SCL toggle after a STOP before the next START command "in the real world"? None of the timing diagrams in the spec seem to address this possibility; all diagrams show SDA and SCL staying high for the foreseeable future. I'd guess that the thing to do is simply put put the I2C slave in a wait state until a START condition is seen. I wouldn't see any reason to toggle SCL between a STOP and the next START, but I haven't seen any real-world designs. Again - many thanks for the replies. ###### From: y_p_w@hotmail.com (y_p_w) Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: 24 Jun 2003 00:51:06 -0700 Organization: http://groups.google.com/ Lines: 101 Message-ID: <591da479.0306232351.4e296200@posting.google.com> References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <3EF7744D.1CF9F6D@yahoo.com> NNTP-Posting-Host: 216.175.101.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1056441066 12996 127.0.0.1 (24 Jun 2003 07:51:06 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 24 Jun 2003 07:51:06 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.icl.net!newsfeed.fjserv.net!news.maxwell.syr.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29908 rickman wrote in message news:<3EF7744D.1CF9F6D@yahoo.com>... > Tauno Voipio wrote: > > > > "rickman" wrote in message > > news:3EF744FB.AF2FB36E@yahoo.com... > > > Tauno Voipio wrote: > > > > > > > > "y_p_w" wrote in message > > > > news:591da479.0306230937.42883d68@posting.google.com... > > > > > 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. ###### From: "Gerard" Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <591da479.0306231512.415e28d0@posting.google.com> Subject: Re: regarding I2C protocols Date: Tue, 24 Jun 2003 12:49:45 +0200 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Lines: 46 Message-ID: <3ef82cdb$0$49110$e4fe514c@news.xs4all.nl> NNTP-Posting-Date: 24 Jun 2003 12:50:03 CEST NNTP-Posting-Host: 213.84.77.40 X-Trace: 1056451803 news.xs4all.nl 49110 213.84.77.40:16472 X-Complaints-To: abuse@xs4all.nl Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!news-ge.switch.ch!switch.ch!news.belwue.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.stueberl.de!newspeer1-gui.server.ntli.net!ntli.net!news2.euro.net!transit.news.xs4all.nl!newsfeed.xs4all.nl!xs4all!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29903 > > Thanks for the answer. I actually re-read the spec, and noticed > that a STOP following a START in the same SCL high period is illegal. > I'm going to ignore an illegally applied STOP (i.e. illegal STOP > ignored). I was also worried about the possibility of repeated STOP/ > START/STOP/START sequences. > > However - as a follow-up question, would it be possible to see SCL > toggle after a STOP before the next START command "in the real world"? > None of the timing diagrams in the spec seem to address this > possibility; all diagrams show SDA and SCL staying high for the > foreseeable future. I'd guess that the thing to do is simply put > put the I2C slave in a wait state until a START condition is seen. I > wouldn't see any reason to toggle SCL between a STOP and the next > START, but I haven't seen any real-world designs. > > Again - many thanks for the replies. Hi Well that's what really matters (IHO), "the real world". And in the real world everything is possible. You can have a lousy implemented micro-controller software I2C or even if you are debugging the hardware you can accidentally toggle a line. I know applications where they misuse the spec and by driving the SCL low between STOP and START for a certain time, they signal other devices for example busmaster takeover. Everything is possible. If you are designing this for a real application you have to deal with the real world and you must handle all the situations you can think off. It's very clumsy if your hardware is 'hanging'. Master controllers are build by spec's and slaves by sense. Gerard www.stacktools.com ###### From: rickman Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: Tue, 24 Jun 2003 10:32:38 -0400 Organization: Arius, Inc Lines: 75 Message-ID: <3EF86106.BCB1DCB@yahoo.com> References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <3EF7744D.1CF9F6D@yahoo.com> <591da479.0306232351.4e296200@posting.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: UmFuZG9tSVZVW+ft7goqrzJBrGLUIXg2mq2QO7jHQN6HhHJBWYLHa3tnSioxAfa6 X-Complaints-To: abuse@rcn.com NNTP-Posting-Date: 24 Jun 2003 14:32:53 GMT X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!feed1.news.rcn.net!rcn!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29944 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 rick.collins@XYarius.com 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 ###### Message-ID: <3EF87139.36651031@yahoo.com> From: CBFalconer Reply-To: cbfalconer@worldnet.att.net Organization: Ched Research X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <3EF7744D.1CF9F6D@yahoo.com> <591da479.0306232351.4e296200@posting.google.com> <3EF86106.BCB1DCB@yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Lines: 82 Date: Tue, 24 Jun 2003 16:41:05 GMT NNTP-Posting-Host: 12.90.174.31 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1056472865 12.90.174.31 (Tue, 24 Jun 2003 16:41:05 GMT) NNTP-Posting-Date: Tue, 24 Jun 2003 16:41:05 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!wn14feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29943 rickman wrote: > 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. 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. I seem to vaguely recall that I2C is a collision detection and backoff system with priority determined by addresses, operating at baseband. -- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. USE worldnet address! ###### From: "Tauno Voipio" Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <3EF7744D.1CF9F6D@yahoo.com> <591da479.0306232351.4e296200@posting.google.com> <3EF86106.BCB1DCB@yahoo.com> <3EF87139.36651031@yahoo.com> Subject: Re: regarding I2C protocols Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Message-ID: Date: Tue, 24 Jun 2003 16:52:59 GMT NNTP-Posting-Host: 80.222.87.113 X-Complaints-To: abuse@inet.fi X-Trace: read3.inet.fi 1056473579 80.222.87.113 (Tue, 24 Jun 2003 19:52:59 EEST) NNTP-Posting-Date: Tue, 24 Jun 2003 19:52:59 EEST Organization: Sonera corp Internet services Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!newsfeed.stueberl.de!news-stoc.telia.net!news-stoa.telia.net!telia.net!nntp.inet.fi!central.inet.fi!inet.fi!read3.inet.fi.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29922 "CBFalconer" wrote in message news:3EF87139.36651031@yahoo.com... (-- 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 ###### From: y_p_w@hotmail.com (y_p_w) Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga Subject: Re: regarding I2C protocols Date: 24 Jun 2003 10:41:51 -0700 Organization: http://groups.google.com/ Lines: 80 Message-ID: <591da479.0306240941.345e6902@posting.google.com> References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <3EF7744D.1CF9F6D@yahoo.com> <591da479.0306232351.4e296200@posting.google.com> <3EF86106.BCB1DCB@yahoo.com> NNTP-Posting-Host: 66.134.94.158 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1056476511 30830 127.0.0.1 (24 Jun 2003 17:41:51 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 24 Jun 2003 17:41:51 GMT Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!cyclone.bc.net!newsfeed.stanford.edu!postnews1.google.com!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29935 rickman wrote in message news:<3EF86106.BCB1DCB@yahoo.com>... > 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 ###### From: "kryten_droid" Newsgroups: comp.lang.verilog,comp.lang.vhdl,comp.arch.embedded,comp.arch.fpga References: <591da479.0306230937.42883d68@posting.google.com> <27HJa.326$4q6.117@read3.inet.fi> <3EF744FB.AF2FB36E@yahoo.com> <5LHJa.361$4q6.102@read3.inet.fi> <3EF7744D.1CF9F6D@yahoo.com> <591da479.0306232351.4e296200@posting.google.com> <3EF86106.BCB1DCB@yahoo.com> <591da479.0306240941.345e6902@posting.google.com> Subject: Re: regarding I2C protocols Lines: 5 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: Date: Tue, 24 Jun 2003 23:09:40 +0100 NNTP-Posting-Host: 62.253.144.31 X-Complaints-To: abuse@ntlworld.com X-Trace: newsfep2-win.server.ntli.net 1056492656 62.253.144.31 (Tue, 24 Jun 2003 23:10:56 BST) NNTP-Posting-Date: Tue, 24 Jun 2003 23:10:56 BST Organization: ntlworld News Service Path: chonsp.franklin.ch!pfaff.ethz.ch!news-zh.switch.ch!switch.ch!news.mailgate.org!nntp.infostrada.it!newsfeed01.sul.t-online.de!t-online.de!newspeer1-gui.server.ntli.net!ntli.net!newsfep2-win.server.ntli.net.POSTED!53ab2750!not-for-mail Xref: chonsp.franklin.ch comp.arch.fpga:29917 Opencores and Xilinx have VHDL I2C code that might be of use. Though of course there is no warranty on its correctness.