Hello All,
As we discussed in the last mumble session, here is some status on the analog toolchain I intend to use for the 555. First, some note on the general approach: Many of the tools here are typical Unix-style (invoked in terminal, file goes in, file comes out). This is good from an integration and modularity perspective, and it is a tempting thought to strip all "unnecessary" intermediate steps (gnetlist, gspiceui) and write the SPICE deck and invoke tools manually (as suggested). However, I think this shall be a last resort in case when everything else goes FUBAR, because of two things: first, manual processing is error-prone and we need to really firm regarding what we layout is what we simulate (it is easy to just forget or mistype something and then overlook it) and second, if someone sees in the repo that doing a single .OP requires 6-10 hand-crafted terminal commands (not to mention parameter sweeps or monte carlo), it may be a huge deterrent in adoption (engineers are humans too, and humans in general love the convenience of a big green button).
The tools so far (RFC if you think there's a better option): gschem 1.8.2 (schematic capture) gnetlist 1.8.2 (netlist extractor, alleged source is at https://packages.ubuntu.com/source/xenial/geda-gaf) gspiceui 1.1.00 or 1.2.36 (orchestrates netlist extraction, deck generation, simulator invocation, waveform viewer invocation, like ADE, source: https://sourceforge.net/projects/gspiceui/) ngspice 26 (simulator) gaw (waveform viewer)
Problems discovered so far: 1. In gschem, components automatically get '?' refdes on place or copy. Refdes must be unique, therefore it is beneficial to insert some lines (see https://ashwith.wordpress.com/2010/09/10/circuit-simulation-in-gnulinux-lets...) into gschemrc (and not gafrc, that doesn't work).
2. gnetlist makes use of the gschemrc configuration to establish mapping between symbols and sub-schematics (subsch is not recorded in the schematic, but in the symbol file). However, gspiceui invokes gnetlist not in the current working directory, but where the schematic is loaded from, so local gschemrc is not parsed. Possible solutions: - Adapt a flat directory structure (no sources, tbench, ...). Ugly but works. - Place a link to the local gschemrc everywhere - Set libraries in the global gschemrc (not good because necessary config no longer contained in the project dir) - Patch gspiceui (PrcGNetList.cpp 396) - Invoke gnetlist manually outside gspiceui and import complete netlist
3. In case of hierarchical designs flattened into a single circuit, gnetlist places '/' into net names and component names ("X1/R1 11 7 100k"). This breaks ngspice (interpreted like "X1 R1 11 7 100k"). Blind replacement does not help, as if we use parametric models, we may need expressions containing division.
4. Nets in lower levels and nets at higher levels connected to them are treated as separate entities and not connected, for example: MX1/M26 X1/OUTPUT 18 X1/GND X1/GND nmos4 l=0.5u w=20u R3 1 5 100 (shall be R3 1 X1/OUTPUT 100) Maybe the wrong port symbol is used in the lower level, this needs to be checked first.
5. When flattening hierarchical designs, component designators sometimes have wrong first letter (first letter denotes component type). Particularly, MOS works but resistors are not: MX1/M11 X1/GND 13 13 X1/GND nmos4 l=0.5u w=10u X1/R4 12 X1/GND 40k Output from console: --- checking package = X1/M12 device = NMOS_TRANSISTOR Found NMOS transistor. Refdes = X1/M12 Checking prefix. Package prefix =X correct prefix =M nomunge mode = #f different-prefix=#t --- checking package = X1/M11 device = NMOS_TRANSISTOR Found NMOS transistor. Refdes = X1/M11 Checking prefix. Package prefix =X correct prefix =M nomunge mode = #f different-prefix=#t --- checking package = X1/R4 device = RESISTOR Found resistor. Refdes = X1/R4 --- checking package = X1/R2 device = RESISTOR Found resistor. Refdes = X1/R2
Most of the errors can be reproduced by invoking gnetlist on the current testbench (before that, V? needs to be changed into V1). Command line: /usr/bin/gnetlist -v -g spice-sdb -o /home/kiseferi/IC/github/CMOS-555/TBench/geda/Use-Case_astable-mode.ckt /home/kiseferi/IC/github/CMOS-555/TBench/geda/Use-Case_astable-mode.sch
The resulting netlist of course makes no sense (no .MODEL for MOSFETs, etc...), but what is already there should be structurally correct.
Maybe a solution is to use either a .SUBCKT instead of flattening (good only if internal nodes remain query-able), or to use a single schematic page (ugly).
Regards, Ferenc
Hi,
On Mon, May 20, 2019 at 1:48 AM Éger Ferenc eegerferenc@gmail.com wrote:
Hello All,
As we discussed in the last mumble session, here is some status on the analog toolchain I intend to use for the 555. First, some note on the general approach: Many of the tools here are typical Unix-style (invoked in terminal, file goes in, file comes out). This is good from an integration and modularity perspective, and it is a tempting thought to strip all "unnecessary" intermediate steps (gnetlist, gspiceui) and write the SPICE deck and invoke tools manually (as suggested). However, I think this shall be a last resort in case when everything else goes FUBAR, because of two things: first, manual processing is error-prone and we need to really firm regarding what we layout is what we simulate (it is easy to just forget or mistype something and then overlook it) and second, if someone sees in the repo that doing a single .OP requires 6-10 hand-crafted terminal commands (not to mention parameter sweeps or monte carlo), it may be a huge deterrent in adoption (engineers are humans too, and humans in general love the convenience of a big green button).
In terms of establishing a proper design flow, I agree with you.
The aspect of libre-silicon even more important than a workable EDA design flow may be to get a proof-of-concept circuit on actual silicon as soon as possible, so that David et al. don't lose access to a foundry. In this case, we analog IC design guys should focus on giving the foundry alchemists a layout that has a chance to be functional by any means, without relying on EDA tools and simulations based on device models that aren't verified, and will remain impossible to get verified without some sort of established IC fabrication flow.
What kind of circuit layout would make a difference for David et al. within the next two weeks?
tatzelbrumm
Hello All,
Short update: problems outlined in the previous mail solved: 1. as described 2. Call gnetlist from the terminal for existing testbench. For the actual design, I will use a single work directory. 3. See http://wiki.geda-project.org/geda:hierarchy (gnetlistrc) 4. Wrong pins are used in the schematic (see 3). Also, I removed the overbar from the symbol, as the pin label string is used to match symbol and schematic pins, and backslash may screw things up. 5. This is a real problem. The rootcause is that the spice-sdb backend coming with gnetlist is more or less a stub. Patching an installed file is neccessary (/usr/share/gEDA/scheme/gnet-spice-sdb.scm, attached).
Another disability: gnetlist disregards the power rail symbols. Attaching a net label to wires as a workaround.
@tatzelbrumm: I understand the point and really don't want to waste too much time on the tooling. However, I do not want to start laying out something that was not checked at least once against at least nominal conditions. Although it is true that we won't have a stable process with a proper PDK in time, but committing the design before even we have the first realistic parameters from the lab based on that a similar design used to work on a no-one-knows-what process seems to be too head-into-brickwall for me.
After I clean up the mess, I will commit the current status.
Regards, Ferenc
On Mon, May 20, 2019 at 5:22 AM Christoph Maier christoph.maier@ieee.org wrote:
Hi,
On Mon, May 20, 2019 at 1:48 AM Éger Ferenc eegerferenc@gmail.com wrote:
Hello All,
As we discussed in the last mumble session, here is some status on the
analog toolchain I intend to use for the 555. First, some note on the general approach: Many of the tools here are typical Unix-style (invoked in terminal, file goes in, file comes out). This is good from an integration and modularity perspective, and it is a tempting thought to strip all "unnecessary" intermediate steps (gnetlist, gspiceui) and write the SPICE deck and invoke tools manually (as suggested). However, I think this shall be a last resort in case when everything else goes FUBAR, because of two things: first, manual processing is error-prone and we need to really firm regarding what we layout is what we simulate (it is easy to just forget or mistype something and then overlook it) and second, if someone sees in the repo that doing a single .OP requires 6-10 hand-crafted terminal commands (not to mention parameter sweeps or monte carlo), it may be a huge deterrent in adoption (engineers are humans too, and humans in general love the convenience of a big green button).
In terms of establishing a proper design flow, I agree with you.
The aspect of libre-silicon even more important than a workable EDA design flow may be to get a proof-of-concept circuit on actual silicon as soon as possible, so that David et al. don't lose access to a foundry. In this case, we analog IC design guys should focus on giving the foundry alchemists a layout that has a chance to be functional by any means, without relying on EDA tools and simulations based on device models that aren't verified, and will remain impossible to get verified without some sort of established IC fabrication flow.
What kind of circuit layout would make a difference for David et al. within the next two weeks?
tatzelbrumm
Hello All,
Short update: problems outlined in the previous mail solved: 1. as described 2. Call gnetlist from the terminal for existing testbench. For the actual design, I will use a single work directory. 3. See http://wiki.geda-project.org/geda:hierarchy (gnetlistrc) 4. Wrong pins are used in the schematic (see 3). Also, I removed the overbar from the symbol, as the pin label string is used to match symbol and schematic pins, and backslash may screw things up. 5. This is a real problem. The rootcause is that the spice-sdb backend coming with gnetlist is more or less a stub. Patching an installed file is neccessary (/usr/share/gEDA/scheme/gnet-spice-sdb.scm, attached).
Another disability: gnetlist disregards the power rail symbols. Attaching a net label to wires as a workaround.
@tatzelbrumm: I understand the point and really don't want to waste too much time on the tooling. However, I do not want to start laying out something that was not checked at least once against at least nominal conditions. Although it is true that we won't have a stable process with a proper PDK in time, but committing the design before even we have the first realistic parameters from the lab based on that a similar design used to work on a no-one-knows-what process seems to be too head-into-brickwall for me.
After I clean up the mess, I will commit the current status.
Regards, Ferenc
On Mon, May 20, 2019 at 5:22 AM Christoph Maier christoph.maier@ieee.org wrote:
Hi,
On Mon, May 20, 2019 at 1:48 AM Éger Ferenc eegerferenc@gmail.com wrote:
Hello All,
As we discussed in the last mumble session, here is some status on the
analog toolchain I intend to use for the 555. First, some note on the general approach: Many of the tools here are typical Unix-style (invoked in terminal, file goes in, file comes out). This is good from an integration and modularity perspective, and it is a tempting thought to strip all "unnecessary" intermediate steps (gnetlist, gspiceui) and write the SPICE deck and invoke tools manually (as suggested). However, I think this shall be a last resort in case when everything else goes FUBAR, because of two things: first, manual processing is error-prone and we need to really firm regarding what we layout is what we simulate (it is easy to just forget or mistype something and then overlook it) and second, if someone sees in the repo that doing a single .OP requires 6-10 hand-crafted terminal commands (not to mention parameter sweeps or monte carlo), it may be a huge deterrent in adoption (engineers are humans too, and humans in general love the convenience of a big green button).
In terms of establishing a proper design flow, I agree with you.
The aspect of libre-silicon even more important than a workable EDA design flow may be to get a proof-of-concept circuit on actual silicon as soon as possible, so that David et al. don't lose access to a foundry. In this case, we analog IC design guys should focus on giving the foundry alchemists a layout that has a chance to be functional by any means, without relying on EDA tools and simulations based on device models that aren't verified, and will remain impossible to get verified without some sort of established IC fabrication flow.
What kind of circuit layout would make a difference for David et al. within the next two weeks?
tatzelbrumm
Hello All.
Comments inside:
On 5/20/19 1:48 AM, Éger Ferenc wrote:
The tools so far (RFC if you think there's a better option): gschem 1.8.2 (schematic capture)
lepton-schematic --version > 1.9.7 (git: f3a8714)
gnetlist 1.8.2 (netlist extractor, alleged source is at https://packages.ubuntu.com/source/xenial/geda-gaf)
lepton-netlist > 1.9.7.20181211 (git: f3a8714)
gspiceui 1.1.00 or 1.2.36 (orchestrates netlist extraction, deck generation, simulator invocation, waveform viewer invocation, like ADE, source: https://sourceforge.net/projects/gspiceui/) ngspice 26 (simulator)
ngspice > 30
gaw (waveform viewer)
Well, I use lepton-EDA here, installed under Debian SID (somehow a rolling release). The killer-feature IMHO is the possibility to compare two schematic versions graphical by
git difftool -x lepton-schdiff Sources/geda/555_Book-Version.sch
:-)
Problems discovered so far:
- In gschem, components automatically get '?' refdes on place or copy.
Refdes must be unique, therefore it is beneficial to insert some lines
Just after drawing the schematic follows a numbering-step with lepton-refdes_renum or lepton-renum = two tools for the same step.
- gnetlist makes use of the gschemrc configuration to establish mapping
between symbols and sub-schematics (subsch is not recorded in the schematic, but in the symbol file). However, gspiceui invokes gnetlist not in the current working directory, but where the schematic is loaded from, so local gschemrc is not parsed. Possible solutions:
- Adapt a flat directory structure (no sources, tbench, ...). Ugly but
works.
- Place a link to the local gschemrc everywhere
- Set libraries in the global gschemrc (not good because necessary
config no longer contained in the project dir)
- Patch gspiceui (PrcGNetList.cpp 396)
- Invoke gnetlist manually outside gspiceui and import complete netlist
I still figuring out the best solution.
- In case of hierarchical designs flattened into a single circuit,
gnetlist places '/' into net names and component names ("X1/R1 11 7 100k"). This breaks ngspice (interpreted like "X1 R1 11 7 100k"). Blind replacement does not help, as if we use parametric models, we may need expressions containing division.
The link you mentioned regarding the hierarchical designs contains the hint, that with configuration we are able to append the component name tag after the Circuit, eg. R1_X1 which would work for us.
The gnetlistrc with this configuration I'll add soon to the git repository.
- Nets in lower levels and nets at higher levels connected to them are
treated as separate entities and not connected, for example: MX1/M26 X1/OUTPUT 18 X1/GND X1/GND nmos4 l=0.5u w=20u R3 1 5 100 (shall be R3 1 X1/OUTPUT 100) Maybe the wrong port symbol is used in the lower level, this needs to be checked first.
See answer for 3.
- When flattening hierarchical designs, component designators sometimes
have wrong first letter (first letter denotes component type). Particularly, MOS works but resistors are not:
See answer for 3.
Maybe a solution is to use either a .SUBCKT instead of flattening (good only if internal nodes remain query-able), or to use a single schematic page (ugly).
Yes. I prefer the .SUBCKT solution with Toplevel just containing the test bench and the circuit is hidden (and inter-changeable).
Regards, Hagen.
Hello Everybody!
Good news for the 555 also. Today I got the Spice Simulation set right.
All changes are checked in for the 555_Book-Version.sch, all other Versions I still have to fix.
Just look at the
make sim
target in the GNUmakefile. And yes, the Use-Case example still misses the right functionality.
A short howto about how to got the simulation in Spice, which attributes in the Schematics I add (and which removed) will follow soon.. Well, first I have to sleep some hours :-)
Regards, Hagen.
Hello List!
I updated both Versions, from Rigtho and Wikimedia as Sources, also. Now all three 555 schematics are able to run inside a hierarchical Spice Environment, controlled by the Makefile.
Please take a look at https://github.com/libresilicon/cmos-555
and give your feedback.
The announced Howto, as I figured it out, I wrote down here
https://vcs.in-berlin.de/chipforge_stdcelllib/wiki?name=Howto_Hierarchical-g...
for further usage. Well, I'll need it for the Standard Cells as well.
@tatzelbrumm, @ferenc: What else (beside the correct Spice Model from the PearlRiver) we need to do the dimensions? Last Sunday we talked about upscaling the MOSFET Width (W) regarding the new Length of 1 Micron instead 0.5 Micron, but thats all, isn't it?
Regards, Hagen.
On 5/25/19 12:57 AM, Hagen SANKOWSKI wrote:
Hello Everybody!
Good news for the 555 also. Today I got the Spice Simulation set right.
All changes are checked in for the 555_Book-Version.sch, all other Versions I still have to fix.
Just look at the
make sim
target in the GNUmakefile. And yes, the Use-Case example still misses the right functionality.
A short howto about how to got the simulation in Spice, which attributes in the Schematics I add (and which removed) will follow soon.. Well, first I have to sleep some hours :-)
Regards, Hagen. _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Hello Everyone,
The librarian tool (auto-generation of static magic library from spice netlist) is out. Please check if it is useable.
Regards, Ferenc
On Sat, May 25, 2019 at 3:52 PM Hagen SANKOWSKI hsank@posteo.de wrote:
Hello List!
I updated both Versions, from Rigtho and Wikimedia as Sources, also. Now all three 555 schematics are able to run inside a hierarchical Spice Environment, controlled by the Makefile.
Please take a look at https://github.com/libresilicon/cmos-555
and give your feedback.
The announced Howto, as I figured it out, I wrote down here
https://vcs.in-berlin.de/chipforge_stdcelllib/wiki?name=Howto_Hierarchical-g...
for further usage. Well, I'll need it for the Standard Cells as well.
@tatzelbrumm, @ferenc: What else (beside the correct Spice Model from the PearlRiver) we need to do the dimensions? Last Sunday we talked about upscaling the MOSFET Width (W) regarding the new Length of 1 Micron instead 0.5 Micron, but thats all, isn't it?
Regards, Hagen.
On 5/25/19 12:57 AM, Hagen SANKOWSKI wrote:
Hello Everybody!
Good news for the 555 also. Today I got the Spice Simulation set right.
All changes are checked in for the 555_Book-Version.sch, all other Versions I still have to fix.
Just look at the
make sim
target in the GNUmakefile. And yes, the Use-Case example still misses the right functionality.
A short howto about how to got the simulation in Spice, which attributes in the Schematics I add (and which removed) will follow soon.. Well, first I have to sleep some hours :-)
Regards, Hagen. _______________________________________________ Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
Libre-silicon-devel mailing list Libre-silicon-devel@list.libresilicon.com http://list.libresilicon.com/mailman/listinfo/libre-silicon-devel
libresilicon-developers@list.libresilicon.com
-
Christoph Maier -
Hagen SANKOWSKI -
Éger Ferenc