X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
	bh=suOGcPIvv1UX81Nai7AqNrzIjEnh8b2wi0DBYQlPQzM=;
	b=l8VXfbiVmxszV0NrSn50HGgu//erWeqz2u/FkUKdCa5q4JmtBtmlrgRxRF2ifpMkdV
	g7bYtfbYDvfja3zsmEsVixQbCQDHq/wlnziqB6pYCcswtBXyvf+j5ateY9BEnPABB4TL
	qkAnlr6qc6rx51o2mRuU5o5dCQlpCBl5MwVC2G0vHncgRERxkxX4izcTb3QPtBIqkLG/
	qpohvv8MHhKwEGnBlyEBUTvMs2zDuC/IrDj4edsSMnRwJkPXdVY+LV4+kIkrMpyQUzYo
	Np8X+jmLG/iNaYD0v10nDS3Nx3S0x6c8oPajf7kO+84bwsavFRJPR9k06+mW38xDQ9e+
	zDCw==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=suOGcPIvv1UX81Nai7AqNrzIjEnh8b2wi0DBYQlPQzM=;
	b=jbLOQLdlUlulnYNLLn9AEVTiUFwQhnPG4tdghxwLIzlp45SVIuE/8Ejs4WFYaa5lBO
	g4LkV01MB4rcql/8vYCzCyJYizZ1QVoU4FDX0PMueRQHuXLaD822BDgMXdfWqv0dHNTo
	bzb4yX//byvp0tJcq64YTvD9CCrbzzj1PHkdx2AFqMC/6CXERZVl5DNnsHcsCMRMIbBl
	XxOjugm1r8vmFVEmRfaVXJHUftE1p23py4vvPb8staH9GKBweck4XMgdXxy3CowWcWuR
	xGzplPea8lyDIkV7Tf6pEJD/LDGWElhxWpFhcdPU6TXv8x+o+IkbBfdb4hPRXjcnQ+Fu
	iVWQ==
X-Gm-Message-State:	AE9vXwPYZ4GakgnvdmqrgxEwzWzrbQ5xSBWLxUXJknctjbS0f9B84mcz9cz6lWQernQzejpiT4jWglJXoIGEOw==
X-Received:	by 10.25.35.87 with SMTP id j84mr3925340lfj.228.1472672529167;
	Wed, 31 Aug 2016 12:42:09 -0700 (PDT)
MIME-Version:	1.0
In-Reply-To:	<20160831130045.27d23a85@floyd.freeelectron.net>
References:	<CAM2RGhT_pQZ8CGGM6ECwDUwJHeo3UwDJ6d_7RtVWhxJBQ=K1tA AT mail DOT gmail DOT com>
	<57C09C3C DOT 7020708 AT xs4all DOT nl> <20160826171545 DOT 2bc54995 AT floyd DOT freeelectron DOT net>
	<CAM2RGhQJJmbhKBsX5K495jDRid5px33d4MKcFN8cv2MNTkRQMg AT mail DOT gmail DOT com>
	<20160827013103 DOT 63bb0bdd AT floyd DOT freeelectron DOT net> <CAM2RGhSb3-KdN3rMo5vxjkbTO+-vU_Tgj+hOcoHxyz4HGwnzbA AT mail DOT gmail DOT com>
	<20160831130045 DOT 27d23a85 AT floyd DOT freeelectron DOT net>
From:	"Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Date:	Wed, 31 Aug 2016 15:42:08 -0400
Message-ID:	<CAM2RGhTuY3gyOVmafBuoYy14GBzLJQsKWdDbavUTqMDjpNS4WQ@mail.gmail.com>
Subject:	Re: [geda-user] Microwave PCB layout simulation or How to eat all
	your processing power in 3 easy steps
To:	gEDA users mailing list <geda-user AT delorie DOT com>
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

On Wed, Aug 31, 2016 at 1:00 PM, al davis <ad252 AT freeelectron DOT net> wrote:
> On Wed, 31 Aug 2016 03:16:26 +0000
> "Evan Foss (evanfoss AT gmail DOT com) [via geda-user AT delorie DOT com]"
> <geda-user AT delorie DOT com> wrote:
>
>> Reading the rest of your email that seems mostly like moving to
>> verilog is just a way of making the workflows graph simpler. Like
>> verilog ams is one container that we could use in place of a few other
>> ones.
>
> The proposal is about a standard interchange format for simulation,
> synthesis, layout, and schematic, hopefully to avoid everything needing
> to explicitly support everything else, usually poorly.
>
> The intent is that you go from whatever to the interchange format, and
> from there to whatever-else.
>
> Eventually, ideally, the tools could support the interchange format
> directly, if they want.
>
> Also, supporting an interchange format means you can freely change your
> tool format and keep compatibility, as long as you provide a path to
> and from the interchange format.

We can always go back and add verilog support later. Right now it is a
chicken and egg thing.

>>
>> I like gnucap but I don't want it to be the only tool that plugs into
>> the field solver stuff we add. Just like I would not want geda to only
>> support gnucap as it's one simulator. I would really like this to
>> continue with netlists as we have them. Xyce is a simulator that
>> supports gEDA like it is a thing they are proud of. Xyce is also nice
>> in that it works on distributed (MPI) environments. I want
>> compatibility and the choice to use Xyce or Gnucap depending on the
>> scale/type of problem.
>
> Have you ever actually used Xyce?  I could not get it to compile on my
> computer.

I have it built and am playing with it now.

> I think the whole distributed thing (MPI) is overrated.  The algorithms
> are more important.  I wouldn't be surprised to find that for large
> circuits gnucap is faster on a scalar machine than Xyce is on a
> parallel machine.  Multiprocessor support is the domain of the compiler
> people.  Then we all get to benefit from it.

This is distributed processing which pretty much requires the
programmer to say where and how the distribution makes sense. I don't
think a compiler would ever understand that since it goes to the
programmers understanding of the problem and the way the data being
processed is optimally handled.

> As to the "only tool" .. I agree.  That's the point of using an
> interchange format based on a published industry standard language
> (Verilog).  It seems everyone else is thinking only tool, then another
> only tool, and yet another only tool, and ...
>
> By supporting a common interchange format, you support everything else
> that supports the interchange format.

Does the gnetlist backend for verilog-ams even support the geometric
information we want to add into it? How about the gnucap-verilog?

> So the gnucap project does not want you to support gnucap explicitly.
> We want you to support the interchange format, and so have chosen to
> support the interchange format directly, and provide tools for
> supporting the interchange format.

I get the appeal but I can live in our current ecology of mime types.

Right now only one person here even seems to have experience with this
kind of thing. We are still only talking about coding a geometry
export the whole rest of it will need some consideration and probably
some utility to be the openems file parser for common problems. Just
imagine how much work goes into that. I would rather focus on that
problem than get distracted with the ultimate interface to it.

Once more eventually people will want the ability to put the pcb into
a 3d cad so that they can simulate their antenna or what ever in a
real world chassis added in the 3D cad. Then export to openems. How
does verilog handle that? What if the antenna is in a feed horn?

We need to figure out how it will be used and then work backwards to
make more realistic utilities to fit that workflow. At that point we
should think about supporting verilog and probably about a half dozen
other formats too.

-- 
Home
http://evanfoss.googlepages.com/
Work
http://forge.abcd.harvard.edu/gf/project/epl_engineering/wiki/

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2

mQENBFYy4RYBCAC183JomLtbdAlcKiaPDoVHq52LDmVmH75aiEc69m7YxDt54/ai
VtYCAobbGVIyn3Hlz3uhF6LnPl/6Lm1VdnCfpwu3KQhCO6ds10ow2C30X4ohCqOd
hCVg5C+ILmQkEffFrFODy3ji+PYTF4pADvHCWsTMv0hf0llwFOJsBCK6cl02IffE
JPqy4PjM1nZ9HpzT84JBaG/4OGvTZ8SQ2yFUl265jagvygPTf88H1xpZHH1r8dB1
stjUHLmPH8AOyDgKxFchgGeDc3p/vJtgDDIXAFfDXG0NSRovLmtaQdGxe47Zf/go
bXiEM7YL2WqQe5zfEA919JxkEwlDKYniOSVzABEBAAG0N0V2YW4gRm9zcyAoVGhp
cyBpcyBteSBwdWJsaWMga2V5LikgPGV2YW5mb3NzQGdtYWlsLmNvbT6JATkEEwEC
ACMFAlYy4RYCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRCIpQTcE8nN
bbBaCACAm8pU5lG1ev2Fsw68Axtcl57SJrYieqX96c3YuYH9JpqMqJRnd9nDKw9X
tQuvuH7tUk0VbOaDqReOYJVI/4c5wb9AaOFp6K2DUcupq6XhgXpvz3HzoPwjAdIj
XuQzdRUx5+innTJrSkGuBYW/CZ2zqEx4xfLlq4rO0hoTUMR8QVp2cCrkw6BT0m86
APIw/ZnjoxM8IEzr7MxfRIg3qpzrZk28rmhx+k78Jyk61UhwcCPGIm/pjUopTwYJ
3YBdRB2cYD2aN7A1JVf5cRmSQYooHBGpH0kYvomGk97PKqypVuJ7OpG9xM58wUcC
qUVt9hKlePLzP8csYjt8onqI7qIIuQENBFYy4RYBCADlH8spG3WkCx62vB5mr5Z0
SCDd/RcyA4A5y5EOj5KurQkrSWpgi9Ho1yKruMJ6blQR2qkc66KqH9pnXDm/ZI1M
K/wdW3ngETxBmXoozzFMT89aEWIVR5/PFodWK1elekE9iJxACuR98Zg2QttTD3x8
A9w8VEyMLOXcDTrPFpHegMKswFBg5iuMulAdXAoGejWTI3n+qKFpabHm2Lfs6wjk
5rjucpTdeFK6UeWF1xAvNxXibuu5BlGwv53930qIXRwO/Gn2Rh5DXWxKU2fEIme/
xgQQmIsDeUoWbfybdjw/x7Q0LW4mINiLDQcGHHRQKFIxbAJCT3USPLGh5xwE9/Er
ABEBAAGJAR8EGAECAAkFAlYy4RYCGwwACgkQiKUE3BPJzW0uYAf9Hf30n8tM3mR2
Zo6ESE0ivgdgjaJtAWrBUx7JzAzPjBnBOlNnu5Y9lVEqetvUPH6e3PvaHYUuaUU8
0HwxuKBW9nUprgV6uIu1DZmlcp+SxpbuCy7RDpNocRLNWWFMaYYzznmTgfnTgD4D
gCq8Mf1mcfrluTkOAo+QNqbMfl1GISClopRqxVuAo59ewgMnFujwgd8w12BwWl24
CzqOs5HqcUslePj+LzcjSNgVCklYwKl+0dsb/fctMOCtHodwqm2CBJ+zydvNmYkD
fxda/J91Z1xrah5ec++FL0L4vs+jCiIWJeupJFKlr1hCMZiiGH7W554loK5l4jv3
EY347EidAw==
=Ta4p
-----END PGP PUBLIC KEY BLOCK-----

- Raw text -