date: 10 october 2000
gEDA: gnetlist vams mode
first unrevised vams mode documentation
Written by: Martin Lehmann
-------------------------------------------------------------------------
VHDL-AMS support for the gEDA gnetlist tool
-------------------------------------------
CONTENT:
1. functionality
1. ARCHITECTURE generation
2. ENTITY generation
3. automatisate gnetlist calls
2. implementation
1. the vams mode of gEDA gnetlist
1. scheme
1. settings and new definition
2. gnet-vams.scm
1. routines main structure
3. helpfully setting in gEDA gschem environment
2. new c-code
1. routines
2. code-adaptation
2. automatic generating gnetlist calls in gEDA gschem
1. generated gEDA gnetlist calls
2. scheme
1. generate_netlist.scm
2. settings
3. new c-code
1. routines
2. code-adaptation
The purpose of our endevour, is that gEDA gnelist completly
supportted VHDL-AMS (VHDL Analog and Mixed-Signal) netlist
generation.
The VHDL-AMS netlist support mode is called vams.
1. FUNCTIONALITY
gEDA gnetlist in vams mode allow it to generate a VHDL-AMS
ARCHITECTURE or an ENTIY declaration. Which of both tasks is
performed, dependends on the generate-mode variable. This variable
is defined in the gnetlist command or will be set default.
If generate-mode=1 (default) gnetlist creates a netlist as an
VHDL-AMS ARCHITECTURE of the current schematic. Otherwise
(generate-mode=2), it creates an VHDL-AMS ENTITY declaration of the
selected component (this task needs information from gEDA gschem,
see below).
Now follows a stepwise discription of the program run in both
submodes.
We presuppose that you are familiar with the structure of gEDA
gnetlist usage (otherwise try gnetlist -help) and that you have
ever seen an VHDL-AMS ARCHITECTURE with its belonging ENTITY. If
you does not then the following distription will be seems very
strange to you. Maybe the syntax files (syntax_entity.txt,
syntax_architeture.txt) can helps you further.
==================================================================
1.1. ARCHITECTURE GENERATION
We suppose generate-mode is equal to 1, from this it follows that
vams creates a netlist as an ARCHITECTURE (saved to
<value-of-toplevel-attribute-entity>_arc.<output-fileextension>).
ARCHITECTURE <architecture-identifier> OF <entity-identifier> IS
The architecture-identifier we are getting from the toplevel
attribute architecture, which we have introduced. If it is not
defined, we are setting architecture-identifier default
(default_architecture). The same have we doing with the
entity-identifier (toplevel attribute entity, default_entity).
{<subnet-object> <subnet-name> : subnet-kind;}
In the signal declaration part all subnets of the schematic will be
declarated. A subnet declaration consists of an net-object, a
net-name and a net-kind. All subnets are connected to various
components pins. If this pins have all the same port-object and the
same port-kind it is ok, but if one of them different, the net is
faulty, and will be not declarated. Moreover, if the subnet-object
a quantity, then it will be checked, whether the subnet consists
exactly one output pin (port-mode), else the subnet is faulty too.
The three net attributes (object, kind, mode) we are getting from
the pin attribs, port_kind, port_object and port_mode (which we
have introduced newly) of a component pin.
BEGIN
Ok. it's only marks the start of the architecture body.
{<label> : ENTITY <entity> [(<architecture>)]
[GENERIC MAP (<set generic> => <generic-value>
{; <set-generic=> <generic-value>})]
PORT MAP ( <pin-name> => <subnet-name>{; <.. => ..>});}
We only support component instantiation statements, like this
above, because we generate simple VHDL-AMS netlists. The label of
an instance is defined from the uref of the instanciated
component. Watch out, this label must be unique,it is not checked
anywhere. The entity variable is not the same as the
entity-identifier, it is the value of the device attribute which on
its part identifies the precompiled ENTITY of this special
component. Similar is the architecture variable belonging to the
instanciated components ARCHITECTURE (note: one ENTITY can have more
ARCHITECTURES), hence we are getting it from the component
attribute ARCHITECTURE (newly introduced).
All generics of the generic-list are component parameters, which
are different from its default values (set in its ENTITY
declaration). How can we distinguish them? All defined generics
are attached to the component and looks like :
<attribute-name>=?<default-value> <- default, not in
generic-list
And if you want to change a parameter, you only must delete the
?-character and replace the default-value with your wanted value,
like this :
<attribute-name>=<new-value> <- element of generic list
If you do it this way, the new assigned value and its attribute-name
will be appear in the GENERIC MAP (set-generic=attribute-name and
generic-value=new-value).
The PORT MAP consists of all pins of a component and which nets
them connected to. The pin-name is getting from the pin# attribute
of the pin and the subnet-name means the value of the label
attribute of a net (mostly default named), which the pin is
connected to. If the pin directly wired to a PORT component (=
component, which device attribute =PORT), then we assign the uref
of this component to subnet-name.
END ARCHITECTURE <architecture-identifier>;
I think, this line needs no more explanation. The
architecture-identifier is the same like in the first line of
ARCHITECTURE declaration. Hence, the ARCHITECTURE part ends here.
==================================================================
1.2. ENTITY GENERATION
Now, we suppose generate-mode is equal to 2, from this it follows
that vams creates an ENTITY declaration of a component (save to
<component-device>.vhdl). If there no component selected (empty
top-attribs list) then it will be created an toplevel ENTITY of the
current schematic (save to
<value-of-toplevel-attribute-entity>.vhdl).
LIBRARY <library-identifier>{,<library-identifier>};
USE <package-identidier>{,<package-identifier>};
Well, the context clause part is not very ingenious. All libraries
and packages you needs for your simulation you must insert staticly
(a library contents precompiled ENTITIES, ARCHITECTURES and
PACKAGES, which are needed from base components [base of the
hierachical netlist] of your schematic. a package contents
predefined types, constants, ...). We are searching for a better
usability of this part.
ENTITY <entity-identifier> IS
[genric_clause]
[port_clause]
END ENTITY;
If you want generate a toplevel ENTITY of your current schematic
then the entity-identifier is defined from the toplevel attribute
entity of the schematic-file. Moreover, there are no generic_clause
and no port_clause.
In case of an component based ENTITY declaration, the
entity-identifier is getting from the device attribute of the
selected component (this attribute is included in top-attribs list,
which is defined in the automatic generated gnetlist command .. more
about this, later).
generic_clause :=
GENERIC ( <generic-identifier> : REAL := <default-value>
{;<generic-identifier> : REAL := <default-value>});
All needed generic-identifiers and it default-values are getting
from the top-attribs list. Note: all attached attributes of a
component appears in the generic_clause, only special attributes,
like uref, source and architecture, are taked out. The values of
this attributes are taked from the top-attribs list, too, but it
does not matter whether the value starts with a ?-character or not
(?-character always will be deleted, if it exist in front of a
value).
port_clause :=
PORT (<port-kind> <port-identifier> : [<port-mode>] <port-type>
{;<port-kind> <port-identifier> : [<port-mode>] <port-type>});
All variables of this clause are grabbed from the symbol of the
selected component. Port-kind corresponds with the value of the
port_kind attribute of the pin, which pin# attribute value is equal
to port-identifier. Just as corresponds port-type with the the
value of the pin attribute port_type and port-mode with the value
of port_mode.
===================================================================
1.3. AUTOMATISATING gnetlist CALLS
Because it is very arduous to type the whole gnetlist command,
which all its parameters, per hand into the terminal, we are
implement an automatisation of this process in gEDA gschem. This
makes it possible to create a VHDL-AMS ARCHITECTURE or ENTITY
whitout any commandline actions. The only thing you must do, is to
use one of the following hotkeys:
<g e> for generating an ENTITY
<g n> for genarating an ARCHITECTURE.
NOTE to <g e> - hotkey : If one component of the schematic
selected then the ENTITY generation
will be applied to this component !!
===================================================================
2. IMPLEMENTATION
At this section it will be explained the basic concept of the
implementation, which is splited in two sections. The first one
aimed to the gnelist implementation and the second to the gschem
implementation.
2.1. THE VAMS MODE OF gEDA gnetlist
To realize gnetlist VHDL-AMS support, it was necessary to create
new scheme and c stuff.
2.1.1. SCHEME
The scheme implementation contents two parts. On one hand the new
file gnet-vams.scm, which realize the VHDL-AMS-code generation, and
on the other hand some settings in rc-files.
2.1.1.1. SETTINGS AND NEW DEFINITIONS
The following lines insert in your gschemrc, or wherever you want,
but it must be loaded at gnetlist startup.
- load two modules, which we needs in our new implementation.
(define-module (ice-9 ls) :use-module (ice-9 common-list)
:use-module (ice-9 string-fun))
- load main file for VHDL-AMS support, which contents the
startup procedure vams.
(load "<path_of_gnet-vams.scm>/gnet-vams.scm")
2.1.1.2. gnet-vams.scm
This file contents all necessary scheme-functions to generate
VHDL-AMS-code. Especially, the main procedure vams, which can be
execute from the gnetlist command.
For example :
gnetlist -g vams schematic_filename.sch
...
2.1.2.1. ROUTINES MAIN STRUCTURE
the mainly functions structure looks like:
- (vams output-filename)
ARCHITECTURE generation
- (vams:write-secondary-unit architecture entity output-port)
- (vams:write-architecture-declarative-part output-port)
- (vams:write-signal-declarations output-port)
- (vams:write-architecture-statement-part packages output-port)
- (vams:write-generic-map output-port package)
- (vams:write-port-map package output-port)
ENTITY declaraction
- (vams:write-primary-unit entity port-list generic-list output-port)
- (vams:write-context-clause output-port)
- (vams:write-generic-clause generic-list output-port)
- (vams:write-generic-list generic-list output-port)
- (vams:write-port-clause port-list output-port)
- (vams:write-port-list port-list output-port)
2.1.1.3 HELPFULLY SETTING IN THE gEDA gschem ENVIRONMENT
This settings are not absolutly necessary, but they makes work
easier.
- set in .gEDA/gschemrc or wherever you want, but place it
right.
(attribute-promotion "enable")
(promote-invisible "enable")
(enforce-hierarchy "disabled")
(attribute-name "port_object")
(attribute-name "port_type")
(attribute-name "port_mode")
(attribute-name "entity")
(attribute-name "architecture")
2.1.2. NEW C - CODE
To got all informations, which we needed for currently netlist
generation, we must implemented two new c - functions.
2.1.2.1 NEW ROUTINES (saved in vams_misc.c)
SCM vams_get_package_attributes(SCM scm_uref)
The first function gets all attribute names (not its values) of a
component. This routine requires the name a component (package),
especially the uref of it, and returns a list of all attribute
names which are attached to this package.
We needs this functionality to produce a currectly
VHDL-AMS GENERIC MAP.
char* vams_get_attribs_list
(OBJECT *object, SCM *list, OBJECT **return_found)
It exists only for the support of the first function.
2.1.2.2. CODE ADAPTATION
To place this new functions at gnetlist scheme's disposal, you must
perform the following actions.
(1) gnetlist/src/g_register.c
gh_new_procedure1_0
("gnetlist:vams-get-package-attributes",
vams_get_package_attributes);
(2) gnetlist/include/prototype.h
SCM vams_get_package_attributes(SCM scm_uref);
(3) edit gnetlist/src/Makefile.in or directly in Makefile
(if you have edited Makefile.in you must run make config of
course)
- add "vams_misc.c" to gnetlist_SOURCES - variable
- add "vams_misc.o" to gnetlist_OBJECTS - variable
(4) copy vams_misc.c to gEDA/gnetlist/src/
(5) compile your code newly
===================================================================
2.2. AUTOMATIC GENERATING gnetlist CALLS IN gEDA gschem
To realize this new feature it was necessary to put more
information from the schematic to the scheme world of gEDA gschem.
Concretly, we needs the filename of the current schematic, because
gEDA gnetlist required it, and the attached attributes of a
selected component for creating an VHDL-AMS ENTITY. Hence, the
gnetlist command is mutated to an unidirectional interface between
the world of gschem scheme and the world of gnetlist scheme.
There are three important things, which transfer through this
interface:
(1) the source-file, which contents the complett filename
(with path) of the current schematic.
(2) the top-attribs list, which contents all attached
attributes of the selected component.
(3) the generate-mode, which is defined by the users actions.
2.2.1. STRUCTURE OF gEDA gnetlist CALLS FROM COMMANDLINE OR FROM gEDA
gschem.
typical commandline call :
gnetlist [-o <output-filename>]
-g vams
<schematic-file>
There are nothing to explain. The top-attribs list and the
generate-mode variable are default defined ('() and 1).
calls from gEDA gschem (3 possible variations) :
Note: vhdl-path is a predefined variable, which is set in
generate_netlist.scm first times. You can it simple redefine
in your local gschemrc file, which is loading everytimes you
starts gEDA gschem.
(1) hot-key-stroke: - g n (generate netlist)
--> generates a netlist of the current schematic.
gnetlist -o <vhdl-path>/<target-file>
-g vams
<source-file>
The source-file variable is equate to the complett
path+filename of the current schematic, which we get with
help of a self coded c function. If you cut out the filename
of the source-file variable (source-file without path) then
you are getting the target-file.generate-mode and
top-attribs are default again.
(2) hot-key-stroke: - g e (generate-entity)
and no component is selected.
--> generates an toplevel ENTITY of the current
schematic.
gnetlist -c <scheme-comm>
-o <vhdl-path>/<target-file>
-g vams
<source-file>
scheme-comm="(define top-attribs '<top-attribs>)
(define generate-mode '2)"
Source-file needs no comment, because it is the same as in
(1). To get all attributes of a selected component, we are
must write a new c function again. The values, which we get
from this new function are saved in top-attribs. The sense
of the scheme-comm command is to put top-attribs and
generate-mode from the gschem to the gnetlist environment.
At last, the target-file consists of the pure basefilename
of the source-file and an .vhdl extention.
(3) hot-key-stroke: - g e (generate-entity)
and only one component is selected.
--> generates an ENTITY of the selected schematic.
commandline is the same as in (2).
Differences: The target-file is different, but it does not
matter, because gnetlist generate an new output-filename in
in this case (<device-name-of-selected-component>.vhdl,
normally).But one fact is very important: the top-attribs
variable includes all attached attributes of the selected
component now.
2.2.2. SCHEME
The gnetlist command is generating from two scheme functions, which
are saved in generate_netlist.scm. This functions starts if the
gschem user is typing one of the specified hot-keys ([g e] starts
generate-entity and [g n] starts generate-netlis). Both routines
puts the whole gnetlist command together and execute it. The syntax
you see above.
2.2.2.1. generate_netlist.scm
2.2.2.2. SETTINGS
If you want use the new feature then you must do some entries in one
of your gEDA gschem rc-files
necessary defines:
- in system-gschemrc
("g" . gnetlist-keymap)
Edit your global-keymap and if "g" always defined then find
out an other free hot-key-stroke.
Note: the documentation supports the "g" - key only.
- in one of the gschem startup files
(define gnetlist-keymap
'(("n" . generate-netlist)
("e" . generate-entity)))
loads :
(load "/home/fliser3/.gEDA/generate_netlist.scm")
2.2.3. NEW C-CODE
The c-code makes it possible to get directly informations from the
gschem tool, which is necessary for the online execution of
gnetlist.
2.2.3.1. ROUTINES
It exists two new c-functions. Both are put down in
misc_for_gnetlist.c.
SCM get_selected_filename(gpointer data,
guint callback_action,
GtkWidget *widget)
This function returns the whole filename of the current schematic,
which is picked from the w_current->page_current->page_filename
string.
SCM get_selected_component_attributes(gpointer data,
guint callback_action,
GtkWidget *widget)
How the name is saying, this functions returns all attributes of
the selected component. It is realized with a simple while loop
over all objects of the schematic, which picked out all elements
where the selected flag is set.
2.2.3.2. CODE-ADAPTATION
Here are some actions you must conclude to makes the software
runable.
(1) new lines in /gschem/src/g_register.c
gh_new_procedure0_0 ("get-selected-filename",g_get_selected_filename);
(2) new lines in /gschem/include/prototype.h
SCM g_get_selected_filename();
(3) copy the file misc_for_gnetlist.c to gschem/src
(4) add in file /gschem/src/Makefile.in or directly in Makefile.
(if you have edited Makefile.in you must run make config of
course)
- add "misc_for_gnetlist.c" to gschem_SOURCES - variable
- add "misc_for_gnetlist.o" to gschem_OBJECTS - variable
(5) add new lines in /gschem/src/g_key.c
SCM g_get_selected_filename(void)
{
return (get_selected_filename(window_current, 0, NULL));
}
(6) compile your changed c-code newly