Tuesday, April 26, 2011

FPGA's rock

So I'm in an R&D organization at work, I lead or am involved in a lot of projects.

One of the projects I'm working on is one where we are streaming multiplexed, phase-synchronized audio over a wifi link to an accessory driving a speaker array hooked up to I2S peripherals.


We're using a FPGA to instantiate all the peripherals, those no simple COTS solutions available that we can use.   So we leveraged some work I did before with a Cyclone-III based design running ThreadX from ExpressLogic (highly recommend, those guys rock and their code is tight).   Our previous design was super clever:  we ran the NIOS at 64MHz, attached it to a Numonyx NOR/PSRAM stacked device, and double-clocked the memory (x16) at 128Mhz.  This gave us an effective x32 interface at the CPU (128MHz x16 = 64MHz x32, the native clock and bandwidth of our avalon architecture).

The previous architecture was super cool and really optimized for our memory part.  But like all things that are optimized, they aren't very flexible.   We needed to achieve 13Mbps across the wifi link, and we just ran out of bandwidth clocked at 64MHz when we shoveled data across the wifi link (too much processing required for moving the data).   We couldn't just up the CPU clock, because it was tightly coupled to the PSRAM memory interface (2x the CPU clock), and if we increased above 64, we'd exceed the spec of the memory of 128MHz.

Taking the easy route, I went brute-force and I changed the design to add a DDR2 400 part, which would allow us to up our CPU to 128MHz (128 MHz on a x16 PSRAM part would've been obviously memory interface bandwidth limited).  I'd have the everything boot from NOR, copy the code to DDR, then execute from DDR.   Run the DDR full rate x16 at 128MHz, so effective x32 data to the CPU at 128MHz.  Cool, memory bandwidth and CPU clock double from the previous design, problem solved.

So I spent the weekend implementing that, and of course, nothing goes well.  Our old design was based on Quartus 9.1, but we had to upgrade to 10.1 to get the latest DDR controller...  And of course, that broke.  Timing broke.   New nets added to Top.   Dogs and Cats started fighting, it was terrible.  Enter Scott & Cal (Altera FAE's), one of the prime reasons why I stick with Altera.

At 10:00 pm, I send Scott an email because I'm failing timing, the PLL's not instantiating correctly, the fitter auto-placed pins at the wrong location, and my thermostat was set wrong.   So Scott set's up a Webex at 10:00, and we work for 1 hour slogging through all this. 

After 1 hour, my pins are placed, I sent the netlist and routing instructions off to the CAD group, and we're back on track. Scott and Cal:  absolutely brilliant.  You want the best, use the guys from Altera, they know what they are doing and their stuff Just Works.  It's brilliant.

In the words of John  "Hannibal" Smith:  I love it when a plan comes together.