Although we may think of smartphones as being like tiny desktop computers, they do have at least one key difference - in order to save battery power, many of their functions are hardwired into highly-efficient dedicated processors, instead of taking the form of software. Because smartphones perform so many functions, however, not all of them can be hardwired. As a result, designers of mobile devices must decide which functions will be handled by software, and which by hardware. Computer scientists from MIT have recently devised a system that should make those designers' jobs a lot easier - if they're willing to adopt it.
Using current technology, problems can arise if a designer decides after the fact that it would be better to change a function from hardware to software, or vice-versa. Typically, doing so involves going back and spending a lot of time and energy reworking everything that they just did - that, or they go ahead with what they now know is a flawed design.
NEW ATLAS NEEDS YOUR SUPPORT
Upgrade to a Plus subscription today, and read the site without ads.
It's just US$19 a year.UPGRADE NOW
The new system is an extension of the existing BlueSpec chip-design language. Users start by specifying everything that they want their mobile device to do. They then decide which things should be handled by hardware and which by software, assign them as such, at which point the system automatically generates circuit diagrams or software code for each function. In the course of doing so, it often incorporates shortcuts that humans might not think of.
If the designer later decides to switch a function between hardware and software, however, the system will rejig all the associated circuits and codes accordingly - no more having to rework everything manually. It will also determine how to connect dedicated hardware to a device's general-purpose main processor, and will let designers know if they're trying to assign a function to hardware that can only work in software, or vice versa.
The MIT system may take some getting used to, however, as it requires designers to describe functions as sets of rules, instead of sequences of instructions.