*********************** Hello <!channel>, We know you are waiting for information on the MPW7 selection. If you’ve been reading the updates on MPW2, you’ll know that we are working hard to get to a full understanding of what went wrong with the MPW2 tapeout. https://groups.google.com/g/skywater-pdk-announce/c/HelusBBUZ20 Given what we now understand, there are 2 tasks we want to run on all the submitted MPW7 designs that will help to avoid these issues in the future. 1/- A top level timing check to prevent hold violations between macro blocks, or macros and the Caravel management core. 2/- Set defaults for all the GPIOs by including the user_defaults file in the submitted repository. This is to ensure that if there is a problem with the management core, the GPIOs will already be set correctly for your project. Once both of these tasks are ready to deploy, we will give everyone who submitted to MPW7 one week to complete both tasks. We will support you here with any problems you encounter. Once that new deadline is over, we will make the selection on all the designs that have completed both tasks. Thanks for your patience and understanding. ***********************

#1 was my concern in mpw6 @Matt Venn

Macro based flows are known to create immense timing challenges. Many of us were wondering about it, when they heard about the Caravel concept. IMHO, the Openlane flow is not capable to insert the (sometimes very) long delay chains. This is why I wrote this app note (below) to fix this issue by design. But I could also be completely wrong, then please let me know. I was just trying to communicate the issue and I was trying to help. https://github.com/cloudxcc/CaravelAppNotes/tree/main/AN_WBHT

Yes, and thanks for posting that again Tobias

What I’m trying to emphasize here is, that once the hold time check is implemented and the (most likely) result is a violation, what are you doing then ??? IMHO Openlane doesn’t fix it for you (constraining, …). The “only” feasible solution is to use inverse edges and then we can leave the concept as is. And once you use the inverse edges approach, hold time check becomes irrelevant. So this whole "hold time check on top level" implementation is a waste of time in the current Caravel\management concept.

yes, so either merge all your little blocks together in the case of inter macro issues. Or apply a concept like yours.

If there are analog macros - what is to be done ? Since we dont characterize the analog macros to have the hold time requirement ? What about digital-analog interface ?

I'll make sure we cover that in the documentation for the 2 tasks

Nice

For step 2/, do we set the GPIO defaults in verilog/rtl/user_defines.v?

Yes, but we'll give detailed instructions asap

@jeffdi @Matt Venn - is there any validation we can do on designs submitted prior to MPW7? I'm thinking MPW5. I'm assuming it is too late to change anything there, but we could at least know if we are likely to run into issues with our designs.

I hope we'll be able to use the timing script on the previous submissions.

What exactly need to be done here? https://github.com/efabless/caravel_user_project merge updates from here and re-run flow again and submit again?

We'll release instructions when its ready

thanks @Matt Venn

👍

My design is an ongoing project and things get added. Can we add more blocks when we perform these 2 tasks. For example, At the time of MPW7 submission my SoC had a processor and 8 blocks of OpenRAM. Now I have added one SPI and one I2C block. Can I perform the two tasks on the new SoC and submit. If yes, what is the impact on selection (lottery tickets for ever week)?

good question, I'll get back to you

@Matt Venn the instructions aren't ready yet?

It's less about the instructions, more about this top level timing script. We are still waiting on that to be ready.

@Matt Venn Any idea where the code going to be updated? Is that macro re-hardening required or only wrapper level script going to be updated? Thanks

Will metal ECOs be allowed to be done on the existing design?