Open mithro opened 2 years ago
Some description of the .mdm
file format is found at https://people.ece.ubc.ca/robertor/Links_files/Files/ICCAP-2008-doc/icug/icug136.html
There is also an image which describes the data at https://github.com/google/skywater-pdk-sky130-raw-data/blob/main/docs/_static/mdm-format.png
Alright, I've gone through some of the raw data and I think some basics can be put together quickly to then do some incremental dev. Any particulars on this? Can I use panads/dfs should this be numpy only?
No real particulars, do what ever you think is the most fun. FWIW I think being able to pull the data into pandas/dfs would be cool.
Here is a little bit more potentially useful information;
From what I understand mdm files are produced by a tool call IC-CAP and are used to record experimental measurements.
PathWave Device Modeling (IC-CAP) software is the industry standard for DC and RF semiconductor device modeling. The Integrated Circuit Characterization and Analysis Program (IC-CAP) extracts accurate compact models used in high speed/digital, analog and power RF applications. Today’s most advanced semiconductor foundries and IDMs rely on IC-CAP for modeling silicon CMOS, Bipolar, compound gallium arsenide (GaAs), gallium nitride (GaN) and many other IC device technologies. IC-CAP is the most advanced, customizable modeling software and includes measurement, simulation, optimization and statistical analysis tools.
- Open modeling software architecture enables maximum accuracy and provides ultimate flexibility to create and automate measurement, extraction and verification procedures
- Turnkey extraction solutions for industry standard CMOS models, such as BSIM3/BSIM4, PSP and HiSIM, minimize the learning curve and maximize model accuracy
- Most direct links to commercial simulators ensure consistency between extracted models and the simulators used by circuit designers
Yup, already saw that.
There are a few FOSS tools that could interface with iccap but they’re no longer maintained (disappeared from source forge)
The approach I’m taking right now is, read in limited options for the header file and then construct the data frame corresponding to that metadata. Going to try and do a mwe that I can iterate on.
On Sun, Jul 31, 2022 at 15:10 mithro @.***> wrote:
Here is a little bit more potentially useful information;
From what I understand mdm files are produced by a tool call IC-CAP and are used to record experimental measurements.
PathWave Device Modeling (IC-CAP) software is the industry standard for DC and RF semiconductor device modeling. The Integrated Circuit Characterization and Analysis Program (IC-CAP) extracts accurate compact models used in high speed/digital, analog and power RF applications. Today’s most advanced semiconductor foundries and IDMs rely on IC-CAP for modeling silicon CMOS, Bipolar, compound gallium arsenide (GaAs), gallium nitride (GaN) and many other IC device technologies. IC-CAP is the most advanced, customizable modeling software and includes measurement, simulation, optimization and statistical analysis tools.
- Open modeling software architecture enables maximum accuracy and provides ultimate flexibility to create and automate measurement, extraction and verification procedures
- Turnkey extraction solutions for industry standard CMOS models, such as BSIM3/BSIM4, PSP and HiSIM, minimize the learning curve and maximize model accuracy
- Most direct links to commercial simulators ensure consistency between extracted models and the simulators used by circuit designers
— Reply to this email directly, view it on GitHub https://github.com/google/skywater-pdk-sky130-raw-data/issues/1#issuecomment-1200481993, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJT7Q4RUORFZXK27T7LBCTVW3FQ3ANCNFSM543OTB6A . You are receiving this because you commented.Message ID: @.***>
@siddharth-joshi - Feel free to dump links and other resources into this issue as you discover them so other people can also follow along.
Actually realized that this might be a solved problem. There's a comprehensive open-source MOS modeling community, the EKV model for e.g., came from there. A presentation I cam across: https://www.iee.et.tu-dresden.de/iee/eb/forsch/AK-Bipo/2019/7-MOS-AK-Association_wgr_BipAK19.pdf links to the python device modeling toolkit. DMT is at https://gitlab.com/dmt-development/dmt-core DMT .
DMT also is widely interoperable, including being able to read from mdm files: https://gitlab.com/dmt-development/dmt-core/-/blob/main/DMT/core/data_reader.py . Note that they convert it into their own format but can output dataframes too.
IMHO given this is an existing and tested project, you might wish to use this instead of something I cobbled together hastily.
@siddharth-joshi thanks for the find!
I'll try to switch my notebook to that https://colab.research.google.com/gist/proppy/00b7a5e58314a9d387e8174581c77866/skywater-pdk-sky130-raw-data.ipynb, that'll be way more reliable than the current fragile regexps.
@siddharth-joshi I gave it a try in https://github.com/google/skywater-pdk-sky130-raw-data/pull/7
Cool, your notebook looks pretty clean with DMT! Just an FYI, I think DMT is GPL, you may wish to double check you can actually use it.
Also, their code looks remarkably simple, I'm curious re: if they're covering all edge cases?
I think DMT is GPL, you may wish to double check you can actually use it.
Ah yes, you're right I should update the copyright notice of the combined work (the notebook) to GPL-v3.
FYI - I logged https://gitlab.com/dmt-development/dmt-core/-/issues/12 to suggest they use the data from this repository in their test cases and documentation.
Thanks for supplying the publicly available mdm data, we will add a test case and examples in DMT using the skywater PDK in the future.
Hi, only loosly relatied to this topic, but also related to reading the files:
How exactly are the file names build? My impression is:
sky130_fd_pr__nfet_01v8_w0p36u_l0p15u_m1(8701_9_10_IDVD).mdm
^- Device name
^- width in m
^- length in m
^- metal contact
^- Here is 8701_9_10 and 8701_11_12. What is the difference ?
^- measurement curve (either IDVD or IDVG)
That would help to provide an example with the data read correctly..
@miesli thanks for raising this, let's continue the discussion about the naming scheme in https://github.com/google/skywater-pdk-sky130-raw-data/issues/9#issue-1325945012.
I tried to document the naming scheme for the base level primitives at http://bit.ly/open-source-pdks-naming and https://bit.ly/sky130-names
I added a test case for the mdm parser to DMT-core, it shows that your files can be easily read using it. This is not really surprising since we both used ICCAP to generate the mdm-files.
Furthermore, I generated an example to read in the full data set you provided in https://dmt.semimod.de/examples/readin_dut_lib.html To show off some off the possibilities, here is the generated documentation of the measurement: documentation.pdf I only filtered for the "esd nfet 01v8". If all devices were added, the document would be way too big.
I hope this helps you to check, read and further process the measurement data. My next goal is to be able to simulate the PDK transistors easily in DMT and compare these to the measurements.
All feedback is welcome!
FYI - @proppy
Furthermore, I generated an example to read in the full data set you provided in https://dmt.semimod.de/examples/readin_dut_lib.html To show off some off the possibilities, here is the generated documentation of the measurement: documentation.pdf I only filtered for the "esd nfet 01v8". If all devices were added, the document would be way too big.
We should definitly update the notebook to leverage this!
I noticed that a fair amount of https://dmt.semimod.de/examples/readin_dut_lib.html is about moving files and extracting information from the naming scheme, would it make sense to store/package/distribute the data as a DutLib
? Is there a common repository where the DMT project already publish and version such datasets?
Yes, to read in the data correctly, the data has to be sorted accordingly. I can imagine multiple ways to distribute the sorting:
Dutlib
DMT.DutLib
Currently, I was not really able to decide, which way is the best, as each have their own advantages and disadvantages. Distributing the DutLib
is easy, but not really flexible (also, the sorting is not perfect currently). The read-in file would be nothing else but a copy-paste of the example in the first step, and was not really worth the effort. Finally, implementing into DMT.DutLib
could be done for the tree folder, but not for the naming of the devices and the measurements.
Personally, I would opt for distributing the read-in file in a repository with a build-chain to release the DutLib
on changes in the file or the raw-data. I would be happy to contribute to that or set it up.
What are your thoughts on that?
I was able to start my preferred option: https://gitlab.com/dmt-development/skywater130-pdk-dutlib
In this repo there are several scripts to play with the measurement data and in the CI it creates the DutLib
to download:
https://gitlab.com/dmt-development/skywater130-pdk-dutlib/-/jobs/2847403361/artifacts/file/skywater130_lib.tar.gz
(Later it will properly create a release, I just fixed the CI...)
I hope, this combines the best of all worlds.
To create the DutLib
on your own, you can clone the repo and then call the commands as it is done in the CI.
If you only want to play with it, you should be able to download the lib directly. But I expect some hick ups here, as porting DutLib
objects is not thoroughly tested until now.
We need a decent Python library which makes it trivial to open the
.mdm
files found in these repositories. Will be useful for plotting the data with things like matplotlib and exploring with other Python data analysis tooling.