[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: geda/lepton schematics

From: Felix Salfelder
Subject: Re: geda/lepton schematics
Date: Sat, 26 Mar 2022 23:22:02 +0100

On Sat, Mar 26, 2022 at 09:33:50PM +0100, 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/")
> (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:
> 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

Thanks, need to revisit his work.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]