The Amp Hour Electronics Podcast

A weekly show about the trends in the electronic industry.

  • For Us
    • Donate
    • Link Here!
    • Suggest
      • Guest Suggestions
      • Story Suggestions
      • Feature My Workbench!
    • Advertising
  • For You
    • Episode Index
    • Guest Episodes
    • Buy Stuff
  • About
  • Email
  • Facebook
  • LinkedIn
  • RSS
  • Twitter
  • YouTube
You are here: Home / Guest Appearance / #505 – Hardware Revision Control with Kyle Dumont

#505 – Hardware Revision Control with Kyle Dumont

Play

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | RSS

Welcome, Kyle Dumont of Allspice!

  • Kyle has a background in EE and worked at iRobot.
  • After that he worked at Voxel8 on the Developer’s Kit, the 3D printer that could do plastics plus circuits. You may remember a quadcopter that could fly off of the print bed.
  • Using a high end milling machine, they could get 100 micron trace/space. They did this by milling out the channel and filling with silver.
  • Things went quiet on the circuits front, so Voxel8 moved into rapidly printed footwear. Things like “stylized uppers”
  • First printer launched was called the developers kits and was good for doing things like 3D antennas and getting blind vias for free.
  • Kyle recently graduated from the new MS/MBA program at Harvard.
  • He mostly took CS / Datascience classes on the technical front, because of the availability of graduate level classes. So no exposure to Horowitz or Hill, unfortunately.
  • Kyle started Allspice with his classmate Valentina, as a way to make hardware design more like software.
  • Building a git release for hardware designs, instead of relying on zip files. This took direct cues from his experience doing product development.
  • Processes are built around the waterfall development process
  • When starting the EE team at Voxel, they used GitHub
  • What would you tell a new hire for using Git?
  • These days, younger EEs do firmware anyway.
  • How does git work?
  • Git allows design revision control
  • Different than Subversion, another revision control method used by Altium.
  • Git holds the entire history, and only tracks the incremental changes.
  • Separation between local and remote.
  • Jesse Vincent’s talk at KiCon about tooling for manufacturing files
  • Using Continuous Integration
  • Simulation is usually super targeted, trying to get 4th order accuracy
  • Atul Gowande Checklist Manifesto
  • Tying footprints to MPN
  • Initial focus was on teams using git with hardware designs
  • Building visual red-lines, so that you can see what has changed during a design review.
  • Kyle can name the likelihood of a CAD program based on industry!
  • Altium building Altium365
  • Explaining how a change ripples out
  • Users of Git and Allspice will learn to break changes up into the most digestible changes
  • JEDEC30 format
  • Component information
  • Pull request is analogous to the ECO process
  • “Can this be done” vs “Should this be done”
  • Unit testing
  • How would this work with PCB manufacturing?
  • Tagging to put a version on a board. Chris used to put commit numbers on PCBs.
  • Check out Allspice for more info, or email Kyle directly

Comments

  1. Denis Tcherniak says

    September 1, 2020 at 2:36 am

    Hi Chris,

    During the podcast you mentioned that it would be nice to have a PCB checklist that one could consult/use as a starting point before ordering PCBs. (and of course also develop a habit for using it). One of my friends has created just that, check it out here:

    http://pcbchecklist.com

    it has a bunch of various points for different things, and can be tailored to your own needs. It is open source, so you are free to contribute 😉

Copyright © 2025