Dave Lacey - Technical Director of Software Tools at XMOS
I think I started coding on a ZX Spectrum when I was about 11. On that computer, I started off with BASIC and then experimented with Z80 machine code (no assembler though—I had to assemble it by hand on paper).
I did my undergraduate at Oxford University and I actually studied Mathematics and Philosophy. I then went on to get my doctorate in computer science, with an emphasis on compilers. Since then I’ve been conducting research in compilers and working to develop tools for software development.
Previously I was working at another semiconductor company called Clearspeed, that specialized in High Performance Computing. That company was also in Bristol; the South West of Britain has quite a community within the semiconductor companies, which goes back to the INMOS and the transputer in the 1980s. I ended up at XMOS through people I know in this community. XMOS is closely connected to INMOS. David May, who is our CTO was involved with both companies.
The XMOS Development Tools! With slightly less self-promotion: I use Emacs for editing, and of course that can do anything (http://xkcd.com/378/).
For software, I’m a bit of a scripting addict. If a task is remotely repetitive I’ll try and hack up something in Perl or Python to do it for me. I think every programmer should learn to do this comfortably to be productive.
I’m working on several different parts of our development tool chain as well as looking at what new technology we can harness to make our tools even better.
Yes, that’s right. Quite a lot of my day job involves doing compiling. There’s also an aspect to the job where I spend some of my time looking into future directions for the tools, including features such as compilers, programming languages, software timing analysis, things like that. Still, most of my time is spent doing development making sure the compiler and the toolchain work well.
Yes, we’re a relatively small semiconductor company, and as a result all of our engineering is centered in Bristol. We’re all in the same building, so the tools guys are right next to the silicon design guys. It’s nice because it allows the tools and the hardware to develop in parallel with each other, which is quite important because silicon is only as good as the tools that target it.
It’s a very good place to work, with lots of clever, hard-working people. We aren’t what people would consider a start-up any more, but we’re still a relatively small company, especially for semiconductors. There’s a lot of exciting stuff going on, with new technology being developed all around. People have a chance to try things and do new stuff to get a competitive edge. These chances might not exist in another company.
We do. There are two main ways that the feedback comes in. We have customers who are designing our chips into their products, with whom we work quite closely. We also have a community website – xcore.com – with forums where feedback often comes from as well. The nature of our chip is that people with different backgrounds use it. One thing that is quite interesting is that the chip can do things that previously you wouldn’t necessarily do using software; you would use FPGA devices. So we get people who are used to designing with FPGAs and with using EDA design tools. We also have some people who come from an embedded software background and then we have some people who are system integrators that do a bit of everything – these people do whatever is needed to put the system together. All three of these groups have different ways of thinking about development, even though the end result is often the same. This means we have to make sure that our tools are natural for those people coming from the various backgrounds.
Our chips are much more than simple microcontrollers. They’re like microcontrollers in that they are programmed in C, so you get all the benefits of the software development process. In terms of application, however, they can do things that FPGAs can do as well. For instance they can do real-time I/O tasks really well due to the deterministic nature of the architecture and built-in timing support. They can also do things that traditionally would use a DSP chip for. The real-time features, predictability and built in timing support mean that you can tackle areas that you generally implement in hardware, using software.
We do have to adapt it quite a bit. We put some specific optimizations in there for the special I/O parts of the device. It’s a multi-core architecture so we have to put in mechanisms to handle that. Another big difference is, because the architecture’s properties make it predictable, we have a very nice timing tool (XMOS Timing Analyzer – XTA). So, when you’re writing a program and you want to make sure that some part of your program meets timing requirements (for example you want two pin samples to be no more than 200ns apart) the tool checks the code to make sure that it will meet those timing constraints. It’s a tool that shows the power of the architecture, and that’s unique to us.
We bundle a simulator with our tool set, which is very accurate. It also simulates all of the communication of the chip. The simulator can be operated standalone, or we provide a plug-in so you can integrate it into another verification infrastructure.
The best part about all of this is that all the tools are free! They can be downloaded from our website.
Details are available on our website. There are the basic-level boards that can be used to test out different features of the architecture and chips. Second we have development platforms such as our motor control platform that people can integrate their own IP into and customize to fit into their particular areas of interest. Third we have reference design boards that come with ready-to-use software designs; these include our USB Audio 2.0 and iPod dock designs.
When you want an integrated solution for microprocessor tasks, DSP tasks or FPGA real-time tasks. XMOS devices are valuable when you find that you need something that’s all brought together or could be brought together. When you do that, you get very tight integration with low latency between parts on one processor and also a reduced BOM cost. Examples of that are things like audio processing, industrial control, and also in instances where you want to implement glue logic from one interface to another.
We have a tool that has just come out, which is called XScope which is like a hardware scope, but from within the software. It’s an instrumentation framework that you put into your software to read values within the codes. As it has a very low overhead, it will get the information that’s running on the chip and then send out over to a connector in real time so you can see the information about the internals of the design as you run it on hardware.
System designers are requiring more and more software skills and I can only see that increasing as time goes on. Our solutions are a good example; you can now do things in software that previously you would need silicon/hardware for.
The same as always: faster, better, cheaper…
Headquartered in Bristol, UK, XMOS has developed the next generation of 32-bit, multi-core, embedded processors that significantly lower the development time and cost of electronic products. Its revolutionary multi-threaded processor combines the efficiency of a RISC processor, the performance of a digital signal processor and the unique flexibility of implementing interfaces in software, not silicon. The XMOS multi-core architecture supports high levels of real-time performance and enables systems to be scaled to meet performance requirements. XMOS was founded in 2005 and has employees in the US, UK, India, Hong Kong, China and Taiwan.
For more information about XMOS and its solutions, please visit http://www.xmos.com or the XMOS open community site at http://www.xcore.com.