@Tim Edwards Is there discussion somewhere on the root cause of the hold violations in the scan chain? One of my test methods is also a scan chain that can test the SRAMs and I had no reported violations, but now I'm wondering what I need to do to have the correct characterization. Is it an extraction issue or an STA issue?

I would also be interested in a detailled list of all the hold violations that were found

There were hold violations in two main places, and I think neither of them applies to you. Within a block synthesized entirely by Openlane, the timing is properly handled, which explains why the processor itself works fine and doesn't have any hold violations that I'm aware of. The issues arose because we put together the top level as a hierarchy above the processor, and all of the GPIO control blocks were instantiated in the top level. The synthesis tools had no way to alter the timing between the blocks, since it was just doing a top-level routing job, and the paths between the GPIO blocks were long and subject to a lot of parasitic coupling and delays. Then there was a second error which was a failure of the back-annotation of extracted delays into the hierarchy, so Openlane wasn't reporting the timing violations that it couldn't fix (the extraction was fine, and the delays had been calculated but didn't get applied to the post-layout STA). The other place we had errors was in the housekeeping unit, because the SCK input to the housekeeping was not specified as a clock, and so the tools didn't even try to analyze or correct the timing involving SCK (the fact that the housekeeping is set up to allow access from both the SPI and the wishbone meant that the clock setup was non-trivial). Once we understood the errors in setup and methodology, we finally got the tools to report errors which matched the violations we have seen on silicon. All of these issues existed in MPW-one, but the fiasco with the clock tree synthesis was so bad that it shadowed all the other errors. There remain some unknowns related to any interface between blocks at the top level, so that includes the wishbone interface between the processor and the user projects. That, by contrast to the other problems, was being mitigated by margining the timing at the interface in the setup. Whether that margining was enough or not remains to be seen; we'll have to get feedback from designers who made use of the wishbone interface.

I think Tim missed only one other fundamental hold issue in the IO chain the generated clock(derived by bit banging a register) used to drive the IO configuration registers was not identified as a clock in constraints so even though it was used in addition to the serial clock as a possible configuraton path we did not have clock to data timing constraints correctly in place for either path. Once the annotation and constraint issues were resolved we could see the issues present in the siicon. The annotation issue unfortunately affects all top level wiring between blocks in any hierarchical implementation until the flow fixes were made. (So it could affect both the user designs and the caravel if they were both implemented and verified in open source tools. ) There is a detailed document being put together on this which may help others to both understand and improve. Hope this helps.

@Andrew Wright: Not quite true. The bit-bang and automatically-generated clock signals into the I/O shift register are combined, so they are not different paths. The bit-bang configuration programming has exactly the same characteristics as the automatic configuration programming, and fails in the same places for the same reasons with the same hold violations.

But if either clock had been identified as a clock it would have been caught in the io ring STA...