Redesigned Grid
The idea of making all bricks 60mm tall was a bad one: some bricks like faders will need it, but others like the keyboard or trackpad won't, and we should not waste all that vertical space. Therefore, we have decided to redesign our grids in order to make them more modular.
For that reason, bricks will now come in three possible heights:
1. Short: 20mm
2. Medium: 40mm
3. Tall: 60mm
Of course, any given brick will come in a single height — no SKU explosion!
Accordingly, grids will come in three heights as well:
1. Short (used with tall bricks)
2. Medium (used with medium bricks)
3. Tall (used with short bricks)
By design, medium and tall grids will have a lot of empty space in them, which could be used for either extra batteries or additional computing power (in the form of the NVIDIA Jetson AGX Xavier).
Our original grids had a 2 × 6 footprint, which meant that we had to mount two USB hubs on them in order to provide 12 USB ports, which was not very elegant. Furthermore, because we will use multiple grids of different heights, having smaller grids is probably better. Therefore, we have decided to go for a 2 × 4 footprint, but to use two of them in front of every Single-Board-Computer, as can be seen on this new setup. This 960mm × 600mm configuration now gives us 8 × 2 × 2 × 4 = 128 OTO units in an 8-SBC setup, allowing us to include every single Mutable Instrument module, including the non-redundant discontinued ones.
The reference setup also shows the 5 most relevant KORG volca modules on the left side, like the volca nubass, which uses the KORG Nutube vacuum tube. These modules won't sit on any grid (it would be a massive waste of USB ports). Instead, they're just there to show what a typical configuration might look like. Also, they clearly demonstrate the need for more MIDI ports, which will be addressed by offering a 1 × 1 M9 bricks made of 9 MIDI ports.
On the reference setup, we've also moved the Grayhill Touch Encoder at the top of the Channel module, because it will be used as master volume control by default. And we've added two more of them underneath the 128-pad grid, on top of two SpaceMouse modules that could be used to manually modulate sounds using both hands with 12 degrees of freedom — try doing that with an analog instrument!
The 128-pad grid will be an actual LinnStrument 128 with a custom made enclosure for it to fit within a 6 × 3 area. And because the LinnStrument's code is available under an Open Source license, we should be able to integrate it into the platform quite deeply.
Also, because mixing is such an important function of the system, we have decided to add one D1E4 brick (one display and 4 encoders) on top of every dual fader brick. This will provide two encoders with direct display feedback for each fader, thereby allowing the modification of the most common channel settings without without having to use the shared Channel module.
With so much more space available to us on the control surface, we've also managed to develop a much more rational layout for the modular synthesis section: ports on the left (9 × MIDI and 48 × Audio/CV), sound and modulation sources next to the ports, sound modification and plumbing in the middle, and sequencing and control on the right.
In order to make all that work, we will need an 8-port USB hub. Fortunately, the HX3 USB 3.0 HUB Controller can do that, thanks to Shared Link™, a proprietary feature that doubles the number of USB ports, creating 8 ports from a 4-port hub.
We're now working on a more detailed USB topology for the whole system.
The idea of making all bricks 60mm tall was a bad one: some bricks like faders will need it, but others like the keyboard or trackpad won't, and we should not waste all that vertical space. Therefore, we have decided to redesign our grids in order to make them more modular.
For that reason, bricks will now come in three possible heights:
1. Short: 20mm
2. Medium: 40mm
3. Tall: 60mm
Of course, any given brick will come in a single height — no SKU explosion!
Accordingly, grids will come in three heights as well:
1. Short (used with tall bricks)
2. Medium (used with medium bricks)
3. Tall (used with short bricks)
By design, medium and tall grids will have a lot of empty space in them, which could be used for either extra batteries or additional computing power (in the form of the NVIDIA Jetson AGX Xavier).
Our original grids had a 2 × 6 footprint, which meant that we had to mount two USB hubs on them in order to provide 12 USB ports, which was not very elegant. Furthermore, because we will use multiple grids of different heights, having smaller grids is probably better. Therefore, we have decided to go for a 2 × 4 footprint, but to use two of them in front of every Single-Board-Computer, as can be seen on this new setup. This 960mm × 600mm configuration now gives us 8 × 2 × 2 × 4 = 128 OTO units in an 8-SBC setup, allowing us to include every single Mutable Instrument module, including the non-redundant discontinued ones.
The reference setup also shows the 5 most relevant KORG volca modules on the left side, like the volca nubass, which uses the KORG Nutube vacuum tube. These modules won't sit on any grid (it would be a massive waste of USB ports). Instead, they're just there to show what a typical configuration might look like. Also, they clearly demonstrate the need for more MIDI ports, which will be addressed by offering a 1 × 1 M9 bricks made of 9 MIDI ports.
On the reference setup, we've also moved the Grayhill Touch Encoder at the top of the Channel module, because it will be used as master volume control by default. And we've added two more of them underneath the 128-pad grid, on top of two SpaceMouse modules that could be used to manually modulate sounds using both hands with 12 degrees of freedom — try doing that with an analog instrument!
The 128-pad grid will be an actual LinnStrument 128 with a custom made enclosure for it to fit within a 6 × 3 area. And because the LinnStrument's code is available under an Open Source license, we should be able to integrate it into the platform quite deeply.
Also, because mixing is such an important function of the system, we have decided to add one D1E4 brick (one display and 4 encoders) on top of every dual fader brick. This will provide two encoders with direct display feedback for each fader, thereby allowing the modification of the most common channel settings without without having to use the shared Channel module.
With so much more space available to us on the control surface, we've also managed to develop a much more rational layout for the modular synthesis section: ports on the left (9 × MIDI and 48 × Audio/CV), sound and modulation sources next to the ports, sound modification and plumbing in the middle, and sequencing and control on the right.
In order to make all that work, we will need an 8-port USB hub. Fortunately, the HX3 USB 3.0 HUB Controller can do that, thanks to Shared Link™, a proprietary feature that doubles the number of USB ports, creating 8 ports from a 4-port hub.
We're now working on a more detailed USB topology for the whole system.
Wouldn't it be much easier to use a DSP like a Sharc or Sitara?
I mean you have a big FPGA with DSP Slices and you want to use an ARM Core on it for floating point operations? That doesn't really make sense to me.
Sharc or Sitara DSP are available in various types including ARM Cores and are specialized for floating point operations.
Also I saw that you want to use 4 Layer PCBs. Consider using PCBs with at least 6 Layers so you can use plane layers for low impedance power rails.
A possible stackup would look like this:
L1 -> Signal layer
L2 -> GND
L3 -> split plane +3V3 / positive supply
L4 -> split plane +5V / negative supply
L5 -> GND
L6 -> Signal Layer
I mean you have a big FPGA with DSP Slices and you want to use an ARM Core on it for floating point operations? That doesn't really make sense to me.
Sharc or Sitara DSP are available in various types including ARM Cores and are specialized for floating point operations.
Also I saw that you want to use 4 Layer PCBs. Consider using PCBs with at least 6 Layers so you can use plane layers for low impedance power rails.
A possible stackup would look like this:
L1 -> Signal layer
L2 -> GND
L3 -> split plane +3V3 / positive supply
L4 -> split plane +5V / negative supply
L5 -> GND
L6 -> Signal Layer
Last edited:
As far as I can tell, the top-of-the line Sitara DSP does thirty-two 16 × 16-Bit fixed-point multiplies per cycle. The top-of-the-line UltraScale+ chip does 3,528 27 × 18-Bit fixed-point multiplies per cycle. Width-aside, we're looking at two orders of magnitude... Corrected for frequency (the Sitara is about twice as fast), we're still looking at a 50× improvement. Of course, the XILINX chip is 10 to 20 times more expensive, but the power/cost ratio remains 3 to 5 times better... And that's before looking at the real-estate and power requirements when using 3 to 5 Sitara chips instead of a single XILINX chip.
For raw DSP power, FPGA-based SoCs are really hard to beat today, mostly because most applications that require reconfigurable logic also require massive amounts of signal processing power. And with the demands imposed by 5G equipment, these chips are only going to get better. There is nothing like that driving the evolution of Sharc or Sitara architectures unfortunately.
Last edited:
You might want to take a look at the standard reference on the subject: Electromagnetic Compatibility Engineering: Henry W. Ott: 9780470189306: Amazon.com: Books
This is a decent stack-up for a 6 layer PCB for audio, I think. It's good that it gives a reference plane adjacent to each power plane and top / bot layers, but it gives you no internal routing layers. You might want to look into fabrication cost and decide if 6 layers is worth it or you want to move to 8. The last time I quoted a job, the big price break was at 4 -> 6 layers. The added cost to go from 6 -> 8 was minimal.
Tough to say, with 8 layers you have a lot of options and it's hard to go too wrong.
Here is a page from the author of the book that Mark linked:
PCB Stack-Up - Part 4
All of the options on this page work. I'd probably do something like Figure 10 and use ground fill with generous via stitching, but it depends.
Figure 11 is great but it might require a custom stack-up from the board house. The key to a stack-up like that is the close spacing of the power and ground plane pair. I have read rules of thumb like the spacing must be something like 0.5mm or less to really take advantage of inter-plane capacitance, so about 20 mils. A custom stack-up is not uncommon for commercial products but could be cost prohibitive for a self-funded project. I'm also not sure if there is real benefit to be had for an audio device.
sciencesky, I must apologize for having dismissed your idea a bit too quickly. I have given it some more thoughts overnight, and I am starting to see an alternative configuration that might work even better.
Our goal is to get as much DSP power as possible, with as little latency as possible. One solution could consist in using one AM5748 directly attached to each AK5578EN chip. Doing so, we would get rid of the XMOS and XILINX chips, as well as the single-board-computers, making for a much simpler architecture. In a nutshell, you'd have a cluster of 64 Sitara chips...
Each of the two DSP cores found in the AM5748 give you 32 16 × 16-Bit fixed-point multiplies per cycle. At 1.5GHz, that's 96 DMIPS. With 8 chips on an ADC board, that's 768 DMIPS. And with 8 boards (Cf. reference setup), that's 6,144 DMIPS.
It is hard to compare that against a XILINX XCZU15EG because of the difference in width, but 3,528 DSP slices running at 750MHz will give you a theoretical 2,646 DMIPS peak performance. Of course, this would assume that you can route your signals through all the DSP slices offered by the FPGA, which is highly unlikely.
From a pricing standpoint, you can get an AM5748 for about $50 when buying hundreds of them, while the XILINX XCZU15EG will cost you around $1,000. Therefore, the performance/cost ratios are very similar (the quick math I did yesterday missed the fact that you have two DSP cores on the AM5748).
This architecture would have two main benefits:
- Much simpler in terms of number of subsystems to deal with
- Dramatically easier to program
While the Sitara chips are not as optimized as the XMOS chips for real-time processing, I like to believe that doing all the signal processing on the DSP cores should give us a deterministic-enough behavior.
From there, we would have to figure out a way to mix all the signals produced by the 64 Sitara chips. To do so, we should consider a stem mixing approach, whereby each ADC board would be responsible for mixing its own signals, and any ADC board could mix the stems produced by other ADC boards.
Last but not least, we would have to figure out a proper interconnect architecture between the 8 chips of a grid module and the 8 grid modules of a complete system. With such a cluster, taking advantage of the 2 Gigabit Ethernet ports offered by each Sitara chip might make sense.
Last edited:
The AM5748 is a brand new chip, and the only System-on-Module I could find with it is the recently-announced Lenovo Industrial Intelligence Development Board: Super Edition. It has the following features:
- 2GB DDR3L 1333 high speed memory
- 16GB eMMC high speed storage
- 2 Gigabit Ethernet ports
- 2GB DDR3L 1333 high speed memory
- 16GB eMMC high speed storage
- 2 Gigabit Ethernet ports
Attachments
As an 8 Layer Stackup we always use something like Figure 11.
In my current design I'm working on I also use one of the inner signal layers as plane layers because it has alot of different planes.
But if you don't have complex chips on your PCB, an 8 Layer Stackup is rarely necessary.
In my current design I'm working on I also use one of the inner signal layers as plane layers because it has alot of different planes.
But if you don't have complex chips on your PCB, an 8 Layer Stackup is rarely necessary.
I'm working for a company that is specialized in signal processing but I'm doing the PCB designs and don't have much of a clue about signal processing.
But I think that what you want to do is overkill.
In our current product we are using a single core Sharc DSP and it is capable of doing signal processing for 16ch in and 16ch out and it also connects to alot of more digital channels through Dante.
And with that DSP you are a bit limited but nonetheless you can do alot of stuff with it.
Using one DSP for one channel has the downside that you can't do signal processing on multiple channels if you don't couple the DSPs of the different channels.
But I think that what you want to do is overkill.
In our current product we are using a single core Sharc DSP and it is capable of doing signal processing for 16ch in and 16ch out and it also connects to alot of more digital channels through Dante.
And with that DSP you are a bit limited but nonetheless you can do alot of stuff with it.
Using one DSP for one channel has the downside that you can't do signal processing on multiple channels if you don't couple the DSPs of the different channels.
Yes, this is massively overkill, but it's a big part of the fun.
Also, I should clarify a couple of things: first, while the new architecture suggests one Sitara chip per audio channel, this chip will be used to synthesize many other audio channels; second, each audio channel in the digital domain will be 32-bit at 768KHz or 1.536MHz, so we'll need quite a bit of DSP power anyway.
Might be a good idea to be able to route ADC intput and dac output to /from a DAW interface, perhaps via ASIO. Or, at least have the hardware capable of doing it should someone want to program it that way. All the hardware would likely be much more useful if it can flexibly interface with other common audio processing tools.
Moving Processing to the Edge
We might have found a way to dramatically simplify the overall architecture while making it more powerful and more brick-centric at the same time. The new architecture is based on four main ideas:
1. Moving the ADC and DAC components to the bricks
2. Splitting bricks into two parts (top and bottom)
3. Using USB for the grid-to-brick interconnect
4. Using mixed pins for the bottom-to-top interconnect
Our initial architecture had a very complex stack of boards. The new one is dramatically simpler:
- 2 × 4 USB grid PCB
- Brick bottom PCB
- Brick top PCB
- Stick PCBs (as originally envisioned)
No more Single-Board-Computer, ADC Board, DAC Board, and FPGA System-on-Module. Instead, just a USB grid with USB bricks mounted on it. And this is made possible thanks to the following trick: splitting the brick into two separate parts: a bottom part containing a chip as basic as an ATmega328 microcontroller or as advanced as a Sitara AM5728, and a top part containing all the logic and controls that we might want to fit in there.
The bottom part would be connected to the grid through a USB port, using spring-loaded headers or some magnetic connectors. As originally envisioned, this bottom part could be mounted on the grid in any orientation. The top part would contain the brick's logic and controls, now including things like ADC or DAC converters. The interconnect between the bottom and top parts would provide a mix of pins (single orientation):
- One or two USB ports
- Up to four SPI ports
- up to 16 GPIOs
- Various power levels
- Ground
Interestingly, by switching from an AM5748 to an AM5728, we just lose two Gigabit Ethernet ports, but we gain the ability to source a System-on-Module today that would fit within our bricks (55mm × 45mm): the phyCORE-AM57x. I do not know the price of this module yet, but a similar one goes for $96. And the beauty of the design is that such a relatively expensive module could be used with different tops. In other words, by splitting our bricks into two separate components, we make them a lot more modular, and we make the expensive parts usable for different applications at different times. Of course, one could also make a bottom with a much cheaper chip like a $1 ATMmega328. In that case, only a subset of the bottom-to-top ports would be populated, but this might be sufficient for a wide range of applications.
Then, according to this design, we can move the ADC and DAC converters into the tops of bricks. For example, the Khadas Tone Board is an excellent open source DAC and is only 82mm × 74.5mm, including three RCA connectors. Therefore, I believe that we could make a version that would fit into a 60mm × 60mm brick and put two of these boards on top of each other, thereby enabling a 4-channel audio output brick. And with a bit of luck, we should be able to do the same for audio outputs, thereby offering 8 inputs and 8 outputs on a 2 × 2 OTO surface.
With such a design, the ADC or DAC converters mounted within brick tops would be connected to the brick bottoms over USB 3.0. As a result, we would have a very clean decoupling between audio input, audio processing, and audio output, and we could use off-the-shelf ADC and DAC boards initially, while we focus on the core OTO form factor. Of course, I still want my AK5578EN 32-bit, 768kHz, 130dB ADC and my AK4499EQ 32-bit, 768kHz, 140dB DAC, but these could come a bit later.
I must say that I like this design a lot more than the previous one...
We might have found a way to dramatically simplify the overall architecture while making it more powerful and more brick-centric at the same time. The new architecture is based on four main ideas:
1. Moving the ADC and DAC components to the bricks
2. Splitting bricks into two parts (top and bottom)
3. Using USB for the grid-to-brick interconnect
4. Using mixed pins for the bottom-to-top interconnect
Our initial architecture had a very complex stack of boards. The new one is dramatically simpler:
- 2 × 4 USB grid PCB
- Brick bottom PCB
- Brick top PCB
- Stick PCBs (as originally envisioned)
No more Single-Board-Computer, ADC Board, DAC Board, and FPGA System-on-Module. Instead, just a USB grid with USB bricks mounted on it. And this is made possible thanks to the following trick: splitting the brick into two separate parts: a bottom part containing a chip as basic as an ATmega328 microcontroller or as advanced as a Sitara AM5728, and a top part containing all the logic and controls that we might want to fit in there.
The bottom part would be connected to the grid through a USB port, using spring-loaded headers or some magnetic connectors. As originally envisioned, this bottom part could be mounted on the grid in any orientation. The top part would contain the brick's logic and controls, now including things like ADC or DAC converters. The interconnect between the bottom and top parts would provide a mix of pins (single orientation):
- One or two USB ports
- Up to four SPI ports
- up to 16 GPIOs
- Various power levels
- Ground
Interestingly, by switching from an AM5748 to an AM5728, we just lose two Gigabit Ethernet ports, but we gain the ability to source a System-on-Module today that would fit within our bricks (55mm × 45mm): the phyCORE-AM57x. I do not know the price of this module yet, but a similar one goes for $96. And the beauty of the design is that such a relatively expensive module could be used with different tops. In other words, by splitting our bricks into two separate components, we make them a lot more modular, and we make the expensive parts usable for different applications at different times. Of course, one could also make a bottom with a much cheaper chip like a $1 ATMmega328. In that case, only a subset of the bottom-to-top ports would be populated, but this might be sufficient for a wide range of applications.
Then, according to this design, we can move the ADC and DAC converters into the tops of bricks. For example, the Khadas Tone Board is an excellent open source DAC and is only 82mm × 74.5mm, including three RCA connectors. Therefore, I believe that we could make a version that would fit into a 60mm × 60mm brick and put two of these boards on top of each other, thereby enabling a 4-channel audio output brick. And with a bit of luck, we should be able to do the same for audio outputs, thereby offering 8 inputs and 8 outputs on a 2 × 2 OTO surface.
With such a design, the ADC or DAC converters mounted within brick tops would be connected to the brick bottoms over USB 3.0. As a result, we would have a very clean decoupling between audio input, audio processing, and audio output, and we could use off-the-shelf ADC and DAC boards initially, while we focus on the core OTO form factor. Of course, I still want my AK5578EN 32-bit, 768kHz, 130dB ADC and my AK4499EQ 32-bit, 768kHz, 140dB DAC, but these could come a bit later.
I must say that I like this design a lot more than the previous one...
Khadas tone board may be a pretty good open source dac, but its weaknesses will probably become very evident to some when directly compared with AK4499. Therefore, any outputs should probably be redirectable to the dac of choice, particularly if one were recording from analog outputs.
That's very much part of the plan: it must be possible to do a soft patch of any digital audio signal to any analog audio output.