Mail Archives: geda-user/2015/10/19/00:35:13
--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--
- Raw text -