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

В этой я расскажу о синтезируемом подмножестве SystemC, сравнивая его с синтезируемым SystemVerilog. Сам я пользуюсь SystemC уже где-то 3 года, а до этого несколько лет писал на Verilog/SystemVerilog. Попытаюсь охватить предмет с разных сторон: начиная с философских рассуждений о причинах возникновения SystemC, краткого обзора экосистемы и инструментария и заканчивая практическими примерами синтаксиса и семантики.

Подразумевается, что читатели знакомы с Verilog и C++.

Размышления о причинах возникновения SystemC

За свою длинную историю индустрия разработки электроники нашла применение множеству языков программирования и породила огромное количество DSLей (Domain-specific languages). Если представить себе гипотетического full-stack аппаратчика (по аналогии с full-stack веб-программистом), который в одиночку может спроектировать современную микросхему, от алгоритма до реализации в кремнии, то ему помимо знания матчасти (арихитектура эвм, электроника, алгоритмы из прикладной области и др.) придется владеть целой кучей разнообразных языков: Matlab для разработки алгоритмов, Verilog или VHDL для описания RTL модели, SystemVerilog/E/Vera для написания тестов и тестового окружения, TCL для написания скриптов управляющих САПР пакетами, SPICE/Verilog-AMS для моделирования аналоговых подсистем, SKILL или Python для генерации топологий, Си/Asm для написания всевозможного firmware. При желании список можно продолжать и дальше.

Конечно в природе такие универсальные инженеры практически не встречаются и проект делают несколько команд, каждая из которых хорошо разбирается в своей достаточно узкой области. Однако, очень часто приходится совмещать работу на нескольких этапах разработки. К примеру, легко представить, что человек написавший RTL модель IP блока напишет для него и набор тестов для верификации. Это в свою очередь создает запрос на создание универсальных языков, пригодных для решения смежных задач.

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

Но что если мы хотим большего? Язык на котором помимо всего вышеперечисленного можно разрабатывать алгоритмы, писать встроенное ПО, создавать виртуальные прототипы. Не пора ли добавить к SystemVerilog еще пару DSL?


We need to go deeper

Существует однако и другой подход: вместо придумывания всё новых DSLей, можно создавать программные библиотеки, предназначенные для решения специального класса задач. Таким путём пошли создатели SystemC — библиотеки для C++, позволяющей моделировать цифровую аппаратуру. Хотя в каком-то смысле SystemC является DLS’ем, созданным средствами метапрограммирования на C++, сам C++ при этом не расширяется новыми синтаксическими конструкциями. Метапрограммирование широко применяется и в других C++ библиотеках.

У такого подхода существуют свои плюсы и минусы. Основной плюс C++ в его универсальности: сегодня ты можешь писать хардвер на SystemC, а завтра GUI на Qt. (Хотя придется потратить достаточно много времени на изучение каждой из этих библиотек). Основной минус в синтаксисе: код на чистом DSL будет намного красивей, особенно если нужно сделать что-то простое (для простых модулей код на Verilog будет компактней и проще, чем аналогичный код на SystemC).

Помимо недостаточной универсальности у Verilog есть и другая проблема: он очень низкоуровневый. В каком-то смысле синтезируемый Verilog это макроассемблер для аппаратуры ( если ассемблер для аппаратуры это логическая схема). Новые конструкции, появившиеся в синтезируемом SystemVerilog не решают эту проблему низкоуровневости. Очень часто приходится прибегать к использованию всевозможных генераторов кода на Verilog, например скриптов на Python. Среди моих коллег популярной была идея вставлять код на Perl внутрь модулей на Verilog. Полученный таким путём гибрид назвали перлилогом. Думаю многие знакомы с Verilog-mode для emacs, который умеет генерировать Verilog код для соединения модулей.

По сравнению с SystemVerilog, синтезируемый SystemC позволяет гораздо больше. Да, вы можете писать синтезируемый код с классами! При решении сложных задач средства абстракции C++ позволяют писать более элегантный (простой и компактный) код.

Экосистема SystemC

Рассмотрим основные программные инструменты, с которыми приходится иметь дело разработчикам на SystemVerilog и SystemC.

Среда разработки

SystemVerilog:
Большинство программистов на Verilog для написания кода используют текстовый редактор: поддержка Verilog есть в Vim, Emacs, Sublime Text, Notepad++, Slickedit и других популярных редакторах. Прикладным программистам написание кода в тестовом редакторе может показаться архаизмом: большинство из них используют умные IDE с авто-подсказками, автоматизированными рефакторингами, удобной навигацией. Однако в мире синтезируемого Verilog огромной пользы от использования IDE нет: это объясняется тем что вся функциональность разбивается на совершенно независимые друг от друга модули. Весь контекст с которым работает разработчик отдельного модуля обычно умещается в один файл. Совсем другое дело с написанием тестбенчей на SystemVerilog, здесь вполне может пригодится IDE, такая как DVT.

SystemC:
При написании синтезируемого C++/SystemC простым текстовым редактором уже не обойтись. К счастью, существует множество C++ IDE (в том числе и бесплатных), которые в состоянии справиться с кодом на SystemC. Например, можно использовать привычную многим MS Visual Studio. Я долгое время пользовался Eclipse CDT и Netbeans для написания кода на C++/SystemC. Последнее время пробую Clion от Jetbrains.
Написание SystemC кода в Clion

Симуляция и отладка

SystemVerilog:
Для симуляции и отладки кода на Verilog используется HDL симулятор. Существуют как бесплатные (IcarusVerilog), так и платные симуляторы. По сравнению с бесплатным симулятором коммерческие решения обеспечивают большую скорость симуляции и предоставляют удобные графические среды для отладки.

SystemC:
C SystemC ситуация в целом похожа: можно использовать референсный симулятор и GDB для отладки, но когда нужно отлаживать какой-то более-менее сложный сигнальный протокол приходится пользоваться одним из коммерческих симуляторов.

Отладка SystemC в симуляторе

Синтез

SystemVerilog:
Синтез SystemVerilog поддерживается основными FPGA и ASIC вендорами. В том числе существуют и бесплатные версии пакетов для FPGA, чем пользуются многие российские вузы для обучения студентов азам цифровой схемотехники.

SystemC:
Для синтеза SystemC используются специальные пакеты высокоуровневого синтеза (англ. High-level Synthesis, HLS). Что в них такого высокоуровневого спросите вы? Всё дело в том, что HLS пакеты, помимо традиционного RTL кода написанного на SystemC умеют синтезировать и чисто поведенческий (“untimed”) код, автоматически вставляя регистры, там где это необходимо.

Большинство HLS пакетов могут синтезировать и чистый C/C++, SystemC используется только в тех случаях, когда нужно добавить модульность и сигнальные интерфейсы. В каком-то смысле синтез с C/C++ является технологией для разработки акселераторов, конкурирующей с синтезом с OpenCL. Хотя при использовании SystemC мы не ограничены только разработкой акселераторов, а можем разрабатывать совершенно любые цифровые схемы. Чуть позже я расскажу про HLS немного подробнее.

На выходе HLS пакета мы обычно имеем привычные RTL модули на Verilog, которые затем синтезируются с помощью Verilog синтезатора.

К сожалению, все существующие HLS с поддержкой SystemC исключительно коммерческие и стоят много денег. Бесплатных версий нет, хотя университетам всё продают с большой скидкой.
Лучшими средствами синтеза SystemC на рынке являются Stratus от Cadence и Catapult C от Calypto/Mentor Graphics.

Другие EDA пакеты для SystemC

Помимо написания синтезируемого кода, SystemC достаточно широко используется для виртуального прототипирования. Создание виртуальных прототипов (эмуляторов) на C++/SystemC используется в пакетах Synopsys Virtualizer, Mentor Graphics Vista, Cadence Virtual System Platform. При этом нельзя сказать что SystemC на этом рынке является доминирующим решением: существуют и продукты SystemC не использующие, например WindRiver Simics.

На этом обзорная часть статьи завершается. Пришло время погрузиться в код.


Погружение в код

Синтезируемый SystemC. Базовые строительные блоки

Не буду здесь полностью описывать весь стандарт SystemC, пройдусь только по самому необходимому. Все примеры будут построены на сравнении SystemVerilog и SystemC.

Типы данных

SystemVerilog:
Основным типом используемым в синтезируемом SystemVerilog является тип logic. Переменная типа logic может принимать 4 значения: 1, 0, x, z. x означает неизвестное значение. z означает высокоимпедансное состояние. Можно создавать вектора типа logic различной длины, например:

logic [1:0] data; // 2-х битный вектор
initial begin
	data = 7;
	$display(data);
end

Выведет в консоль:3

SystemC:
В SystemC тоже есть типы с 4-мя состояниями. Однако на практике в основном используются типы с 2-мя состояниями 1 и 0. Основная причина — типы с 2-мя состояниями симулируются быстрее.

После синтеза все типы с 2-мя состояниями превращаются в logic. Это может привести к различиям в результатах симуляции SystemC (до синтеза) и Verilog (после синтеза). В SystemC не сброшенный регистр будет иметь значение 0, в Verilog — x. К счастью, синтезатор выдает предупреждение каждый раз когда видит регистр без сброса, поэтому на практике после чтения лога синтезатора проблем с расхождением результатов симуляции можно избежать.

Очень часто в коде на SystemC используются встроенные типы C++, такие как int или char. Если же нам требуется число с заданным количеством бит, можно использовать тип sc_uint:

sc_uint<2> data;  // 2-х битная переменная
data = 7;
cout << data;

Выведет в консоль:3

Как реализован sc_uint? Это просто шаблонный класс в котором перегружены все основные операторы.

Модули

Рассмотрим пример пустого модуля на SystemVerilog и SystemC
SystemVerilog:

module top (
input clk, rstn,
input [7:0] din,
output logic  [7:0] dout
)

// тело модуля
endmodule

SystemC:

struct top: public  sc_module {
   sc_in<bool>         clk, rstn;
   sc_in<sc_uint<8> >  din;
   sc_out<sc_uint<8> > dout;

   top(const char* name) : sc_module(name) , clk("clk") , rstn("rstn") , din("din"), dout("dout")
   {  }
  
};

Разберем интересные строки подробнее:

struct top: public  sc_module {

модули в SystemC это производные классы от класса sc_module

   sc_in<bool>         clk, rstn;
   sc_in<sc_uint<8> >  din;
   sc_out<sc_uint<8> > dout;

Для создания портов в SystemC используются специальные классы sc_in и sc_out.

   top(const char* name) : sc_module(name) , clk("clk") , rstn("rstn") , din("din"), dout("dout")

Конструкторам модуля и портов передаются строки содержащие их имя. Это нужно для того чтобы симуляционное ядро могло выдавать удобные для чтения логи, например:
Error: (E109) complete binding failed: port not bound: port 'top.dout' (sc_out)
Ошибка: порт dout модуля top никуда не подключен.
( Возможно, когда в C++ появится нормальная поддержка интроспекции объекты в SystemC смогут узнавать свои имена самостоятельно )
Для удобства создания модулей в SystemC определено несколько макросов. С их использованием аналогичный модуль выглядит следующим образом:

SC_MODULE(top) {

   sc_in<bool>         clk, rstn;
   sc_in<sc_uint<8> >  din;
   sc_out<sc_uint<8> > dout;

SC_CTOR(top) , clk("clk") , rstn("rstn") , din("din"), dout("dout") {}
};

Переменные и присваивания

SystemVerilog:
Можно утверждать что все переменные в синтезируемом SystemVerilog- статические: они существуют с начала и до конца симуляции. И имеют глобальную область видимости (хотя доступ к сигналам “через крышу” по иерархическому имени не допускается в синтезируемом коде). Еще одной особенностью SystemVerilog является наличие нескольких операторов присваивания: блокирующего и неблокирующего присваивания в процедурных блоках, а так же непрерывного присваивания.
Блокирующее присваивание происходит либо сразу, либо блокирует исполнение текущего процесса до момента когда присваивание совершится.
Пример:

logic  a;
initial begin
	a = #42 1;
	$display($time);
end

Выведет в консоль:42
т.к. вызов функции $display произойдет лишь в момент времени 42, когда присваивание произойдет.
Неблокирующее присваивание откладывает присваивание на какой-то момент симуляционного времени в будущем и не блокирует исполнение процесса. Если время не указано явно, присваивание происходит на следующем дельта-цикле.

initial begin
	a <= #42 1;
	$display($time);
end

Выведет в консоль: 0

SystemC:
Переменные в C++ ничего не знают про симуляционное ядро SystemC и поэтому ведут себя привычным для C++ программиста образом. Для того чтобы промоделировать неблокирующее присваивание в SystemC используется специальный тип sc_signal, переменные этого типа далее называются сигналами:

sc_signal< sc_uint<2> > data;  // сигнал типа sc_uint<2> 

Любое присваивание значения data будет неблокирующим.
Синтезируемый SystemC требует, чтобы взаимодействие между несколькими процессами происходило через сигналы. Аналогично, в Verilog хорошим стилем является использование исключительно неблокирующих присваиваний в always_ff процедурных блоках. В противном случае рискуем получить неопределенное поведение (состояние гонки), когда результат симуляции будет зависеть от порядка вызова процессов в одном дельта цикле.
Аналога блокирующего присваивания в SystemC нет.

Процессы (Процедурные блоки)

SystemVerilog :
Синтезируемый SystemVerilog поддерживает два основных типа процедурных блоков always_comb и always_ff. Помимо них есть еще always_latch, но использовать регистры-защелки на практике приходится довольно редко.
always_comb используется для описания комбинаторной логики

always_comb 
begin
	a = b + c;
end

Процесс будет исполняться каждый раз, когда изменяется значение b или c. То же самое можно было бы написать более явно, как в классическом Verilog:

always@(b or c)
begin
	a = b + c;
end

Помимо процедурного блока always_comb для описания комбинационных схем можно использовать оператор непрерывного присваивания:

assign a = b + c;

Процедурный блок always_ff используется для описания последовательностной логики, т.е. схем с памятью.

always_ff @(posedge clk or negedge arst_n) begin
	if(~arst_n) begin
    	    a <= 0;
	end 
        else begin
    	    a <= a + 1;
	end
end

Этот пример описывает двоичный счетчик с асинхронным сбросом.

SystemC:

Процессы в SystemC создаются в конструкторе модуля. Тело процессов описывается в функциях-членах модуля. Тип процесса похожего на always блок из Verilog в SystemC называется SC_METHOD.
Рассмотрим примеры процессов, аналогичные приведенным ранее процедурным блокам на SystemVerilog:
Комбинаторная логика:

SC_CTOR(top) {
	SC_METHOD(comb_method);    // макрос для создания процесса типа SC_METHOD
	sensitive << b << c;   // список чуствительности  (аналог @(a or b) )
}

void comb_method() { a = b + c;  }        // тело процесса описывается в функции-члене 

Последовательностная логика:

SC_CTOR(top) {
	SC_METHOD(seq_method);  // макрос для создания процесса типа SC_METHOD
	sensitive << clk.pos() << arst_n.neg();  // список чуствительности ( @(posedge clk or negedge arst_n)  )
}

void seq_method() {  // тело процесса описывается в функции-члене 
if (!arst_n) 
    a = 0;  
 else
    a = a + 1; 
}

Аналога непрерывного присваивания в SystemC нет. Так же как и нет возможности указать wildcard в списке чувствительности ( always@* в Verilog). Даже мощная шаблонная магия C++ не позволяет реализовать это средствами метапрограммирования.

Параметризация

Модули на SystemVerilog можно параметризовать. К примеру, можно написать параметризуемое FIFO, ширина и глубина которого будут указываться при создании экземпляра.

В SystemC для создания параметризуемых модулей используются шаблонные классы. С использованием шаблонов и наследования возможности по параметризации в SystemC становятся почти безграничными.

Промежуточные итоги

SystemC позволяет описывать аппаратуру на уровне RTL в стиле очень близком к простому Verilog. Код на Verilog будет изящней и компактней, но в целом всю функциональность можно повторить. Рассмотрим полноценный пример: реализуем на Verilog и SystemC сдвиговый регистр с последовательным входом и выходом (serial-in/serial-out) и асинхронным сбросом:
Код на Verilog:

module shifreg (
     input clk, sin, reset,
     output sout
); 

reg [7:0] tmp; 
 
always @(posedge clk or posedge reset)    begin 
    if (reset) 
        tmp <= 0; 
    else 
        tmp <= {tmp[6:0], sin}; 
end

assign sout = tmp[7]; 

endmodule

Код на SystemC

// Для сигналов и портов используется инициализация в стиле C++11

SC_MODULE(shift_reg) {
    sc_in<bool> clk{"clk"}, sin{"sin"}, reset{"reset"};
    sc_out<bool> sout{"sout"};

    SC_CTOR(shift_reg) {
        SC_METHOD(shift_method);
        sensitive << clk.pos() << reset.pos();
        // т.к. непрерывного присваивания нет, приходится создавать процесс
        SC_METHOD(sout_method);         
        sensitive << tmp; 
     }

private:

    sc_signal <sc_uint<8> > tmp {"tmp"};

    void shift_method() {
	 // для чтения и записи сигналов используются методы read и write
	 // метод write - аналог неблокирующего присваивания в verilog
        if ( reset.read() ) {
            tmp.write(0);
        } else {
            // перегруженный оператор "," (запятая) используется для конкатенации
            tmp.write((tmp.read().range(6,0) , sin.read()));   
        }
    }

    void sout_method() {
        sout = tmp.read()[7];
    }

};

Хороший SystemC. Возможности синтезируемого SystemC, которых нет в SystemVerilog

Пользовательские типы данных

Синтезируемый SystemC полностью поддерживает объектно-ориентированное программирование на C++. Это позволяет создавать удобные типы данных для работы в своей предметной области. Например, если вы занимаетесь 3D графикой, то вам постоянно приходится иметь дело с 3-х мерными вещественными векторами. Для их аппаратной реализации потребуется решить несколько задач.
Во первых, операции с плавающей точкой как правило не поддерживаются синтезатором. Поэтому вам придется реализовать их самостоятельно, или использовать стороннюю библиотеку, например DesignWare floating point. И в том и в другом случае вы можете создать удобный класс для работы с плавающей точкой:

class my_float  {
public:
	my_float operator+( const my_float &rval) const;
	my_float operator-( const my_float &rval ) const;
	my_float operator*( const my_float &rval ) const;
	// и другие операции ...
private:
	sc_uint<32> raw_data;  // внутри себя float это простой 32-битный вектор
} 

С использованием my_float можно реализовать класс для работы с векторами:

class vector_3d {
public:
	vector_3d operator*( const vector_3d &rval ) const; // vector product
	vector_3d dot_product (const vector_3d &other) const; // dot product
 	// и другие операции ...
private:
	my_float x, y, z;
};

После чего эти пользовательские типы можно использовать в синтезируемом SystemC.

vector_3d a,b,c;
c = a + b;

Синтезаторы SystemVerilog не поддерживают синтез классов, но умеют синтезировать структуры. Поэтому программирование на SystemVerilog чем-то напоминает программирование на языке Си. На SystemVerilog эта задача с векторами обычно решается следующим образом: вы создаете отдельный пакет, а в нём определяете структуры и функции для работы с ними:

package Vector3DPkg;
typedef struct {
logic [31:0] x, y, x;
} vector_3d;

function vector_3d add(vector_3d a, b);
add.x = float_add (a.x, b.x);  
add.y = float_add (a.y, b.y);  
//...
endfunction

function vector_3dmul(vector_3d a, b);
//....

endpackage : Vector3DPkg

SC_CTHREADS (clocked threads). Процессы с неявным состоянием

Синтезируемые процессы в Verilog не могут использовать выражения для управления временем и ожидания событий. Т.е. запущенный процесс должен исполниться до конца и только потом передать управление другому процессу. К примеру, данный процесс не синтезируется:

always @(posedge clk)
begin
    out <= 1;    
    @(posedge clk); // ожидание события не синтезируется
    out <= 2;
    @(posedge clk); 
    out <= 42;
end

В Verilog мы должны явно специфицировать регистр состояния, который будет определять поведение процесса на каждом такте. Синтезируемым аналогом предыдущего примера кода будет следующий процесс:

logic [1:0] state;  

always @(posedge clk or negedge reset_n)
begin
    if ( ~ reset_n)
	state <= 0;
	out <= 1;
    else 
case (state)
    0: begin
    	state <= 1;
        out <= 1;
    end
   1: begin
	state <= 2;
        out <= 2;
    end
    2: begin
	state <= 0;
        out <= 42;
    end
end

В SystemC синтезируемые процессы описывающие последовательностную логику (цифровой автомат) могут останавливаться на ожидании события от тактового сигнала. Это позволяет описывать автомат без явной спецификации регистра состояния. Процессы такого типа создаются с помощью макроса SC_CTHREAD. Остановка процесса до следующего тактового сигнала осуществляется путём вызова функции wait(); Пример:

SC_CTOR ( top ) {
	// процесс создается в конструкторе
        // clk.pos() означает тактирование по переднему фронту сигнала clk
	SC_CTHREAD(test_cthread,  clk.pos() );
	async_reset_signal_is(reset_n, 0);  // асинхронный сброс по уровню 0
}

void test_cthread () {
      // код до первого вызова wait() называется reset-секцией, выполняется при запуске процесса или при активном сигнале сброса.
      out <= 1;
      wait(); 

     // в отличии от SC_METHOD, SC_CTHREAD не должен завершаться никогда
     // поэтому в теле процесса всегда есть бесконечный цикл
     while (1) { 
           out.write(1);
           wait (); // ожидание переднего фронта на clk

           out.write(2);
           wait (); // ожидание переднего фронта на clk

           out.write(42);
      }
}

На первый взгляд польза от наличия таких процессов не очевидна. В конце концов не так уж и сложно явно закодировать переменную для состояния цифрового автомата (переменная state в примере на Verilog).
Истинная мощь SC_CTHREAD процессов заключается в возможности вызова функций, которые могут заблокировать процесс, т.е. вызывать функцию wait(). Такая функция может исполняться несколько тактов! Аналогом из мира Verilog являются task’и, они однако не синтезируются и используются только в тестах.
Например:

while (1) {
res = calculate_something(); // несколько тактов занимаемся какими-то вычислениями
spi_send(res); // отправляем результат по SPI, тоже за несколько тактов
}

Ещё больше пользы от функций, исполнение которых иногда занимает несколько тактов, а иногда происходит мгновенно, без вызова wait().
Для примера рассмотрим процесс, который читает данные из FIFO, обрабатывает их, после чего отправляет результат в память по системной шине (например, AMBA AXI). Пускай данными будет 3-х мерный вектор рассмотренный раннее, а обработка будет заключаться в нормализации этого вектора. С использованием SC_CTHREAD и готовых классов для работы с FIFO и AXI написать такой процесс очень просто:

fifo  data_fifo; // экземпляр FIFO
amba_axi bus_master; // реализация мастера шины AMBA AXI

void computational_thread() {
wait();
while (1) {
	vector_3d vec = data_fifo.pop();  // читаем данные из FIFO
	vec.normalize();     	    	    // обрабатываем данные
	bus_master.write( 0xDEADBEEF,  vec); // отправляем результат в память по адресу 0xDEADBEEF
}

Предположим что нормализация вектора реализована в виде комбинационной схемы. Тогда, в зависимости от готовности FIFO и шины, исполнение одного цикла такого процесса может занимать от одного такта и более. Если в FIFO есть данные и шина не занята, то нормализация одного вектора будет происходить за такт. Если FIFO пустое, то процесс заблокируется на функции чтения из FIFO data_fifo.pop до момента поступления новых данных. Если шина занята, то процесс заблокируется на функции bus_master.write до момента когда шина освободится.

У опытного разработчика наверняка возник вопрос, как мы делаем нормализацию вектора за такт? На какой частоте работает наш модуль? Действительно, цепочка из умножения, двух сложений, квадратного корня и деления это слишком много для одной комбинационной схемы. Тем более что речь идет об операциях с плавающей точкой. В случае синхронной схемотехники эта комбинационная цепочка наверняка станет узким местом, ограничивающем максимальную тактовую частоту работы всей схемы.

В зависимости от требований к пропускной способности нашего нормализатора проблема может быть решена несколькими способами:

• Если мы никуда не торопимся, то можно сэкономить на ресурсах и реализовать нормализацию в виде FSMD с одним умножителем, сумматором, делителем и модулем извлечения квадратного корня. В этом случае мы потратим 6 тактов на вычисление длины вектора и еще 3 такта для вычисления значения каждого из элементов результата, в сумме — 9 тактов на один вектор.
  
  
• Если мы сильно торопимся, а ресурсов не жалко, оригинальную комбинационную схему можно превратить в конвейер. В этом случае в пике (когда в FIFO постоянно есть данные) мы получим тот же 1 такт на вектор, но уже на большей тактовой частоте.
  
  
• Так же возможны любые промежуточные между первым и вторым варианты. К примеру, если логика дорогая а регистры дешевые, то в первом рассмотренном варианте микроархитектуры можно начинать обработку следующего вектора не дожидаясь завершения выполнения предыдущего, по мере освобождения ресурсов. После вычисления трех квадратов элементов первого вектора, умножитель освобождается и можно начинать обработку следующего вектора. Такая реализация называется конвейером с интервалом инициализации в 3 такта. Т.е. каждые три такта конвейер будет забирать из FIFO новый вектор.

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

Высокоуровневый синтез.

Высокоуровневый синтез это процесс трансформации алгоритмического кода написанного на высокоуровневом языке программирования в цифровую аппаратуру его реализующую. На вход HLS пакета подаются:

• Исходный код. Иногда его называют untimed code, т.к. он не содержит конструкций для остановки процесса, таких как функция wait
• Timing constraints. Временные ограничения. Задают список тактовых сигналов и их период, а так же задержки на внешних портах
• Спецификация микроархитектуры. В качестве микроархитектуры мы можем выбрать любой из рассмотренных ранее вариантов

В нашем примере мы хотим подвергнуть высокоуровневому синтезу функцию нормализации вектора:

void vector_3d::normalize() {
	my_float magnitude = sqrt( x*x + y*y + z*z );
	x = x / magnitude;
	y = y / magnitude;
	z = z / magnitude;
}

В качестве микроархитектуры можно например выбрать конвейер с интервалом инициализации в 1 такт и задержкой (latency) в 4 такта, а тактовую частоту установить в 500 МГц. Используя технологическую библиотеку HLS пакет определит задержку распространения сигнала через каждый арифметический элемент и оптимально расставит их по стадиям конвейера. При необходимости, выполнение одной операции может быть разбито на несколько стадий: например деление это достаточно сложная операция, выполнение которой может и не влезть в один тактовый период. Поэтому вполне возможно, что синтезетор разобьет делитель между 3ей и 4ой стадией конвейера.

Анализ проекта в HLS пакете от Cadence

Опытные пользователи средств логического синтеза знают что некоторые из них (например Deisgn Compiler) обладают похожей функцией, которая называется ретайминг (retiming). В сравнении с ретаймингом HLS обладает несколькими преимуществами:

• Не требуется руками специфицировать регистры, логику остановки конвейера.
• HLS позволяет переключаться между несколькими микроархитектурами не меняя исходный код.

Еще одной интересной особенностью HLS является работа с памятью. Абстракцией памяти в HLS является обычный массив. От нас лишь требуется указать синтезатору библиотеку доступных в техпроцессе памятей. Например, можно переделать наш пример таким образом, чтобы результат не отправлялся по шине AXI, а записывался напрямую в память:

uint32_t write_address;  // 32-битный адрес
vector_3d  memory[1024]; // память 1024x96  , каждый вектор - 96 бит
....
while (1) {
	vector_3d vec = data_fifo.pop();  // читаем данные из FIFO
	vec.normalize(); // обрабатываем данные
	memory [write_address] = vec; // записываем результат в память
	write_address ++;
}

Хочется также отметить что не все HLS средства поддерживают синтез с SystemC. Использование SystemC требуется лишь там, где необходимо описывать сигнальные интерфейсы (например AMBA или UART). На FPGA платформах шинные интерфейсы как правило стандартизированы, поэтому их использование в HLS коде может быть неявным. К примеру, Vivado HLS от Xilinx ориентирован прежде всего на синтез с чистого C/C++. В рамках SoC платформы Xilinx стандартом является интерфейс AMBA AXI, поэтому предполагается что отправлять и получать данные ваши функции будут по AXI, либо с помощью простого handshake протокола. Всё что от вас требуется — описать алгоритмический код. Конечно у такого подхода есть и свои недостатки: при создании сложных проектов вы вполне можете прийти к склеиванию множества HLS модулей в коде на Verilog или графическом редакторе схем. Для этих целей у Xilinx есть еще один продукт — Vivado IP Integrator.

Соединение HLS блока с ARM процессором через AMBA AXI в Vivado IP Integrator

Заключение

В качестве заключения хочу попробовать ответить на вопрос который часто задают RTL разработчики увидев новый тул: А что с качеством результата? Как будут отличаться тайминги, площадь, энергопотребление схем описанных на SystemC и синтезированных с помощью HLS в сравнении с RTL описанным на SystemVerilog?

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

В этой статье я никак не коснулся вопроса верификации. Верификация всегда занимает большую часть времени разработки и SystemC есть что предложить на этом поприще. Хорошо написанный SystemC стимулируется быстрее чем RTL, т.к. часть кода написана в “untimed стиле”, а сигнальные интерфейсы можно заменить на вызовы функций (Transaction-level modeling). Библиотека SCV (SystemC Verification Library) позволяет рандомизировать тестовые вектора, так же на подходе SystemC версия UVM. А т.к. SystemC это C++, то части исходного кода можно переиспользовать между синтезируемым кодом, референсной моделью, виртуальным прототипом и драйвером операционной системы. Но рассказ обо всём этом достоин отдельной статьи.