[Libre-silicon-devel] Analog design toolchain for 555

[Éger Ferenc]

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 at ieee.org>
wrote:

> Hi,
>
> On Mon, May 20, 2019 at 1:48 AM Éger Ferenc <eegerferenc at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.libresilicon.com/pipermail/libre-silicon-devel/attachments/20190521/46322a7f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnet-spice-sdb.scm
Type: text/x-scheme
Size: 86045 bytes
Desc: not available
URL: <http://list.libresilicon.com/pipermail/libre-silicon-devel/attachments/20190521/46322a7f/attachment.bin>