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