delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/08/31/18:15:39

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=jqng4/jeat4Pkman2GAhZO10nfpXfp7BkmkQatw/nXI=;
b=t032b3IxZk/tXSMIqGl3fo4ndoEudhFxntgmDeq6z13HKi5yrH2naohm5PrBmKeNEP
TUrjDaAFXYdHGJWogpjf8N4vIw9lS5uGncnvQlG6q6VQyYnGcTLAN3q0lbTAlxmdEvwk
5gyAcmX1+JTdfc4tLCUKuFGjpNIn0SdliB59XyVw2WV1seyGs6PJ8i+DrdqxcwtIvih/
0H9l6xY4elpuH2vKR6f/KaOM9jyNDOImD/BE79+Gtk+dRd8AVtb1yXr+A/2gaawJEKbF
3ByOCQIS1glhgMJaVxmfEGT6WUzSq6TF8hcTqr4FHKf1YreuVvZBRs+lfah9YR6h6GBq
hAnQ==
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=jqng4/jeat4Pkman2GAhZO10nfpXfp7BkmkQatw/nXI=;
b=BKIQksH9NmoP7po1lLJ2Y9VczgCIDqNKhYgvO4jBn1tI/M6jeuPgLczcTuA0oMH1RX
CH+7Jt+JDnBEEOrWvCI+BIesNChMqajSJm/wbYSUOsesamOTzmKc11j9Oju3Jl14NTWm
XCs9Ulk1tnjJccMM9zjMpF+gcma2nbBYuQdPwktT4WpLWg0gIk1JxvjCZUnUTPPo+/hj
lmy0ZSR+QpIamUGhh9i9X0U5ka5qIAtw+Lg2rWOPwZtS5I+M+tQTzs2QenLHN/7uRLs3
WQp2Sr/bZ8C3jqCsdLCMvtX89grLykOYgByui19AEKh7QOjKH0yx82FFg9tRKH3e4Im2
N0BQ==
X-Gm-Message-State: AE9vXwNqKehUtCB1+XUQTwI2Rc3plpQeJjwsTkenfkQ0EXzd/0Wc1PBToP8qeHulfGz4TQ==
X-Received: by 10.25.215.220 with SMTP id q89mr167494lfi.30.1472681651935;
Wed, 31 Aug 2016 15:14:11 -0700 (PDT)
Date: Thu, 1 Sep 2016 01:14:09 +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: <20160831221409.GA2585@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>
MIME-Version: 1.0
In-Reply-To: <CAGde_xNfx_VmpWTm6EwHac2QaKQCRefs1cKK=s9gE8OOuMiWdA@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

Svenn,

On Thu, Aug 25, 2016 at 08:11:26AM +0200, Svenn Are Bjerkem (svenn DOT bjerkem AT googlemail DOT com) [via geda-user AT delorie DOT com] wrote:
> On 24 August 2016 at 20:58, Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via
> geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> > Of course, you might your own backend for personal use. However,
> > if such a change is useful for you and harmless for others, why to
> > not have it?
> 
> Hi Vladimir,
> I think the vhdl backend is kind of unfinished. The vams backend
> example in gnetlist directory does not work out of the box.

It is so, to put it mildly. I mostly offline these days, so cannot
discuss it in details, though now I have a little window being
online (and having internet connection again :-)) so I'll try to
express what I'm thinking on this.

The vams backend has been introduced as one-commit unfinished
stuff in 2000 and broken by second commit in 2002 due to
'uref' to 'refdes' name change (at least, entity creation part has
been broken after this change). The vams example code for gschem
has been broken since 2008 (I wonder if anybody used it at all
since 2002). These are my observations after I started to work on
vams half a year ago when one user asked about its state. I have
seen your previous post about vams on this list and was going to
apply my fixes I did so far, but now I see some new issues and am
thinking not all has been done right. Anyway, now, compared to my
previous attempt, I at least almost realize what the backend
should output ;-) The basic-vhdl/ directory contains some
examples. I would appreciate any help on this. As for hierarchy, I
have written a small scheme script for testing it all that runs
gnetlist for all the hierarchy a schematic has. I have still
some questions wrt what to do in some cases, though.

> I have so many thoughts about how gschem/gnetlist can help me organize
> "throwaway" testbenches for my vhdl design, but it is all a side
> project to my daily work.
> I am working on my own version of a vhdl back-end, but I am not very
> far at the moment. Learning.

OK, probably we could work together to make something useful
then. I am going to publish my changes made so far somewhere, so
if you're interested, we could discuss the topic.

> Also thinking on how to use std_logic_vectors (buses) and component
> ports with more than on signal/wire (bus ports). (John Doty, I think,
> once said that this must be handled in the back-end based on some
> software logic in the back-end)
> 
> I appreciate your code suggestion. I think that piece of code would be
> a nice replacement in both vhdl and vams backend.

OK, I hope I'll commit those changes then.

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

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


-- 
  Vladimir

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019