Your SlideShare is downloading. ×
Toor con2010 - w0z
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Toor con2010 - w0z

10,008
views

Published on

Toor con2010 - w0z

Toor con2010 - w0z

Published in: Technology

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
10,008
On Slideshare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
45
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Hi. My name is Amanda, people call me ‘w0z’ and it’s no relation. Welcome to my talk – Hardware will Cut You. And you’ve ever gotten a ninja badge, you know *my* hardware *will* cut you (and bleed you real quiet-like), just ask Dan Kaminksy.
  • If you want to be a Kingpin- or Ada-class destroyer, you’re going to have to set a few things on fire. Arduino is a great platform to start out with, I have grad students use it all the time. Also, ‘Art of Electronics’ is not a textbook, it is a cookbook. It gives you recipes that you can make and have come out as smoking non-functional biscuits while you’re finding your ass with both hands.
  • In software, often times the design of the software implementation is concurrent with writing it. Which is to say, you can hack around and let software develop fully formed – most of you probably don’t sit down and draw out the network abstraction layers and plan out protocols based on flow charts. You just sit down and work, and when you’re done, you have something to show. Hardware isn’t like that.
  • Here’s a summary of hardware terms that you’ll need to know, if you aren’t already familiar with them.
  • All the traditional hardware design work is done in CAD and can refer to schematic entry or layout. Both require skill sets in the tools and common sense about what is and isn’t physically feasible. All the software is old and doesn’t have features that you think it should have.
  • Your CAD design requires you to define parts and they have to exactly match the part you’re going to be using IRL. This connection of logical data gets stored in a CAD library. If you get it wrong at the library level, your board will not work. Propagated errors are the bane of hardware design. Sure, you can get libraries from other people, but, hey, you know. Trust but verify.
  • So, when you use CAD, you abstract the logical connections of your design (a schematic) from the actual physical construction and implementation of your design (a layout). If your CAD program is any good, it will propagate logical changes from the schematic to the layout and visa versa. This is called cross-annotation or backwards annotation. If you EVER make your two file types inconsistent, you will have to start over from the beginning. Most CAD programs don’t have the state of PhotoShop, in part, because you’re expected to be an expert to use them.
  • After you make your design files, then you generate gerbers and stuff that are used for fabrication and assembly of your hardware. Think of it like the EXE output of the CAD process.
  • You might say, “Wow, those prototypes look nothing like the final design,” and that is, at long last, the point of this talk. Neither one of these boards had intermediate versions and all the blue-wire hacks are really minimal, which doesn’t matter because the build quantity was less than 20.
  • You might say, “Wow, those prototypes look nothing like the final design,” and that is, at long last, the point of this talk. Neither one of these boards had intermediate versions and all the blue-wire hacks are really minimal, which doesn’t matter because the build quantity was less than 20.
  • HOWEVER, SUDDENLY PROBLEMS BECOME REALLY IMPORTANT WHEN YOU MAKE 500 OF SOMETHING. And with quantity, specs and deadlines, things break and they break badly. Getting something into production is actually a really painful process. And if you do it wrong, IT WILL CUT YOU.
  • The difference between making five of something and five HUNDRED of something is that any mistake you make, in technical implementation, design, schedule or cost is amplified to the point where it can make the entire project an abject failure. These are the classes of errors that will cut you. Now, in 2009, Brandon and I knew from the beginning that we’d be building the ninja badges by hand and by ourselves and we took some license and made some shortcuts related to assembly prep. If we had been more thorough (aka, if we’d been unable to devalue the cost of impatience to our future selves) we would half caught these errors... because we would have been appropriately paranoid. as it is, my friends in boston and his friends in LA came out to the assembly party and made the project happen just under the wire.
  • And here’s the proof that history doesn’t have to repeat itself.

    After all the SNAFU of 2009, the 2010 ninja hardware was perfect. We succeeded by keeping track of all of the board designs. I got everything into the library early. the only revs of the prototypes were done to check silkscreen and logos and to tweak the components for design for manufacturability. How do you learn DFM? I learned it from the ex-military guys who were the CAD team at analog and i thought about, “if i were a machine, how would i put this part on this board?” Parts were ordered early. Costs for assembly were negotiated down in advance. And I was super-friendly with my vendors and self-documented the schematic and layout as i went. We paid cost for assembly and had no downstream problems... unlike 2009. Technical win.

    However, the project had some bugs. Even while hardware is heavily back-end loaded, play-testing and large-scale deployment is even more so. In 2009, the software took 48 hours to write. In 2010, it was taking weeks. The 2010 Ninja badge was a FIRST TIME RIGHT prototype that was ready two months in advance, but we only had 5 prototype units, because each one took me 5 hours to build (and the prep for mass-manufactured assembly begins only after you’ve got a confirmed design).

    So. Uber-complex project. Working hardware, behind schedule. Two months to go. Uber complex code, also behind schedule. Brandon and I were a two person team technical team in Boston with a disconnected production team in LA. 5 prototype modules for a massive multiplayer game. It ended up not being feasible to have multiple release deadlines on a project like this, so we didn’t bother. It’s more typical to have as-you-go iterative testing, but that requires manpower. Before Blackhat, no more than two boards were tested at once (two of us, right?), so most of the software bugs didn’t show up until we got the first batch of boards back from assembly, at which point Brandon started finding every bug in the RF block of the MCU and started writing network stacks in assembly.

    Overall, for the project, we had 99% yield. We hit budget if you don’t count that the feature creep where we added 100 boards to the build order AFTER buying the bulk components from China.
  • Self-explanatory!
  • Also self-explanatory.
  • The heuristic for good design comes from experience and mistakes and the good designer validates at every layer.
  • You have to make your own BOM – keeping track of it streamlines your design. Some people write BOM extraction scripts based on your CAD library, which don’t help you if your CAD library is a piece of shit. If you download an existing library, like the Sparkfun Library, the Adafruit Library or the EAGLE libraries, you still need to validate your own stuff.
  • Seriously – set it up so that you’ve got some documentation method that keeps track of what you have and haven’t done in your design. The larger the design, the more important that this is. Because if you omit something, or get a part wrong, or something becomes made of unobtainium, then you WILL BE FUCKED. And I can attest to this design aid because it meant that when I went home for a family emergency to take care of my mom, I could still spec and swap out the cheapo-LEDs in my existing design to add the PLCC2 LEDs we used because the colors just simply *had* to match World of Warcraft.

    Seriously, LED swap. Seems simple, right? Why bother with an OCD spreadsheet? Well, an LED swap *IS* simple, but so is adding a reverse-protection FET. If you get cocky and you mess up your “Action Items” or “Bug Tracker,” you’ll end up trying to deliver product on a Hail Mary play. It’s better to be thorough than to be a hero.
  • Design validation is how you tell the difference between what you actually built from what you meant to build. So, while in software you might step through the code, in hardware you’re going to go through your netlist and cross-check net names and actual connections between the pins of different devices with what you connected up in your CAD program. I don’t care if you use a text file, a spreadsheet or a script. It pays to be detail oriented.
  • The fastest way to hardware is to copy. Copy hard. Copy fast. That’s why the open source hardware movement exists, because more of you should be making real, physical things.
  • And we’re totally out of time.
  • If you want to get started, go over to the adafruit site and look at limor’s tutorials. she covers cad, sourcing components, libraries, part selection and actual building. she has open source kits and she links to tons of people working on tons of projects. it’s a good place to get started.
  • Transcript

    • 1. amanda w0zniak
    • 2.  Electrical engineering is a discipline like any other, you learn by experience and mistake.  The design process is part intuition, part art and all iterative tenacity.  There is no “black magic,” about hardware, just physics and RTFM.  Dive in with an Arduino and ‘The Art of Electronics,’ and don’t wuss out while you’re getting up the learning curve.
    • 3.  When you are building hardware, you have to physically instantiate your idea.  Each instantiation (required to debug problems and test concepts) takes time, money, materials and skills.  Compile times are counted in weeks.  A working design means you are only 15% done and that the fun part is over.  Software project models do not apply.
    • 4.  Hardware is made of PARTS: aka resistors, ICs, switches, batteries and wires combine to make CIRCUITS  You buy parts from distributors like Digikey and Mouser  Every part has a data sheet  For a prototype, you can connect parts by hand ad-hoc and then hack away  If it works, stuff happens, you move on  If it doesn’t work, you RTFM
    • 5.  EAGLE, Cadence, PCBXpress, Mentor  CAD = Computer Aided Design  We don’t make circuit boards by drawing out traces by hand and masking photo resist with tape (why it’s called “tape out”)  Instead, we use 15 year old software suites
    • 6.  A “part” or “device” in CAD consists of a “footprint/package” and a “symbol”  Your “library” holds all of the devices for your design = +
    • 7.  You “design” in a “schematic”  The CAD program (eagle, cadence, pcbxpress) extracts a “netlist” from the schematic to create a “layout”  You “route” all the IRL copper to connect the devices according to your schematic design.
    • 8.  Once you are done with your “layout,” you extract “gerbers,” aka executable design files  A “fabrication house” takes your gerbers and makes a printed circuit board for you  An “assembly house” takes your PCBs and your physical parts, your BOM list and assembles your hardware  All of these steps can be done by hand, and all the steps are required even with DIY
    • 9.  non-DFM device footprint (YETDA! YETDA! YETDA!)  Schematic symbol error (rotated FET syndrome)  Non-validated prototype (due to part unavailability or failure to schedule properly)  Non-validated components (sourcing from china or last- minute substitutions)
    • 10. you don’t need to be an MIT engineer
    • 11.  Do not “begin at the beginning.”  Start at the end.  Estimate lead times: assembly, fabrication, shipping and BOM cost.  Back out cost vs. time and quantity.  Select obtainable, known components.  Curate your CAD library.  Validate your design implementation.  Iterate design through prototypes.
    • 12.  A good designer considers every layer of “fabrication,” from PCB limitations to the end assembly method in order to make a good design that can be built to specification, on schedule and on budget.  Curate as you go. You will be too tired to remember, let alone correct, any of your implementation errors post-facto.
    • 13.  a BOM is the list of all components that are in your design (resistors, ICs, modules, connectors, etc)  Reference Designator (R1, U28)  Component ID (Digikey/Mouser #)  Component Count and Cost  Footprint (SOIC-8, TSSOP, 0402)  Use/Purpose/Function/Sub-circuit  CAD Status
    • 14.  Connections in schematics are called “nets”  A “netlist” is the list of all the nets in your design  Use a netlist to validate what you built from what you meant to build (LVS verification)  Brandon & I co-wrote the netlist to keep the signal names equal between the board and the code.... in a spreadsheet
    • 15.  there’s a full Eagle library, schematic, layout, gerber package and BOM for the ninja boards in my public directory  download it, start messing around.  http://web.mit.edu/~awozniak/www/ninjas/
    • 16. but now we’re out of time
    • 17. until next time... http://www.adafruit.com/  tutorials