What is a firmware design document (FDD) in terms of an embedded system?

I am working on developing an application that would be working on a customised board similar to the Xilinx Zynq Development Board(running on Arm Cortex A9 processor). I am using the SDK IDE provided by Xilinx which provides some in-built libraries for hardware functionalities like SPI, UART, etc for the processor.

Now I have been tasked to write a FDD for the above custom board. What would the FDD include in such a case? Will it include the firmware libraries already provided by Xilinx or the hardware(and/or HDL software) that we are developing on the custom board?

  • 2
    Drop the F, its a Design Document, so what are you attempting to communicate to whom? Once you've figured out the audience describe what they need to know. Do they need pin-outs, transfer protocols, and clock timings? Do they need to know the specific interrupts, libraries, assembly, etc? Do they need to know how to debug the kernel extensions that work with this board? Or do they need to know how you are building, testing, marketing, and handling the resources for developing this? – Kain0_0 Nov 23 at 5:23

On software design, usually the key document is the SDD, the Software Design Document, which describes in detail how the software works, as it would be finished (e.g. in present time: the system HAS..., it USES...). Since firmware is just a type of software, I assume an FDD would just be an SDD, with specific features related to the firmware.

You will find a lot of gibberish about how to structure your document. I think only on this: a system is a set of interrelated parts (Von Bertalanffy et.al.). So, you need to describe your software system in two parts: the system (statics) and the interrelations (dynamics). Google for SDD templates, and you will see that is the generic structure. So, you will have an introduction, the statics section, the dynamics section, and a conclusive part, that would consider the consequences of the design.

Do not forget that the purpose is not to deliver a document, but to actually think (and allow others thinking) in a systematic manner on the details of the implementation.

The last SDD I've written responded to a set of client requirements (yes, systems have a purpose!). Then, the document had almost this structure:

  1. An introduction describing the software and its context, short, an abstract. That is, what is this software? which function does it performs? for what objectives? references to documentation (or actual content, if the project is small), where what the project is about, what teams participate, their roles, etc. A person that reads this document should either know the project or either have a way to know its details. In our case, the software requirements were already defined, so references were included.
  2. The methodology the software design has been performed and how it is implemented. In my case, this is a research project, researches were done over the theoretical domains and that was taken to use cases, which defined the static structure of the system, components, tests, blahblah. Important to describe the tools (e.g. UML, Agile, etc.). I assume you need to include features specific to the hardware, circuits, whys and hows.
  3. First, what I call the static section: the system, its components (subsystems, subsub...), interfaces, structure, implementation, etc. Personally, I consider it is very important to describe in part 2. the use cases (e.g. a person pushes a button and a light is activated), which would help define the system and its subsystems (e.g. we need a button, a light diode, a battery). Tests can be considered components, in specific cases, because they act many times as reference implementations. In systems managing databases, data structures are to be included in a proper section or whole chapter, if required. In your case, you should pay attention to all static features of your system: components, specifications, alternatives, etc. Interfaces are a key element, since they determine the interactions between parts.
  4. Second, the dynamics section: the interactions between the parts (which determine the relations). Following the example, here you will say "the parts are connected using cables like this; since the button allows current passing, then, the current flows within cables A and B, and the LED is subject to a difference of potentials causing it to emit light, and cause the battery to drain at rate X".
  5. Then, feel free, according to your personal criteria, to enter into the details you consider important to clarify. In our button-battery-LED system, we could introduce the impact of having such fragile circuit exposed, so why a box encloses it; how often the button should be changed due to risk of failure, a recommendation to include a battery level meter, the economic impact (expensive, but cheap on the long term), and how would it be connected, etc.

Feel also free to look other templates and include parts you consider important, but within the structure defined previously.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.