5
\$\begingroup\$

Daily build in software is taking the source code, compiling it and generating the executables, then running that nightly. This is considered a best practice since it catches errors that prevent the build sooner rather than later, which makes it easier to fix. And if the build works, then others can make sure they aren't introducing errors.

What would be the equivalent for a schematic design? Clearly I can't build the PCB, but there might be something more than generating the netlist.

Edit 1/21/11: Also a smoke test is running some tests against the build. Again, not possible. I like the DRC (design rule check) idea, I'm thinking of checks such as that.

Edit 1/24/11: I was think of the schematic since that's what I do, rather than the PCB.

\$\endgroup\$
  • \$\begingroup\$ The use of meta-tags such as [best-practices] is discouraged. \$\endgroup\$ – Dean Jan 21 '11 at 21:05
  • 1
    \$\begingroup\$ Does your schematic capture program allow you (possibly through an export or import) to run a simulation? gEDA has a lot of tools which could be easily automated to run Spice or Verilog simulations. \$\endgroup\$ – Kevin Vermeer Jan 22 '11 at 1:06
  • 1
    \$\begingroup\$ Also, are you referring to the schematic or the PCB layout? Building the PCB (even if it was feasible) is rather detached from errors I'd expect to see on a schematic. PCBs have their own problems. \$\endgroup\$ – Kevin Vermeer Jan 22 '11 at 1:07
  • 2
    \$\begingroup\$ There are real-time DRCs... close enough? \$\endgroup\$ – tyblu Jan 22 '11 at 18:13
  • 1
    \$\begingroup\$ simulation from the actual schematic is not really feasable for most real-world designs of any complexity. it is better to spin the board early and plan to throw the first one away. c2.com/cgi/wiki?PlanToThrowOneAway \$\endgroup\$ – markrages Jan 24 '11 at 21:26
5
\$\begingroup\$

One little nit: Only really sloppy developers use daily builds because one build a day means having to wait up to a day to find out if you broke the build.

The best solution is to build and test every single change individually before letting it hit the public branch and revert the change if it breaks the build in any way.

Doing any sort of automatic testing on a schematic or a board layout might be very hard or impossible, but everything you can automate should be automated via something like Hudson, things that come to mind are:

  • ERC
  • DRC
  • BOM updating (check that the parts exist, are available and calculate total cost)
  • Generate Gerbers and other manufacuring files.
  • Generate PDFs of the schematic and PCB layers as well as 3d renderings of the PDB, BOM diff and other documentation.
  • Drop a mail to the developer mailing list with the commit message and links to the output files, so developers can review the change easily.

The number of errors that can be caught automatically might not be terribly high, but having the CI system generate the output files means that it will happen correctly every time and that you don't forget some silly setting when doing it manually.

\$\endgroup\$
  • \$\begingroup\$ daily builds are less important now that a build can be done in under 30 seconds normally. A once a day master build as a double check does not hurt though. \$\endgroup\$ – Kortuk Jan 24 '11 at 17:36
  • 1
    \$\begingroup\$ In KiCAD, the schematic ERC is called the "Schematic Electric Rules Check" -- there's a button on the schematic window for it. In gEDA, the schematic ERC is called "drc2" -- there's a command-line tool to run the check. \$\endgroup\$ – davidcary Aug 10 '11 at 19:21
9
\$\begingroup\$

I don't think there's an analogue of the daily build for hardware. It may be possible to not allow a schematic to be checked in if it doesn't pass DRC (or maybe simulation) but that's about all I can think of. Software folks have the benefit of actually being able to run the finished product (for the most part) at a moment's notice and they get a lot of automated tools. Schematic capture programs and simulators are for the most part not up to speed on automation, versioning, etc and it's really a shame. I'd like to see the software design process mimicked as much as possible for hardware but I doubt it will be entirely possible.

\$\endgroup\$
3
\$\begingroup\$

I suppose if your tools support it you could export netlists and do something with them that you find is very repetitive and mundane.

One useful thing I can think of is generating the bill of parts. I used to work at a small company that would design the hardware schematics and netlists and specify the parts, and then we outsourced the layout to PCB design experts.

We had a very helpful Excel VBA program to read in the netlist and generate the parts list from a database of parts.

\$\endgroup\$
2
\$\begingroup\$

The idea of a daily software build is to catch problems introduced by changes.

If you change the schematic, you'll need to test the PCB before going to manufacture. You can reduce the risks by logging and reviewing all changes.

\$\endgroup\$
2
\$\begingroup\$

I think the closest equivalent is to develop the production test fixture and test script for your circuit as soon as possible. Make sure you test all important functionality. The test fixture emulates whatever user interface and sensor hardware are attached to the circuit. The "design verification" test script will probably have more tests and take longer than the production test script, where you are mostly testing to see that the pieces are connected together properly.

So when you are making changes to the firmware or the circuit itself, you can occasionally run the design verification test against it to make sure you haven't caused any regressions. It is also helpful to make reduced test scripts to test one aspect of the circuit's performance, for example testing response across supply variations, or a particularly tricky state machine that would require two pages of instructions for a human to attempt. These shorter scripts are to save time and give better test coverage than the full script. But you always run the verification test before committing changes to the schematic or firmware. For final released design run the verification test across temperature.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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