CODEC

A

Amit

Guest
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
 
On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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
 
On Sun, 30 Mar 2008 02:37:06 -0700 (PDT), Amit <amit.kohan@gmail.com>
wrote:

On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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
 
On Mar 30, 2:41 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sun, 30 Mar 2008 02:37:06 -0700 (PDT), Amit <amit.ko...@gmail.com
wrote:





On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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 -


Thanks for your help.
 
On Mar 30, 2:41 pm, Allan Herriman <allanherri...@hotmail.com> wrote:
On Sun, 30 Mar 2008 02:37:06 -0700 (PDT), Amit <amit.ko...@gmail.com
wrote:





On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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 19 http://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
 
On Mar 31, 2:04 pm, Amit <amit.ko...@gmail.com> wrote:
On Mar 30, 2:41 pm, Allan Herriman <allanherri...@hotmail.com> wrote:



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

On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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
 
On Mar 31, 2:30 pm, kennheinr...@sympatico.ca wrote:
On Mar 31, 2:04 pm, Amit <amit.ko...@gmail.com> wrote:



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

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

On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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
 
On Mar 31, 7:56 pm, Amit <amit.ko...@gmail.com> wrote:
On Mar 31, 2:30 pm, kennheinr...@sympatico.ca wrote:



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

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

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

On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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
 
On Mar 31, 6:49 pm, kennheinr...@sympatico.ca wrote:
On Mar 31, 7:56 pm, Amit <amit.ko...@gmail.com> wrote:





On Mar 31, 2:30 pm, kennheinr...@sympatico.ca wrote:

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

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

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

On Mar 30, 2:30 am, Amit <amit.ko...@gmail.com> 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- Hide quoted text -

- Show quoted text -

Kenn,

Wow! I don't know what to say. You made my day. As I said this is my
first experience with Timing and to me was so confusing but you
did a great job in explaining it. I truly appreciate your HELP!!!!

Some minor questions I still have :( if you don't mind!


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.
Question:
1) Cannot I use a multi-dimensional array to transfer the data to
CODEC instead of using shift register?


2) As far as I understood there must be 6 states. Please correct me if
I'm wrong. I read page end of page 46 and beginning of page 47 and it
looks I should create 5 steps:

1) idle (waiting for start condition)
2) Start
3) Read 7-bits + R/W
4) Write Control address
5) Write Control data
6) Stop

About ACK step I'm not sure yet!

Thanks.
Amit
 
"Amit" <amit.kohan@gmail.com> wrote in message
news:3360d6a2-28f5-4953-a276-e016fe1928e4@s37g2000prg.googlegroups.com...
Wow! I don't know what to say. You made my day. As I said this is my
first experience with Timing and to me was so confusing but you
did a great job in explaining it. I truly appreciate your HELP!!!!

Thanks.
Amit
It's very worrying that you can write a statement like "... this is my first
experience with timing ..." without apparently appreciating the significance
of what you are saying. It's almost as if you are treating "timing" as a
specialist skill or technology like, for example, DDR interfacing or video
processing. These examples are things that you can afford to be blissfully
ignorant of until you're involved in a project that actually needs them.
However, the whole concept of understanding timing diagrams to ensure that
blocks interface together in a logically and functionally correct way with
adequate timing margins over all conditions is absolutely fundamental to
electronic design.

Please tell me you are a hobbyist, or at worst, an undergraduate student,
and not a "professional" engineer. There are many very knowledgeble people
on these boards that spend time that they no doubt could put to better (for
themselves) use, but instead choose to help out. Most people are happy to
help with specialist issues, or even "simple", but non-obvious to the
novice, issues. However, it does take the piss a bit when you start
expecting people to explain to you how to do your job. No offence intended.
 
On Apr 1, 5:30 am, "David Spencer" <davidmspen...@verizon.net> wrote:
"Amit" <amit.ko...@gmail.com> wrote in message

news:3360d6a2-28f5-4953-a276-e016fe1928e4@s37g2000prg.googlegroups.com...

Wow! I don't know what to say. You made my day. As I said this is my
first experience with Timing and to me was so confusing but you
did a great job in explaining it. I truly appreciate your HELP!!!!

Thanks.
Amit

It's very worrying that you can write a statement like "... this is my first
experience with timing ..." without apparently appreciating the significance
of what you are saying. It's almost as if you are treating "timing" as a
specialist skill or technology like, for example, DDR interfacing or video
processing. These examples are things that you can afford to be blissfully
ignorant of until you're involved in a project that actually needs them.
However, the whole concept of understanding timing diagrams to ensure that
blocks interface together in a logically and functionally correct way with
adequate timing margins over all conditions is absolutely fundamental to
electronic design.

Please tell me you are a hobbyist, or at worst, an undergraduate student,
and not a "professional" engineer. There are many very knowledgeble people
on these boards that spend time that they no doubt could put to better (for
themselves) use, but instead choose to help out. Most people are happy to
help with specialist issues, or even "simple", but non-obvious to the
novice, issues. However, it does take the piss a bit when you start
expecting people to explain to you how to do your job. No offence intended..

No I'm a programmer who is interested in this and trying to learn it.
I hope this is no against the rules in here.
 
On Apr 1, 10:24 am, Amit <amit.ko...@gmail.com> wrote:
On Apr 1, 5:30 am, "David Spencer" <davidmspen...@verizon.net> wrote:





"Amit" <amit.ko...@gmail.com> wrote in message

news:3360d6a2-28f5-4953-a276-e016fe1928e4@s37g2000prg.googlegroups.com...

Wow! I don't know what to say. You made my day. As I said this is my
first experience with Timing and to me was so confusing but you
did a great job in explaining it. I truly appreciate your HELP!!!!

Thanks.
Amit

It's very worrying that you can write a statement like "... this is my first
experience with timing ..." without apparently appreciating the significance
of what you are saying. It's almost as if you are treating "timing" as a
specialist skill or technology like, for example, DDR interfacing or video
processing. These examples are things that you can afford to be blissfully
ignorant of until you're involved in a project that actually needs them.
However, the whole concept of understanding timing diagrams to ensure that
blocks interface together in a logically and functionally correct way with
adequate timing margins over all conditions is absolutely fundamental to
electronic design.

Please tell me you are a hobbyist, or at worst, an undergraduate student,
and not a "professional" engineer. There are many very knowledgeble people
on these boards that spend time that they no doubt could put to better (for
themselves) use, but instead choose to help out. Most people are happy to
help with specialist issues, or even "simple", but non-obvious to the
novice, issues. However, it does take the piss a bit when you start
expecting people to explain to you how to do your job. No offence intended.

No I'm a programmer who is interested in this and trying to learn it.
I hope this is no against the rules in here.- Hide quoted text -

- Show quoted text -

However, it does take the piss a bit when you start
expecting people to explain to you how to do your job. No offence intended.
As far as I remember I have never asked anybody to do my job! what I
usually ask are things that I get stuck while reading a book
or doing an experiement. I'm a little bit confused here since (correct
me if I'm wrong) every group either software related or hardware
always welcome
newbies or interested people (w/ experience in another field). I felt
the same here but your post means different here or maybe I don't get
what you are saying.

Should I stop asking questions about simple VHDL questions? if this is
the rule here then please let me know.

Thanks for your comment
 
Amit wrote:

Should I stop asking questions about simple VHDL questions? if this is
the rule here then please let me know.
Ask what you like, but keep in mind that the answers
here are a few lines of text, if you are lucky.
So ask a specific vhdl question
and include your source code and error messages.

General questions about digital electronics,
are best covered by finding a tutorial and studying it.

http://www.google.com/search?q=digital+electronics+tutorial

-- Mike Treseler
 
"Amit" <amit.kohan@gmail.com> wrote in message
news:97268d15-3cb4-4d1e-b38f-e46ce500aa2d@s37g2000prg.googlegroups.com...

As far as I remember I have never asked anybody to do my job! what I
usually ask are things that I get stuck while reading a book
or doing an experiement. I'm a little bit confused here since (correct
me if I'm wrong) every group either software related or hardware
always welcome
newbies or interested people (w/ experience in another field). I felt
the same here but your post means different here or maybe I don't get
what you are saying.

Should I stop asking questions about simple VHDL questions? if this is
the rule here then please let me know.

Thanks for your comment
No - there are no rules here (that I'm aware of) as to what type of
questions you can ask. However, I'm sure most the posters here will agree
that the primary role of newsgroups like this isn't to teach someone a broad
subject starting from the very basics. Unfortunately, too many posts on this
board are from students who have been set homework assignments and can't be
bothered to do them themselves, or, in some cases, real engineers who are
too lazy to do their job or even develop the skills they need to do it. I'm
sorry if I tarred you with the same brush, but I couldn't tell from your
questions what your background was or why you were asking the basic
questions you were.

Mike's reply to you made a good point. The answers you get here, if any,
will hopefully be correct but will also likely be terse and specific to the
question you asked. This is not a good way to learn a new discipline from
scratch. As Mike suggested, have a look at various tutorials and with a bit
of work you will gain a much better basis to build your knowledge of digital
design on. Once you have the basics, Googling a few keywords related to a
particular topic you are interested in is likely to bring up masses of
useful information.
 
On Apr 1, 11:33 am, "David Spencer" <davidmspen...@verizon.net> wrote:
"Amit" <amit.ko...@gmail.com> wrote in message

news:97268d15-3cb4-4d1e-b38f-e46ce500aa2d@s37g2000prg.googlegroups.com...

As far as I remember I have never asked anybody to do my job! what I
usually ask are things that I get stuck while reading a book
or doing an experiement. I'm a little bit confused here since (correct
me if I'm wrong) every group either software related or hardware
always welcome
newbies or interested people (w/ experience in another field). I felt
the same here but your post means different here or maybe I don't get
what you are saying.

Should I stop asking questions about simple VHDL questions? if this is
the rule here then please let me know.

Thanks for your comment

No - there are no rules here (that I'm aware of) as to what type of
questions you can ask. However, I'm sure most the posters here will agree
that the primary role of newsgroups like this isn't to teach someone a broad
subject starting from the very basics. Unfortunately, too many posts on this
board are from students who have been set homework assignments and can't be
bothered to do them themselves, or, in some cases, real engineers who are
too lazy to do their job or even develop the skills they need to do it. I'm
sorry if I tarred you with the same brush, but I couldn't tell from your
questions what your background was or why you were asking the basic
questions you were.

Mike's reply to you made a good point. The answers you get here, if any,
will hopefully be correct but will also likely be terse and specific to the
question you asked. This is not a good way to learn a new discipline from
scratch. As Mike suggested, have a look at various tutorials and with a bit
of work you will gain a much better basis to build your knowledge of digital
design on. Once you have the basics, Googling a few keywords related to a
particular topic you are interested in is likely to bring up masses of
useful information.

If that is the case then ok. I guess I have to deal with it and will
submit those questions that are not basic from now on.
I guess I have to sumbit a question when I don't find any tutorial on
google ....

Yep life is getting better now
 

Welcome to EDABoard.com

Sponsor

Back
Top