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]" 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> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 Precedence: bulk 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 >> ) [via 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 > > > >