X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Wed, 31 Aug 2016 13:00:45 -0400
From: al davis <ad252 AT freeelectron DOT net>
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] Microwave PCB layout simulation or How to eat all
 your processing power in 3 easy steps
Message-ID: <20160831130045.27d23a85@floyd.freeelectron.net>
In-Reply-To: <CAM2RGhSb3-KdN3rMo5vxjkbTO+-vU_Tgj+hOcoHxyz4HGwnzbA@mail.gmail.com>
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>
X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
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

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.


> 
> 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 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.

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.

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.