@User @User I enjoyed the FOSSi video. Excellent work. It prompted some thoughts on the next shuttle process. I expect the next (and following) shuttle(s) to be beyond capacity and I've been thinking through the implications of that. I am of the opinion that it would be good if the selection of which designs are going on the shuttle can be made 1 month prior to tapeout day. There are two main reasons for this: 1. At least in the analogue world, there is more space on the shuttle than we know what to do with. The one month period will allow multiple people/teams to combine their work so that more designs can make it on the shuttle and we all win. 2. As you know getting to a tapeout ready design is a huge effort of weeks of concentrated work. To do all that and then find out after tapeout date that you haven't been selected is hugely demotivating. To be honest I'm already mentally juggling the amount of effort required and what I estimate a 25% chance of getting selected (if no project combining takes place) but I'm staying positive and moving forward in good faith. The one month period would allow people to kept developing their designs in a modular way. At the one month mark decisions get made and people can then start combining and/or making those modular blocks tapeout ready. I'm sure you can also see the advantage of encouraging design to be more modular and portable across projects. I understand you've got a huge load of things to juggle but I just wanted to share my thoughts now as a data point before you start making decisions final. Maybe other members of the community have opinions they'd like to share too? Thanks for all the great work so far and into the future!

I'm working on a framework to allow people to easily combine small projects into one application. https://github.com/mattvenn/multi_project_tools

Very nice, definitely a valuable tool to have moving forward

I hope it can be useful!

@yrrapt: I am expecting to rely on Matt's multi-project-project. This adds a layer of complexity to the shuttle submission process, though, which I have discussed a bit with Matt. Essentially what it comes down to is that priority will most likely be given to projects of greater scope and complexity; it would be up to the user then to decide if their project is too simple/minimalist and likely to get booted from the shuttle, and consider joining a shared project space. Having simple or small projects sharing one chip would maximize the number of people who can get something on any given shuttle run.

@Tim Edwards ah OK, I didn't realise there was priority, I assumed it was just going to be a random draw. It does make sense though if the goal is to rapidly get the ecosystem up and running. Thats very useful information, thanks

@yrrapt: It could be a random draw; there has been no final decision on what the selection process will be, yet. Part of that depends on testing Matt Venn's submission from the first shuttle run. If the shared-space chip works out well, then it seems to me wise to apply some pressure to get people to optimize the submissions in a way that maximizes the number of people that can get something onto a shuttle run.

my system is currently assuming every project is the same area, but that could be easily changed

Hmm... A catastrophic error in one design could take dow the whole thing.

It's possible to completely isolate separate designs as long as the interfaces are designed with that in mind. For analogue multi-design projects I would be looking to be able to completely power down unused designs. The normal way of doing that is to have an enable signal to each of the designs but that does assume the enable signal is implemented correctly. So it's probably safer to power gate using a pass transistor. Much less area efficient but means there's certainty that designs can be disabled completely and won't affect other designs being evaluated. I expect power gating is not really necessary with digital designs though

I'm currently working with only digital designs, and using tristates to isolate all outputs. I am interested in increasing robustness, so any examples of catastrophic errors @Jean?

@Matt Venn: The typical worst-case scenario is the user project shorting power and ground. As Philip notes, this could and should be detected through LVS, so you are dependent upon the diligence of every designer of a sub-project to have properly run and passed LVS. That can be avoided by connecting power to each user project through a very large MOSFET switch so that each project is independently powered. I don't know if your design is doing anything like that.

my multi project tools check LVS against powered verilog and GDS. But nothing is in place to check that they haven't connected power and gnd inside their design.

Not a fast method but pretty foolproof is to run a spice sim of the gate level netlist and see what the dc current draw is. That will also protect against low resistance connections that aren't a short. Although I'm not sure if ngspice will choke with an op sim of that size...

Nice idea

DC current draw seems like it should be a required final design rules checkoff, and if it chokes ngspice, make that design a new regression test for ngspice.

I've done a bit more work on this now (see https://github.com/mattvenn/simulate_7seg), but it turns out it's really not necessary. If there's a short then LVS fails so then there's not even really any point measuring current with the extracted spice deck.