Sign In
Forgot Password?
Sign In | | Create Account

Fix it in the software!

Colin Walls

Colin Walls

Posted Jun 22, 2009

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?

Hardware, FPGA, ASIC

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over thirty years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: Visit The Colin Walls Blog

More Posts by Colin Walls


No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)


Online Chat