Abstract
I developed it from the original SW, and then developed it from the event FW. In the past few years, I switched it to the Development of HW. In the years when I worked with the HW project, I learned four things that I could not learn in SW and FW.
Introduction
In the past few years when I started HW, I learned four things that I had not learned before SW and FW from other HW engineering engineers, these four things also reflect the methods and guidelines for developing SW and FW.
1. Verification
The HW project implements verification very heavily. When a project starts to kick off, it does not want any design yet. It is already thinking about how to upload a certificate, to test case, it is also strange that HW is generally better than Sw/FW, because HW's verification ratio is Sw/FW.
2. Architecture
Before the launch of the HW project, the whole architecture will be clearly divided before the design starts. Sw/FW does not seem to be so heavy on the architecture, it is often the case that the hardware architecture is changed and the hardware architecture is changed. This is also strange that HW has a general architecture than Sw/FW.
3. Document
The HW project has a very heavy inventory file. datasheet is less than 100 bytes, and SW/FW has weak file requirements, it is often seen that no file exists in the entire project, and only the source code is available. This is also strange that SW/FW is often better than HW.
4. Root Cause
For debug, The HW project always needs to find the root cause, that is, to find the metadata that actually causes the bug, sw/FW engineering practices are similar to solving bugs, that is, how to avoid bugs. It doesn't matter if the real root cause is not found, this is also strange. Sw/FW is often used to dig things and solve the bug, which may generate another B bug.
conclusion
HW and SW/FW have two different backgrounds. Once HW is configured, if a problem occurs, the loss of a service pack is acceptable, this also caused the entire HW process to be very cautious and expected to reduce all possible risk factors in the development process. Sw/FW is too easy to be updated, it is common to hold the "re-modify" mind, the quality of SW/FW is not determined by HW. When I was developing Sw/FW, I had no idea how to use the method and process of developing HW, I think the above four points are a good example of HW engineering, and they are worthy of SW/FW engineering learning.