tkgate(1) [debian man page]

TKGATE(1)						      General Commands Manual							 TKGATE(1)

NAME

       tkgate - Tcl/Tk based digital circuit editor and simulator

SYNOPSIS

       tkgate [-xqs] [-X script] [-l file] [-p file] [-P printer] [files...]

DESCRIPTION

       TkGate  is  a  graphical  editor and event driven simulator for digital circuits with a tcl/tk-based interface.	Supported circuit elements
       include basic gates (AND, OR, etc.), tri-state gates, adders, multipliers, registers, memories and mos transistors.  Hierarchical design is
       also supported with support for user defined modules.  Save files are based on the Verilog netlist format.

       TkGate documentation can be found at:

       http://www.cs.cmu.edu/~hansen/tkgate

OPTIONS

       The options are as follows:

       -X script      Automaticaly start the simulator and execute the specified simulation script.

       -p file	      Print circuit to file without starting GUI.

       -P printer     Print circuit to printer without starting GUI.

       -l file	      Read the specified file as a library.

       -x	      Automaticaly start the simulator.

       -q	      Suppress startup messages.

       -s	      Excute with a synchronous X server connection.  This option is primarily for debugging.

       -L lang	      Specify a locality to use if tkgate has been configued for Japanese support.  The locality should be either "ASCII" for Eng-
		      lish, or "ja_JP.EUC" for Japanese. This option can also be set via the LANG environment variable.

HISTORY &; CREDITS
       TkGate begin life as an undergraduate project at Carnegie Mellon University (CMU) in 1987.  At that time it was called  simply  'gate'  and
       ran under the 'wm' window manager, a windowing system developed at CMU before X11 was widely used.  In this incarnation it was used by stu-
       dents in the computer architecture course at CMU to develop a simple microprocessor (dubbed "The Bat Computer").  After laying dormant  for
       several	years, it was resurrected in 1991 and ported to run under X11 with the Xlib API.  In this incarnation it was used several times by
       students in the introductory digital logic course, but after the author graduated and left CMU,	it  went  into	hibernation  again.   This
       Tcl/Tk  incarnation  was begun in 1998.	While there is certainly some cruftyness in the implementation in places due to the multiple rein-
       carnations, many new features have been added since the older wm and X11 versions, and the interface has been made much easier to use.

SEE ALSO

       gmac(1)

AUTHOR

       Jeffery Hansen (hansen@cmu.edu)

COPYRIGHT

       Copyright (c) 1987-2004 by Jeffery Hansen

																	 TKGATE(1)

VHDL(5) 					      VHDL subset of ASIM/LIP6/CAO-VLSI lab.						   VHDL(5)

NAME

       ALLIANCE VHDL Subset

ORIGIN

       This  software  belongs	to  the  ALLIANCE CAD SYSTEM developed by the ASIM team at LIP6 laboratory of Universite Pierre et Marie CURIE, in
       Paris, France.

       Web : http://asim.lip6.fr/recherche/alliance/
       E-mail : alliance-users@asim.lip6.fr

DESCRIPTION

       The ALLIANCE VHDL subset is dedicated to digital synchronous circuits design.  The same subset is used for:
	      logic simulation (asimut)
	      logic synthesis (boom, boog, loon)
	      functionnal abstraction (yagle)
	      formal proof (proof)

       The ALLIANCE VHDL subset is fully compatible with the IEEE VHDL standard Ref.  1076 (1987). That means that a VHDL  description	using  the
       ALLIANCE subset can be simulated with any full-VHDL commercial compiler-simulator.

       Here follows the main restrictions of the ALLIANCE subset.

       The VHDL description of a circuit is made of two seperate parts: the external view and the internal view.

       The  external view defines the name of the circuit and its interface. The interface of a circuit is a list of ports. Each port is specified
       by its name, its mode, its type, its constraint for an array and, its kind.

       The mode of a port depends only on the manner the port is used inside the circuit (in the internal view of the circuit). If the value of  a
       port  is  to be read in the view of the description, the port must be declared with the mode in. If the value of a port is to be written by
       the internal view, the port must be declared with the mode out. If both above conditions are satisfied the port must be declared  with  the
       mode inout.

       Only structural and behavioural data flow are supported as internal view.

       In  order to allow automatic translation from structural VHDL to other netlist formats (EDIF, ALLIANCE, COMPASS, ...) it is not possible to
       mix behavioural and structural description. Of course, a circuit, a subcircuit or a cell can have two different descriptions:
	      a structural view may be defined in a file with a .vst extension (see vst(5)).
	      a behavioural data flow description may be defined in a file with a .vbe extension (see vbe(5)).

       A typical VHDL model will be made of a hierarcical structural description (a hierarchy of structural files) and,  for  each  leaf  cell,  a
       behavioural description.

       In  a  behavioural description, only concurrent statements (except process) are supported. Up to now, sequential statements are not allowed
       by the ALLIANCE VHDL compiler.

       Timing information can be specified in behavioural descriptions using After clauses. However, those delays are currently only used for sim-
       ulation. After clauses are supported but not used for synthesis and formal proof.

       A predefined set of types has been defined (other user defined types are not supported):

       bit	      the predefined standard bit type ('0' or '1')

       bit_vector     array of bit

       mux_bit	      a resolved subtype of bit using the mux resolution function. This function checks that only one driver is actually connected
		      to a signal. The effective value of the signal is the value of the active driver. If all drivers are disconnected, the value
		      of the signal is '1' (pull up). A signal of type mux_bit must be declared with the kind bus.

       mux_vector     array of mux_bit

       wor_bit	      a  resolved  subtype  of	bit  using  the  wor resolution function. This function allows a signal be driven by more than one
		      driver. All active drivers have to drive the same value. The effective value of the signal is the value of  active  drivers.
		      If  all  drivers	are disconnected, the value of the signal is '1' (pull up). A signal of type wor_bit must be declared with
		      the kind bus.

       wor_vector     array of wor_bit

       reg_bit	      a resolved subtype of bit using the reg resolution function. This function checks that only one driver is actually connected
		      to  a signal. The effective value of the signal is the value of the active driver. A signal of type reg_bit must be declared
		      with the kind register (which makes the signal keep its previous value when all drivers are disconnected).

       reg_vector     array of reg_bit

       In the next ALLIANCE release the VHDL subset will be largely extended (sequential statements, user defined types) .

SEE ALSO

       vst(5), vbe(5), asimut(1), boom(1), loon(1), boog(1), proof(1)

BUG REPORT

       This tool is under development at the ASIM department of the LIP6 laboratory.
       We need your feedback to improve documentation and tools.

ASIM
/LIP6							  October 1, 1997							   VHDL(5)