Abiding by Industry Standards

A printer ASIC was designed to be just a PCI Express endpoint so some of the configuration registers were hard-coded as such and it was used in a printer model. Sometime later, for a new printer model, the engineers wanted to use the ASIC as a root complex to bridge to other PCI Express devices […]

Read More

The (not so) Exciting World of Documentation

In a survey I conducted of several firmware engineers, lack of good documentation of hardware was the number one complaint. It is because firmware engineers so heavily rely on the hardware documentation to correctly do their job. Some of the engineers said that wrong documentation is worse than no documentation because of the wasted time […]

Read More

Designing a Chip for Unplanned Products

One of the rules of the Extreme Programming design philosophy for software is Never Add Functionality Early. This means that when coding for one product, do not add features or functionality needed for a future product. While this rule does have some merit for software development, it should be applied more judiciously to hardware development. […]

Read More

Built-in Debugging Support

After a presentation I gave at a conference, one of the attendees came up and told me about his ASIC design team that consisted of young engineers. They had completed their design and told him that they were done. He then asked the question, “Six months from now when you get the silicon back and […]

Read More

Accommodating Product Changes

Late in the development of a new printer, a third-party print engine that interfaced with a block on the ASIC changed its interface behavior. The print engine would quit sending pulses before the block was done with its job, causing the block to hang waiting for more pulses. This behavior existed in other printer models; […]

Read More

Basic Interrupt Behavior

On an ASIC, my ISR had to write a 1 in one place and a 0 in another place to acknowledge (ack) the interrupt. The hardware engineer I talked to tried to explain how one was an interrupt bit so that is why it needed a 1, but the other bit is a status bit […]

Read More

Balancing How Firmware Waits on Hardware

A common question engineers often wrestle with is how long hardware will take to do a requested task so firmware can take the next step. Engineers implement different designs (both in hardware and firmware) depending on the length of time, and these designs have varying impacts on hardware and firmware complexity and overall system performance. […]

Read More

Different Bit Types in Different Registers

Several years ago I came across a register that, at first glance, seemed to be a typical register with several read/write bits. Upon closer inspection, I saw that one bit behaved differently, depending on its state and whether I was writing a 1 or a 0 to it. Since firmware had to handle that one […]

Read More

Early Hardware/Firmware Collaboration

A few years ago, I was invited to a high-level design review of a new SoC. The proposed design contained an I/O block that needed features added. I successfully convinced them to replace that block instead with an existing block that had the needed features, had seen silicon, and had a functional driver. Months later […]

Read More

Welcome to the Embedded Bridge Blog

Welcome to the new Embedded Bridge blog on the newly-redesigned Embedded Gurus website. So why the word, “bridge”? It is not used in the literal sense of bridges that carries human or vehicular traffic. (Although I came across this embedded bridge in Inc Magazine. Roll the mouse over numbers 1 and 4.) I used “bridge” in the […]

Read More