X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-CMAE-Analysis:	v=2.3 cv=TbDoSiYh c=1 sm=1 tr=0
	a=+cj0cO56Fp8x7EdhTra87A==:117 a=mhpGnLKyAIE+x33AOwGRLw==:17
	a=9+rZDBEiDlHhcck0kWbJtElFXBc=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19
	a=IkcTkHD0fZMA:10 a=afefHYAZSVUA:10 a=a1KZgU7cAAAA:8 a=Mj1Xp5F7AAAA:8
	a=rEs-uQuVAAAA:20 a=ZNzOqGV4AAAA:8 a=jCSw-aINb3543_6idqIA:9 a=QEXdDO2ut3YA:10
	a=ng0hpkU2jXKPaRTLMVYJ:22 a=OCttjWrK5_uSHO_3Hkg-:22 a=E-7ZDB97qVM_U7m9UvkO:22
X-SECURESERVER-ACCT:	glimrick AT epilitimus DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
	d=epilitimus.com; s=default; h=Content-Transfer-Encoding:Content-Type:
	In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:
	Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From:
	Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:
	List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
	bh=yh2S/1TaPdDkxfCdML2SViRoy0qRi1RY3ZBKcQi6ibM=; b=ODL/tY6raTKWEMTQoxnuN06rDB
	0pa5t+UDmnf0LXVN+1jKBE7nXSfIQnAccYWo4XPLq9tm9N60n2HGpUJGsVSmnK25t18CMxRfGVT6M
	Uzq3uBiudz+h9poj3FsILVxDo7FrizM3w86GcgzOaG+kglIfNl7ILUl3TzG4JhPf4J0gZmRc4REWa
	BYLqh/P0OW5DiBdf4VIR10VO5wispPgltrvWIJn04QZIoGJsti7dtKpYcWk3HvXZdmf0XkVjsTqQY
	sXEtUZDUKNWl3wfZxJYGvjyA2NIOe9K7gnpzrfll38QY5YzP5McG2elTiB7ihBtVjy6d5AtFvEynT
	EtUKb+lQ==;
Subject:	Re: [geda-user] A proposal to allow simulation only component to be
	embedded in schematics
To:	geda-user AT delorie DOT com
References:	<8e4ea0e5-a35f-59e3-8052-8e5901225461 AT epilitimus DOT com>
	<19E1ADF6-6DB0-44F2-B1BA-4FB0F34CF7E8 AT noqsi DOT com>
From:	"Glenn (glimrick AT epilitimus DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Message-ID:	<60f1ec51-d94b-e981-765b-a63b4012563c@epilitimus.com>
Date:	Fri, 16 Oct 2020 10:09:48 -0800
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
	Firefox/60.0 SeaMonkey/2.53.3
MIME-Version:	1.0
In-Reply-To:	<19E1ADF6-6DB0-44F2-B1BA-4FB0F34CF7E8@noqsi.com>
X-AntiAbuse:	This header was added to track abuse, please include it with any abuse report
X-AntiAbuse:	Primary Hostname - a2plcpnl0121.prod.iad2.secureserver.net
X-AntiAbuse:	Original Domain - delorie.com
X-AntiAbuse:	Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse:	Sender Address Domain - epilitimus.com
X-Get-Message-Sender-Via:	a2plcpnl0121.prod.iad2.secureserver.net: authenticated_id: glimrick AT epilitimus DOT com
X-Authenticated-Sender:	a2plcpnl0121.prod.iad2.secureserver.net: glimrick AT epilitimus DOT com
X-Source:
X-Source-Args:
X-Source-Dir:
X-CMAE-Envelope:	MS4wfAwgWwozRKlyjG+bP0bFOK7WKaRYW6ANnTH3uV0DhFzT326Yw7biEMlFIvdqQlYsNjyUfaZ3maCfgxU2jOzLjJKAS4ESBXJpMUbZCaTItI3uliNQB4TD
	eIHNFouHEVcV+fMjz+GavaLWUM9HX8yvuf1yVuWufJ6RDk8TYn/IV+mATk52N/ayl7J7UJZ57cfKZ7eE2yI1AXjForyDuYhUvQ0=
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

I will look at spice-noqsi further but seems like we are coming at the
problem from opposite directions. I am saying put the SOCs in the
schematic and remove them when doing non simulation output. The only way
I can see to do this without all the backends having to contain the same
SOC removal logic is to put it in gnetlist. To my way of thinking this
also allows for clean printout.

Having separate test-fixture and layout versions puts you back into the
parallel design issue.

Does spice-noqsi support the xspice components, digital and hybrid?

Admittedly the possible error checking things were sort of add-ons. The
core idea is to handle SOCs transparently with minimal surrounding
infrastructure. I don't see a reason to have makefiles etc if all you
want to do is have a transistor inverter between a couple of logic gates.

So I think the main difference between our approaches (other than you've
actually already coded yours) is starting point. Having multiple options
allows the user to pick the approach that works best for them.

Glenn

John Doty wrote:
>
>
>> On Oct 15, 2020, at 11:31 PM, Glenn (glimrick AT epilitimus DOT com
>> <mailto:glimrick AT epilitimus DOT com>) [via geda-user AT delorie DOT com
>> <mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com
>> <mailto:geda-user AT delorie DOT com>> wrote:
>>
>> I did look at spice-noqsi but it didn't look to me like it solved the
>> problem.
>
> The spice-prototype attribute in spice-noqsi can do much of what you want.
>
> A component omitted from simulation has:
>
> spice-prototype=* comment on reason for omission.
>
> A two terminal component to be short-circuited in simulation has:
>
> spice-prototype=R? #1 #2 0
>
> There’s great benefit in separating simulation and layout
> environments,
> see https://github.com/noqsi/gnet-spice-noqsi/wiki/Broadband-amplifier-board.
> Simulation-only components may appear in “test fixture” schematics.
> Flow of revisions from master (layout) to tinkering (simulation) may
> be controlled by a Makefile. Using SPICE to expand hierarchy for
> simulation while flattening hierarchy for layout allows for
> simulation-only components, where the spice-prototype rules
> simulation, while a source file with no components (but possibly
> connections) rules layout.
>
> For me, the missing piece is attributes on net segments. These could
> be used for series parasitics in SPICE (using a suitable
> spice-prototype) as well as communicating current-carrying capacity,
> impedance, and topological constraints to layout. Right now,
> attributes can be attached to nets with graphical symbols, but
> topological information is lost.
>
> I intended spice-noqsi to augment the toolkit approach, so it doesn’t
> cover things that your configuration files, makefiles, sources, and
> SPICE itself can accomplish.
>
> John Doty              Noqsi Aerospace, Ltd.
>
> jpd AT noqsi DOT com <mailto:jpd AT noqsi DOT com>
>
>
>
>

- Raw text -