2
\$\begingroup\$

I'm currently designing a digital mixing console. We have a somewhat large number of ADCs and DACs (more than the multi channel audio serial port on the processor can handle). We decided the solution for this was to use an FPGA to interface with the data converters and let the processor access the data through the RAM in the FPGA. We have not yet picked out a FPGA.

From what I have read we can configure the FPGA RAM as being a NOR non-multiplexed 16-bit device through the GPMC. Is this correct? And my other question is it would probably be too slow to keep the data in RAM of the FPGA so would it be possible to set up a DMA transfer from the FPGA RAM to other memory in the processor that is easier and faster to access? Or would we need to use a PRU to copy the data?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ GPMC, PRU? How is this question related to TI? How is NOR and non-multiplexed related to the RAM in an FPGA? FPGAs have internal SRAMs. This RAM (BlockRAM, Embedded BlockRAM or Distributed RAM) is very fast, at least faster than an ARM can handle. The question is: What interface will you use? The limiting factor is your ARM-FPGA interface and its latency. \$\endgroup\$
    – Paebbels
    Commented Apr 23, 2016 at 21:14
  • \$\begingroup\$ The TI AM335x processor has a GPMC (general purpose memory controller, and 2 PRUs (programmable real time units). SRAM is faster but I cannot access it fast enough I don't believe through the GPMC interface. I'm asking how I interface with the SRAM on the FPGA. \$\endgroup\$
    – Caleb Merchant
    Commented Apr 23, 2016 at 21:24
  • \$\begingroup\$ So you could implement a memory interface in the FPGA, so it acts as a normal memory chip.The advantage could be that the FPGAs SRAM is visible in the ARMs global address space allowing DMA. Do you have other interfaces: PCIe, parallel buses, AMBA .... ? What memory interfaces are supported by the GPMC: (S)SRAM, DRAM, Flash, SD-Card (QuadSPI) .. ? \$\endgroup\$
    – Paebbels
    Commented Apr 23, 2016 at 21:31
  • \$\begingroup\$ The GPMC supports NOR, NAND, and SRAM. But in the pin mux tool that TI offers is gives options to NOR and NAND multiplexed and non-multiplexed and I read somewhere that SRAM interfaces like NOR. \$\endgroup\$
    – Caleb Merchant
    Commented Apr 23, 2016 at 21:55
  • 2
    \$\begingroup\$ I don't know this ARM, but the usual parallel NOR interface provided by CPUs are compatible with parallel SRAMs. Which is probably what you want to use. Serial NORs & serial SRAMs are completely out of question (they are usually single or multi-data-bit SPI interfaces), ditto for the NAND interface, and it's very unlikely that you want to emulate a DRAM with your FPGA for the ARM. Whether to use multiplexed or non-multiplexed interface: that depends on the number of pins available, and the speed you want to achive. \$\endgroup\$
    – Laszlo Valko
    Commented Apr 23, 2016 at 22:14

1 Answer 1

Reset to default
3
\$\begingroup\$

I will make some assumptions: since this is mixing audio, you will want to sequentially read all of the ADCs at some fixed synchronous rate (like 96kHz), and sequentially write all of the DACs at the same rate. I think the PRU will be the easiest way to implement a fast data-pipe to/from an FPGA.

There are two PRU processors in a AM335x Sitara processor, and each has 32 input pins and 32 output pins. Since you would probably need some control signals and are likely using 24-bit codecs, that should work out nicely. You could dedicate one PRU to receive data and the other to send data. With tight C code, I estimate that you could get at least 10 samples per microsecond in each direction (30 megabytes/second), and more with assembly language.

I have put multiple I2S audio interfaces into an FPGA, and it's not that hard. As you said, the codecs could move data to/from FPGA sram, and after each codec cycle (every 10.417 microseconds at 96kHz) the PRUs could read/write the data as a contiguous block. A simple sequencer in the FPGA could respond to strobes from the PRU to walk through the block of data. In the Sitara, a Linux process can allocate a block of memory to share with the PRU. I've put C structures and arrays into shared ARM/PRU memory to allow the Linux process and the PRU to share data as C variables.

Hope that helps.

\$\endgroup\$
8
  • \$\begingroup\$ Yeah this is very helpful. And your assumptions were correct. I was thinking about the same thing as you were saying, however, I'm assuming left justified data because one of my ADCs does not support I2S. But, the complexity is the same. And also I didn't know if I could use DMA transfer from the FPGA SRAM. If I can I'll use that, if not I can use the PRUs like you stated. Either way I'm okay with. \$\endgroup\$
    – Caleb Merchant
    Commented Apr 24, 2016 at 2:22
  • \$\begingroup\$ Yeah, I2S and Left-Justified are almost identical - I allowed my FPGA codec interface to handle both by simply adding two D-flops and a 2:1 mux. \$\endgroup\$
    – Mark
    Commented Apr 24, 2016 at 3:05
  • \$\begingroup\$ I'm just curious, what FPGA did you use? I'm not exactly sure how powerful my FPGA needs to be. \$\endgroup\$
    – Caleb Merchant
    Commented Apr 24, 2016 at 3:07
  • \$\begingroup\$ I have never used DMA on the Sitara, because the PRUs can deposit data directly into the Linux application's memory, much like DMA (but under control of a C program). Programming DMA looks daunting to me. \$\endgroup\$
    – Mark
    Commented Apr 24, 2016 at 3:09
  • \$\begingroup\$ I think almost all FPGAs will be fast enough, it's more a matter of the right size. I used an Actel 42MX16 (an anti-fuse based part) for the codec interface (it also did a lot of other things, like capturing motor velocities and positions). I clocked everything at 18.432 MHz, and the part was loafing at that speed. Today, I would use something flash-based, like a A3P part. Actel is now MicroSemi. \$\endgroup\$
    – Mark
    Commented Apr 24, 2016 at 3:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.