X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
X-TCPREMOTEIP: 207.224.51.38
X-Authenticated-UID: jpd AT noqsi DOT com
Content-Type: multipart/signed; boundary="Apple-Mail=_22C603D1-9924-441E-991C-ABD1AB15D0A4"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: [geda-user] Pin mapping (separate symbols from mappings)
X-Pgp-Agent: GPGMail 2.5.2
From: John Doty <jpd AT noqsi DOT com>
In-Reply-To: <201510190232.t9J2W6XC008909@envy.delorie.com>
Date: Sun, 18 Oct 2015 22:34:25 -0600
Message-Id: <C2839D1B-8CBF-4DD8-BEB7-E45F9265D484@noqsi.com>
References: <20151018204010 DOT 9cce6a231dcc296256e187bd AT gmail DOT com> <201510181843 DOT t9IIhmWo025346 AT envy DOT delorie DOT com> <20151018234424 DOT c0551dad9bef0859130239d9 AT gmail DOT com> <36B94694-F2AC-4A75-A8EB-40A1CE9A534C AT noqsi DOT com> <201510182225 DOT t9IMPkxK032763 AT envy DOT delorie DOT com> <C040B148-8DCD-4CDC-A6F9-E0B92D349738 AT noqsi DOT com> <201510190232 DOT t9J2W6XC008909 AT envy DOT delorie DOT com>
To: geda-user AT delorie DOT com
X-Mailer: Apple Mail (2.1878.6)
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


--Apple-Mail=_22C603D1-9924-441E-991C-ABD1AB15D0A4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Oct 18, 2015, at 8:32 PM, DJ Delorie <dj AT delorie DOT com> wrote:

>=20
>>>> In my opinion, geda-gaf must remain neutral with respect to the
>>>> specifics of the downstream flow.
>>>=20
>>> If we added a tool that sat between gschem and <downstream> that
>>> "heavified" symbols, would that tool be part of geda-gaf and thus =
have
>>> to be neutral about <downstream>, or would that tool not be, and =
thus
>>> something geda-gaf would have to be neutral about?
>>>=20
>>=20
>> A pcb-specific tool
>=20
> I didn't mention pcb, or even layout, in my question.  "Heavy" symbols
> are needed by most backends in some form or another, but what "heavy"
> means tends to be backend-specific.
>=20
>> A tool that adjusts BOM and connectivity data upstream of the
>> gnetlist back end (and is therefore compatible with all of the back
>> ends) would be a proper part of geda-gaf.
>=20
> What if the backend needed more "history" than just what's in the
> schematic?  For example, in layout (any layout, not just pcb) the
> netlister might need to reference the as-built in order to know which
> gates are still available for allocation and pin-mapping.

That information can be extracted from a netlist, and most layout tools =
can produce an as-built netlist.

>=20
> Such functionality would still be part of the netlister, but would
> have to be backend-specific, since each backend has their own idea of
> an "as-built".  How can a downstream-specific backend "remain neutral
> with respect to the specifics of the downstream flow=94 ?

By making the interface be a neutral representation of netlist and BOM.

>  Where and how
> do we decide between "this feature is part of geda-gaf" and "this
> feature doesn't belong because it's too downstream-specific" even if
> geda-gaf is the ideal place to implement that feature?

The challenge for a toolkit is to enable users to create the features =
they need, not to force them to use what we in our folly imagine they =
might need.

>=20
> I'm not trying to be annoying here, I'm just thinking that heavy
> symbols by definition are downstream-specific,

Actually, one of the goals of gnet-spice-noqsi is to have =
symbols/instances that work for a variety of layout tools and for =
simulations. I think it=92s pretty much there. I have schematics that =
work with three different layout programs, and with ngspice. Hurray for =
gEDA!

> we can't help but have
> downstream-specific helpers (pin mapping, model choosing, whatever)
> for the netlisters to use.

Pin mapping is independent of the layout tool. Model choosing depends =
somewhat on the simulation tool, but is currently handled by =
user-written back ends without any specific support in the geda-gaf =
core.

>  What does "neutral" mean for these
> helpers?

It means that they have no flow-specific support in the core code.

>  That we can't have a helper unless at least two backends use
> it, or that it has to be offered in a way that a backend can either
> use it or not?

It means that the flow-specific code is in optional scripts, as it is =
now.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com



--Apple-Mail=_22C603D1-9924-441E-991C-ABD1AB15D0A4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWJHLRAAoJEF1Aj/0UKykRvVcQAKoRO/fq99jNBrMIsOpESihg
leOVVPprJ+PXF3hMypCo0X8v4ZVOpFNAVo8+FulOBupw5mTY+2YXt2UNFveTdIN4
2n7fpZMTC1czCDAOjs825f8tRU+QjximmUdOqXdvI8x0Z8G62YhxbHXQQeLLIPGP
oIqdcK3Fpf/xcC0nbBstugXJInvqGT1q7TeecSALZTcbNNCN7NsaJ4d+HmjtCZ5z
2EF9aNSR7s4axxdEt2aBd+TM0pVdA4Q8/s98QL9Z1HbyToMMoyvItZzYJgJLKyv9
8GPjRyz5/d0TQe1MsQqCUvJWRE6KQEx8av3D4aus85BuWuGjmkGOPApr+nz8it4L
XCEpAW24LU2frKGtgqMq1MiXjDEGVHYmi2dHFJB2MLIxf2R25kMWh1bTv+DUFmDb
TmTV2nGKv60Mvem7R/vVYLfE54fiZzOVK0+zspFc+9sKzdzkyB1JgV/ZW94qMr4B
3nQXX4oFBkoltteGFQsi/xJJIvMKxCK1CWnae2T7x182Q4q/z/z3CDG7nXL86FCS
I+UaNuNyFzeVrxCVEa/dYuEOkeCbjRncBvQAbmO0wjMTyFUd2AXorcKHQPmSCjle
gK1rqV+S3W5JWz/SLCBIk9bh2SbSGBcYwPNw0+eoJ0x/ssshnJ/8y2tjggNGREhZ
7S0Y3Z3ezY2rNMgiLWTB
=NZnO
-----END PGP SIGNATURE-----

--Apple-Mail=_22C603D1-9924-441E-991C-ABD1AB15D0A4--