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=date:from:to:subject:message-id:mail-followup-to:references
	:mime-version:content-disposition:in-reply-to:user-agent;
	bh=SvJGSgacjOSKMa0jA/3e+TpM0C966kAiv1lTbDEcPfw=;
	b=HgdE74jzDm8YSfK55DKZ/Y/c6vU/VLFWTCcNyVvUrmOaxfNRoUWKxo9u7/mPH6YGgf
	dSUjCRMRYRkwxswChDqjyxXiGfEjDiUYcCLorS4IjsoFKYFFsk0BWqqErFKesLBnaaT9
	WoM5/pcKrO48RQITzPjZa6EcGugBwsXVo7WMuwhnekWkb+qIyuyBF4lD8IgJiQhoS1ao
	uWDpkUVOCIFW/ojskVpyq8yRHvT41xThAwPtmnQNDdblaDBGHdmJAGcl5yKr8qxXYjbT
	dpc8puE+I19ZtE/W/HqTJNtksNzluMyNmyx7dd827w6B2B4o203RvMIL2si6jd1Cf1C4
	sqmg==
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to
	:references:mime-version:content-disposition:in-reply-to:user-agent;
	bh=SvJGSgacjOSKMa0jA/3e+TpM0C966kAiv1lTbDEcPfw=;
	b=jEaevV7ENN4fDHWgBtj4zE8rq2Jjrb+FVA17lCtNzclm+zcIiXFOy4T2pjD5WPLNHc
	BrMPbjWmWRoR8ctOBBzOYNGWLwy/t5xe82BRp3olikawHKQ4tgBcfZNjvKnyyikzFjTA
	aW6m4rQ3e9IUAP5fO5hwE5pwX0BNqdGVjzkgqth2c/n9YdplVUzMbmX+wS4ZgGLZe2wp
	KaHubZCvjs6+h09MuHnEKOC4ZzJFYRkf9Qj30O5vSNwNQzxvvKBEvFx+bhz7wVTaSXyO
	xvqQKEkIKFXb1ze9TiPyQ1fu2X018o0q2zoP+1Y+hHxxQsepAl+242ewFTpFu3d5mv+h
	USjw==
X-Gm-Message-State:	AE9vXwMErDRq957VYf7wKy1F0zVyQYN+Ba5j4MPZJFWYjkd8HyFr6MAB9MPyUwyVmndYBw==
X-Received:	by 10.25.87.12 with SMTP id l12mr10072295lfb.153.1473197669076;
	Tue, 06 Sep 2016 14:34:29 -0700 (PDT)
Date:	Wed, 7 Sep 2016 00:34:26 +0300
From:	"Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	geda-user <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] Can an attribute be attached to text for later
	inclusion in gnetlist backend?
Message-ID:	<20160906213426.GA10224@localhost.localdomain>
Mail-Followup-To:	geda-user <geda-user AT delorie DOT com>
References:	<CAGde_xMkqgbbfH81MPOLPfTaui0wRvmUctk31r-eE3=fQ+U0pA AT mail DOT gmail DOT com>
	<A9C29BBE-B381-4BD1-BD54-E0E27DF1307C AT noqsi DOT com>
	<20160823053301 DOT 865f671a1b40b5a422e59ce7 AT gmail DOT com>
	<da433c1d-c711-e0d8-f9ff-a6e843bfe266 AT sbcglobal DOT net>
	<AB0B2DAD-9075-4AEC-B33E-A57DA050B079 AT noqsi DOT com>
	<CAGde_xOYrkv-4eWyR4OOTT+XQMPcr4MxmT1xomB9uCneZBCT6A AT mail DOT gmail DOT com>
	<20160824185818 DOT GD14293 AT localhost DOT localdomain>
	<CAGde_xNfx_VmpWTm6EwHac2QaKQCRefs1cKK=s9gE8OOuMiWdA AT mail DOT gmail DOT com>
	<20160831221409 DOT GA2585 AT localhost DOT localdomain>
	<CAGde_xMDpUFy5P05Mg+zmzDtvbshvZAghR13F4UkSxxMqtw7yw AT mail DOT gmail DOT com>
MIME-Version:	1.0
In-Reply-To:	<CAGde_xMDpUFy5P05Mg+zmzDtvbshvZAghR13F4UkSxxMqtw7yw@mail.gmail.com>
User-Agent:	Mutt/1.5.23 (2014-03-12)
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 Thu, Sep 01, 2016 at 11:22:43PM +0200, Svenn Are Bjerkem (svenn DOT bjerkem AT googlemail DOT com) [via geda-user AT delorie DOT com] wrote:
...

> I can discuss, but I am not good in scheme yet.

OK, let's start then.

(If you want to figure out how some gnetlist Scheme code works, I
would be glad to help you as much as I can, I'm interested in it, too.)

> 
> 
> >>
> >> I am also looking into choosing top-level attribute names which will
> >> work the same accross vhdl, verilog and vams backends so that the
> >> schematic can be used with little modification on different types of
> >> simulators.
> >
> > There are too many different simulators. I believe we could
> > concentrate on a limited subset, say, spice, verilog and/or vhdl.
> 
> I noted that the verilog back-end expects the attribute which define
> the name of the module to build a netlist for to be module-name and
> the vhdl back-end expects the attribute to be module_name. I don't
> know what the spice back-end expects.

AFAIUI, spice doesn't expect a top-level module name, though
understands subcircuits. We could name them `modules', though I
don't think it would be helpful. Having been thinking before of
all the ambiguous attribute names we have in geda where each
gnetlist backend has its own vision on their use, now I think
every one of them being non-compatible with others should have a
different backend-specific name. Say, you cannot use the same
toplevel entity/module definition for vhdl, verilog and
spice. OTOH, you could have top-level (floating) attributes in
your schematic for every of them having called them differently,
say, vhdl-module-name, verilog-module-name, spice-prolog etc. The
same would be convenient e.g. for pcb pins/vhdl ports/spice
nodes. Thus we could define, say, resistor.sym, having all such
attributes, and each gnetlist backend would request only those it
wants. For this to work we could use the following naming scheme:
{backend-name}-{attribute-name}=value. For example,
spice-sdb-device and spice-noqsy-device. This could make those
backends work on schematics using such attributes without
conflicts/ambiguities. In order to make a symbol compatible with
another backend, you would need only add some attributes specific
for the backend.

WDYT?

> 
> >
> >>
> >> My main target is to just create top-level block-type schematics. I am
> >> not sure gnetlist could handle a "real" hierarchical design. I know
> >> too little about its capabilities.
> >>
> >
> > If I would know what is "real" hierarchical design... ;-) Yes,
> > gnetlist has many limitations, though it has some means for
> > working with hierarchical schematics.
> 
> I find it hard to describe what makes a design a real hierarchical
> design other than that a symbol can represent a new schematic filled
> with symbols which again represent schematics. Kind of the way scheme
> works recursively into its problem solution. geda users make
> hierarchical spice netlists all the time, so I am not sure what really
> is the snag with gnetlist here, but for my most frequent use-case, a
> schematic will be one level only where each symbol represent a file
> with vhdl code (or verilog).
>

OK, gnetlist already has means for such hierarchies. More work is still
needed to make a more convenient user API. I, for one, would
prefer to use its capabilities inside gschem without using system
calls. I delayed my work on vams looking forward to make gnetlist
internals better for future work.

-- 
  vladimir

- Raw text -