gnucap-devel
[Top][All Lists]
Advanced

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

Re: geda/lepton schematics


From: al davis
Subject: Re: geda/lepton schematics
Date: Sun, 27 Mar 2022 02:36:13 -0400

On Fri, 25 Mar 2022 22:43:14 +0100 (CET)
karl@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)
karl@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.





reply via email to

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