Re: CODEC

On Mar 31, 7:56 pm, Amit <amit.ko...@xxxxxxxxx> wrote:
On Mar 31, 2:30 pm, kennheinr...@xxxxxxxxxxxx wrote:



On Mar 31, 2:04 pm, Amit <amit.ko...@xxxxxxxxx> wrote:

On Mar 30, 2:41 pm, Allan Herriman <allanherri...@xxxxxxxxxxx> wrote:

On Sun, 30 Mar 2008 02:37:06 -0700 (PDT), Amit <amit.ko...@xxxxxxxxx>
wrote:

On Mar 30, 2:30 am, Amit <amit.ko...@xxxxxxxxx> wrote:
Hello group,

Can somebody advise me on page 19 (figure 8) please? as you see we
have SCLK and SDIN as output.

Is SDIN clocked by a master clock such as MCLK?

What is the relation between SCLK and SDIN?

How can I synch SDIN and SCLK? or everything should be synced using
MCLK?

Thanks,
Amit

sorry here is the link I had missed in previous post.
http://www.wolfsonmicro.com/uploads/documents/en/WM8731.pdf

"2-Wire" mode is the same as I2C or SMBus. SCLK is an input on the
CODEC, not an output. I2C devices can work without needed any clock
other than SCLK (known as SCL in the I2C spec). BTW, this is not a
clock in the usual sense of a continuous square wave; it can stop or
be stretched.

Here is version 2.1 of the I2C spec:http://www.nxp.com/acrobat_download/literature/9398/39340011.pdf

Here is the Wikipedia page:http://en.wikipedia.org/wiki/I%C2%B2C

Regards,
Allan- Hide quoted text -

- Show quoted text -

Allan,

(Ref: page 19http://www.wolfsonmicro.com/uploads/documents/en/WM8731.pdf)

By now, I have written a small code to generate those outputs (SCLK
and SDIN). However, since I'm new to Timing topic I will appreciate it
if you or other experts will advise me on this.

The way I have understood it is that SCLK (or continuous square wave
in output) starts with t3 (where t3=600ns minimum) delay after SDIN.
However since the table represetns t3 as 600ns (MIN) so I conisidered
it as 1.3us instead. The reason I did this is because I have
considered SCLK low pulsewidth and high pulsewidth both as 1.3us.

Now, all I need to know:

Is it correct to generate the SCLK with a delay about 1.3us after
SDIN? or there are other issues that I'm missing?
if so, what are they and should I add them to the delay time?

Any suggestions or help will be appreciated greatly.

Amit

Amit,

Sorry if this is isn't directly timing, but for I2C-type interfaces,
one is often able to use a "bit-banging" style of parallel
microprocessor interface, instead of a full blown serializer & state
machine logic. Assuming that this device is hosted on some kind of
microprocessor, you can set up a direct one-byte register that when
you write to it, has some basic control bits, For example, bit 0 turns
on and off the SDA tri-state. Bit 1 turns on the SCLK open collector
driver, and bit 2 provides the data for SDA. A readback register
would have 2 bits to read the status of the SCLK and SDA lines. By
writing the appropriate bit-masks from a series of program statements
you control the lines; for example to generate a pulse on SDA:

*(volatile char *)MY_REGISTER_ADDRESS = 0x02;
*(volatile char *)MY_REGISTER_ADDRESS = 0x00;

This is somewhat simplified -- in real life you have to worry about
atomicity, timing variations due to pre-emption by an ISR, etc. And
you probably want an interrupt as well if you're a slave device.

Getting back to the timing aspects, in embedded systems, one often
guarantees a minimum time between edges just by inserting NOP's
between consecutive register writes.

Most hardware guys cringe at this, especially when it's usually safer
and more robust and reliable to do the byte -level transactions
directly in hardware. But for a simple interface in a controlled
environment, it's sometimes a good fall-back position, and lets you
put the effort into software instead of hardware, which helps if
you're a software guy at heart.

- Kenn

Kenn,

Thank you for your time. currently my concern is not the hardware
setting or C programming. What I need to understand is in terms of
VHDL implementation. All I'm doing is a simple simulation using
Quartus II and getting some waveform to simulate on how to initialize
and write into WM8731 which is defined on page 19 and because I'm
completely new to timing so it seems I get confused.

Back to page 19, in that PDF file. I have created 400Kkhz SCLK output
using counters (not able to use WAIT FOR statement since I use
Quartus). Now I need to create the SDIN waveform but how can I know
what should be pulse width of the SDIN?
Where in the timing table can I find this out?

Please let me know it.

Regards.
amit

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

.

Relevant Pages

  • Re: CODEC
    ... have SCLK and SDIN as output. ...  I2C devices can work without needed any clock ... toggling clock for a full cycle should never take less than (1.3 ...
    (comp.lang.vhdl)
  • Re: How to create a delay?
    ... I'm using Quartus II to design the control interface for Wolfson ... I need to make delay for SDIN. ... By far the easiest way is to start with a clock at twice the speed of SCLK ...
    (comp.lang.vhdl)
  • Re: Patch: Make iBook1 work again
    ... > backlight can be either done by the ATI chip or by some other uController ... their clock is removed but not their power. ... Luckily the BIOS on my Rage LT Pro did use SCLK to clock the engine, ...
    (Linux-Kernel)
  • Re: How to create a delay?
    ... It says that SDIN must be stable 20ns ... before the rising edge of SCLK. ... must stay stable for 20 ns following this rising edge. ... Just clock the data out at the same time as the falling edge of SCLK. ...
    (comp.lang.vhdl)
  • Re: CODEC
    ... Is SDIN clocked by a master clock such as MCLK? ... What is the relation between SCLK and SDIN? ... other than SCLK (known as SCL in the I2C spec). ...
    (comp.lang.vhdl)