@Tim Edwards would it be possible to implement my own pad ring for the next run in ChipIgnite please? If I go ahead, I'd keep the location of the current PAD ring exactly as is, so dicing & packaging shouldn't be an issue, but change the IO itself (functionality), and obviously remove the uP (so more space for user cct). Thank you!

We can't support this at the moment. We have plans for an "open frame" version of caravel which would work exactly as you describe. But we have not finished that development yet. An alternative choice, depending on how big the design is, is to create your own padframe inside the user project area. Other people have done that, successfully (packaging would be up to you, in that case, from bare die that we send you).

@Tim Edwards Putting IO in the user area would be wasting significant space ... Why is it not supported in the next run? From an implementation perspective, it 'just' requires checking die size to make sure it fits current standard, and then full drc for tapeout (basically skipping some of the precheck steps). IO changes can be at our own risk given relevant documentation is provided ...

Good use of quotes!

@Andrea Mifsud: Because we have defined an automated submission system that runs various final preparation steps and checks, and it is pegged to specific top-level cells (caravel and caravan). You can ask Jeff DiCorpo whether it would be possible to run a project from a GDS that contains the entire chip. We have done similar things for some of our own projects, but those are still all based on caravel or caravan.

@Matt Venn yeah haha; it's always work, even 'just' something! @Tim Edwards thank you for the reply - I did not realise that submission was automatic (thought only checks were). Not sure if it would help or not, but can keep the same name for the top-level cell - you'd still have to skip a number of those steps though (or maybe detect another name, and if so - skip a number of checks?) @jeffdi would this be something you'd consider for the Nov run?

I think that the way the system is set up, we would still need to add the seal ring and run fill generation ourselves. Assuming we can do it at all.

I can generate those locally if need be (have seal ring pcell + metal fill script) - however drc would still flag if there are density issues at higher level (i.e. when all designs are added to reticle) which might need your input; obv I can't fix unless I have access to that report (which I'd be happy to do). I can also run tighter drc density rules on my end if you prefer to mitigate this (did something similar previously)