AC97 system integration

[Arnim Läuger]

Hi all,

I've been using Rudi's AC97 controller for a couple of projects and
found it's working very well. In the first place, I was in doubt about
compatability issues as there are many codec chips around and not all of
them might have been used with this core up to now.
Surprisingly, I've had only very few issues when integrating the whole
AC97 stuff using a very simple configuration. There's just an FSM
stimulating the Wishbone interface doing the basic initialization of the
core and the codec. After initialization, the FSM performs regular
writes to the FIFO to send 8-bit audio samples to the codec.

Well, in the future I might step to more complex applications and would
like to share experience with other users of the AC97 controller core.
I've identified three things that are worth mentioning concerning system
integration.

Xilinx' Project Navigator seems to have problems determining the
resulting hierarchy from all the conditional instantiations. For the
time being, I fixed the verilog RTL to my specific implementation but
that's not very nice. Is there a way that PN can handle the definitions
in ac97_defines.v properly?

The National Semi LM4550 requires a SYNC high time of 1.3 us for warm
reset instead of 1.0 us. Just had to adjust AC97_RES_SIG in
ac97_defines.c accordingly.

The Wishbone clock must be at least 2x bit_clk_pad_i. Sometimes, I got
excessive noise on the speaker lines when this rule was violated.
Tweaked the circuit in ac97_soc.v to account for lower WB clocks.


Do you have further input/comments? Is the whole AC97 story really
plug'n play; What should one be aware of?


Cheers

  Arnim
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[Martin Schoeberl]

>
> The National Semi LM4550 requires a SYNC high time of 1.3 us for warm
> reset instead of 1.0 us. Just had to adjust AC97_RES_SIG in
> ac97_defines.c accordingly.
>
This hint helped me to get the AC97 core more stable with an
AD1981BL [1]. I had sometimes startup problems. Setting this value
to 2us and also AC97_RES_DEL to 2us helped. I did not see this issue
anymore.

Thank you Arnim.

Martin

[1] http://www.soc.tuwien.ac.at/courses/projects/dspio/
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[hunkZ]

Any idea why "The Wishbone clock must be at least 2x bit_clk_pad_i"?

I had noise problem with my own AC97 controller on LM4550: when I had speaker and headphone both plugged, the speaker output is ok. But when I unplugged the headphone, the speaker output because noisy instantly; The heaphone output was always noisy regardless whether the speaker is connected or not.

[Arnim Läuger]

Hi!

> Any idea why "The Wishbone clock must be at least 2x bit_clk_pad_i"?

This is my interpretation of the circuit built around bit_clk_r in
ac97_soc.v. bit_clk_r samples the AC97 clock on bit_clk_pad_i with the
Wishbone clock.  This can only work reliably when wclk has at least
twice the frequency of the sampled signal.

Initially, I did not recognize this and got GO/NOGO designs depending on
the frequency of wclk. For a design where wclk was close below 2x
bit_clk_pad_i, there was much noise on the speaker output. Sometimes no
signal at all which turned into noisy audio when I touched some of the
analog components connected to the V_REF pin on LM4550. Another design
with wclk around 20 MHz worked perfectly fine. Nearly drove me mad...

> I had noise problem with my own AC97 controller on LM4550: when I had
>  speaker and headphone both plugged, the speaker output is ok. But
> when I unplugged the headphone, the speaker output because noisy
> instantly; The heaphone output was always noisy regardless whether
> the speaker is connected or not.

*Might* be similar to my observation. I mean, messing with the analog
domain often reveals effects that are hard to diagnose at first sight.
What frequency is your wclk?


Cheers

  Arnim
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[Rudolf Usselmann]

On Sat, 2006-03-18 at 15:36 +0100, Arnim Laeuger wrote:
> Hi!
>
> > Any idea why "The Wishbone clock must be at least 2x bit_clk_pad_i"?
>
> This is my interpretation of the circuit built around bit_clk_r in
> ac97_soc.v. bit_clk_r samples the AC97 clock on bit_clk_pad_i with the
> Wishbone clock.  This can only work reliably when wclk has at least
> twice the frequency of the sampled signal.

...

> Cheers
>
>   Arnim

Arnim,

why don't you publish your modifications that you previously
emailed me ? I think they might be helpful to others as well.

Best Regards,
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis
****** Certified USB 2.0 HS OTG and HS Device IP Cores ******
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores

[Arnim Läuger]

>>> Any idea why "The Wishbone clock must be at least 2x
>>> bit_clk_pad_i"?
>>
>> This is my interpretation of the circuit built around bit_clk_r in
>> ac97_soc.v. bit_clk_r samples the AC97 clock on bit_clk_pad_i with
>> the Wishbone clock.  This can only work reliably when wclk has at
>> least twice the frequency of the sampled signal.
>
>
> Arnim,
>
> why don't you publish your modifications that you previously emailed
> me ? I think they might be helpful to others as well.

I've uploaded the modified ac97_soc.v to

  http://home.mnet-online.de/al/ac97_soc.v

The changes work fine for my designs at the moment. I.e. the suspend
detection circuit doesn't reinitialize the AC97 link periodically.
However, it's worth mentioning that my application doesn't deal with
intentional suspend at all. So the modification is not tested against
this scenario.

For integration details refer to the project files at

  http://home.freeuk.com/fpgaarcade/cv.htm


Best regards

  Arnim
_______________________________________________
http://www.opencores.org/mailman/listinfo/cores