Fix it in the software!
As a specialist in embedded software, I think that Mentor Graphics is an interesting place to work. The company has historically been dedicated to serving the needs of hardware developers – whether they are designing cables, boards, FPGAs, ASICs or custom chips. These technologies still dominate the product range today. The Embedded Systems Division is different – we offer products for embedded software engineers.
It is this different focus that makes life interesting. Most of my colleagues in the wider company have a hardware design background. They speak a different language and take a different perspective on many issues. There are two areas where differences really come to the fore: division of functionality between hardware and software and rectification of hardware bugs located late in the development cycle.
Any embedded system is a bunch of functionality, which is realized by means of some hardware and some software. It is a fundamental design decision – the division between the two implementation options. Sometimes it is obvious: if a very cheap and easy to incorporate piece of hardware can remove a large chunk of software, the hardware is the clear choice; if, for example, the software needs to interpret some bits in a non-intuitive way, that is a small price to pay compared with using extra gates to do the inversion in thousands of systems. But this cannot be taken too far. I have seen RS232 serial communications done bit-by-bit in software to avoid the cost of a UART. Does that make sense? Many years ago I worked on a system which featured an immensely powerful [by the standards of the early 80s] 16-bit CPU. The designers got carried away with how powerful the processor was and more and more functionality was unloaded from the hardware to the software. Eventually, the system was brought to its knees and some major design rethinks were necessary.
During testing of an embedded devices, it is almost inevitable that bugs are found. There then follows an argument as to whether hardware or software is at fault. If it is software, then the code is changed accordingly. If it is hardware, late changes can be difficult, expensive or even impossible. So it is annoyingly common for the software to be changed to get around shortcomings in the hardware. This is not so bad if the change is trivial, but I have encountered cases where major software rewrites have been necessitated. Is this fair?
