Hello everyone, we have a mixed signal design we are going to submit to the Nov 6th ChipIgnite. We are also opening up our spare silicon to community members for free. Just looking for tips on the best way to go about this. Our own mixed-signal PWM, Switch Capacitor Filter and Ramp/Samp modules each have a piece of Digital/Verilog to control them and talk to the wishbone. The outputs from the digital component then need to be routed to the Analog portion of each module, before finally getting routed out to the I/O pads. What we are thinking about doing is: Digital: 1) Combining all of the digital control verilog into one module ‘TOP_DIGITAL.v’ 2) Instantiating this into user_project_wrapper.v 3) hardening this with Openlane, to generate a macro - with the I/O pins around the outside Analog: 4) Write all of our Analog modules from magic to .GDS files. Combine: 5) Create a top level design in Magic for the whole project: ‘TOP_MIXED.mag’ 6) Instantiate the Analog modules into this top level by reading in the .GDS 7) Instantiate the TOP_DIGITAL.gds Macro generated in (3), place it in the corner so that it’s reachable by Openlane’s router 8) Wire up the connections between TOP_DIGITAL and our Analog Modules - (? by hand) 9) More hand edits to ensure the pins and vdda/vssa etc are correctly labelled and reachable by the router/Caravels PDN 10) Instantiate TOP_MIXED into Caravel User Project as a module (LEF, verilog module for ports, netlist etc). Then the other users we are sharing with can include their own designs as other modules in Caravel User Project. Please let us know your thoughts, whether there is a better/established way, and any other advice etc. Thank you 🙂

Not sure how many people will see this short of doing an at-channel blast. I think this is a valid way to go about it. I don't really have an opinion yet about what is the "best" way; analog can be integrated either as macros dropped into a digital assembly flow with openlane or dropped into the top level and wired up by hand. For the former method you'd probably end up wanting to hand-wire the analog anyway. Although I think analog wiring can also be put in a macro, abstracted, and the top level assembly will just route around it.

Thanks Tim, we will go about it this way and see how we go, changing if we run into problems. We would put the analog macros through the digital flow, however we aren't confident that the analog and digital portions of each module would be correctly connected that way!

If you make macros out of the analog and put them through the digital flow for assembly, then the digital wiring will be done correctly, but you will probably not like what it does to the analog connections. The solutions I can think of are (1) let the digital flow route the analog, erase it, and reroute by hand; (2) put all digital connections in ``ifdef` blocks in the verilog so that the router doesn't see them and doesn't route them, and then route them by hand; (3) do all the analog routes by hand, first, and make that into one or more macros that then become blockages for the digital routing. I think (3) is the best solution, but I have not tried it. One issue with it is that either you have to do the analog signal routing in the middle of the flow (between placement and digital routing), or else you need to specify the placement of all analog blocks. Generally, though, you probably have a floorplan in mind from the beginning and you do want to manually place all your analog blocks, mainly to make sure you have short and straight paths from output to pin, for example.

Thank you Tim! Yes we are aiming for (3) as we are mostly analog with just a bit of digital control circuitry, so will be happy to place and route the floorplan ourselves. 🙂

First I have to say that I have not myself tried working with analog macros placed and routed inside openlane, so I don't have a feel for which method is the best or easiest. Presumably there will be a verilog placeholder or behavioral model for each analog block. If you mark the analog pins as type

inout

in verilog, then none of the tools should complain if you have them all unconnected. I would try doing that---making a special netlist in which all of the digital connections are declared, but none of the analog connections, and then pass that through openlane to get it to do all the digital routes. The reason for doing analog routes first is that openlane will use all available empty space to do its routing, and is likely to run routes inconveniently over areas you need for analog signal routing. I used to do that at MultiGiG, although the digital routing was done by hand, but the analog routes would be done first, shielded if necessary, and the digital would be done afterward. But if the digital is being routed automatically, then it needs to know where the analog routing is so that it routes around it. If you take the analog routes, combine them into a single cell or multiple cells, create LEF views of those cells (the metal routes can be either pins or obstructions, as long as the routing tools see them and know they're there), and then pre-place those macros. In my openframe example at https://github.com/RTimothyEdwards/caravel_openframe_project, there are power connections that are done this way. You'll find placeholder verilog views, layout, and LEF views of the power connections, which are just some metal wires. Those are pre-placed, and openlane does place and route around them. I think that's the model that you want for all the analog routing.

Ahhhh ok! That is really useful to know. Last December we made a very rushed attempt at an Open MPW, but Openlane kept failing on routing. We hadn't included any obstruction areas for our hand-drawn analog wires, so maybe that was contributing to the problem

I think we were looking to do a similar thing; one concern we had was whether Caravel had the support for analog pads? We were currently operating along the idea that we had to harden the digital macros and use them in Caravan - would it be feasible to use analog designs in Caravel instead?

Hi @Aidan McNay, Caravel does indeed support Analog designs, but there a few hoops to jump through to ensure your analog macro is powered and connects up Ok. What shuttle are you aiming for? We are close to having our design working and going through pre-checks for the Nov 6th shuttle, but once thats finished I can share what worked/didn't work etc with you

Cool - thanks for sharing! My team is hopefully targeting June (CI 2406), so a bit away, but we have both analog and digital designs, and weren’t sure whether it would be best to try to combine them in Caravel or Caravan. Would love to hear your thoughts/perspective 🙂