OPENCORES.ORG

i2c_cmd_ack does get set to '1'; otherwise the code wouldn't work

A few comments;
1.
SCL and SDA should be pulled to 'H', not set to '1'.
I2C uses open-drain outputs.

2.
I don't see SCL and SDA toggle in your timing diagram.

Richard

-----Original Message-----
From: cores-bounces@o... [mailto:cores-bounces@o...] On
Behalf Of g-sus@g...
Sent: Wednesday, July 04, 2007 6:09 PM
To: cores@o...
Subject: Re: [oc] I2C clock timing / Masterbyte Controller / VHDL

hello again, 
while debugging all the core signals it was noticed that the al
(arbitration lost bit) gets set in the bit controller. 
This seems to happen because of a delay while sending back the 
SCL und SDA line to the core  at the highest level of our controller
like this,

[code]
SCL <= scl_o when (scl_oen = '0') else '1';
SDA <= sda_o when (sda_oen = '0') else '1'; 
scl_i <= SCL; 
sda_i <= SDA; 
[/code]

the timing results always look like the following image: 
http://www.imagehoster.info/images/Bild8-846b83.png
(we are using the Quartus2 classic timing analyzer) 

i am very new to the VHDL Development and in urgent need off help with
this problem ... 
thanks a lot 

PS : Is there some tutorial using I2C together with quartus ?  

----- Original Message ----- 
From: Richard Herveille<richard@h...> 
To: 
Date: Sun Jul  1 07:00:46 CEST 2007 
Subject: [oc] I2C clock timing  /  Masterbyte Controller / VHDL 

> i2c_cmd_ack does get set to '1'; otherwise the code wouldn't work 
> :p 
> The i2c_master_controller uses a somewhat different approach then 
> the 
> simple_i2 controller. 
> Run the i2c_master_controller's testbench to see the relationship 
> between 
> the signals. 
> Richard 
> -----Original Message----- 
> From: cores-bounces at opencores.org [mailto:cores-bounces at 
> opencores.org] On 
> Behalf Of g-sus at gmx.li 
> Sent: Thursday, June 28, 2007 5:57 PM 
> To: cores at opencores.org 
> Subject: Re: [oc] I2C clock timing / Masterbyte Controller / VHDL 
> > Make sure you keep the control signals asserted until you get 
> a 
> > cmd_ack from ... 
> so we can't use a code like this to check for the next state ? 
> ( similar to the DS1621 Sample Code) 
> [code] 
>  when i2 => -- send "access config" 
> command 
>  if (cmd_ack = '1') then 
>  nxt_state := i3; 
>  -- check aknowledge bit 
>  if (lack = '1') then 
>  ierr := '1'; -- no 
> acknowledge received from last command, expected ACK 
> 	 
>  end if; 
>  istart := '0'; 
>  iread := '0'; 
>  iwrite := '1'; 
>  iack := '0'; 
>  istop := '0'; 
>  iD := x"AC"; 
>  end if; 
> [/code] 
> 
> We noticed that the cmd_ack bit ( mapped to the cmd_ack bit of the 
> byte controller) never gets 1 (but it schould get set through the 
> bit 
> controller). Is this a timingproblem, or is this approach completly 
> wrong ? 
> _______________________________________________ 
> http://www.opencores.org/mailman/listinfo/cores 
> 
> 
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores