Re: geda/lepton schematics

[karl]

> Also posting to the devel list.  This thread really should be there,
> because it is developer related.

Ok, moving to gnucap-devel.

Regards,
/Karl Hammar

Re: geda/lepton schematics

[al davis]

Also posting to the devel list.  This thread really should be there,
because it is developer related.


On Thu, 31 Mar 2022 16:47:33 +0200 (CEST)
k...@aspodata.se wrote:
> > Not sure what you mean. What is a top module?  
> 
> https://www.accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf
> p.129 "6.1 Overview"
>  To describe a hierarchy of modules, the user provides textual definitions
>  of various modules. Each module definition stands alone; the definitions
>  are not nested. Statements within the module definitions create instances
>  of other modules, thus describing the hierarchy.
> 
> p.131 "6.2.1 Top-level modules and $root"
>  Top-level modules are modules that are included in the source text, but do
>  not appear in any module instantiation statement, as described in 6.2.2.

There's also, from IEEE Std 1364-2001, p. 165
===
12. Hierarchical structures

The Verilog HDL supports a hierarchical hardware description structure
by allowing modules to be embedded within other modules. Higher-level
modules create instances of lower-level modules and communicate with
them through input, output, and bidirectional ports. These module
input/output ports can be scalar or vector. 

As an example of a module hierarchy, consider a system consisting of
printed circuit boards (PCBs). The system would be represented as the
top-level module and would create instances of modules that represent
the boards. The board modules would, in turn, create instances of
modules that represent ICs, and the ICs could, in turn, create
instances of modules such as flip-flops, mux s, and alu s. 

To describe a hierarchy of modules, the user provides textual
definitions of the various modules. Each module definition stands
alone; the definitions are not nested. Statements within the module
definitions create instances of other modules, thus describing the
hierarchy.
==


A top-level model just sits there.  It must be instantiated, but that
is not your job.

A generated file from a schematic is not expected to be all you need
for simulation.  It needs to be instantiated, and instruments need to
be added.

Gnucap has an extension to Verilog that lets you do this.  Other
simulators are all different in this regard.  It is common to do the
top level circuit in Spice mode.

The name of a module corresponding to a schematic strictly doesn't
matter, but you should give it a meaningful name, possibly user
specified.  If you don't have anything else and must pick a name
automatically, the name of the file, with extensions stripped, would be
a good choice.

If the schematic is hierarchical, it may make sense to put them all on
one file, each page as its own "module".  If you want them as separate
files, that's ok too.  It's your choice.

Re: geda/lepton schematics

[Felix Salfelder]

On Thu, Mar 31, 2022 at 04:47:33PM +0200, k...@aspodata.se wrote:
> There is no mention of the name main as a module name in the above pdf.
> I'd use the sch file name without the .sch/.sym suffix as module name.

Hey Karl.

I rechecked, and you are right. The standard name for "main" was just
wishful thinking. I can't think of a better or more useful name though.

Thanks for briging it all up.

Cheers
felix

Re: geda/lepton schematics

[karl]

Hi Felix, I think we are in agreement but don't understand each other.

Regards,
/Karl Hammar

Re: geda/lepton schematics

[Felix Salfelder]

On Thu, Mar 31, 2022 at 04:47:33PM +0200, k...@aspodata.se wrote:
> From what I understand after reading the above pdf, is that you can 
> flatten or not flatten. For a .sch to verilog-ams converter, I'd prefer
> to keep the structure as it is in the .sch files, that would make it
> easier to do backannotations.

Hi Karl.

There might have been a misunderstanding. You write ".sch to verilog-ams
converter", but then "the .sch files" (plural).

Storing (NB: not converting) a gEDA schematic in verilog format does not
require multiple .sch files. Do one at a time. The key is the explicit
connectivity. Anything else follows, and will be more straightforward.

Eventually, you could paste a bunch of modules into a single file, and
rename them, if needed.

> I'd use the sch file name without the .sch/.sym suffix as module name.

This violates the "single point of truth" principle. Renaming a file
will make the data inconsistent (but shouldn't). Renaming a .sch file
has no such side-effect.

cheers
felix

Re: geda/lepton schematics

[karl]

Felix:
> On Wed, Mar 30, 2022 at 10:12:10PM +0200, k...@aspodata.se wrote:
> > Seems "everything" is a module, and you can just call the top module
> > main if you'd like.
> 
> Not sure what you mean. What is a top module?

https://www.accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf
p.129 "6.1 Overview"
 To describe a hierarchy of modules, the user provides textual definitions
 of various modules. Each module definition stands alone; the definitions
 are not nested. Statements within the module definitions create instances
 of other modules, thus describing the hierarchy.

p.131 "6.2.1 Top-level modules and $root"
 Top-level modules are modules that are included in the source text, but do
 not appear in any module instantiation statement, as described in 6.2.2.

So a top level module is a module not referenced by other modules.

> There is only (exactly) one circuit in a gEDA schematic (didn't we agree
> to stick to this?).

Don't remember that, but in a schematic structure, you can choose to
focus on a sub-hier., so there can possible be multiple cirucuits, 
especially if the top sheet is just a collection not connected 
subsheets. You can do that to make it easier to browse through some
possible unrelated projects.
 Also, a top sheet can ref. submodules connected via cables, and when
simulating you might want to simulate them seperately.

But in the end, source symbols in a sch file are not required to be 
interconnected, so there no such thing as one circuite in a geda 
schematic, unless the user imposes such a rule.

> The standard suggests to call it "main", which is as
> close as you get to "objects at top-level". Now you may call it "fred",
> but that won't lead much further.

There is no mention of the name main as a module name in the above pdf.
I'd use the sch file name without the .sch/.sym suffix as module name.

...
> > > >From there, you can think about flattening. Perhaps gnucap-geda does it
> > > "the wrong way", but it will adapt.
> > 
> > >From what I read about verilog-ams, you don't need to flatten the nets,
> > it follows from the structure.
> 
> Not sure what you mean. You can flatten the hierarchy, and there may be
> good reasons you would want that. How does this relate to Verilog-ams?
> 
> It all depends on what you'd like to do. Please expand on that end.

>From what I understand after reading the above pdf, is that you can 
flatten or not flatten. For a .sch to verilog-ams converter, I'd prefer
to keep the structure as it is in the .sch files, that would make it
easier to do backannotations.

Regards,
/Karl Hammar

Re: geda/lepton schematics

[Felix Salfelder]

On Wed, Mar 30, 2022 at 10:12:10PM +0200, k...@aspodata.se wrote:
> Seems "everything" is a module, and you can just call the top module
> main if you'd like.

Not sure what you mean. What is a top module?

There is only (exactly) one circuit in a gEDA schematic (didn't we agree
to stick to this?). The standard suggests to call it "main", which is as
close as you get to "objects at top-level". Now you may call it "fred",
but that won't lead much further.

Note how a "main" module provides a standard way to explicitly specify
port names, port order and parameters -- and how useful this will be
when interpreting hierarchical schematics with a different tool.

> > >From there, you can think about flattening. Perhaps gnucap-geda does it
> > "the wrong way", but it will adapt.
> 
> >From what I read about verilog-ams, you don't need to flatten the nets,
> it follows from the structure.

Not sure what you mean. You can flatten the hierarchy, and there may be
good reasons you would want that. How does this relate to Verilog-ams?

It all depends on what you'd like to do. Please expand on that end.

cheers
felix

Re: geda/lepton schematics

[karl]

Felix:
> On Mon, Mar 28, 2022 at 12:05:58PM +0200, k...@aspodata.se wrote:
> >  every sym file is a module
> >  every sch file is a module
> 
> gEDA uses one file for one schematic, and one file for one symbol.
> Perhaps it makes sense to stick with it.

Yes, I thought so.

> Verilog does not allow top level components, but the standard has a
> notion of "main". It looks C inspired, maybe it is.
>
> A schematic file could be stored in a verilog file that contains a
> single "main" module, and the main module contains the components (port
> values represent connectivity) and maybe text or graphics.

Seems "everything" is a module, and you can just call the top module
main if you'd like.

...
> >From there, you can think about flattening. Perhaps gnucap-geda does it
> "the wrong way", but it will adapt.

>From what I read about verilog-ams, you don't need to flatten the nets,
it follows from the structure.

Regards,
/Karl Hammar

Re: geda/lepton schematics

[Felix Salfelder]

On Mon, Mar 28, 2022 at 12:05:58PM +0200, k...@aspodata.se wrote:
>  every sym file is a module
>  every sch file is a module

gEDA uses one file for one schematic, and one file for one symbol.
Perhaps it makes sense to stick with it.

Verilog does not allow top level components, but the standard has a
notion of "main". It looks C inspired, maybe it is.

A schematic file could be stored in a verilog file that contains a
single "main" module, and the main module contains the components (port
values represent connectivity) and maybe text or graphics.

Similar approach might work for symbols but you no longer need them to
see the circuit.

>  you only need to find out the implicit nets within the sch file
>   not for the whole system

Not necessarily, if you just want to store the schematic, which should
be the first step.

>From there, you can think about flattening. Perhaps gnucap-geda does it
"the wrong way", but it will adapt.

cheers
felix

Re: geda/lepton schematics

[karl]

Felix:
...
> A subsheet is essentially a subcircuit macro. It exists in spice
> (.subckt) and in Verilog ("module" with sub-components), and in the
> others as well.
>
> Such a macro has ports, internal nets, parameters and a list of
> components + the connectivity (!). Much the same as a schematic
> subsheet, just without the positions.
...

Soo,
 every sym file is a module
 every sch file is a module
 you only need to find out the implicit nets within the sch file
  not for the whole system

and you could basically make, as a cache, verilog files of every
sch/sym file you have, and later only update the subsheet references.

Hälsningar,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sverige

Re: geda/lepton schematics

[Felix Salfelder]

On Sun, Mar 27, 2022 at 12:53:46PM +0200, k...@aspodata.se wrote:
> Felix:
> ...
> > Lepton people should store connectivity in their schematic files. Then,
> > their schematic files would be much closer to structural Verilog (to an
> > extent that they could just consider to use Verilog instead).
> ...
> 
> I don't think that that is possible in a design with subsheets (why is 
> hierarchical so hard to spell, I need a better name for it).

A subsheet is essentially a subcircuit macro. It exists in spice
(.subckt) and in Verilog ("module" with sub-components), and in the
others as well.

Such a macro has ports, internal nets, parameters and a list of
components + the connectivity (!). Much the same as a schematic
subsheet, just without the positions.

Think of it in this way or the other.

This way: The Verilog standard defines variables for positions
($xposition and $yposition). Set the device positions in a Verilog macro
module, and obtain a schematic.

The other way: take a gEDA schematic, make connections explicit, and
find a way to store it (try Verilog?).

> If you only have nets and symbols, the full connectivity is contained
> in just one file and could just as well be listed there.

You are suggesting to flatten the net. Why do you need that? Once you
have lost the hierarchy, there is no way to recover it.

> But if you have a subsheet, say a dc-dc converter with a source symbol
> that says
>  pin  label
>  1Vin
>  2GND
>  3Vout
> then that could refer to anything from a resistor+zener, 7805 to some

There are circuits with subsheets in some gnucap-geda/{examples,tests}/*
(I am sure they lack documentation and instructions.)

cheers
felix

Re: geda/lepton schematics

[karl]

Felix:
...
> Lepton people should store connectivity in their schematic files. Then,
> their schematic files would be much closer to structural Verilog (to an
> extent that they could just consider to use Verilog instead).
...

I don't think that that is possible in a design with subsheets (why is 
hierarchical so hard to spell, I need a better name for it).

If you only have nets and symbols, the full connectivity is contained
in just one file and could just as well be listed there.

But if you have a subsheet, say a dc-dc converter with a source symbol
that says
 pin  label
 1Vin
 2GND
 3Vout
then that could refer to anything from a resistor+zener, 7805 to some
complex nonisolated switched power supply. So you can only get the 
full connectivity by scanning the full stack, since the user might
deside to change to another subsheet.

That is the beuty and complexity of subsheets.
The outside world only needs to know that this is a dc/dc conv., and
I can swap the implementation depending on spec.

Regards,
/Karl Hammar

Re: geda/lepton schematics

[karl]

Felix:
> On Sat, Mar 26, 2022 at 09:33:50PM +0100, k...@aspodata.se wrote:
> >  Maybe it is sufficient to parse the .sch files
> 
> No. The connections are implicit, so the Symbols are necessary. This is
> the major problem with .sch files.

 I did "just the parsing" thing in (perl) "sub parse_text($@)" in
http://aspodata.se/git/openhw/bin/GedaSch.pm

> > but does it also
> > hanlde reading the config files that tells where the symbols are ?
> >  I have lines like
> > (component-library-search "/Net/cvs/cvs.gedasymbols.org/www/user" "cvs/")
> > (define home (getenv "HOME"))
> > (source-library-search (build-path home "git/openhw/share/gschem"))
> > in gafrc, does your code catch that also ?
> 
> This is exactly what gnucap-geda uses libgeda for. I think it could be
> easily replaced, but will also have to implement a substitute for the
> gafrc settings.
...

 I did an ad hoc gafrc reader in "sub read_gafrc(@)" in:
http://aspodata.se/git/openhw/bin/examine_sch.pl

Regards,
/Karl Hammar

Re: geda/lepton schematics

[al davis]

On Fri, 25 Mar 2022 22:43:14 +0100 (CET)
k...@aspodata.se wrote:
>  Would something like this suffice ?

Actually, no, but it's a start.
> 
> $ lepton-netlist -g verilog arm_can_test.sch
> $ head -30 output.net 
> /* structural Verilog generated by lepton-netlist */
> /* WARNING: This is a generated file, edits   */
> /*  made here will be lost next time  */
> /*  you run netlister!*/
> 
> module \not found  (
> 
>   );
> 
> /* Port directions begin here */

You don't need to specify port directions, but if you do they must be
correct and supported by the target.  The schematic probably doesn't
have this info, so it is best to just leave it out, and not try to
guess.

> 
> 
> /* Wires from the design */
> wire \3/EN  ;

The use of the word "wire" here is usually incorrect.

wire is a net type.  There are other net types too.  The most common in
analog would be "electrical".  In general, it is not allowed to mix net
types.  Some net types are compatible, but usually they are not.  The
standards document talks about this in great detail.  I can say here
that "wire" and "electrical" are incompatible.

Like the port directions, you don't need to specify a net type, but if
you do they must be correct and supported by the target.

What net types are supported by gnucap are totally determined by
plugins.

Remember that here we are not making any attempt to support the full
language.  Only the structural subset is supported here.  The
structural subset doesn't need net types, so at top level gnucap does
not even support the syntax.  At the model compiler, which deals with
behavioral modeling, the net types are supported and enforced.

It's only with behavioral modeling that net types are used, but even if
not used they would be checked.  In this context, behavioral modeling
includes all of the built-in devices regardless of what language they
were coded in.

On Fri, 25 Mar 2022 21:14:30 +0100 (CET)
k...@aspodata.se wrote:
> Wouldn't it be best if geda/lepton supported gnucap instead of the 
> other way around ?  

Ideally, yes, and thank you for trying to do that.

What is really best is to support standards that have a published
document and are used by many.

Also, remember that file conversion goes both ways.  Ideally, you would
be able to do a lossless round trip .. from format A to format B and
back to format A and not lose any info.

So, the other what is best when there is no standard is usually that
tools do their own import, because they are the users of it.

If you are coding an import function, the test is whether it works at
the target.  If you are coding an export function, how do you test it?
One way is to also code an import function, so you can test the round
trip, but you need the target too.

In Gnucap, the file format is determined by a plugin.  It is not in the
core.  A plugin is required to read or save any file at all.  As
distributed, "language plugins" for Spice, Spectre, and Verilog formats
are supplied as standard, with Verilog considered to be preferred.
Actually, they are all really subsets of what they should be.

Re: geda/lepton schematics

[Felix Salfelder]

On Sat, Mar 26, 2022 at 09:33:50PM +0100, k...@aspodata.se wrote:
>  Maybe it is sufficient to parse the .sch files

No. The connections are implicit, so the Symbols are necessary. This is
the major problem with .sch files.

> but does it also
> hanlde reading the config files that tells where the symbols are ?
>  I have lines like
> (component-library-search "/Net/cvs/cvs.gedasymbols.org/www/user" "cvs/")
> (define home (getenv "HOME"))
> (source-library-search (build-path home "git/openhw/share/gschem"))
> in gafrc, does your code catch that also ?

This is exactly what gnucap-geda uses libgeda for. I think it could be
easily replaced, but will also have to implement a substitute for the
gafrc settings.

> Feel free to ask for specific help with this.

I could use help with include/*.v, tests, examples and bugfixes. Pick
your favourite (hierarchical?) schematic, fill in the components and set
up a smoke test.

>  He talks about verilog-ams, this seems to be its reference:
> https://www.accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf
> 
> A first step could be if I work with the lepton people to shape up 
> their (actually geda) verilog exporter so it emits files that makes
> sense.

There is verilog-AMS for component models and structural verilog for
netlists, schematics etc. Probably, there is a common grammar, but the
challanges in adopting them are distinct and unrelated to parsing.

Lepton people should store connectivity in their schematic files. Then,
their schematic files would be much closer to structural Verilog (to an
extent that they could just consider to use Verilog instead).

> > Regardless. In order to make sense of the Symbols in Gnucap,
> > electrically, we need a library with component models. I have started
> > one in gnucap-geda/include/*.v. This is meant to resolve the default
> > values for the component text attribute in the gEDA symbol library, by
> > section. Such a library will give us something to play and explore,
> > until we will be able to do Verilog/AMS.
> 
> Yes, I can see that, but I'm not experienced in model design to help
> with that for the moment.

Even most elementary components are missing. There are more in
Gnucsator, but names, port order and such are Qucs style and likely
quite different.

> Yes, there is a lot of talk about that, but not much happens.
> There are some converters between file formats by people in the geda 
> and pcb-rnd communities and part of the problem is that there is more
> or less always some data loss.

Verilog allows to carry along as much data (name value pairs) as you'd
like (much like geda schematics?). Any tool can pick the data that is
relevant for a task.

>  Igor2 has done some tries with
> http://www.repo.hu/projects/edakrill/
> http://repo.hu/projects/tedax/

Thanks, need to revisit his work.

cheers
felix

Re: geda/lepton schematics

[karl]

Felix:
> On Sat, Mar 26, 2022 at 10:47:31AM +0100, k...@aspodata.se wrote:
> > You wrote earlier that:
> > > Connections in gEDA schematics are implicit, and port positions are
> > > needed to infer them. For this, the symbol database is required. The gEDA
> > > library has been used to look up the symbols.
> > 
> > By running the lepton/geda netlister you get the connections.
> > You don't need to have your own code for it.
> 
> Gnucap is not a netlister. The "code" is just a parser, and the
> intention is not to flatten the netlist, but to read in the schematic as
> a whole. This is not only required for lepton/geda, but wherever
> circuits are represented as a schematic.

I'm not sure libgeda is complete for that purpose. At the time when I
was involved in libgeda, the intentions of the then devs was to replace
it with guile code.
 Maybe it is sufficient to parse the .sch files, but does it also
hanlde reading the config files that tells where the symbols are ?
 I have lines like
(component-library-search "/Net/cvs/cvs.gedasymbols.org/www/user" "cvs/")
(define home (getenv "HOME"))
(source-library-search (build-path home "git/openhw/share/gschem"))
in gafrc, does your code catch that also ?

Feel free to ask for specific help with this.

> > lepton/geda has some code to produce verilog.
> > If verilog is the if. you want, why spend time on the geda plugin when
> > it might be more fruitful to get help from e.g. the lepton people to
> > shape up their verilog handling ?
> 
> Al has proposed a data interchange system quite some time ago [1].
> Nobody has done this, nor did the lepton people.
> [1] https://archive.fosdem.org/2016/schedule/event/eda_data_interchange/

 He talks about verilog-ams, this seems to be its reference:
https://www.accellera.org/images/downloads/standards/v-ams/VAMS-LRM-2-4.pdf

A first step could be if I work with the lepton people to shape up 
their (actually geda) verilog exporter so it emits files that makes
sense.

> Regardless. In order to make sense of the Symbols in Gnucap,
> electrically, we need a library with component models. I have started
> one in gnucap-geda/include/*.v. This is meant to resolve the default
> values for the component text attribute in the gEDA symbol library, by
> section. Such a library will give us something to play and explore,
> until we will be able to do Verilog/AMS.

Yes, I can see that, but I'm not experienced in model design to help
with that for the moment.

> > The drawback with that would be back annotation if I understand you:
> 
> The real problem is data interchange between eda tools, particularly in
> FOSS tools. Netlists, schematics, pcbs, floorplans...

Yes, there is a lot of talk about that, but not much happens.
There are some converters between file formats by people in the geda 
and pcb-rnd communities and part of the problem is that there is more
or less always some data loss.

 Igor2 has done some tries with
http://www.repo.hu/projects/edakrill/
http://repo.hu/projects/tedax/

Regards,
/Karl Hammar

Re: geda/lepton schematics

[Felix Salfelder]

On Sat, Mar 26, 2022 at 11:08:27AM +0100, k...@aspodata.se wrote:
> $ git diff configure.ac 
> diff --git a/configure.ac b/configure.ac
> [..]

Thanks!

> And I'm able to do this:
> 
>  cd tests
>  $ make inv_tr.out
> [..]

I have tidied up the mess a bit. The target is now inv_tr.gc.out.

cheers
felix

Re: geda/lepton schematics

[Felix Salfelder]

On Sat, Mar 26, 2022 at 10:47:31AM +0100, k...@aspodata.se wrote:
> You wrote earlier that:
> > Connections in gEDA schematics are implicit, and port positions are
> > needed to infer them. For this, the symbol database is required. The gEDA
> > library has been used to look up the symbols.
> 
> By running the lepton/geda netlister you get the connections.
> You don't need to have your own code for it.

Gnucap is not a netlister. The "code" is just a parser, and the
intention is not to flatten the netlist, but to read in the schematic as
a whole. This is not only required for lepton/geda, but wherever
circuits are represented as a schematic.

> lepton/geda has some code to produce verilog.
> If verilog is the if. you want, why spend time on the geda plugin when
> it might be more fruitful to get help from e.g. the lepton people to
> shape up their verilog handling ?

Al has proposed a data interchange system quite some time ago [1].
Nobody has done this, nor did the lepton people. I wasn't standing in
their way. Note that gnucap-geda dates back to 2012, and is pushing in
this direction since.

Regardless. In order to make sense of the Symbols in Gnucap,
electrically, we need a library with component models. I have started
one in gnucap-geda/include/*.v. This is meant to resolve the default
values for the component text attribute in the gEDA symbol library, by
section. Such a library will give us something to play and explore,
until we will be able to do Verilog/AMS.

> The drawback with that would be back annotation if I understand you:

The real problem is data interchange between eda tools, particularly in
FOSS tools. Netlists, schematics, pcbs, floorplans...

cheers
felix

[1] https://archive.fosdem.org/2016/schedule/event/eda_data_interchange/

Re: geda/lepton schematics

[karl]

Felix:
> [1] https://codeberg.org/gnucap

Ok, the += seems troublesom (not /bin/sh syntax) here 
(do you have sh -> bash symlink?), so I did:


$ git diff configure.ac 
diff --git a/configure.ac b/configure.ac
index 0f1c268..b4f36e1 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,9 +32,9 @@ AS_IF([ test x$program_suffix = xNONE 
],,[_program_suffix=$program_suffix])
 # Checks for libraries.
 
 # Checks for header files.
-GC_CPPFLAGS+=" $(gnucap-conf$_program_suffix --cppflags)"
+GC_CPPFLAGS="$GC_CPPFLAGS $(gnucap-conf$_program_suffix --cppflags)"
 OLD_CPPFLAGS="$CPPFLAGS"
-CPPFLAGS+=" $GC_CPPFLAGS"
+CPPFLAGS="$CPPFLAGS $GC_CPPFLAGS"
 AC_CHECK_HEADER([l_dispatcher.h],,[AC_MSG_ERROR([cannot find gnucap headers])])
 CPPFLAGS="$OLD_CPPFLAGS"
 AC_SUBST([GC_CPPFLAGS])
@@ -62,7 +62,7 @@ PKG_CHECK_MODULES(GEDA, [libgeda >= 20100214],
[geda], [s_path_sys_data],
[
 geda=yes
-LIBS+=-lgeda
+LIBS="$LIBS -lgeda"
],
[ AC_MSG_ERROR([gEDA package found but header 
broken]) ],
[-lgeda])
@@ -81,12 +81,12 @@ AC_CHECK_HEADERS([boost/assign.hpp],
  ])
 
 old_CPPFLAGS=${CPPFLAGS}
-CPPFLAGS+=" ${GEDA_CFLAGS}"
+CPPFLAGS="$CPPFLAGS ${GEDA_CFLAGS}"
 AC_CHECK_HEADERS([libgeda/libgeda.h],
  [ AC_DEFINE([HAVE_GEDA], [1], [geda present]) ],
  AC_MSG_ERROR([libgeda.h not 
available]), )
 CPPFLAGS=${old_CPPFLAGS}
-CXXFLAGS+=" -Wall -pedantic"
+CXXFLAGS="$CXXFLAGS -Wall -pedantic"
 
 gnucap=$(which gnucap)
 AC_SUBST([gnucap])


 git clone https://codeberg.org/gnucap/gnucap-geda.git
 cd gnucap-geda/
patch configure.ac
 ./bootstrap 
 PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/guile_1.8.8/lib/pkgconfig/"  
./configure
 make

And I'm able to do this:

 cd tests
 $ make inv_tr.out
 make: Circular /Net/git/gnucap-geda/tests/CMOS_Inverter.sch <- 
/Net/git/gnucap-geda/tests/CMOS_Inverter.sch dependency dropped.
 echo gctest...
 gctest...
 export GUILE_WARN_DEPRECATED=no LD_LIBRARY_PATH=../src/.libs; gnucap -a 
../src/.libs/lang_geda.so  < inv_tr.gc | \
sed -e '/^default plugins/d'  -e '/^lang_geda/d' | \
sed -e '/^parameter /d' -e '1,/^stashing as/d' -e '/^\/\/v /d'| \
grep -v ^@ > inv_tr.out
 ** Message: 11:03:28.522: Loaded RC file [/usr/share/gEDA/system-gafrc]

 ** Message: 11:03:28.837: Loaded RC file [/home/karl/.gEDA/gafrc]

 ** Message: 11:03:28.838: Library name [.] already in use.  Using [.<1>].

 ** Message: 11:03:28.838: Loaded RC file [/Net/git/gnucap-geda/tests/gafrc]

 @@#
 @@@
 unreachable:lang_geda.cc:861:parse_comment
 ** Message: 11:03:28.879: More than one component found with name [gnd-1.sym]

 ** Message: 11:03:28.898: More than one component found with name [gnd-1.sym]

 @@#
 @@@
 incomplete:symbol.h:84:label
 @@#
 @@@
 incomplete:symbol.h:84:label
 @@#
 @@@
 incomplete:symbol.h:84:label
 @@#
 @@@
 incomplete:symbol.h:84:label
 @@#
 @@@
 incomplete:d_gedasckt.cc:251:default_connect
 @@#
 @@@
 incomplete:d_gedasckt.cc:268:default_connect
 @@#
 @@@
 incomplete:d_gedasckt.cc:251:default_connect
 @@#
 @@@
 incomplete:d_gedasckt.cc:268:default_connect

Regards,
/Karl Hammar

Re: geda/lepton schematics

[karl]

Felix:
> On Fri, Mar 25, 2022 at 10:43:14PM +0100, k...@aspodata.se wrote:
...
> >  Would something like this suffice ?
> > 
> > $ lepton-netlist -g verilog arm_can_test.sch
> > [..]
> 
> What do you intend to do with it?

You wrote earlier that:
> Connections in gEDA schematics are implicit, and port positions are
> needed to infer them. For this, the symbol database is required. The gEDA
> library has been used to look up the symbols.

By running the lepton/geda netlister you get the connections.
You don't need to have your own code for it.

and:
> I think it is desirable to eventually have Qucs <=> Verilog <=> gGEDA
> roundtrips for schematics. (It doesn't have to be Verilog, but some
> suitable standardised format for circuit models.)

lepton/geda has some code to produce verilog.
If verilog is the if. you want, why spend time on the geda plugin when
it might be more fruitful to get help from e.g. the lepton people to
shape up their verilog handling ?

The drawback with that would be back annotation if I understand you:
> >  When you do (the old way) lepton-sch2pcb or gsch2pcb, you get a
> >  .net file.
> This is lossy. If you read it into Gnucap, you won't get your schematic
> back (nor a Qucs, Verilog or similar schematic). If you do something
> more elaborate (say parasitics extraction), how will you annotate the
> schematic with your findings?

There are some work done about back-annotation:
 https://archive.org/details/pcb-rnd-back-annotation

Could something like that be sufficient ?

Regards,
/Karl Hammar

Re: geda/lepton schematics

[al davis]

On Fri, 25 Mar 2022 21:14:30 +0100 (CET)
k...@aspodata.se wrote:
> That repo is a little strange, I get this:
>.
> It seems it consists of a few non-connected branches.


That repo is for any plugins except models, trying to avoid setting up
a new repo for every new set of plugins.  

In all of the gnucap repos, the master branch is considered stable.  A
master branch with a tag is a release.  All work is done in feature
branches.  When ready, you would post a merge request on gnucap-devel,
which is a call to all developers to test it, beat on it, fix it, etc.
Then when it is found to be good it is merged into develop.  It sits
there for a while, then when the develop branch appears to be stable
enough for release, it is pushed to master.  A lot of the feature
branches are experimental and are never finished, so they stay there
under their own name.

Such is the geda branch.  It was started elsewhere as a Google
Summer-of-code project (actually in the main gnucap repo, because we
didn't yet have the sub repos) and brought in, in an unfinished state.
Felix did some work on it.  With all the other stuff going on, it was
never really finished to the point where it could be merged.

There's no master or develop in gnucap-plugins.git because none of them
have reached the level needed for release, or the authors never asked.

This illustrates an important feature of the plugin system.  Without
plugins, if the code needed to be merged into a main repo the way most
other projects work, we would be faced with a hard decision of whether
to merge code that is known to not be ready which would degrade the
quality of the main program causing a major maintenance headache, or not
merge the code rendering it essentially unavailable and eventually
lost, even though it really might be useful to some.

In this repo, none of them have made it to that level, but they are all
available anyway, to anyone who can deal with the unfinished work.

The gnucap-models repo is more like it is supposed to be.

https://git.savannah.gnu.org/cgit/gnucap/gnucap-models.git

Re: geda/lepton schematics

[Felix Salfelder]

On Fri, Mar 25, 2022 at 11:12:25PM +0100, Felix Salfelder wrote:
> > You can try this package (a lot of dists dep. on debian):
> >  https://packages.debian.org/buster/libgeda-dev
> > and its dependancies.
> 
> Will give it a go. Thanks. (Issue seems to be guile-2.0-dev.)

I managed to install headers & libgeda.so from the ancient geda-gaf
source package. It is sufficient to make install -C libgeda. I just had
to bypass the guile version check (guile seems irrelevant for this).

Anyway, "make check" passes all tests, except spice.gc (known for a
while, known cause. Never managed to build it since.)

The hack/workaround we need might be... include libgeda with gnucap-geda
and link statically. Replace it as time permits.

cheers
felix

Re: geda/lepton schematics

[Felix Salfelder]

On Fri, Mar 25, 2022 at 10:43:14PM +0100, k...@aspodata.se wrote:
> > Which netlist?
> 
>  When you do (the old way) lepton-sch2pcb or gsch2pcb, you get a
>  .net file.

This is lossy. If you read it into Gnucap, you won't get your schematic
back (nor a Qucs, Verilog or similar schematic). If you do something
more elaborate (say parasitics extraction), how will you annotate the
schematic with your findings?

> With the patch I send, and using:
> PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/guile_1.8.8/lib/pkgconfig/"  
> ./configure
> I could make configure and make to work.

Highly appreciated.

> You can try this package (a lot of dists dep. on debian):
>  https://packages.debian.org/buster/libgeda-dev
> and its dependancies.

Will give it a go. Thanks. (Issue seems to be guile-2.0-dev.)

>  Would something like this suffice ?
> 
> $ lepton-netlist -g verilog arm_can_test.sch
> [..]

What do you intend to do with it?

cheers
felix

Re: geda/lepton schematics

[karl]

Felix:
> On Fri, Mar 25, 2022 at 09:14:30PM +0100, k...@aspodata.se wrote:
...
> > > Connections in gEDA schematics are implicit, and port positions are
> > > needed to infer them. For this, the symbol database is required. The gEDA
> > > library has been used to look up the symbols.
> > 
> > Don't you get the connections from the netlist ?
> 
> Which netlist?

 When you do (the old way) lepton-sch2pcb or gsch2pcb, you get a
 .net file.

 If you do lepton-netlist/gnetlist --list-backends there a few to 
 choose from, among others:
spice
spice-sdb
switcap
systemc
tango
vams
verilog
vhdl

> > > When I try to configure gnucap-geda, I get
> > > [..]
> > > checking for libgeda >= 20100214... no
> > > configure: error: gEDA package not found
> > 
> >  ./bootstrap works fine here, but
> >  ./configure gives:
> > checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > ./configure: 16616: GC_CPPFLAGS+= -I/usr/local/include/gnucap: not found
> 
> I have a line (17649) in my configure that seems related. but it reads
> GC_CPPFLAGS+=" $(gnucap-conf$_program_suffix --cppflags)",
> note the quotation marks. It is the same as line 35 in configure.ac.

The "'s was there in the configure script, it is just the printout
that are missing them.

> Not sure what is going on. My configure starts with
> # Generated by GNU Autoconf 2.71 for gnucap-geda 0.0.3-rc5.
> And I am on commit 312cd3c3c26.
...

With the patch I send, and using:
PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/guile_1.8.8/lib/pkgconfig/"  
./configure
I could make configure and make to work.

For various reasons I needed multiple versions of guile installed.

> > I think something is not good enough with guile-2.0, and that the
> > libgeda package should be updated for a newer guile version.
> > Bug your distro about that.
> 
> I can try. Do you have a working libgeda-dev? which distro?

You can try this package (a lot of dists dep. on debian):
 https://packages.debian.org/buster/libgeda-dev
and its dependancies.

I'm on gentoo.

> > Wouldn't it be best if geda/lepton supported gnucap instead of the 
> > other way around ?
> 
> Not sure what you mean. One idea behind Gnucap is to read/write netlists
> & schematics (and support models) from other projects.
> 
> It might be better if gEDA supported Verilog (and explicit connections)
> to store schematics. Gnucap already reads structural Verilog for quite a
> while.

 Would something like this suffice ?

$ lepton-netlist -g verilog arm_can_test.sch
$ head -30 output.net 
/* structural Verilog generated by lepton-netlist */
/* WARNING: This is a generated file, edits   */
/*  made here will be lost next time  */
/*  you run netlister!*/

module \not found  (

  );

/* Port directions begin here */


/* Wires from the design */
wire \3/EN  ;
wire \3/unnamed_net136  ;
wire \5/EN  ;
wire \5/unnamed_net137  ;
wire \5/unnamed_net138  ;
wire \5/unnamed_net139  ;
wire \5/unnamed_net140  ;
wire \5/unnamed_net141  ;
wire \+2V  ;
wire \+3.3V  ;
wire \+5V  ;
wire \+12V  ;
wire \-12V  ;
wire GND ;
wire \JT/TCK  ;
wire \JT/TDI  ;
wire \JT/TDO  ;

Is it fine to thave thoose names with / in verilog.
They comes from hierarchical designs.

...
> I think it is desirable to eventually have Qucs <=> Verilog <=> gGEDA
> roundtrips for schematics. (It doesn't have to be Verilog, but some
> suitable standardised format for circuit models.)

Ok.

Regards,
/Karl Hammar

Re: geda/lepton schematics

[Felix Salfelder]

On Fri, Mar 25, 2022 at 09:14:30PM +0100, k...@aspodata.se wrote:
> It seems it consists of a few non-connected branches.

Oh, if forgot. I once put some of it here [1] as standalone repos,
probably more of what you'd expect.

> > Connections in gEDA schematics are implicit, and port positions are
> > needed to infer them. For this, the symbol database is required. The gEDA
> > library has been used to look up the symbols.
> 
> Don't you get the connections from the netlist ?

Which netlist?

> > When I try to configure gnucap-geda, I get
> > [..]
> > checking for libgeda >= 20100214... no
> > configure: error: gEDA package not found
> 
>  ./bootstrap works fine here, but
>  ./configure gives:
> checking dynamic linker characteristics... (cached) GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> ./configure: 16616: GC_CPPFLAGS+= -I/usr/local/include/gnucap: not found

I have a line (17649) in my configure that seems related. but it reads
GC_CPPFLAGS+=" $(gnucap-conf$_program_suffix --cppflags)",
note the quotation marks. It is the same as line 35 in configure.ac.
Not sure what is going on. My configure starts with
# Generated by GNU Autoconf 2.71 for gnucap-geda 0.0.3-rc5.
And I am on commit 312cd3c3c26.

> checking l_dispatcher.h usability... no

This is just a consequence of the above if guess.

> I think something is not good enough with guile-2.0, and that the
> libgeda package should be updated for a newer guile version.
> Bug your distro about that.

I can try. Do you have a working libgeda-dev? which distro?

> Wouldn't it be best if geda/lepton supported gnucap instead of the 
> other way around ?

Not sure what you mean. One idea behind Gnucap is to read/write netlists
& schematics (and support models) from other projects.

It might be better if gEDA supported Verilog (and explicit connections)
to store schematics. Gnucap already reads structural Verilog for quite a
while.

> > Next steps are more technical, and I am happy to talk about it. Now
> > there is a translator "Qucs schematics" <=> "Verilog schematics", and I
> > can think of a way to do gEDA schematics properly...
> 
> Yes ?

I think it is desirable to eventually have Qucs <=> Verilog <=> gGEDA
roundtrips for schematics. (It doesn't have to be Verilog, but some
suitable standardised format for circuit models.)

cheers
felix

[1] https://codeberg.org/gnucap

Re: geda/lepton schematics

[karl]

Re: geda/lepton schematics

[karl]

Felix:
...
> Thanks for your interest. There are plugins for geda schematics [1], but
> with some problems.

> [1] http://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/log/?h=geda

That repo is a little strange, I get this:

$ git clone git://git.savannah.gnu.org/gnucap/gnucap-plugins.git
Cloning into 'gnucap-plugins'...
remote: Counting objects: 4666, done.
remote: Compressing objects: 100% (1567/1567), done.
remote: Total 4666 (delta 3020), reused 4666 (delta 3020)
Receiving objects: 100% (4666/4666), 1.87 MiB | 1.59 MiB/s, done.
Resolving deltas: 100% (3020/3020), done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

$ cd gnucap-plugins/
$ git co geda
Branch 'geda' set up to track remote branch 'geda' from 'origin' by rebasing.
Switched to a new branch 'geda'
$

It seems it consists of a few non-connected branches.

> Connections in gEDA schematics are implicit, and port positions are
> needed to infer them. For this, the symbol database is required. The gEDA
> library has been used to look up the symbols.

Don't you get the connections from the netlist ?

> When I try to configure gnucap-geda, I get
> [..]
> checking for libgeda >= 20100214... no
> configure: error: gEDA package not found

 ./bootstrap works fine here, but
 ./configure gives:
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
./configure: 16616: GC_CPPFLAGS+= -I/usr/local/include/gnucap: not found
./configure: 16618: CPPFLAGS+= : not found
checking l_dispatcher.h usability... no

 so something is strange.
$ ls -l /usr/local/include/gnucap/l_dispatcher.h 
-rw-r--r-- 1 karl users 3877 Feb  3 18:29 
/usr/local/include/gnucap/l_dispatcher.h

> Unfortunately, installing libgeda-dev does no longer work (for me).
> 
> The following packages have unmet dependencies:
>  libgeda-dev : Depends: guile-2.0-dev but it is not installable
>  libgeda42 : Depends: guile-2.0-libs but it is not installable
>  Depends: libgc1c2 (>= 1:7.2d) but it is not installable

I think something is not good enough with guile-2.0, and that the
libgeda package should be updated for a newer guile version.
Bug your distro about that.

> I don't know what it takes to fix it. Ideally the dependency on libgeda
> should be avoided, as it makes things more complicated than necessary.
> (Any workaround/hack will improve things!).

Wouldn't it be best if geda/lepton supported gnucap instead of the 
other way around ?

The guile 1.8 to 2.x step was a bit painful in general.
My guess is that geda with its xorn need some time to evolve out of
the guile dependancy and strange things happens there, at least for me.
So currently I'm mostly working with lepton.
so... my gueass is that geda/lepton changes faster than gnucap, and
that is why they should support gnucap and not the other way around.

> Next steps are more technical, and I am happy to talk about it. Now
> there is a translator "Qucs schematics" <=> "Verilog schematics", and I
> can think of a way to do gEDA schematics properly...

Yes ?

Regards,
/Karl Hammar

Re: geda/lepton schematics

[Felix Salfelder]

On Fri, Mar 25, 2022 at 02:30:36PM +0100, k...@aspodata.se wrote:
>  According to:
> http://gnucap.org/dokuwiki/doku.php/gnucap:user:netlist_import_and_export
> 
> there are something missing going from geda/lepton to gnucap.
> 
> I'm know about geda/lepton file format, but am rather new to gnucap.
> Is there anything I could help with ?

Hi Karl.

Thanks for your interest. There are plugins for geda schematics [1], but
with some problems.

Connections in gEDA schematics are implicit, and port positions are
needed to infer them. For this, the symbol database is required. The gEDA
library has been used to look up the symbols.

When I try to configure gnucap-geda, I get
[..]
checking for libgeda >= 20100214... no
configure: error: gEDA package not found

Unfortunately, installing libgeda-dev does no longer work (for me).

The following packages have unmet dependencies:
 libgeda-dev : Depends: guile-2.0-dev but it is not installable
 libgeda42 : Depends: guile-2.0-libs but it is not installable
 Depends: libgc1c2 (>= 1:7.2d) but it is not installable

I don't know what it takes to fix it. Ideally the dependency on libgeda
should be avoided, as it makes things more complicated than necessary.
(Any workaround/hack will improve things!).

Next steps are more technical, and I am happy to talk about it. Now
there is a translator "Qucs schematics" <=> "Verilog schematics", and I
can think of a way to do gEDA schematics properly...

Best regards
felix

[1] http://git.savannah.gnu.org/cgit/gnucap/gnucap-plugins.git/log/?h=geda