Re: [oc] I2C: help with ack timing

[Tom Loftus <tloftus@intrinsix.com>]

Richard,

Yes, that is precisely the problem I am seeing.

Is this problem documented on the web site
somewhere?  It would have saved me some time
if a known problem was listed there.

I played around with the generation of the cmd_ack
signal but couldn't seem to get it quite right.
For now, I have concluded that there needs to
be two signals.  1) the existing cmd_ack which says 
that the command passed into the bit_ctrl machine has
been recognized. 2) a data_valid signal which
indicates that the ack value or the byte value
from the outside has been captured.

My fix right now is to add this second signal which
I called data_valid which is set by the low level
bit_ctrl machine after it samples the response
data and it has been shifted into the byte.  This
signal is passed up through the byte_ctrl machine
to my higher level controller.

If I don't care about the ack response or am writing
out bytes and don't care about dout, then I don't
use the data_valid.  However, if I want to check
the ack or read the data, then after getting the
cmd_ack, I then wait for data_valid to know when
the ack and/or data are valid.

This is working for me now, but I am not terribly
happy with it and would like to verify it more 
before submitting it as a solution.

As I mentioned, I am not using the wishbone
interface so I don't know if this would be the
proper fix for that situation.

Does this solution sound reasonable or did you
have something else in mind?

Tom
Richard Herveille wrote:
> 
> Ok everyone,
> 
> Here's the problem. There's a problem with the I2C core concerning read-ack
> timing. The interrupt signal and the TIP signal are asserted resp. negated
> to early (before the ACK bit has been read). This is a known bug caused by
> the cmd-ack (command acknowledge) signal being generated to early. But I
> don't have the time at the moment to fix it. Please be patient (or try to
> fix it yourself and send the fix back to CVS or me).
> 
> Richard
> 

> --
> To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml