Battle for the AI toolflow

Feature articles |
By Nick Flaherty

“Inside AI is machine learning, inside machine learning is deep learning and inside that is CNN. AI does not imply CNNs, that’s the hammer that people are using for things like images,” said Jos Martin, director of engineering at MathWorks, whose tools are widely used for AI development.

“I think of machine learning as taking data plus an idea and generating a model that replicates the model that the data represents,” he said. “Anything that you can phrase like that is machine learning, and it incorporates traditional machine learning, CNN as well as deep learning and spiking nets.”

There are multiple steps in the AI development process. “You go through two or three stages. There’s data preparation, often of gnarly data, then you then go through training, and analysis. Then you train lots of different types of models, which might fit best, which are the smallest or the fastest, and then you deploy the models.”

These stages can present a challenge for the AI toolflow.

“The whole intent of what we do is to make every stage is available in the tools. No matter what you want to do in data preparation and checking followed by the coding ability to code up the model and the way to deploy the training,” said Martin. “This is a whole flow and throughout that whole tool chain there might be point tools to deploy to an embedded target, or run a training loop in the middle.”

MathWorks is working with AI developer AImotive on a toolflow for automotive applications. AImotive already supplies the AI technology for Sony’s prototype electric vehicle.

“We can see that there is a growing trend that OEMs want to own the toolchain itself, the integration and the architecture as well,” said Szabolcs Jánky, Product Manager of aiSim at AIMotive.

Next: AI toolflow

“This is because it is all strongly tied to how (process) and what (product) is developed. The tools themselves may be from a third party as long as the appropriate interfaces have been clarified. It sets new requirements towards the tools themselves. Tools need to be open enough to integrate into the toolchain and work with each other seamlessly. It is quite rare for a large OEM to outsource the development toolchain and entirely rely on a single supplier.”

“Anyone who offers the whole flow, just go and do that. But if you ever need to leave it, you have a problem. If you need to join things together you want a tool to do that,” said Martin at MathWorks. “You can use Java, Python, C++, .NET, you can write code in different languages. I use Matlab to link things together.

A large organisation will not have one tool that does the while flow, he says. “Tensorflow lacks the pre processing – it’s great for the training, and you can go through ONNX to Tensorflow and use our code generation tools. You might train in Tensorflow, quantise in our code to reduce the size of the model. That’s fine,” he said.

Automating a toolflow with different tools requires coding, he says. “When one tool doesn’t quite do the right thing for the next tool you are going to end up writing code. My conjecture is you will always end up massaging one into the next and you need a language for that. Every time you build a tool flow you are incurring a lot of risk when there’s a change, an upgrade – the more point tools you have the more risky your flow is. To de-risk the flow you want to minimise the point tools, minimise the dependencies,” he said.

“Companies that think carefully about their flows probably has as few tools in the flow as possible. If two tools are made by the same company you will probably chose those in a drive to a more unified flow, but you may need a language like Matlab or Python to put it together. We have lots of point tools down the workflow, we give you the language to make that possible.”

“However, they will not have the expertise to create all components of this complex toolchain,” said Jánky at AImotive. “Environment, vehicle dynamics simulation, sensor models and cloud service will still be delivered by many different suppliers. Outsourcing the entire toolchain is a viable option for the new entrants who don’t have enough bandwidth to drive the toolchain development in-house along with the complete product development,” he said.

This is even more of an issue at the edge of the network.

“We saw our early hardware customers facing barriers to operation at the edge due to lack of software tools,” said Dinakar Munagala, CEO of Blaize, which has developed a chip and software development kit (SDK) for coders but also an end-to-end toolflow to simplify the process.  

“Today in edge computing there’s a huge dearth of tools to build AI applications,” said Munagala.

“While AI is migrating to the edge and outpacing the data centre the deployment is lagging as it takes too long to build the apps and deploy the apps to hardware. End to end software development is lacking,” he said. “The largely manual methods will give way to tools to fully automate AI workflows.”

Instead of using the Picasso SDK, AI Studio aims to provide such a end-to-end tool flow, tied to its hardware. This uses Python libraries and adding a public data market places and repositories to discover models and even complete applications.

The AI Studio toolflow is tightly integrated with the Blaize hardware but its based on open standards so the company says it can deploy to any hardware that supports open standards such as ONNX.

And despite offering a complete flow for edge AI, the company acknowledges that there are demands for a mixed tool chain.

“This is important as we recognise there are existing tools and workflows,” said Dmitry Zakharchenko Vice President Research & Development. “Providing the proper integration points would be the way to connect to the existing tools, so we have developed a robust set of APIs to integrate with existing tools especially in the data wrangling tools and we should be taking advantage of those tools.”;;

Related articles 

Other articles on eeNews Europe 


Linked Articles
eeNews Europe