Thread: [myhdl-list] myHDL First Project: Audio Effects System
Brought to you by:
jandecaluwe
From: Bob C. <Fl...@gm...> - 2011-09-29 18:04:28
|
I want to attack a useful stand-alone application as my first myHDL project, with the primary goal being to become intimately familiar with all aspects of the myHDL-to-hardware development process (making full use of the expertise captured on the myHDL site), and the secondary goal being to start learning digital design by examining the work of others and porting it to myHDL. To the greatest extent possible, code will be released under an appropriate Open license on OpenCores, GitHub and/or the myHDL site. I've chosen to implement an audio effects suite that would initially be suitable for use as a guitar pedal system or voice processor. I have the following specific goals: A. General specifications/scope: - Support line-level analog input and output. - Start with 44.1 KHz audio sample rate, sample width of ~10 bits. - Design should be parameterized for faster/wider analog data. - Allow for future resampling to support different input and output sample rates/widths. - Start with single audio channel I/O. - Allow for upgrades for multiple input and output channels and mixing. - Modular design for individual effects with a common streaming interface. - Effects built from a set of reusable mathematical/operational elements. - Allow for implementation optimizations to mux operating elements in time domain. - Start with simple effects (echo, reverb, filtering). - Allow for more complex effects (e.g., pitch modification, auto-tune). - Start with a simple discrete button control interface. - Allow for multiple control interfaces: MIDI, SPI, parallel. - Allow for use by internal uP (e.g. http://opencores.org/project,avr_core) - Start with simple discrete LED status/configuration display. - Allow for output of current status/configuration (serial, parallel). - Allow for tracking net delay between input and output (effects modules would eventually need to report the delay they currently add to the process). - Allow for future inclusion of a VGA display (control, status, animated effects) B. Implementation constraints: - Initial hardware target is a Spartan 3E-500-4 FPGA with external SRAM available. - My initial dev board: http://www.kickstarter.com/projects/794668827/aliencortex-av - Use PWM on a standard digital output with RC filter to implement a 44.1 KHz ~10-bit DAC. - Use an LVDS comparator to implement a successive-approximation or sigma-delta 44.1 KHz ~10-bit ADC. - Allow for future use of external ADCs/DACs (SPI, parallel) and other streaming data sources (PC, S/PDIF). I have several reasons for choosing this project: - It's useful and fun. - It is relatively easy to understand. - It is a stand-alone system (minimal parts needed other than FPGA itself). - It is a true SoC, but a fairly simple one. - It can be expanded almost without limit. - Data rates are slow enough to monitor with inexpensive equipment (PC, multimeter). - Real-time simulation/emulation possible with even slow PCs. - Relevant software and Verilog/VHDL code snippets are freely available, permitting initial development to focus more on architecture and process rather than detailed digital design. - Opportunities for cosimulation and mixed-signal simulation (Spice for external analog components). - Could eventually become an end-to-end myHDL hands-on tutorial. - Should be compatible with broad community participation. I expect the system will have multiple implementation/elaboration cycles, starting with simple (perhaps inefficient) and progressing to sophisticated and highly optimized. For example: - Implement DAC using PWM first, successive-approximation later. - Test DAC with canned data and multimeter (DC) or o'scope (AC). - Implement digital ADC using LVDS comparator: successive-approximation first, delta-sigma later. - Test ADC with resistor ladder (DC tests). - Do Spice analog cosimulation of external components of ADC and DAC (optional). - Connect ADC input to DAC output. - Connect microphone and earbuds, test 'live'. - Measure delay between input and output. - Add fixed echo effect. - Test as isolated component. - Integrate with ADC/DAC. - Test as system. - Modify echo module and tests to support variable echo delay and decay times. - Use buttons to control echo module, and discrete LEDs to display state. - Add hiss (low-pass) filter effect. - Test in isolation. - Test as integrated system. - Test via cosimulation (optional). - Add mux/switch component to select effects and their order. - Update modules to use uniform streaming and control interfaces. - Add RS-232 status/control interface (for use by a person with a terminal program). - Add more effects: - Import other HDL code (e.g. FIR filter) into a myHDL wrapper. - Add myHDL tests. - Port code from other HDL to myHDL. - Add SPI interface for use by external uP (make it look more like just another part). - Add subsystem reuse in time domain (with state switching). - Add basic VGA display. - Convert from a stand-alone component to a core. - Add AVR8 core (or, more correctly, add effects system as AVR8 peripheral on SoC). - Add software for more sophisticated and flexible operation (e.g., simpler external control). (I really wish the embedded core could run Python...) While the project goals are initially based on my own desires, I hope this project could eventually become an ideal gateway tutorial project for myHDL, since it creates a real product (not a toy example) that starts simple (and fully functional) and grows to a complete SoC, while hopefully requiring only minimal resources (few components, simple tools, no logic analyzer) and limited digital design skills (e.g., no SDRAM interface). Before going any further, I'd like to solicit suggestions and recommendations from the myHDL community: 1. Would you be interested in supporting this project with mentoring, infrastructure, and/or code? 2. I think I'd like to document project progress on a wiki. Recommendations? Alternatives? Should I use a page on the myHDL wiki? Or would a blog be better (possibly with a wiki)? 3. Is it OK to use the myHDL list as a forum for this project, or should it get its own facilities? 4. What is this project missing? Thanks, -BobC |
From: Christopher F. <chr...@gm...> - 2011-10-01 19:15:49
|
My thoughts and opinions (opinions are like ...) On 9/29/11 1:04 PM, Bob Cunningham wrote: > I want to attack a useful stand-alone application as my first myHDL project, with the primary goal being to become intimately familiar with all aspects of the myHDL-to-hardware development process (making full use of the expertise captured on the myHDL site), and the secondary goal being to start learning digital design by examining the work of others and porting it to myHDL. > > To the greatest extent possible, code will be released under an appropriate Open license on OpenCores, GitHub and/or the myHDL site. > I would use GitHub or Bitbucket. Clean interfaces and you have the potential to include interested parties outside of the MyHDL community. The first item on you list should be determining the license you want to use. <snip> > B. Implementation constraints: > - Initial hardware target is a Spartan 3E-500-4 FPGA with external SRAM available. > - My initial dev board: http://www.kickstarter.com/projects/794668827/aliencortex-av > - Use PWM on a standard digital output with RC filter to implement a 44.1 KHz ~10-bit DAC. > - Use an LVDS comparator to implement a successive-approximation or sigma-delta 44.1 KHz ~10-bit ADC. > - Allow for future use of external ADCs/DACs (SPI, parallel) and other streaming data sources (PC, S/PDIF). I would not use a kickstarter board, simply because your project is then dependent on the kickstarter project. Personally, for a project like this I would make it board agnostic. You haven't indicated anything that would tie you to a particular board. I would focus on the project development versus the hardware platform but you provide "examples" for a particular board. This also allows folks with other dev boards to participate without having to get the "project" board. Tangent, the online back and forth (claims) of the AlienCortex project and the PapilioOne are, as Bohr would say, interesting. <snip> > > Before going any further, I'd like to solicit suggestions and recommendations from the myHDL community: There can be benefit of completely defining the goals and specification of a project and developing the project to the specification. I think for this "project" you can start building the IP/cores/blocks. Completely define the interfaces required to build the system and completely define and document the cores as you build them. Unless you are looking to do a kickstarter type project, I would start basic and create some inertia, keeping in mind you final goal. Start simple: * Select your licensing scheme (source code and documentation) * Select your hosting site * Select one of the "cores" and *start* working on it. I assume you are interested in building the project completely in Python/MyHDL versus system design, i.e. integrating a bunch of blocks. If that is the case, capture the overall project in a simple sentence or two and start building the IP for the project. If you start with the DAC check out a previous MyHDL community member's work, http://www.myhdl.org/doku.php/projects:dsx1000. > > 1. Would you be interested in supporting this project with mentoring, infrastructure, and/or code? > > 2. I think I'd like to document project progress on a wiki. Recommendations? Alternatives? Should I use a page on the myHDL wiki? Or would a blog be better (possibly with a wiki)? > The wiki is a possible spot, also, Sphinx is a popular method for documenting Python projects. Both GitHub and BitBucket support static pages where you can post the Sphinx output. > 3. Is it OK to use the myHDL list as a forum for this project, or should it get its own facilities? I don't see an issue (I am just one vote though). If the day came were core development and user discussion activity is too high, I imagine a dev and user groups could be created. Regards, Chris Felton > > 4. What is this project missing? > > > Thanks, > > -BobC > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 |
From: Bob C. <Fl...@gm...> - 2011-10-01 23:31:32
|
Hi Chris, On 10/01/2011 12:15 PM, Christopher Felton wrote: > I would not use a kickstarter board, simply because your project is then > dependent on the kickstarter project. > > Personally, for a project like this I would make it board agnostic. You > haven't indicated anything that would tie you to a particular board. I > would focus on the project development versus the hardware platform but > you provide "examples" for a particular board. This also allows folks > with other dev boards to participate without having to get the "project" > board. > > Tangent, the online back and forth (claims) of the AlienCortex project > and the PapilioOne are, as Bohr would say, interesting. Well, I already bought the board! It should ship Real Soon Now... My hobby budget allows for no other board purchases in the near-term. From a technical perspective, I found the Papilio to be a PITA for newbie FPGA folks like me: - It is little more than a breakout board. - It lives in its own universe (no standard interconnects). - It does little out-of-the-box (the FPGA doesn't even come programmed with a useful self-test demo). However, for what it is, the Papilio is truly a decent piece of hardware at a great price. Bryan's board, OTOH, screams "Use me!": - On-board peripherals and interfaces are simple and generic, making them useful for multiple projects. - Ease-of-use has been addressed at multiple levels: * The "Core-Pack" integrates several proven SoC-level ready-to-run projects in a cross-platform package that even integrates the programming tool on PS, Mac and Linux platforms (a real technical accomplishment). * Several ready-to-run soft processors are included. * Multi-core AVR support is provided, with 1, 2 and 4 cores supported. * For the AVR cores (both single and multi), free unlimited custom versions of 3 commercial compilers from MikroElektronika are included (quite a coup). IMHO, and from my perspective and for my specific needs, Bryan's feature and value propositions excel on all levels, not just compared to Papilio, but also when compared to any other FPGA dev board available on the planet. Digilent is the next closest I found, and it isn't all that close. That is the only reason I'm Bryan's customer instead of Jack's or Digilent's: It's all about what I want for my own uses, how functional it is, and how I can get it all for the least money. I became Bryan's backer on the day his KS project appeared: The moment I saw it, I knew it was what I wanted. At the time, I was literally a day or two away from placing an order for a Digilent board! I've repeatedly communicated with both Bryan and Jack, and have read everything each has written publicly. Bryan supports his arguments extremely well, and (to me) Jack doesn't. It is actually worse than that: I believe Jack may have emotional issues that have spilled over into what should be a merit- and evidence-based discussion. He uses innuendo and appeals to authority rather than stating clear dates and verifiable facts. If he has a good argument to make, he has gotten in his own way while trying to make it. Despite already having already backed Bryan's board, I contacted Jack when he started his own own KickStarter project (http://www.kickstarter.com/projects/13588168/papilio-fpga-shield-for-arduino) to try to help him see the limited appeal of his approach, and to warn him that his project would probably not exceed 50% of his goal (an amount I based on my analysis of other electronic KS projects). I gave him a whole list of suggestions to improve his presentation and broaden his appeal (again, based on what I saw other successful projects do). While he did slightly update the content of his video, he did nothing to make his overall pitch more attractive, to make his support levels more enticing, or to make his minimum monetary goal more realistic. Not surprisingly, his KS project failed. Quite surprisingly, it failed within 10% of my predicted yield! Basically, it seems clear to me Jack didn't bother to do any due diligence investigation of the KS market, so he wound up creating a product and pitch that had little chance of success in that universe. And even when I did an analysis for him, and freely shared my conclusions and recommendations, he generally ignored them (or he may have failed to comprehend them - he never questioned the reasoning behind my observations and suggestions). The impression I was left with was simple: When it comes to his business, Jack doesn't play well with others. He is the Commanding Officer, and he is alone on the bridge. Which is totally his prerogative. This matches well with Bryan's public descriptions of his interactions with Jack. The thing is, I absolutely believe the market is more than big enough for *both* Jack and Bryan to succeed and even thrive (along with Seed Studios, SparkFun, AdaFruit, and all the others). I also believe they should be 'coopetitors', innovating together (even selling each other's hardware) while each leaves the other to their own product focus. Bryan has publicly wished Jack nothing but success, and has repeatedly encouraged him to innovate and compete, rather than complain. Jack has never responded in kind. Unless, of course, you take Jack's KS project to be a de-facto acknowledgment of, and agreement with, but poor copy of, Bryan's strategy, focus, features, and arguments. If you look at the timeline of Bryan's and Jack's public actions and statements, a clear pattern emerges. Jack's actions seem to run completely counter to his words: - Jack creates Papilio - Jack creates Papilio 'wings' with individual peripherals - Bryan works (and lives!) with Jack - Bryan and Jack part ways (with tension, but no acrimony at that time) - Bryan designs some music-related sequencer and synthesizer boards, none reaching full implementation until the current board - Bryan unveils his KickStarter project - Internet bickering starts - Jack, having previously rejected using KS (one of the reasons they parted ways) suddenly creates his own KS project with feature-for-feature functionality surprisingly equivalent to Bryan's, but without the tight product focus and OOBE: * Jack tries to sell a board that has no working prototype, compared to Bryan's fully tested board * Jack also adds an Arduino pin-out to the Papilio, but fails to add 5V level shifters, making it incompatible with many Arduino shields * Jack also integrates SRAM on the board with the FPGA * Jack adds similar I/O integrated as a separate board, rather than integrating it into a single board * Jack creates the "Community Cores" vapor-ware to match the already-working Core-Pack * Jack sets his functionally equivalent kit price to be a close match to Bryan's If jack had done any of this *before* Bryan's KS project existed, he'd at least have an evidence-based argument to make. But instead he rushed out a half-baked 'me too' KS project that failed. When Jack tried to accuse Bryan of using his work without attribution, Bryan correctly pointed out that the base Papilio is little more than a breakout board. Bryan also made it very clear that every feature Jack complained about came either from published articles and/or app notes, all of which predated Jack's own Papilio work. Bryan had the good taste *not* to accuse Jack of claiming all that 'prior art' as Jack's own work. Jack's accusations of intellectual knowledge theft abruptly ceased immediately after Bryan's post. The thing is, Jack makes much of his living from his GadgetFactory product line, and I would imagine any close competitor would be viewed as a direct threat to his livelihood. I believe Bryan when he says that during his time with Jack he encouraged (maybe even nagged) Jack to expand beyond his current narrow 'hard-core' project market in two ways: 1) To make it easier for newbies to get started, and 2) to provide pre-integrated platform-level functionality out-of-the-box. Jack disagreed, chose the direction he wanted his business to go, and he and Bryan parted ways. I helped convince Bryan to find a better balance between Open licensing and closed business development, to use the 'delayed Open' release schedule and dual-licensing (used by many other companies in the Open space), along with an 'abandonment' release commitment. I think this is precisely the right balance in today's economic and legal climate. And *nothing* prevents *anyone* from reverse-engineering and cloning Bryan's hardware and software! (I may even do so myself.) All Bryan wants is a little bit of a head start based only on his own implementations: He is willing to go head-to-head with anybody and everybody. I also convinced Bryan to ship a full schematic, complete BOM, and annotated VHD files with the board, holding back only the testbenches, Spice analysis, layout and Gerbers. I simply showed him that, since his current board is 2-sided and uses the 3E PQ208, it is trivial to extract the schematic. He wanted to go to 4-layers, but it would have delayed the ship date by at least a month. (I'm amazed the board meets full timing specs with only two layers, but Bryan assures me it does. Quite an engineering accomplishment!) Based on my own experience with each of them, I can say Bryan is much more open to soliciting, responding to, and acting on external input than Jack. At least when it comes to the specific kinds of input I provided to each of them. Bryan has his own business goals, and he is a realist who knows how important the Open community is to his ultimate success. All the functional and porting-related changes he has made to the Open cores in the Core-Pack will be published when the boards ship, as well as being offered as patches to the individual projects. Bryan wants to delay all file releases as long as possible (until board ships) mainly to avoid releasing crap: He wants everything released in sync. He also lacks the time to interact with the community: He intends to improve each product feature until the day the boards ship. It is a simple legal fact that the release provisions of Open licenses don't apply until *after* a product is shipped, and not a moment before. My own project, if successful, will be added to the to the Core-Pack, in addition to being released independently. My secret agenda is to use that effort to encourage Bryan to release some/all of the Core-Pack platform code under an Open license by including in my release a self-installation script to wrap the generated binary. I'm also on a mission for myHDL to be the default HDL for Bryan's board (much as the MikroE compilers are the default compilers), which is why I intend to document my project to death and make it as Open as possible. I hope the combination of Bryan's platform and my project will make it the 'go-to' platform for myHDL education and evaluation. The mention of myHDL on his KS project pages was also my doing. My project can't really be completely board-agnostic simply because it needs an analog interface, and some planned synthesis spins will require buttons, serial and/or parallel interfaces, and even an integrated uP core (making it dependent on FPGA size). Plus, I don't yet know enough to know *how* to make it board agnostic! I intend to provide not only the project itself (files), but also port it to the first board. I will be *very* happy if my project gets ported to work on the Papilio (and Digilent and and other FPGA dev boards), and to make it more generic and platform-agnostic. I would gladly and thankfully review all patches submitted to make that happen! But Bryan's boards will be shipping 'soon', and my project could easily take 6 months to get to its first full-featured functional release (remember, I am a newbie), though I intend to keep my development tree public so anyone can copy it whenever they wish (and provide help!). -BobC |
From: Bob C. <Fl...@gm...> - 2011-10-02 00:38:04
|
My apologies to all list members! My prior post should have been directly addressed. I didn't intend to broadcast all that off-topic content (though I hope it was at least somewhat entertaining). -BobC |
From: Sébastien B. <seb...@mi...> - 2011-10-02 08:16:42
|
On 10/02/2011 01:31 AM, Bob Cunningham wrote: > Bryan's feature and value propositions excel on all levels, not just compared to Papilio, but also when compared to any other FPGA dev board available on the planet. OMGLOL, how about those? http://www.dinigroup.com |