Timing closure, trails and sleep - Embedded.com

Timing closure, trails and sleep

I am a physical design engineer at ON Semiconductor's Pocatello, Idaho facility. Southeastern Idaho isn't subject to nearly as much heat as company headquarters in Phoenix, but our days are hot.

Mountain biking is my favorite pastime, but the summer heat limits when I can hit the trails. In July and August, it's 5:00 a.m. or nothing. I need a clone! She could go to work and I could embark upon my rides at a more respectable and cooler time of day.

Billie Johnson, physical design engineer at ON Semiconductor, and not one but two clones.

Billie Johnson, physical design engineer at ON Semiconductor, and not one but two clones.

In addition to the psychological and physical benefits of mountain biking, I have solved a number of design challenges through the syncopated cadence of my breaths and pedals. One of my most recent problem-and-epiphany scenarios surfaced in the very late stages of timing closure on a 0.18u ASIC that I'll call Zip.

Often times the customer's engineers weren't involved in the original design work or constraint development for an FPGA-to-ASIC conversion or ASICS that combine a few chips into one, so they aren't fully familiar with the timing constraints or other nuances of the chip. This was the case on Zip. From the preliminary timing driven placement to the final days of timing closure, the constraints were changing. Subsequently, so were my targets.

Beginning a design without complete timing constraints poses a considerable schedule risk. The physical design tools can spend hours or days trying to fix invalid paths, logic placement can be less than ideal, or we can get all the way through to a first delivery of post-layout data and uncover a missing constraint necessitating rework of the placement, CTS, routing, and post-route optimization phases. In other words, two to three weeks of rework can be necessary when a missing timing constraint is identified late in layout.

After I felt the timing closure milestone was met on Zip, I delivered a final netlist and parasitic data to the customer and held my breath. I didn't have a chance to turn blue because a failing simulation pinpointed unconstrained logic almost immediately.

The customer had been aware of 24 registers on critical reg2out paths in Zip's zippiest interface that I needed to early clock and place close to their corresponding outputs, but this simulation uncovered another 40 registers requiring the same treatment. With updated constraints I could see the failing paths in my timing reports.

To read more of this external content and to leave a comment, go to “No quick tweak, unfortunately.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.