Re: attributes, possible interface

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 <[email protected]> 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