OpenCores

OpenCores

AC97 system integration

no use

no use

1/1

no use

no use

AC97 system integration by Unknown on Feb 19, 2006			Not available!
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 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

AC97 system integration by Unknown on Feb 19, 2006			Not available!
[q] 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. [/q] 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] <A HREF="http://www.soc.tuwien.ac.at/courses/projects/dspio/">http://www.soc.tuwien.ac.at/courses/projects/dspio/</A> 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/

AC97 system integration by Unknown on Mar 15, 2006			Not available!
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. -- View this message in context: <A HREF="http://www.nabble.com/AC97-system-integration-t1149906.html#a3423149">http://www.nabble.com/AC97-system-integration-t1149906.html#a3423149</A> Sent from the OpenCores - IP Cores forum at Nabble.com. 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. -- View this message in context: http://www.nabble.com/AC97-system-integration-t1149906.html#a3423149 Sent from the OpenCores - IP Cores forum at Nabble.com.

AC97 system integration by Unknown on Mar 18, 2006			Not available!
Hi! [q] Any idea why "The Wishbone clock must be at least 2x bit_clk_pad_i"?[/q] 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... [q] 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.[/q] 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 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

AC97 system integration by Unknown on Mar 18, 2006			Not available!
On Sat, 2006-03-18 at 15:36 +0100, Arnim Laeuger wrote: [q] Hi! [q]> Any idea why "The Wishbone clock must be at least 2x bit_clk_pad_i"?[/q] 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.[/q] ... [q] Cheers Arnim[/q] 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, <A HREF="http://www.asics.ws">http://www.asics.ws</A> Your Partner for IP Cores, Design, Verification and Synthesis **** Certified USB 2.0 HS OTG and HS Device IP Cores ** 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 ****

AC97 system integration by Unknown on Mar 19, 2006			Not available!
[q] 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, <A HREF="http://www.asics.ws">http://www.asics.ws</A> Your Partner for IP Cores, Design, Verification and Synthesis **** Certified USB 2.0 HS OTG and HS Device IP Cores ** _______________________________________________[/q] Rudi, shouldn't it be your job to update your core on the OpenCores webserver, if Arnim found some bugs in it and informed you!?!??! Out of my experience I assume that you won't do it. :-( I know that all your USB cores on OpenCores are buggy and that you don't update them ... probably because you earn more money with the working versions you offer at www.asics.ws ... That's not really in the sens of OpenCores ... Best Regards, damc -- "Feel free" mit GMX FreeMail! Monat fÃ¼r Monat 10 FreeSMS inklusive! <A HREF="http://www.gmx.net">http://www.gmx.net</A> 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 **** _______________________________________________ Rudi, shouldn't it be your job to update your core on the OpenCores webserver, if Arnim found some bugs in it and informed you!?!??! Out of my experience I assume that you won't do it. :-( I know that all your USB cores on OpenCores are buggy and that you don't update them ... probably because you earn more money with the working versions you offer at www.asics.ws ... That's not really in the sens of OpenCores ... Best Regards, damc -- "Feel free" mit GMX FreeMail! Monat fÃ¼r Monat 10 FreeSMS inklusive! http://www.gmx.net

AC97 system integration by Unknown on Mar 19, 2006			Not available!
On Sun, 2006-03-19 at 12:51 +0100, otto otto wrote: [q]> >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[/q] Rudi, shouldn't it be your job to update your core on the OpenCores webserver, if Arnim found some bugs in it and informed you!?!??![/q] Yes that would be my job if he indeed found bugs. But he did not. My design works just fine the way it is (according with the provided spec). He made some modification that go beyond the original design goals. [q] Out of my experience I assume that you won't do it. :-([/q] What experience is that ? [q] I know that all your USB cores on OpenCores are buggy and that you don't update them ... probably because you earn more money with the working versions you offer at www.asics.ws ...[/q] Actually the USB 1.1 Device and PHY are working just fine. There are several success stories about them. The USB 2.0 Device IP got never finished, because when I was developing the free version nobody wanted to help with verification. [q] That's not really in the sens of OpenCores ...[/q] Instead of complaining why don't you go and write a few free IP cores yourself. [q] Best Regards, damc[/q] rudi ============================================================= Rudolf Usselmann, ASICS World Services, <A HREF="http://www.asics.ws">http://www.asics.ws</A> Your Partner for IP Cores, Design, Verification and Synthesis **** Certified USB 2.0 HS OTG and HS Device IP Cores ** On Sun, 2006-03-19 at 12:51 +0100, otto otto wrote: > >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 Rudi, shouldn't it be your job to update your core on the OpenCores webserver, if Arnim found some bugs in it and informed you!?!??! Yes that would be my job if he indeed found bugs. But he did not. My design works just fine the way it is (according with the provided spec). He made some modification that go beyond the original design goals. Out of my experience I assume that you won't do it. :-( What experience is that ? I know that all your USB cores on OpenCores are buggy and that you don't update them ... probably because you earn more money with the working versions you offer at www.asics.ws ... Actually the USB 1.1 Device and PHY are working just fine. There are several success stories about them. The USB 2.0 Device IP got never finished, because when I was developing the free version nobody wanted to help with verification. That's not really in the sens of OpenCores ... Instead of complaining why don't you go and write a few free IP cores yourself. Best Regards, damc 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 ****

AC97 system integration by Unknown on Mar 19, 2006			Not available!
On Sun, 2006-03-19 at 20:27 +0700, Rudolf Usselmann wrote: [q] On Sun, 2006-03-19 at 12:51 +0100, otto otto wrote: [q] > >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[/q] > > Rudi, > > shouldn't it be your job to update your core on the OpenCores webserver, if > Arnim found some bugs in it and informed you!?!??![/q] Yes that would be my job if he indeed found bugs. But he did not. My design works just fine the way it is (according with the provided spec).[/q] Let me correct myself here. First of all writing FREE IP Cores is NOT my job. Secondly, since most people only complain and are never satisfied, I see no reason to contribute to OpenCores at all (or did you see anything from me in the last 2 years ?). For each "Thanks for the hard work" email I get, I get about 100 complain emails like yours. So why should I participate here at all ? [q] He made some modification that go beyond the original design goals. [q]> Out of my experience I assume that you won't do it. :-([/q] What experience is that ? [q]> I know that all your USB cores on OpenCores are buggy and that you don't > update them ... probably because you earn more money with the working > versions you offer at www.asics.ws ...[/q] Actually the USB 1.1 Device and PHY are working just fine. There are several success stories about them. The USB 2.0 Device IP got never finished, because when I was developing the free version nobody wanted to help with verification. [q]> That's not really in the sens of OpenCores ...[/q] Instead of complaining why don't you go and write a few free IP cores yourself. [q]> Best Regards, > > damc[/q] rudi[/q] I presume this is my last posting here, since I will now un-subscribe from this list. Good luck to all the contributors ... rudi ============================================================= Rudolf Usselmann, ASICS World Services, <A HREF="http://www.asics.ws">http://www.asics.ws</A> Your Partner for IP Cores, Design, Verification and Synthesis **** Certified USB 2.0 HS OTG and HS Device IP Cores ** On Sun, 2006-03-19 at 20:27 +0700, Rudolf Usselmann wrote: On Sun, 2006-03-19 at 12:51 +0100, otto otto wrote: > >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 > > Rudi, > > shouldn't it be your job to update your core on the OpenCores webserver, if > Arnim found some bugs in it and informed you!?!??! Yes that would be my job if he indeed found bugs. But he did not. My design works just fine the way it is (according with the provided spec). Let me correct myself here. First of all writing FREE IP Cores is NOT my job. Secondly, since most people only complain and are never satisfied, I see no reason to contribute to OpenCores at all (or did you see anything from me in the last 2 years ?). For each "Thanks for the hard work" email I get, I get about 100 complain emails like yours. So why should I participate here at all ? He made some modification that go beyond the original design goals. > Out of my experience I assume that you won't do it. :-( What experience is that ? > I know that all your USB cores on OpenCores are buggy and that you don't > update them ... probably because you earn more money with the working > versions you offer at www.asics.ws ... Actually the USB 1.1 Device and PHY are working just fine. There are several success stories about them. The USB 2.0 Device IP got never finished, because when I was developing the free version nobody wanted to help with verification. > That's not really in the sens of OpenCores ... Instead of complaining why don't you go and write a few free IP cores yourself. > Best Regards, > > damc rudi I presume this is my last posting here, since I will now un-subscribe from this list. Good luck to all the contributors ... 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 ****

AC97 system integration by Unknown on Mar 19, 2006			Not available!
[q] Any idea why "The Wishbone clock must be at least 2x bit_clk_pad_i"?[/q] 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.[/q] Arnim, why don't you publish your modifications that you previously emailed me ? I think they might be helpful to others as well.[/q] I've uploaded the modified ac97_soc.v to <A HREF="http://home.mnet-online.de/al/ac97_soc.v">http://home.mnet-online.de/al/ac97_soc.v</A> 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 <A HREF="http://home.freeuk.com/fpgaarcade/cv.htm">http://home.freeuk.com/fpgaarcade/cv.htm</A> Best regards Arnim 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

AC97 system integration by BrewsterPorcella on Mar 20, 2006			BrewsterPorcella Posts: 3 Joined: Jun 19, 2012 Last seen: Jun 27, 2012
otto otto..... I don't get it.... What exactly is the "sens" of OpenCores???? If you release free working cores to the world are you responsible for maintaining them forever???? If you release free working cores are you not allowed to make money ???? I'm sorry, but we are all trying to make a living. If there was any notion that there was an OBLIGATION to maintain released work, I suspect you would find very little of value out there. bj Porcella ----- Original Message ----- From: "otto otto" <<A HREF="http://www.opencores.org/mailman/listinfo/cores">damc4 at gmx.de</A>> To: <<A HREF="http://www.opencores.org/mailman/listinfo/cores">cores at opencores.org</A>> Sent: Sunday, March 19, 2006 6:51 AM Subject: Fwd: Fwd: Re: [oc] AC97 system integration [q] I know that all your USB cores on OpenCores are buggy and that you don't update them ... probably because you earn more money with the working versions you offer at www.asics.ws ... That's not really in the sens of OpenCores ... Best Regards, damc[/q] otto otto..... I don't get it.... What exactly is the "sens" of OpenCores???? If you release free working cores to the world are you responsible for maintaining them forever???? If you release free working cores are you not allowed to make money ???? I'm sorry, but we are all trying to make a living. If there was any notion that there was an OBLIGATION to maintain released work, I suspect you would find very little of value out there. bj Porcella ----- Original Message ----- From: "otto otto" damc4 at gmx.de> To: cores at opencores.org> Sent: Sunday, March 19, 2006 6:51 AM Subject: Fwd: Fwd: Re: [oc] AC97 system integration I know that all your USB cores on OpenCores are buggy and that you don't update them ... probably because you earn more money with the working versions you offer at www.asics.ws ... That's not really in the sens of OpenCores ... Best Regards, damc

AC97 system integration by Unknown on Mar 24, 2006			Not available!
Rudolf Usselmann <<A HREF="http://www.opencores.org/mailman/listinfo/cores">rudi at asics.ws</A>> wrote: [q] I presume this is my last posting here, since I will now un-subscribe from this list. Good luck to all the contributors ...[/q] I hope that Rudi will change his mind. I have always considered him the father of OpenCores, the best community spreading free IP cores that over the years has gained respect from industry. We are now starting some new commercial projects based upon his free IP cores and soon or later we'll have to ask him [commercial] support: so open-sourcing applied to hardware design can become the winning model. Please Rudi stay with us!!! We'll try to contribute to this community in the future! Fabrizio -- ============================================ Fabrizio Fazzino - <A HREF="http://www.opencores.org/mailman/listinfo/cores">fabrizio at fazzino.it</A> Fazzino.IT - <A HREF="http://www.fazzino.it">http://www.fazzino.it</A> ============================================ Rudolf Usselmann rudi at asics.ws> wrote: I presume this is my last posting here, since I will now un-subscribe from this list. Good luck to all the contributors ... I hope that Rudi will change his mind. I have always considered him the father of OpenCores, the best community spreading free IP cores that over the years has gained respect from industry. We are now starting some new commercial projects based upon his free IP cores and soon or later we'll have to ask him [commercial] support: so open-sourcing applied to hardware design can become the winning model. Please Rudi stay with us!!! We'll try to contribute to this community in the future! Fabrizio -- ============================================ Fabrizio Fazzino - fabrizio at fazzino.it Fazzino.IT - http://www.fazzino.it ============================================

no use

no use

1/1

no use

no use

© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.