[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: attributes, possible interface
From: |
Felix Salfelder |
Subject: |
Re: attributes, possible interface |
Date: |
Tue, 19 Apr 2022 11:41:51 +0200 |
On Mon, Apr 18, 2022 at 09:26:11PM -0400, al davis wrote:
> On Mon, 18 Apr 2022 22:02:31 +0200
> Felix Salfelder via Gnucap-devel <gnucap-devel@gnu.org> wrote:
> > Looking at the standard, it seems we want attributes in anything inherited
> > from
> > CARD. For this, we need a section similar to the parameter section (but
> > simpler),
>
>
> I had in mind something simpler. Just store the whole thing as a
> string.
Verilog [1] defines such attributes as a list of name/value pairs. If we
stick to this structure, it will be much easier to pass them on.
Made up example: what if (* a=1, b=2 *) resistor R(x, y); looks like
thing
type=resistor
attribute name=a value=1
attribute name=b value=2
port number=1 value=x
port number=2 value=y
end thing
In some (made up) language? A plain string won't make translating
verilog to this (or the other way round) any easier.
> It might look something like
> (* lepton="T 23900 61600 5 10 1 1 0 0 1" *).
> Then, the lang_ plugins need to accommodate it, but only Verilog really
> needs it. The others can just ignore it or treat it as a comment.
Not just verilog. lang_geda will have to parse it, and stash it
somewhere. If I understand correctly, it will also have to print
the value in case the key happens to be "lepton"...?
For this, again we need name/value pairs. The attribute could be
(* lepton="T 23900 61600 5 10 1 1 0 0 1", other_tool="bold, blinking" *),
or equivalently
(* lepton="T 23900 61600 5 10 1 1 0 0 1" *) (* other_tool="bold, blinking" *).
The parsing (of the verilog representation) should happen in
lang_verilog, and not in lang_geda (during printout).
How about one string per attribute? in CKT_BASE,
+public: // attributes
+ virtual void set_attrib(std::string const&){ throw? }
+ virtual int attrib_count()const {untested(); return 0;}
+ virtual std::string const& attrib_by_index(int)const {untested(); return
empty_string;}
or empty string == end of attributes (any simpler?):
+public: // attributes
+ virtual void set_attrib(std::string const&){ /*defer to inherited classes*/
throw(..); }
+ virtual std::string const& get_attrib(int)const {untested(); return
empty_string;}
But there is more to it. Here is an example, a pin instance from a geda symbol.
P 500 600 500 800 1 0 1
{
T 550 650 5 8 0 1 0 0 1
pinnumber=D
T 550 650 5 8 0 1 0 2 1
pinseq=1
T 500 600 9 8 0 1 0 5 1
pinlabel=D
T 500 400 5 8 0 1 0 5 1
pintype=pas
}
In Gnucap, a pin is a COMPONENT, so without attributes it will
approximately look like
GEDA_PIN #(.$xposition(500), .$yposition(600), [..]) D(.pin(D));
in some context.
The "T" lines actually belong to the parameter assignments. A pair of
lines
T 550 650 5 8 0 1 0 0 1
pinnumber=D
represents a subobject of type "T" with label "pinnumber" and parameters
$xposition=550 etc. (There is no provision for subobjects here in
verilog, maybe they could be arranged in Gnucap?). And also it gives
rise to a parameter in D above, maybe like
GEDA_PIN #([..] .pinnumber=D [..]) D(.pin(D));
My idea was to stuff the attribute into the parameter assignment
GEDA_PIN #([..] (* lepton="T [..]" *) .pinnumber=D [..]) D(.pin(D));
But this is not allowed in Verilog, plus, a PARAMETER is not CKT_BASE. So it
does not work. ( NB: In contrast, this is valid, for some reason:
GEDA_PIN #([..] .pinnumber=D [..]) D((* here *).pin(D)); )
And another ugly idea:
(* lepton_T_pinnumber="T 550 650 5 8 0 1 0 0 1" *)
(* lepton_T_pinseq="T 550 650 5 8 0 1 0 2 1" *)
(* [..] *)
GEDA_PIN #([..] .pinnumber(D) .pinseq(1) [..]) D(.pin(D));
thoughts?
thanks
felix
[1] VlogAMS-2.4.0.pdf
- lepton/geda diffs: C (Re: sym to verilog-ams), (continued)
Re: sym to verilog-ams, al davis, 2022/04/04
Re: sym to verilog-ams, al davis, 2022/04/04
- Re: sym to verilog-ams, karl, 2022/04/05
- attributes, possible interface, Felix Salfelder, 2022/04/18
- Re: attributes, possible interface, al davis, 2022/04/18
- Re: attributes, possible interface,
Felix Salfelder <=
- Re: attributes, possible interface, al davis, 2022/04/19
- Re: attributes, possible interface, Felix Salfelder, 2022/04/20
- Re: attributes, possible interface, correction, Felix Salfelder, 2022/04/20