For emergency respins, bureaucracy sometimes prohibits on-the-fly project completion, especially when colleagues refuse to revisit schematics.
Rush jobs can be a pain. They usually come in the form of a small, simple board or a seemingly minor revision to something more substantial. The common thread is somebody wants it right now. Normally, this means setting aside your current project and whipping out a quick spin. It’s a cumulative thing that stretches the longer-term projects.
Meanwhile, some departments or people within the company move at their own pace. You may not have the clout to jump the line for whatever it is they do. An example is having the circuit simulated for signal or power integrity. It could just be the librarian creating the symbols. These are the things you need to get started as early as possible in the process.
For one top engineering department, the process involved us only generating a fabrication drawing if there was an outline drawing for that specific board’s part number that was already released to the system. It wasn’t enough for the mechanical engineer to provide the geometry, even if it was a square with four symmetric holes or a straight-up copy of something else.
The documentation was automated in ways that ensured the board would have all the connectors, mounting holes and other touch-points exactly how they were intended. The outline and other geometry were extracted from the released outline drawing. Most places I have worked neglected the outline drawing until the end-customer demanded it. All we typically saw during development was from a data dump by the mechanical engineer and maybe a 3-D screencapture. No docs.
The bureaucracy of the system meant the designer could not possibly start and complete a project in a single day. Many times, I had to remind someone we didn’t even have a part number in the system, let alone a completed drawing approved by all the stakeholders. While it wasn’t as agile, the tradeoff was we didn’t have to respin boards because a connector was mirrored to the secondary side of the board.
My next stop was Chromebook main logic cards. My first one was finally complete with its two USB type-C connectors. Based on the .emn file, I placed them on the wrong side, where they created fewer design rule issues. We were performing the final design review when my manager pointed them out. This triggered an emergency respin with all the superspeed traces rerouted to swap lanes and polarity of the data bus. At least there was the exact amount of space required to pull this off. It was a lesson to learn about working without a pristine placement. Chances are this would have been caught earlier if I had shared the placement to a wider audience before doing the rest of the work.
For sure, this would not have happened at the previous job. In fact, someone did use the wrong half of a stacking connector pair on their schematic at one point. We’ll call him “Guy.” The result was pin one was on the wrong side of the connector compared to the outline drawing in the document-control system.
The mechanical engineer who provided the outline was reusing a standard form factor for test fixtures with the new part number. I had seen this same outline before and knew it was correct. I recall it was two 80-pin connectors that went on the bottom, but I couldn’t get them to line up the signals if they were placed where they belonged.
Guy was informed we needed to update the connectors so the polarity matched the drawing. He refused to revisit the schematic! I did something I’d never done before: routed all the connections except those that went to the connectors, and then refused to complete the board, informing anyone who would listen.
One of those who listened had based his own inter-board connections on the false information provided by my EE, so he joined the chorus. To say the least, he was not happy. I had already escalated to our manager, and now it went further, until the director of my department and the director of Guy’s had a sit-down. After that, he finally fixed the connector polarity.
At the design review, I learned everyone at the table had made suggestions without getting any traction. So it wasn’t just me, which was a bit of a relief.
Here comes the plot twist.
The boards came in, and another episode came to light. A little backstory: On day one, I told Guy we had two nets with almost the same name, the difference being TCK on one pin and CLK on the other, with the rest of the net-names matching. I pointed that out as a bullet point on the first status report. No update forthcoming. It became a topic of its own, consuming the next report.
Having worked on this chip before, I knew what to expect. It seemed so apparent it was a typographical error that needed cleanup on the schematic. I brought it up the next time Guy was in my office. He said, “Don’t worry about it.” At that point, I still assumed good intentions, and I dropped the matter.
So, with boards in-house, Guy came over with a somewhat ashen complexion. I could tell something was wrong. He asked if I knew the clock was an open circuit.
“Oh yeah, you’re right, Guy, and I told you about it a few times, but you told me not to worry about it, so I didn’t,” I said.
The clock issue was totally forgotten in the struggle with something even bigger.
No blowback came my way, but I think Guy got a bit of “head-shaping.” Given this fellow’s reputation, my ECAD teammates seemed to vaporize anytime Guy had a job for us. I was stuck for the clocked-up board and two more follow-on boards with him. I got through those boards by setting a boundary that went like this: “Guy, this is the fifth time I’ve told you this, and I’m not going to mention it ever again."
He acted on the ultimatum, but not on the first four notifications. In that strange and tortured way, we were able to get through the rest of the projects. Guy’s manager was aware of the issues and not inclined to babysit. Adjusting to the situation was the only way forward, or so it seemed.
Sometimes, we do whatever we have to do to make it work in the end. In terms of problem-solving, one size does not fit all. Identify risks and develop a mitigation strategy, and remember: It’s not all Tetris and Connect the Dots. •
is a career PCB designer experienced in military, telecom, consumer hardware and, lately, the automotive industry. Originally, he was an RF specialist but is compelled to flip the bit now and then to fill the need for high-speed digital design. He enjoys playing bass and racing bikes when he’s not writing about or performing PCB layout. His column is produced by Cadence Design Systems and runs monthly.