|
Message
From: g-sus at gmx.li<g-sus@g...>
Date: Wed Jul 4 18:09:26 CEST 2007
Subject: [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
>
>
|
 |
Browse
