Jade — JAvascript Design Environment

Demonstration video

Quick start

Overview

Jade provides a framework for editing and simulating hierarchical block diagrams. The editing and simulation tools are provided by plug-ins, so it's easy extend the framework to support different types of diagrams.

The basic building block is a module. Each module has one or more aspects, which can be edited using one of the supplied editing tools. Currently Jade has editors for the following aspects:

Extracting a netlist

To run the simulation tools on a module's schematic, Jade converts the (possibly hierarchical) schematic into a flattened netlist that has one entry for each primitive component listing its properties and the signals connected to its terminals. The netlister is given a list of primitive component modules and stops its hierachical descent when one of these components is reached.

The extraction process has several steps:

  1. Label each connection with its associated list of signal names. Signal names are determined by port components or the signal name property, if any, given to a wire. Signal names can include lists of names and/or iterators (see below). If a wire is unnamed, Jade will generate a name to use for the netlist.

  2. Ensure each component in the diagram has a unique name, generating a name for components whose name properties have not been set by the user.

  3. Generate a netlist entry for each primitive component (instances from the /analog collection for device-level simulation, instances from the /gates collection for gate-level simulation). Depending on the signal lists associated with the component's terminals, more than one netlist entry may be generated; see below.

  4. Recursively generate a netlist entry for each hierarchical component, where the signal names connected to the component's terminals become the signal names for wires connected to the corresponding ports in the component's schematic. The component's internal signals will be prefixed with the component's name. When the hierarchy is several levels deep, the prefix reflects the pathname created by concatenating the names of the components as extractor descended the hierarchy, e.g., alu.adder.cin.

Signal names should consist of letters, numbers and _, but must start with a letter or _. For compound signals (e.g., a bus) one can specify a comma-separated list of names

a[3],a[2],a[1],a[0]

You can use an iterator suffix of the form "[start:end]" or "[start:end:step]" which Jade expands into the appropriate comma-separated list. Examples:

a[3:0] → a[3],a[2],a[1],a[0] b[7:0:3] → b[7],b[4],b[1] c[30:0],gnd → c[30],c[29],…,c[1],c[0],gnd d[3:2][1:0] → d[3][1],d[2][1],d[3][0],d[2][0]

Finally, you can use a replicator suffix of the form "#count" which will cause Jade to replicate the prefix the specified number of times. Examples:

gnd#2 → gnd,gnd a[1:0]#2 → a[1:0],a[1:0] → a[1],a[0],a[1],a[0]

Note that multiple suffixes are processed right-to-left.

A single component instance may generate several netlist entries. The width W of each terminal in a component is determined from its label, e.g., a terminal with a label of "foo" has W=1, a label of "sel[2:0]" has W=3. When the netlist for a component is generated, each of its terminals consumes W entries from its associated signal list. Jade will generate N components where

N = max over all terminals(length_of_terminal's_signal_list / terminal's_W)

If N*W is longer than a terminal's associated signal list, the list gets reused in a cyclic fashion. It's a bit hard to explain in words but the results tend to match your expectations. For example, the following schematic using a 2-input XOR gate

will expand into the following 32 2-input XOR gates:

Note that it is an error if (N mod W) is nonzero for any terminal.

Device-level simulation

The device-level simulation tool expects a flattened netlist containing components from the /analog collection.

When simulating digital circuits, the easiest way to run device-level transient simulations is to create a test aspect specifying

.mode device

and then use the tool to run the test. This tool will create the appropriate voltage sources to generate the specified input waveforms, run the simulation long enough to process all the test vectors, then examine the simulation results to ensure the outputs have the specified values as the specified time. The test tool will optionally plot waveforms for the specified nodes.

One can also use primitive components to generate input waveforms (using voltage and current sources) and examine output waveforms (using voltage and current probes). After including the appropriate sources and probes, the following types of circuit analysis can be performed.

Gate-level simulation

The gate-level simulation tool expects a flattened netlist containing components from the /gates collection.

When simulating digital circuits, the easiest way to run gate-level simulations is to create a test aspect specifying

.mode gate

and then use the tool to run the test. This tool will create the appropriate voltage sources to generate the specified input waveforms, run the simulation long enough to process all the test vectors, then examine the simulation results to ensure the outputs have the specified values as the specified time. The test tool will optionally plot waveforms for the specified nodes. In gate-level simulation, node values are one of the following:

Testing

The test aspect makes it easy to test the functionality of a module. Here's a test for an XOR circuit with inputs A and B, and output Z:

// set up Vdd, establish signaling voltages .power Vdd=1 // Vol, Voh set voltages generated for input signals // Vil, Vih set voltage thresholds for determining logic values .thresholds Vol=0 Vil=0.1 Vih=0.9 Voh=1 // test actions are applied to named groups of signals. // A signal can appear in more than one group. Order // of groups and signals within each group determine // order of values on each line of test values .group inputs A B .group outputs Z // set type of simulation to be performed // device -- transient simulation; components must be from from /analog // gate -- gate-level simulation; components must be from /gates .mode device /* Tests are sequences of lines supplying test values; .cycle specifies the sequence of actions that will be performed for each test. Available actions are assert group -- set values for signals in group with H,L test values deassert group -- stop setting values for signals in group with H,L test values sample group -- check values of signals in group with 0,1 test values tran time -- run simulation for specified time interval signal=val -- set signal to specified value */ .cycle assert inputs tran 9n sample outputs tran 1n // the tests themselves -- one test per line // to assert signal this cycle use 0,1; use Z or - if not to be asserted // to sample signal this cycle use L,H; use - if not to be sampled // whitespace can be used to improve readability, non-blank characters // are associated, in order, with signals listed in .group above. 00 L 01 H 10 H 11 L // (optional) produce plots showing the test inputs and/or outputs .plot A .plot B .plot Z

The tests for a module can be run by clicking in the schematic toolbar.

If you'd like to see more examples, each module in the /gates collection has a test aspect that verifies its functionality at the device level.