The first step in developing the hardware is analyzing the entire system. As hardware design engineers, we use standard office software to draw the first level diagram and noise budget, sometimes as simple as MS Excel. Of course, we can use some more sophisticated and expensive tools, but most projects do not need such an overkill, and the benefit is usually not very high.
Our long-term experience allows us to get the same performance from the standard cheap tool as from an expensive high-power tool.
We efficiently utilize the Spice family's tools for the linear and non-linear analysis at low frequencies. Although they are very often free of charge, in most cases, they are sufficient.
Another step we take is the simulation of each hardware component.
As a vital part, our mechanical engineer creates a 3D model for the product from the mechanical point of view. The model is then modified and optimized to achieve the requirements defined in the main definition phase and to be compatible with the electronic design.
When we need to go to very high frequencies, typically above 100 MHz, we take one of our stronger weapons: RF simulation tools.
We can use the most commonly widespread brands, depending on their capabilities. Some tools allow full EM analysis; some are very strong in non-linear simulations. Most of them help us prove the stability of the non-linear system.
And some of them are free of charge, which allows us to minimize the cost of the simulation time and save a small part of the development budget.
We export the data for further development stages as soon as we optimize the PCB structure via these tools.
Once we have all the necessary components simulated and optimized, we go to PCB design. We make a circuit diagram, connect all the components according to their datasheets and application notes and forward the design to the PCB layout team.
Our PCB layout engineers put the circuit diagram to the real PCB model – they do that mostly manually, using their long-years experience, best-practice standards and manufacturers application notes. They also interchange 3D models with the mechanical engineer and solve all the conflicts if needed.
As soon as they are finished with the PCB layout, they export PCB production and assembly data for review.
The phase after we get the first samples from the production is exciting. We use many sophisticated and expensive instruments to prove whether our prototypes fulfill the requirements stated in the definition phase. If they exceed some of the limits, we do a diagnostic activity to find the root cause and solution.
We measure the hardware manually or use test tool framework software developed by our team.
Before we go to the software implementation, we prepare the architecture in the UML model. For such modeling, we use different tools.
A long time ago, we started with Rational Rhapsody, and now we are using PlantUML, Microsoft Visual Studio, Microsoft Visio, Lucid Chart, and Enterprise Architect.
We adjust the architecture appropriately – whether we build on an operating system – Linux or Windows – or bare-metal firmware.
For the software development process, we use a tool family made by Atlassian. We have long experience with JIRA, which is used for bug tracking, where we often utilize Agile process flows based on Kanban or Scrum.
And we exploit the main advantage of JIRA, which is its close connection to the Bitbucket repository.
For the revision control system, we started with SVN a few years ago. During the last years, we have migrated to toolchains based on Git, which brings the benefit of flexible branching and merging (when compared to SVN). We push our content to a remote Bitbucket repository that offers powerful infrastructure and integration with other tools by Atlassian.
We have been using Continuous Integration (CI) technologies like Jenkins Server.
Our colleagues are not forced to use specific tools. Most of them like using VS Code or MS Visual Studio; others like Atom, Eclipse, or any simple Linux-based editors.
Almost all the tools offer the full power of a remote-target debugger and various plug-in packages.
We utilize static code analysis tools like Clang for the source files.
Most of programming languages we use have strong support for both Linux and Windows operating systems.
Some of us like Python for its flexibility and no need to compile, especially for fast software prototyping or test scripts.
On the other hand, the colleagues who are deeply involved in the lower-level ARM Cortex embedded firmware applications are good in C or C++.
Some projects we do for our customers use PCIe cards for a host PC. Such computers mostly run on Windows; therefore, we support our customers in the development of Windows drivers.
We have detailed experience with the older Windows Driver Kit (WDK) and newer Kernel-Mode Driver Framework (KMDF).
Of course, we successfully create drivers for embedded Linux as well – in most cases, for the peripherals that are not a part of the individual SOM (system on module).
Technologies and tools overview
location of our laboratory and head office
Industrial region “Silicone Valley” of Czechia in the middle of Europe
We work in our own lab with a space of 300 m2 equipped with sophisticated measurement instruments (in our ownership) and detailed simulation and development software.