Amit,
OK, I'll interpret the diagram for you. This time only
VHDL-ers
can skip to the next thread now.
First, the clock. T1 is a rule: always drive to clock low for at least
1.3 usec, never less. If it's low for a shorter time, the chip
behaviour is undefined. Similarly, treat t2 as a rule: never drive the
clock high for shorter than 600 ns. Add these together and the rule
says: toggling clock for a full cycle should never take less than (1.3
+ 0.6 usec), roughly 2 usec, which is where the 526 kHz cycle
frequency limit comes from: 1/1.9 usec = a smidgen over 500 kHz.
Next, the rise times t6 and t7. 300 ns is a lifetime in the FPGA
world. Unless you're driving the codec chip at the other end of a 50-
foot piece of lamp cord, you'll probably see rise and fall times from
most modern drivers on the order of 10 ns or better. So you can
generally ignore this one. If you have an open collector SCLK (read
the I2C spec if you don't get this idea, then ask on sci.electronics),
use a small pullup like 1K to ensure fast risetime.
The waveform shows a 1-byte transaction which is framed by a start and
stop condition. The times t3 and t8 refer to conditions for these
start and stop cycles, while t5 and t10 are conditions for regular
bits (the 8 or so bits you're shifting into the part).
In I2C, you normally never change the data when the clock is high. The
exception is for the start & stop cycle; this is how you know it's a
stop or start cycle. t3=600 ns is a rule: when you generate your start
cycle, make sure the data goes low *at least* 600 ns before you drive
the clock low. Dually, for t8.
For generic data bits, you need to make sure the data is presented and
stable, ready to be sampled on the rising edge of SCLK. T5 is a rule,
saying "make sure you put the data out at least 100 ns before you
drive the clock high". t10 is the corresponding rule *after* the
clock edge, saying "make sure you keep the data there for 900 ns so
the chip can see it and sample it".
What should be the pulse width of SDIN? It needs to be stable for at
least 100 ns before the clock and 900 ns after the clock. Therefore,
it needs to be *stable* for at least (t5+t10=100+900 ns) = 1 usec.
But since the overall cycle needs to be closer to 1 usec, you may as
well keep the data valid for the whole cycle, as long as you only
change it according to t5 and t10.
It does not appear that the serial interface needs to be locked to
MCLK. However, it's generally a good principle to keep as many clocks
synchronous as possible. So if you have a super-master clock (say 10x
MCLK rate, or 16x MCLK rate), you would do well to divide it down
using counters (as you described), and if this cycle time is in the
range of 100 ns or smaller, you can "place" each individual edge of
SCLK and SDATA to the nearest "fast clock" tick in a state machine
based on the count value and the master cycle state.
You'll probably want a shift register to drive the data out, plus a
master cycle state machine to cycle through IDLE, START, 8 data bits,
and STOP condition. Hopefully you've already got this set up.
Now the VHDL. I was going to write some code snippets, but that's
really your job (plus I'm too lazy
. As an earlier poster pointed
out, when you have some VHDL-specific questions, we'll be happy to
argue the fine points with you.
Keep in mind that for a simulation model (which won't ever be
synthesized) you can fill up your code with "wait for 100 ns"
statements and "wait for 900 ns" statements. But for a synthesizable
piece of code, you need to use one fast physical counter and figure
out a state machine based on its values. The synthesizable code
probably won't have any wait statements; only "if rising_edge(clk)"'s
should appear.
Happy hacking,
- Kenn- Hide quoted text -
- Show quoted text -
