Chipsets are usually made using a synthesis flow with some custom analog design at the pins. This is an overview of the flow with comments on your bug catching ability at each stage.
First an architectural model is made that shows the logic flow, and can do preliminary performance analysis. The architectural model will show a high-level overview of the performance. You write various simulation cases and you run them through this model to simulate events, like the CPU trying to grab a chunk of data from memory and then doing a page swap or something like this. You could catch the problem at this stage.
When you have this architectural model ready, you usually then create a functional RTL model using Verilog or VHDL that works (ideally) exactly the same as the architectural model but will actually model the detailed inner workings of the design. So in the architectural model you might have a block that is labelled "64-bit register" and you put stuff into the register and take it back out, but in a functional model you actually show how this register would work - which signals would cause it to activate, which buses the data would use to move data in and out, what the hierarchy of the structure looks like. Then you take this model and try and find bugs. You verify it against the architectural model (by running chunks of code on both and debugging where they differ) and you also try to just slam the heck out of the functional model.
Synthesis doesn't tend to like functional RTLs - which look a lot more like programming language programs (say, C++ code) than hardware descriptions, so one step that is often added is converting the functional model (which emulates the function without detailing the structure of the model) into a structural model (which shows the actual structure of the hardware). Some companies skip the functional stage and just write structural RTL from the start, others will synthesize from functional code (but this is not smart). But most normal people will write functional code at first and then gradually swap in structural code over time. But I digress. Whether the code is structural or functional, the model is simulated using code that exercises the functions of the model. This is where you would catch the problem ideally.
Once you have an RTL model, you pull out your "make_chip" suite of programs from Synopsys or Mentor and synthesize and "plane 'n route" it which automatically takes RTL code and converts then into transistors. You check that what the program has produced makes sense and will work, but your model is still the RTL. This step will almost never catch a "bug" like you described, Sunner.
Then you fab the chip and you get silicon back. Once you have silicon you slap it in and fire it up and most of the stuff you simulated on the models above gets done in like the first 500ms of operation. So you have the ability to check a lot more, but another issue comes into play: schedule risk vs. impact of a problem. Everything you fix introduces potential (or real) delay to the shipping schedule. There's the risk that you mess it up, or that something that you do messes something else up. And you only get one or two snapshot points (steppings of the mask) where you can fix things. So if you only get two chances to fix things and if there's the possibility that a complex fix could hose a whole lot of other things, then it needs to go into the first stepping - the risk is too high to put it in the second one because if you mess it then the chip doesn't ship.
Also mask sets are expensive although this is something you don't hear a lot about. I couldn't quote real figures but pulling numbers from the air I would guess that a 0.13um mask set must cost upwards of US$3m. For a company you might think that $3m is not that big a deal but in this case you are talking several mask sets to produce final ship-worthy silicon - maybe 3-4 - that's $9m-12m total... that's a fair amount of capital cost that you need to recover selling a chipset that doesn't have a lot of margin on it. So, it's not like you spin a rev of silicon when you find a bug. It needs to be a big bug to be fixed.
I would guess in this case it was something that slipped through to silicon and then was too expensive/complex/risky to fix. If it was caught in RTL they'd have fixed it, so it wasn't until silicon that they saw it. Then it was judged not to be a disasterous bug but one that would require substantial risk to fix. So they deferred the fix to a later product release.
Patrick Mahoney
Microprocessor Design Engineer
Intel Corp.
Fort Collins, CO
