Optimizing Mill System Design: The view from Low Earth Orbit

Ivan often talks about the view from 40,000 feet. I need to go a bit higher, outside the chip to the system level.

I’m an embedded real-time developer who also does target system design that overlaps the digital, electrical, electro-mechanical, communications and robotic domains. I’m best at developing algorithms then implementing them in the smallest platform needed to get the job done “on time”. The targets range from an ARM M0 up to a multi-core ARM v8, sometimes with multiple instances connected together.

My algorithm development often requires tons of simulation/modeling and big-data work (statistical analysis), from large static data archives to real-time streaming video, and this work can easily consume the small-ish Xeon cluster I use. Since I have a cluster available, I often start my implementation using QEMU to emulate ARM-based target system candidates. But it is a pain to do cross-architecture emulation.

The Mill architecture presents some interesting opportunities for someone like me, with the view to using a single scalable architecture from my cluster all the way down to my embedded systems. In particular, the thought of emulating a number of Mill Minis on a Maxi seems like a dream come true: I’d tell the Mill compiler to emit code for a Maxi, but constrained to use only the resources and timing of a specific Mini specification. Basically, zero-overhead CPU emulation.

Ideally, this *could* facilitate hardware-software co-design for the embedded target, making the process both faster and simpler, and thus far more practical. At present, the two are often separate project phases.

Which leads me to the real topic of this post: Let’s say algorithm development and testing has been completed, and I have working code for my system: Can/will the Mill specification tools be expanded to help find/evolve the ideal target hardware solution?

The only hard constraint would be the target system timing requirements. All other constraints could be expressed as “preferences”. For example, total system power could be expressed as “1-5 watts, with lower power strongly preferred.”

A typical optimization would concern memory speed: Given the memory demands and the system timing requirements, what memory architecture works best overall? Multiple slow channels or fewer fast ones or something in-between?

This, in turn, would push back into the Mill itself: For a specific system, would multiple simple Mill cores be preferred over fewer larger cores, or just a single big core? What are the trade-offs between a single Mill core per memory channel, versus multiple Mill cores sharing a single memory channel, versus a larger Mill core using multiple memory channels?

We have lots of hardware terrain to explore to find the best target system. Can that search be simplified? Can/will the Mill architecture itself contribute to that simplification?

A common problem involves I/O: Sometimes it is best for the CPU to read directly from the hardware, other times it is best for a DMA channel to move data from the hardware to memory. But using DMA means managing memory contention, resulting either in adding a separate memory channel for DMA, or increasing the bandwidth of a shared channel. Not to mention cache issues.

With the Mill, I also have the option to scale the CPU itself. But this would require having a rich set of options available in the market, since I have no desire to roll my own silicon. And that pushes our optimization strategy out into the market, which in turn involves the Mill Computing business model.

Will Mill SoCs be available from multiple competing vendors, like ARM, or will it be constrained to a single vendor, like TI DSPs? Will the Mill be available as a family of architecture and RTL licenses, in addition to whatever chips Mill Computing choses to fabricate?

As someone in the embedded market, I very much hope the ARM approach is used, with silicon from Mill Computing existing mainly to 1) provide reference implementations, 2) seed the chip market, and 3) provide development systems.

I’d like to see a rich and diverse Mill SoC market that will provide no only my next cluster, but also the wide range of embedded system targets I need to deploy.

The key will be not just hardware diversity and availability (and the Mill business model), but also the tools to explore system architectures within that domain, first with emulation, then in hardware selection.

Is Mill Computing working on such system-level tools?