The Embedded Design Checklist – For New Designs

Beginning a new embedded design is both exciting and daunting. There are many aspects of starting a new design that are fun and engaging, however it’s important to step back and make sure you’ve made the right decisions and assumptions up-front, to reduce headaches later. Below is a simple checklist you can use when starting a new design.

Does everyone have a firm grasp of the scope of the project?

Most embedded projects seem simple when designing on the white board, but it’s often the case that large parts of the design aren’t yet known, or are not well communicated to the system architect. Make sure you work with your external customer(s) as well as your internal team to ensure all stakeholders have a firm grasp on the scope of the system. One of the worst phrases you can hear at demo time is “well, where is feature X?”.

Does everyone know their role?

It’s easy to just assign tasks to the team based on approximate time-loading, however this can be troublesome in a number of ways. Since each member of your team probably doesn’t have the exact same skill sets, the team should work together to best understand which tasks are the best fit for each member. It is, of course, important to continue to challenge yourself and team members, however if the project isn’t going to say on budget because a member needs to learn too many skills to complete a task, that doesn’t make sense. This touches on the next checklist item …

Does everyone have the training they need?

Not every new design is going to be “cookie cutter”. It’s very possible that a customer ( internal or external ) requires your new design to use a technology that no one on your team has experience in. This could be as simple as a transmission protocol, or as complicated as a brand new processor, DSP, or FPGA platform/architecture. It’s important to understand what training may be needed, build that cost into the project, and set expectations appropriately with all stakeholders associated with the project on how long it may take to bring everyone up to speed on the new technology.

Has someone done a ‘back of the napkin timeline’?

A big part of engineering is sanity-checking your decisions ( calculations and assumptions ) with estimation. You should always be able to look at a design or problem and get a rough order of magnitude of how large of a problem this is ( this statement obviously falls apart for very large programs such as the space shuttle, but for the argument of this blog post let’s assume this is just for embedded devices and smaller ). Being able to understand what the goal timeline, and what a realistic timeline ( and hopefully those match up closely ) is, will help you continue to set expectations with stakeholders, and better work with your team to meet milestones. There will always be projects that end up behind schedule and will be stressful. However, by having an understanding of what a possible timeline is before starting the project can greatly help reduce stress going in.

Do you have a block diagram?

Spend some time with a whiteboard and your team. Get everyone in the same room with a large, blank whiteboard and go to town. Start with the central processing IC ( Processor, DSP, FPGA, SoC, etc. ), and move outward. Most embedded systems need Memory ( both volatile and non-volatile ), power management, and communications ports. Additional components might include Analog to Digital and Digital to Analog converters. Get as much of the system down onto the Whiteboard as you can, and then start taking pictures. It is also a good idea to have a dedicated note taker for each meeting, and have those meeting notes posted for all team members to see ( it may also be appropriate to send these notes and the block diagram to other stakeholders ).

Has the team settled on what Software Tools will be used?

More than likely everyone on your team is going to be using a computer. And on those computers will be software that will help team members complete the tasks that are assigned to them. Projects live and die based on what software packages and technologies they use. In some cases the software you will be using will be picked for you by the silicon vendor you are using ( you’re going to be working with Vivado if you use Xilinx, or LabVIEW if you use National Instruments ). Other cases you may have a choice. It’s important to have your team spend time between projects working with different software packages so they know which ones work well and which ones are just garbage. By encouraging team members to always be trying new software packages, you are more likely to settle on one that is the right fit for your needs when a new project comes in the door. Additionally, if you have been using the same software package for 5 years or more, it’s probably time to revisit the marketplace to see what innovations have been made in the last half decade.

Have we bitten off too much to chew?

“I know it’s only two months, but do you think you can get this done by October?”. This is the kind of question that often comes from stakeholders ( internal and external ) from management all of the time. Those inside and outside of your team often are going to be pushing you to be a little bit smarter, a little bit faster, and a little bit cheaper. That’s their job. It also can be super stressful and frustrating (especially when they know darn well that it’s an unrealistic request). Sometimes there is just too much work to be done in the timeframe that you’re given (that’s why “Has someone done a ‘back of the napkin timeline’?” is so important). You’re options are usually:

1. Push back right away rather than let stakeholders think that their request was reasonable
2. Fold, and just try your best to get it done ( this is, obviously, the least desirable since it results in long days and a grumpy team )
3. Outsource/subcontract a portion of the project that you know is an easy bite-sized chunk that your team can quickly define.

The third option does not come without headaches – so don’t think it’s always the answer. It can, however, allow work to be done by a contractor in parallel with your team, thus making the unrealistic deadline a little bit more realistic.

So above is my quick New Embedded Design Checklist. The above items, along with reading datasheets, talking with suppliers, and ( sometimes far too many ) team meetings is how I start each new embedded design. If you’d like to chat more about starting a new design, and how I or Viewpoint Systems might be able to help, feel free to drop us a line.  If you’d like to learn more about embedded design considerations, check out this white paper on the Top 5 Embedded System Design Fails.  If you’d like more industrial embedded info, check out our resources page.