Уже на этапе проектирования для прототипирования и верификации целевой системы часто используется инструментарий кросс-разработки (см. например [17-19]). Это позволяет эффективно выполнять тонкую оптимизацию системы (как аппаратуры, так и программ для нее) с использованием системных и прикладных целевых программ, близких к реальным. Благодаря этому, дальнейший переход к выпуску промышленного набора результатов проектирования происходит бесшовно, то есть последняя итерация проектирования и верификации оканчивается результатами, готовыми к производственному применению (спецификацией аппаратуры и программами для нее).

В данном разделе рассматриваются существующие языки описания моделей целевой аппаратуры и соответствующие методы построения инструментария кросс-разработки на основе таких описаний. Выделяются три группы средств описания:

1. языки описания аппаратуры с возможностью синтеза реальных спецификаций для производства микросхем;
2. языки ADL (Architecture Description Languages) для высокоуровневого описания аппаратуры;
3. языки программирования общего назначения.

Рассмотрим три основных языка HDL (Hardware Definition Language) [20], которые используются современными разработчиками для описания моделей аппаратуры, пригодных для дальнейшего автоматического синтеза спецификаций для производства реальных чипов. Это VHDL, Verilog и SystemC. Первые два языка были разработаны в середине 80х и до сих пор являются наиболее популярными классическими HDL-языками; SystemC – относительно современная разработка, находящаяся в стадии развития, но стремительно набирающая популярность.

На верхнем уровне эти языки очень схожи – модель аппаратуры описывается в виде взаимодействующих модулей (блоков), для каждого из которых определяется интерфейс и реализация. Интерфейсы модулей описывают входные, выходные и двусторонние порты, с помощью которых модули соединяются друг с другом для обмена данными и управляющими сигналами. Реализация задает элементы внутреннего состояния и порядок вычисления значений выходных интерфейсов на основе этого состояния и значений входных портов, а также правила обновления внутреннего состояния. Вычисление новых значений выходных интерфейсов и внутреннего состояния инициируется событиями в виде изменения уровней входных сигналов. Важную роль в описании аппаратуры с использованием языков HDL играет понятие времени, которое моделируется целочисленной величиной с возможностью привязки к физическому времени. Для описания причинно-следственных отношений между событиями в рамках одной единицы модельного времени используется понятие дельта-задержки (delta delay), которая разделяет последовательно выполняющиеся события, происходящие в одну и ту же единицу модельного времени. При описании реализации модуля могут использоваться выполняющиеся параллельно процессы, которые обычно представляют собой бесконечные циклы ожидания наступления некоторых заданных событий (называемых списком чувствительности процесса) с их последующей обработкой и возвратом к ожиданию новых изменений.

Рассмотрим каждый из языков более подробно.

VHDL [21-24] был разработан в недрах Министерства Обороны США, изначально предназначаясь для облегчения унифицированного описания микросхем, которые включались сторонними поставщиками в различные решения для этого ведомства. Первая официальная версия VHDL появилась в 1987 году в виде стандарта IEEE 1076-1987 [24]. Многие семантические и синтаксические элементы VHDL заимствованы из языка Ada. Подобно Ada, VHDL – это строго типизированный язык, не чувствительный к регистру символов. В дополнение к стандартным базовым возможностям Ada, VHDL включает расширенные логические операции (например, nand и nor), двунаправленную индексацию массивов, а также дополнительные типы, такие как time, bit, bit_vector, character, string. Позже в VHDL ввели понятие 9-значной (U,X,0,1,Z,W,H,L,-) логики (см. IEEE Std 1164 [25]) и понятие знаковых/беззнаковых типов (см. IEEE standard 1076.3 [26]). Принципиальной особенностью VHDL является поддержка конструкций для задания параллелизма, свойственного аппаратуре, а именно модулей и процессов. Интерфейс модуля задается с помощью ключевого слова entity, ключевое слово architecture обозначает описание реализации, которое заключается между begin и end. Внутри такого блока могут задаваться константы (constant), сигналы (signal) и собственно поведение в виде набора операторов, в том числе, сгруппированных в виде параллельно выполняющихся процессов (с помощью ключевого слова process). Внутри процессов могут объявляться переменные (variable). Важным различием переменных и сигналов является то, что значение переменной меняется сразу после выполнения соответствующего оператора (понятие времени не ассоциируется с понятием переменной), а значение сигнала меняется только после окончания текущей итерации выполнения процесса.

Пример 1 иллюстрирует реализацию на языке VHDL простого мультиплексора (см. рис. 4).

Рис. 4. Простой мультиплексор

entity mux is
	port (c, d, e, f: 	in std_logic;
	      s: 		in std_logic_vector(1 downto 0);
	      mux_out: 		out std_logic);
end mux;

architecture mux_impl of mux is
begin
	muxl: process (s, c, d, e, f)
	begin
	    case s is
	      	when “00” => mux_out <= c;
	      	when “01” => mux_out <= d;
      		when “10” => mux_out <= e;
	      	when others => mux_out <= f;
	    end case;
	end process muxl;
end mux_impl;

Пример 1. Простой мультиплексор на VHDL.

Язык Verilog [21], [28-30] был разработан компанией Gateway Design Automation в 1985 году для целей проектирования интегральных схем на логическом уровне. В 1989 году компания Gateway Design Automation была куплена Cadence, которая сделала этот язык публичным. В 1995 году Verilog стал стандартом IEEE 1364 [29].

Verilog наследует многое из языка C, поддерживает конструкции препроцессора C и большинство основных управляющих конструкций, таких как “if”, “while” и т.п. Verilog полностью поддерживает операторы языка C, но также обладает дополнительными возможностями для удобной обработки двоичных данных (например, операциями ~^ для XNOR или >>> для арифметического сдвига с заполнением знаковым битом). Однако в Verilog не поддерживаются пользовательские типы, структуры, указатели и рекурсивные функции. Типы данных в Verilog имеют явную битовую ширину. В отличие от VHDL, Verilog является слабо типизированным языком, что позволяет смешивать присвоения элементов разного типа за счет неявного преобразования типов.

Как и в случае VHDL, принципиальным отличием Verilog от своего языка-прототипа является поддержка конструкций, выполняющихся параллельно. Модули в Verilog определяются с помощью ключевого слова module и могут быть вложенными. Не происходит явного разделения интерфейса и реализации, как в VHDL. В декларативной части модуля определяются входные (input), выходные (output), двунаправленные (inout) порты, внутренние сигналы (wire) и переменные (reg).

module bcircuit (a, b, av, bv, w, wv);
	input a, b;
	output w;
	input [7:0] av, bv;
	output [7:0] wv;
	wire d;
	wire [7:0] dv;
	reg e;
	reg [7:0] ev;
	. . .
endmodule

Пример 2. Описание модуля и его интерфейсов в Verilog

В процедурной части модуля определяется его поведение. Для этого могут использоваться конструкции вентильного уровня (определяется структура модуля в виде соединенных между собой вентилей определенных типов), параллельные присвоения (assign) или процедурные блоки (always или initial). Процедурные блоки аналогичны процессам VHDL. Конструкции языка в рамках процедурного блока выполняются последовательно, в то время как все процедурные блоки выполняются параллельно. Интересно отметить наличие оператора неблокирующего присваивания <=, который может использоваться для присваивания новых значений в рамках процедурного блока. В отличие от обычного присваивания =, изменение значения, присвоенного оператором <=, происходит только в конце текущего кванта времени.

Важным отличием Verilog от VHDL является подверженность недетерминированному поведению (race conditions) модели на основе описания Verilog и отсутствие таких эффектов в VHDL. Более подробный сравнительный обзор VHDL и Verilog можно найти в [34].

Пример 3 иллюстрирует реализацию простого мультиплексора (см. рис. 4) на языке Verilog.

module mux (c, d, e, f, s, mux_out);
     input 	c, d, e, f;
     input 	[1:0] s;
     output 	mux_out;
     reg	mux_out;

     always @ (c or d or e or f or s)
     begin
        case (s)
          2’b00: mux_out = c;
          2’b01: mux_out = d;
          2’b10: mux_out = e;
          default: mux_out = f;
        endcase
     end
endmodule

Пример 3. Простой мультиплексор на Verilog.

Работа над языком SystemC [30-31] была начата в середине 1990-х в качестве внутреннего проекта компании Synopsis, и язык был открыт сообществу в 1999 году. В 2000 году был учрежден консорциум Open SystemC Initiative [31], в который вошли такие заинтересованные компании, как Mentor Graphics, Cadence, ARM, CoWare. Образование этого консоциума позволило проводить работы по развитию SystemC в интересах всего сообщества. Первая версия SystemC 1.0 вышла в этом же году и сменилась следующей в 2001 году. В 2005 году для SystemC появился стандарт IEEE Std 1666 [32]. В настоящее время ведутся работы над созданием новой версии SystemC 3.0.

На самом деле, SystemC не является самостоятельным языком. Фактически, это библиотека классов, типов и макросов C++, которая позволяет удобно описывать программно-аппаратную систему на различных уровнях абстракции. Благодаря хорошим возможностям языка C++ для определения пользовательских типов, описания на SystemC выглядят достаточно выразительным образом, что позволяет эффективно расширять семантику базового языка. К основным расширениям SystemC, явно отсутствующим в C++, относятся:

1. понятие модельного времени;
2. возможности описания параллельно выполняющихся вычислений;
3. дополнительные типы данных, отражающие специфику проектирования аппаратуры (в первую очередь, многозначная логика 1, 0, X, Z).

Основным преимуществом SystemC над языками VHDL и Verilog является возможность использовать одно и то же окружение и язык для описания системы от самых высокоуровневых моделей на C++ до структурных синтезируемых моделей уровня RTL. Теоретически это позволяет постепенно детализировать описание системы в процессе проектирования. Однако пока инструменты поддержки процесса разработки с использованием SystemC уступают инструментарию классических языков VHDL и Verilog. Это приводит к тому, что SystemC в основном используется как «улучшенный» C++ для описания только высокоуровневых моделей системного уровня с последующим переходом на VHDL или Verilog для описания оптимизированной RTL модели для реального синтеза аппаратуры.

Так же, как и в VHDL и Verilog, основным строительным блоком в SystemC является модуль, который объявляется с использованием ключевого слова SC_MODULE. В модуле могут определяться порты (sc_in, sc_out, sc_inout), данные модуля (включая ссылки на другие модули) и методы. В каждом модуле обязательно должен присутствовать метод-конструктор, который в SystemC обозначается SC_CTOR. Также может объявляться деструктор с использованием обычного синтаксиса C++. Остальные методы делятся на параллельные и обычные (вспомогательные). Обычные методы применяются, как повторно используемые функции для упрощения реализации параллельных методов. Параллельные методы SystemC аналогичны процессам VHDL и Verilog и служат основным средством для описания деталей поведения модели. В SystemC выделяют два основных типа параллельных методов – SC_METHOD и SC_THREAD. Тип метода (обычный или подтип параллельного) указывается в конструкторе модуля. Основное различие между SC_METHOD и SC_THREAD заключается в порядке их исполнения в рамках модели. SC_METHOD запускается в ответ на события из своего списка чувствительности столько раз, сколько раз срабатывает эти события. При этом каждый запуск независим друг от друга в смысле сохранения значений локальных переменных, и выполняется он до конца метода или до явного return. В SC_METHOD нельзя применять функцию wait для динамического контроля над приостановкой процесса. SC_THREAD же запускается только один раз в начале исполнения модели, поэтому обычно реализация SC_THREAD представляет собой бесконечный цикл while(1). Принципиальной особенностью SC_THREAD является возможность использовать функцию wait для приостановки исполнения процесса до наступления заданных условий. При этом управление передается ядру симулятора и возвращается только при наступлении этих условий. Выполнение продолжается со следующей после wait конструкции с сохранением предыдущих значений локальных переменных метода. С точки зрения эффективности симуляции SC_METHOD является более быстрым вариантом SC_THREAD.

В SystemC вводятся следующие основные дополнительные типы данных:

• sc_string – строковое представление чисел в различных форматах (например, число -2 может быть представлено как -0d2 (десятичный), 0b1110 (4-х битный двоичный знаковый), 0b0010 (4-х битный двоичный беззнаковый));
• sc_int<N>, sc_uint<N> – знаковые и беззнаковые целочисленные типы заданной битовой ширины N;
• sc_bigint<N>, sc_biguint<N> – знаковые и беззнаковые целочисленные типы заданной битовой ширины N, превышающей длину значений типа int, который поддерживается на инструментальной машине;
• sc_fixed, sc_ufixed и др. – типы данных с фиксированной точкой
• sc_logic и sc_lv<N> – 4-х значный бит (1, 0, X, Z) и вектор таких битов соответственно.

Для облегчения описания взаимодействия модулей, кроме портов, в SystemC предлагаются более сложные каналы sc_mutex, sc_fifo и sc_semaphore.

Пример 4 иллюстрирует реализацию простого мультиплексора (см. рис. 1.4) на языке SystemC.

В отличие от VHDL и Verilog, в которых может использоваться интерпретатор описания для моделирования системы, в SystemC задается полная исполняемая модель, и описание на SystemC компилируется в исполняемый файл на инструментальной машине обычным компилятором C++ с использованием специальных библиотек SystemC. В начале симуляции модели, аналогично методу main в С, в SystemC управление передается в метод sc_main(argc, argv), в котором происходит инициализация модулей системы и, в конечном итоге, запуск параллельных процессов инициализированных модулей с помощью функции sc_start().

SC_MODULE (mux) {
public:
     sc_in  	c, d, e, f;
     sc_in  >	s;
     sc_out 	mux_out;

     SC_CTOR (mux) {
         SC_METHOD (do_mux);
         sensitive << c << d << e << f << s;
     }

     void do_mux () {
        sc_uint<2> temp_s = s.read();
        switch (temp_s) {
           case 0:  mux_out = c.read(); break;
           case 1:  mux_out = d.read(); break;
           case 2:  mux_out = e.read(); break;
           default: mux_out = f.read();
        }
     }
}

Пример 4. Простой мультиплексор на SystemC.

Поскольку спецификации аппаратуры на языках VHDL, Verilog и SystemC принципиально не содержат явного описания системы команд, кросс-инструменты поддержки разработки прикладных программ на уровне языка ассемблера (ассемблер, дисассемблер, компоновщик) для описанной таким образом аппаратуры не могут быть получены автоматизированным образом. Поэтому главным доступным кросс-инструментом для описанной на этих языках аппаратуры является симулятор.

Для VHDL и Verilog кросс-симуляторы представляют собой программы для инструментальной машины, которые автоматически настраиваются для моделирования целевой аппаратуры на основе HDL-описания. Для VHDL и Verilog используются как подходы с интерпретацией таких описаний, так и с компиляцией модели в код инструментальной машины. Для SystemC-моделей характерен подход с компиляцией. Для заданного начального состояния полученные модели способны моделировать поведение системы с очень высокой точностью (состояние отдельных регистров, буферов, сигналов, шин и т.п. с квантованием по тактам или даже по отдельным событиям). Каждый крупный производитель средств автоматизированной разработки аппаратуры (EDA) поддерживает собственные симуляторы для различных HDL-языков. Synopsis предлагает уже ставшую классической среду VCS [35], способную симулировать модели (в том числе смешанные) на всех трех основных языках - VHDL, Verilog и SystemC. Аналогичные смешанные симуляторы предлагаются компаниями Mentor Graphics (ModelSim [36]) и Cadence (NC-Sim [37], Incisive Verification Platform [38]). Все эти симуляторы поддерживаются интегрированными средами разработки и отладки моделей, в которых одним из основных средств визуализации отладки являются диаграммы изменения сигналов (waveforms).

Основной проблемой HDL-симуляторов является низкая скорость работы порядка 10-50 тыс. модельных тактов в секунду на современных рабочих станциях, в то время как типовой цикл моделирования алгоритмов цифровой обработки сигналов требует миллиарды тактов для обработки репрезентативного тестового сигнала. Такая скорость обусловлена высокой точностью моделирования на слишком низком уровне. Таким образом, скорость работы и отсутствие средств поддержки программирования на уровне системы команд делает применение HDL-симуляторов неприемлемым для эффективной разработки прикладных программ. Тем не менее, такие симуляторы играют важную роль в процессе дизайна и верификации самой аппаратуры.

Изначально ADL (Architecture Description Language) языки (см. обзоры [39-42]) начали появляться в начале 90-х в ответ на потребность в описании модели вычислительной аппаратуры на уровне явной системы команд для обеспечения раннего прототипирования встраиваемых микропроцессоров. Основу описания аппаратуры на ADL-языке составляет спецификация элементов состояния системы (регистры, память) и соответствующей системы команд, осуществляющей вычислительные операции над этими элементами. Основным фактором эффективного использования ADL в процессе проектирования аппаратуры является возможность автоматической генерации необходимых кросс-инструментов (прежде всего, симулятора и ассемблера) для обеспечения моделирования заданных тестовых программ на том или ином варианте аппаратуры. Процесс конструктивного исследования различных проектных альтернатив при проведении предварительного дизайна аппаратуры является наиболее типичным местом эффективного применения ADL-решений. Исходя из прикладных требований, архитектор выполняет разбиение задач на аппаратно и программно реализуемые части (SW/HW partitioning – см. разд. 1), то есть решает, какие функции следует заложить в виде аппаратной реализации, а какие – в виде прикладных программ. Программная реализация функций обеспечивает большую гибкость и минимизирует аппаратные ресурсы (что приводит к меньшей площади кристалла, меньшему энергопотреблению и стоимости), однако, с другой стороны, существуют ограничения на производительность реального времени, которую во многих случаях программная реализация обеспечить не может (а повышение тактовой частоты ведет к ухудшению упомянутых параметров). Ясно, что теоретически существует некий оптимальный баланс между программной и аппаратной реализацией для конкретного класса алгоритмов, нахождением которого собственно и занимается архитектор на этапе проектирования. Однако ввиду того, что процесс разбиения задач между аппаратурой и программами носит эвристический характер на основе грубых оценок, необходима экспериментальная проверка корректности и эффективности различных вариантов. Для этой цели используют симуляцию тестовых программных задач на подразумеваемом аппаратном обеспечении (в виде симулятора). Вот почему наличие быстро обновляемого инструментария кросс-разработки очень важно на этом этапе, и ADL-решения наиболее подходят для достижения упомянутой цели.

Процесс использования ADL-решения начинается с описания общей архитектуры предполагаемой системы на формальном языке с фокусом на системе команд. Можно построить данный процесс на основе имеющихся библиотек решений, которые дизайнер может лишь слегка изменять вместо того, чтобы создавать заново. Инструменты поддержки должны уметь проверять целостность и корректность созданного описания. При корректном описании автоматически генерируется инструментарий кросс-разработки, с помощью которого конструктор может оценить ключевые параметры производительности предполагаемой системы и решить, насколько текущая архитектура удовлетворяет необходимым критериям. Среди критериев, анализируемых путем выполнения, профилировки и отладки программ, можно выделить семантическую корректность результата, производительность, энергопотребление, степень использования системы команд и внутренних аппаратных компонентов (регистров, функциональных единиц, шин) во время выполнения заданных приложений. Если какие-то параметры неудовлетворительны, то на основе полученной информации выявляются узкие места и принимаются решения по изменению аппаратуры (изменению системы команд и пересмотру баланса между аппаратурой и программным обеспечением). Данные изменения вносятся в ADL-описание и программы, и процесс повторяется. Таким образом, основными преимуществами ADL являются быстрота описания модели системы (за счет использования более высокоуровневых абстракций, чем в HDL) и автоматическая генерация инструментария кросс-разработки, что обеспечивает быструю оценку параметров различных вариантов аппаратуры на этапе проектирования.

Если все критерии соблюдены, то происходит детализация описания системы и начинается процесс детальной разработки. Некоторые ADL-решения поддерживают синтез шаблонов на HDL-языках, обеспечивая плавный переход к производственной доработке аппаратуры в системах проектирования аппаратного обеспечения.

Рассмотрим наиболее успешные ADL-языки и соответствующие инструменты более подробно.