> 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
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?
>
>
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
Hi Felix, I think we are in agreement but don't understand each other.
Regards,
/Karl Hammar
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
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?
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
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
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
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
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).
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
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
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
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
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
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
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.
>
>
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
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
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.
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
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
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.
> >
> >
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
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
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
28 matches
Mail list logo
