@User: I would very much like to know the result of that.

Hello. Can anyone please help me to get the analog flow up and running. Do we have documentation somewhere for this? Thank you.

@User: "The analog flow" is a vague concept. What tools do you want to be running?

@User the spectre simulation didn't really work out. Even though spectre is meant to be able to read spice netlists there were tons of syntax issues so I didn't really pursue that any further. But I did notice that the wrong model bin was being selected, and I remember you mentioning there being an ngspice bug with fingers - indeed the device I was using had two fingers. So I'm just sidestepping that for now by using the multiplier version instead which happily simulates at the ss corner at 150C. So I think we can just chalk this up to the previously know ngspice bug

@User: The simulation netlists are specifically written for ngspice, which has a ".control" ... ".endc" block that is, as far as I am aware, completely incompatible with anything that is not ngspice. But for the most part you can remove the ".control" ... ".endc" and change the analysis from "dc" to ".dc" or "ac" to ".ac", etc., and it should perform the same analysis. The "wrdata" is a command that generates column-separated data in ASCII format, and you could replace that with ".save" and then read the resulting raw file.

Yeah, I removed all that ngspice stuff from the test bench and replaced with stock spice sim commands. The syntax 'errors' were in the libraries themselves. It wasnt correctly parsing/evaluating variables in a myriad of ways. I started drilling down into for a bit but realised it wasn't going to be worth it for the issue at hand. If you're really interested I can send you a list of errors. I'm not sure how much people are planning to use these models with spectre versus using the original models under NDA

It’s definitely incompatible with Xyce, or Spice OPUS

sorry I've been gone for a while...my daughter's birthday party, prepping for travel to my brother's wedding, and doing some long needed work on my other main open source project has kept me quite busy

I did some simulation analysis on the available resistors: https://github.com/xorbit/sky130-power-blocks/blob/master/primitive-test/resistors.md Some related questions are: • Where can I find the models that are in the docs but don't seem to be in the repo? • Is the lack of temperature modeling in some of the models due to incompatibility with ngspice? • Are the P- poly resistors really that stable over temperature? • Looking through the rules/device-details doc, there are a ton of symbols that seem to be made in xschem. I can't seem to find them in the PDK, are they available somewhere?

Very interesting write up. Will be useful

I don't fully understand why theres the internal temperature value and then also a temp parameter required which is in the tests and here as well. When the temperature sweep is performed is it sweeping the internal temperature value, the parameter or both? Maybe the devices which dont see any temp effect are referencing the static parameter rather than the swept simulator internal temperature value?

Running the sweep in a control statement loop which explicitly alters both would (dis) prove this theory

Regarding the xschem symbols, I know that @User was making some symbols. Was just digital cells I think when I saw his post weeks ago but maybe there's more now.

I wonder if the P+ poly ones are silicide-block resistors? They can have really good numbers +-10ppm

@User It is entirely possible I'm doing things wrong, it's been years since I've done anything like this and with different tools, so I'm trying to learn as I go. I'd love to see your control loop approach. It would probably be very helpful for doing temp sweep for ac analysis. I haven't been able to figure out how to do this, since the way I found to do this is by abusing a "dc analysis". Back in the day my simulator allowed .temp statement and that was that, but it seems ngspice doesn't do that.

I don't think you're doing anything wrong, we're all still getting used to the new tools, setup and how to get the best out of the technology's personality. Sure, I can pull your example and will try it in a control loop to see if it changes anything. Will report back

What are people using for schematic entry? I saw xschem mentioned, which seems very... dated. Or are y'all just writing netlists with magnetic needles and all that? I also noticed that there do not appear to be any symbols present. Is this something that could be extracted from proprietary formats in the commercial PDK, or do we need to make our own? My unfounded impression is that maybe KiCad's eeschema could be made to support sky130? It has a mature and maintained schematic editor which already integrates with ngspice.

So apparently Electric is another contender for schematic entry that I have not seen before. Interesting...

maybe @User could shed some light here

@User different people will end up picking different programs and that's good. Ultimately the only requirement is that it can generate a netlist. But I did look into the various options and in the end I fully invested in xschem, I can share with you my reasons for that. 1. Hierarchy is king in IC design and is fundamental to everything. Most PCB editors (certainly KiCad) started from a point of discrete component primitives and then added some hierarchy features over the years. They're workable for PCB work but really not great for IC work where you need to be able to seamlessly flow in and out of the heirarchy. (as far as I'm aware) xschem was built with hierarchy in mind from the start and the cell structure works well. It supports retargeting the implementation beneath the symbol easily. One of the reasons this is important is when you want to switch between simulating fast behaviourial model (lets say a spice voltage controlled current source with a couple of passives) or a fully modelled circuit. 2. Simulation is integrated with ngspice and Xyce simulator with gaw and ngspice plotting capabilities with net highlighting too. In my opinion this setup is superior to KiCads simulation features 3. It is fast, reliable and overall a solid piece of software. In a lot of ways it exemplifies the open source way, it performs a very specific function very well and is regularly maintained. I'm not sure that's neccesarly the case with electric which is a java program (maybe that's just my bias showing) with loads of integrated functions and features that was last updated four years ago. The Glade program is also interesting but it is freeware and I will not be invest my time and my designs in a program that I can't complain to someone because I've paid or modify myself 4. The developer, @User, is active in the community and is very helpful with tips and tricks, that gives me faith that I can invest in the program 5. The program looks, feels and behaves very similarly to the dominant commercial tool, Cadence Virtuoso. For some people this does not matter at all, for others this is very important But these are just my reasons why I like xschem. Others may have their own opinions

Ah okay, good to hear xschem is being actively developed. If I search for xschem I get sourceforge which says it moved to coralEDA which is discontinued.

Hmmm, no idea about that, but certainly the activity log shows the most recent change only an hour ago

@User I ran the resistor temperature simulations varying the temperature (

.temp 27

) and the parameter (

.param temp 27

) and still see no temperature effect on those suffix devices. So my hunch was wrong and it must be something else happening.

@User The actual repository for xschem is https://github.com/StefanSchippers/xschem. And yes, even if the software interface looks "old", it is definitively very capable (I'm moving all my "analog" work from gschem to xschem actually

Yea I found the repo and just installed it. My first response: aaaaaaaaaahhhhhh! I opened an example and simulation silently failed because it was trying to launch xterm. But I'm sure it's a very powerful and capable tool. I read somewhere in a thread Stefan is actually working on a Sky130 library, which would be super nice. I think the point of hierarchical design is very important, and I should look into that. Personally, the way I see it there is an "old generation" of software like magic and xschem from the days of lambda rules that during last decades saw minimal use and maintenance. These tools are currently the most powerful we have in the open source space, but they definitely show their age. From the PCB side and the FPGA side, there is already a "new generation" of tools like Yosys and KiCad that see a lot of activity and have full-time teams working on them. What I would personally love to see is a focus on a "new generation" of ASIC tools. KLayout comes to mind as something that could fit the bill. So I think personally I'd like to focus on bootstrapping from well-funded FPGA/PCB tools, and work on a new generation of ASIC tools. I think long term it's the only way to catch up with the commercial tools with their giant budgets but a long and messy legacy.

It’s worth taking a look at BAG especially if you are interested in a reusing components across projects and technology nodes.

Maybe this is a better channel for this question!

Let's start at the beginning and see where I hit a roadblock!

I believe all the pieces are there but I don't know of anyone that's went through all the phases yet. I'm also aiming to start moving to layout with a cell this week, so we could hold each others hand if we run into any issues

Normally I would expect the netlist to represented in a schematic rendered to spice netlist but doing it in RTL is also possible