Важный момент! Пользователь должен понимать, что ALS симулятор переводит обрабатываемую схему в VHDL, затем из полученного описания формирует список соединений (netlist) для последующей симуляции (смотри рисунок). Другими словами, важно понимать что при ALS симуляции создаются два вспомогательных файла: (VHDL) и {net.als}. Полученное VHDL описание текущей ячейки можно посмотреть использовав команду Edit VHDL View из меню View.

Когда вы запрашиваете симуляцию, обрабатывается ячейка в текущем окне. При этом происходит проверка даты для определения того, что более необходимо, перевод в VHDL или компиляция списка соединений. (прим. достаточно запутанный механизм) Если VHDL является текущей ячейкой, то соответственно перегенерации топологии или схематика не происходит, даже если VHDL описание датируется более поздним сроком. Аналогично, если у вас текущая ячейка список соединений, то повторное преобразование из VHDL в netlist не происходит, даже если по дате файл списка соединений более поздний чем VHDL. (во избежание ошибок следите за тем какая ячейка у вас текущая) В любом случае симуляция выбранной ячейки гарантированна.

Обратите внимание, что так как VHDL описание является одним из шагов при проведении симуляции, то ничего не мешает создавать VHDL файл вручную (единственное что может помешать это не знание языка VHDl). (подробнее о такой возможности Section 4-10). Для получения VHDL описания без каких либо симуляций, можно воспользоваться командой Make VHDL View из меню View.
Мощнейшая возможность VHDL это взаимодействие с Silicon Compiler, работа которого основана на VHDL описание! Это дает Electric грандиозные возможности в создании, тестировании и проектировании схем по спецификациям наивысшего уровня! Подробнее о Silicon compile. (прим. очень крутая штука)

Модели состояний
Когда VHDL описание схемы преобразовано в список соединений, компоненты связанности и модель состояний включены в конечный файл. Это делается из-за того что формат списка соединений иерархичен, а в основании иерархии лежат примитивы состояний. Electric распознаёт примитивы для MOS транзисторов и элементов AND, OR, NAND, NOR, Inverter, и XOR. Остальные примитивы могут быть определенны пользователями самостоятельно.
Для создания (или переопределения) примитива состояния, проще создать {net.als} с именем создаваемого примитива. Для этого воспользуйтесь командой New Cell... из меню Cell и выберите "netlist.als" вид. Например, определите состояние ALU, отредактировав файл "alu{net.als}", и переопределите состояние двухвходового вентиля И, отредактировав "and2{net.als}". Далее компилятор автоматически скопирует эти текстовые файлы в описание списка соединений всякий раз когда эти узлы будут генерироваться из VHDl.
Список соединений поддерживает три различных типа записей: model(модель), gate(выход), и function(функция). В модели описывается взаимосвязь с остальными записями. Записи выхода и функции находятся на уровне примитивов. Запись выхода использует таблицы истинности, а функция обеспечивает связь с JAVA кодом. Также при формировании записей для примитивов можно задавать специфицированные операторы, например, задержку распространения сигнала, скорость переключения и т.д.
Ниже на примере разобрано описание списка соединений для RS триггера. "#" - комментарий.

# model declaration for the figure
model main(set, reset, q, q_bar)
inst1: nor2(reset, q_bar, q)
inst2: nor2(q, set, q_bar)
# gate description of nor2
gate nor2(in1, in2, out)
t: delta=4.5e-9 + linear=5.0e-10
i: in1=L in2=L o: out=H@2
i: in1=H o: out=L@2
i: in2=H o: out=L@2
i: o: out=X@2

Приведенный выше пример, представляет законченное описание схемы. Обратите внимание, что когда gate, function, или model упоминаются в рамках описания другой модели, должно выполнятся идентичное соответствие имени сигнала в описании подэлемента и имени сигнала находящегося в заголовке записи. Другими словами, обратите внимание, что при описании (# model declaration for the figure) в заголовке названия сигналов входа и выхода обозначены как (set, reset, q, q_bar), следовательно при описании inst:nor2 мы так же должны должны использовать эти имена. В подэлементе nor2 имена входов и выходов соответственно in и out, так что если бы мы при описании inst:nor2 в качестве имени входа взяли бы in, а не set или reset, то это была бы ошибка.

Симуляторный анализ
ALS симулятор обрабатывает набор (так называемых) узлов симуляции(simulation nodes). Узел симуляции, в некотором роде, является точкой соединения с которой могут быть связаны один или несколько сигналов.
Узел симуляции может принимать три значения(состояния) L, H, или X, и имеет 4 уровня мощности (off, node, gate, и VDD, значения приведены в порядке возрастания мощности). Таким образом узел симуляции может находится в 12 различных состояниях. Симулятор перед началом работы рассматривает состояния и мощности входных узлов, далее в каждый конкретный момент времени состояния узла может изменятся

Управляющий(входной) сигнал может приходить с другого узла, поэтому ему в соответствие ставится значение "gate" (H(gate) означает что на входе логическая единица, пришедшая либо от питания ("VDD" strength) либо заданная пользователем. Если же пользователь никаких действии не производил и узел не подсоединен ни к земле, ни к питанию, то на входе узла будет дефолтовое состояние X(off)).
В приведенном примере, комбинация логической 1 и логического 0 при одинаковых мощностях, пришедших соответственно с сигналами "out" и "in2" в результате обработки симуляцционным алгоритмом(из примера. алгоритм - сумматор) дают неопределенное состояние X (undefined) на выходном сигнале, определенным как q. Также на этом примере можно посмотреть энергетическую составляющую часть симуляции. В нашем примере два входа одинаковой мощности, но с различными состояниями, в этом случае конфликта не происходит и мы получаем неопределенное состояние(неопределенное состояние также является состоянием), в случае когда на входе сигналы различной мощностью, то преобладать будет сигнал с наибольшей мощностью.
Еще одно концептуальное понятие, необходимое для понимания пользователя, это то, что симулятор является event-driven(событийно управляемым). Когда узел симуляции изменяет свое состояние, "движок" симулятора автоматически просматривает netlist узлов потенциально состояние которых тоже может изменится. Очевидно, что это происходит только с узлами объединенными в одну модель или по входам, или обединненых функциональной зависимостью. Если состояние изменилось или требуется произвести какое-то событие (прим. событие может произойти, но состояние не изменится), то событие добавляется в список событий, для дальнейшего выполнения при симуляции. Если же при дальнейшей симуляции событие не состоялось, произошла ошибка, то симулятор заново ищет данные о тех узлах потенциально состояния которых может изменится, при выполнении несостоявшегося события. Этот процесс будет продолжатся до тех пор пока симулятор не пройдет по всем возможным узлам и состояниям.