Verilog

Светодиоды типа WS2812 очень популярны, ими удобно управлять, передавая по одному проводу команды для сотен светодиодов. Они имеют, с одной стороны, очень простой протокол, а с другой стороны, в микроконтроллерах нет аппаратных интерфейсов для этого протокола и его приходится формировать программно управляя выводом микроконтроллера. В этой статье я расскажу, как с помощью UDB микроконтроллеров серии PSOC 4 и PSOC 5LP компании Infineon сделать периферийный модуль для управления этими светодиодами.

Компонент UDB позволяет создавать достаточно сложные аппаратные модули. Данные модули можно проектировать несколькими разными способами: нарисовать схему, нарисовать блок-схему машины состояний, а также, описать с помощью языка высокого уровня Verilog. Я буду использовать язык Verilog, так как он позволяет воспользоваться всеми возможностями UDB.

На данном рисунке показана блок-схема микроконтроллера PSOC 5LP Family.

На рисунке виден блок Universal Digital Block Array, который связан через внутренние шины Digital Interconnect и System Bus со всеми компонентами микроконтроллера.

Для того чтобы начать разработку, необходимо скачать и установить PSOC Creator. Эта IDE абсолютно бесплатна, работает как с компилятором GCC, так и Keil.

После установки и запуска вы увидите стартовую страницу.

Нажимаем File->New->Project и попадаем в окно создания нового проекта.

В этом окне необходимо выбрать целевое устройство. Это может быть оценочная плата, например, CY8CKIT-059. Но чтобы эта плата появился в списке, необходимо скачать и установить соответствующий пакет.

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

Следует заметить, что микроконтроллеры PSOC 4 и PSOC 5LP могут работать в диапазоне напряжений питания от 1.7 до 5.5 вольт. Таким образом, мы сможем напрямую подключить микроконтроллер к светодиоду WS2812 без дополнительного буфера.

Выбираем оценочную плату CY8CKIT-059, жмем Next>. В следующем окне надо выбрать то, с чего мы начнем разработку. Это может быть один из примеров, пустой проект или один из предварительно сохраненных шаблонов. Выбираем пустой проект.

Жмем Next>, в следующем окне надо выбрать имя проекта, место его расположения и имя рабочего пространства.

Нажимаем кнопку Finish и попадаем на закладку схемы проекта.

На панели слева, двойным щелчком, можно открыть файл main.c. Мастер создания нового проекта уже наполнил минимально необходимым содержимым этот файл.

Нажав SHIFT+F6 можно скомпилировать проект, компиляция должна пройти без ошибок.

Для создания нового компонента на вкладке слева жмем закладку Components.

Затем щелкаем правой клавишей на строчке Project и выбираем пункт меню Add Component Item.

Первое, что нам нужно создать, это символ компонента. Поэтому выбираем пункт Symbol Wizard, прописываем имя компонента, Cypress рекомендует включать номер версии в имя компонента таким образом Имя_компонента_v1_0, цифры 1_0 в дальнейшем можно изменять в зависимости от версии компонента.

Нажимаем Create New и попадаем в мастер создания символа компонента, где создаем четыре вывода: вход тактового сигнала, асинхронного сброса, выход для управления светодиодами и выход сигнала прерывания или DMA, который будет устанавливаться в 1 при опустошении буфера FIFO. Выводимые данные мы будем записывать в оперативную память, поэтому на схеме нет выводов для входных данных.

Жмем OK и попадаем на вкладку с созданным символом. Щелкаем на пустом месте листа правой клавишей мыши и выбираем пункт PROPERTIES.

Здесь нам нужно ввести два имени Doc.ApiPrefix и Doc.DefaultInstanceName.

Жмем OK, затем снова щелкаем правой клавишей мыши на пустом месте листа символа и выбираем пункт меню Generate Verilog:

Тут просто нажимаем кнопку Generate.

Двойным щелчком открываем Verilog файл.

Затем выбираем пункт меню Tools->DataPath Config Tool.

В DataPath Config Tool открываем только что созданный Verilog файл.

Теперь нам нужно добавить DataPath в наш Verilog файл. Выбираем пункт меню Edit->New DataPath.

В этом окне нам нужно ввести имя Datapath и выбрать разрядность DataPath, 8 бит нам будет достаточно.

Мастер создал Datapath, заполненный значениями по умолчанию:

Область 1 это 8 команд, которые может выполнять DataPath. Область 2 это маски. Область 3 настройка режима работы элементов Datapath.

Настал момент, когда нам надо разобраться с тем, как устроен и работает этот самый DataPath. UDB состоит: из блока тактовых сигналов, асинхронного сброса, регистра Status для чтения состояния и регистра Control для записи управляющих сигналов UDB.

Также в него входят две PLD матрицы на 12 входов и 4 выхода.

И сердцем UDB является DataPath. Можно сказать, что это очень примитивный микроконтроллер. У него есть: ALU, память программ из восьми ячеек, четыре регистра общего назначения, два буфера глубиной четыре байта организованных как FIFO, сдвиговый регистр, две маски, а также два блока сравнения и два блока проверки на равенство 0x00 и 0xFF регистров A0, A1. Следует также добавить, что эти блоки можно объединять и организовывать 16, 24, 32 битную обработку данных. Микроконтроллер может писать и читать, как в регистры A0,A1,D0,D1, так и в FIFO.

В datasheet к светодиоду WS2812 указаны следующие требования к временных характеристикам сигнала.

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

Рисуем блок схему для нашего модуля состоящую из 8 состояний:

Выбираем длительность такта 200ns, такой интервал будет удовлетворять временным ограничениям указанным в datasheet WS2812B. Длительность импульса сброса в таком случае составит 255*0.2s= 51s. Заполним необходимые поля в DataPath Configuration Tool.

Первая команда это состояние ожидания записи данных в FIFO. Одновременно мы обнуляем операцией Исключающее ИЛИ регистр A1. Функция выбрана XOR, источник A и B регистр A1, запись регистра A1 выбрана из ALU.

На вторую команду мы переходим по сигналу FIFO empty == 0. То есть в FIFO поступили данные, в этот же момент мы устанавливаем выходной сигнал в 0. Во второй команде мы увеличиваем на единицу A1 до тех пор, пока он не примет значение 0xFF. После этого переходим к команде три, устанавливая выходной сигнал в 1.

В команде три мы загружаем байт из FIFO в A0 и загружаем счетчик бит из D1 в A1, и переходим к команде четыре.

В команде четыре и пять DataPath ничего не делает. В команде шесть мы делаем декремент счетчику бит и переходим к команде семь, установив выход в 1. Надо понимать, что когда мы устанавливаем выходной сигнал или флаг, данные изменятся только в следующем такте.

В команде семь происходит ветвление по трем адресам. Если счетчик бит A1 != 0, то мы переходим к команде восемь, чтобы сформировать еще один такт выходного сигнала 1. Если A1 == 0 и FIFO пуст, переходим к первой команде ожидания поступления данных в FIFO. Если FIFO не пуст, то переходим к команде три, загрузка данных из FIFO в A0 и счетчика бит A1 из D1.

Нам также надо включить маску 0 и присвоить ей значение 0x80. При проверке на равенство регистра A0 с маской 0x80, регистру D0 равному 0x80 это даст значение передаваемого бита. FIFO у нас по умолчанию сконфигурированы на ввод данных в DataPath.

В завершении пропишем значения по умолчанию для регистров D0 (маска старшего бита) = 8'h80 и D1 (счетчик бит) = 0'h08, используя пункт меню View->Initial Register Values.

Сохраняем (Ctrl+S) и закрываем Datapath Configuration Tool. Нам осталось написать логику работы машины состояний в Verilog файле. Сначала присвоим сигналам модуля имена используемых нами регистров и флагов.

udb8(        /*  input                   */  .reset(rst),//Входной сигнал сброса        /*  input                   */  .clk(clk),//Входной тактовый сигнал        /*  input   [02:00]         */  .cs_addr(state),//Регистр адреса команды DataPath        /*  input                   */  .route_si(1'b0),        /*  input                   */  .route_ci(1'b0),        /*  input                   */  .f0_load(1'b0),        /*  input                   */  .f1_load(1'b0),        /*  input                   */  .d0_load(1'b0),        /*  input                   */  .d1_load(1'b0),        /*  output                  */  .ce0(send_bit),//Значение отправляемого бита        /*  output                  */  .cl0(),        /*  output                  */  .z0(),        /*  output                  */  .ff0(),        /*  output                  */  .ce1(),        /*  output                  */  .cl1(),        /*  output                  */  .z1(z_count_bit),//Флаг равенству 0 счетчика бит        /*  output                  */  .ff1(end_ws2812_reset),//Флаг равенству 0xFF регистра A1        /*  output                  */  .ov_msb(),        /*  output                  */  .co_msb(),        /*  output                  */  .cmsb(),        /*  output                  */  .so(),        /*  output                  */  .f0_bus_stat(),        /*  output                  */  .f0_blk_stat(fifo_empty),//Флаг пустого FIFO        /*  output                  */  .f1_bus_stat(),        /*  output                  */  .f1_blk_stat());

Первые два сигнала это вход асинхронного сброса и вход тактового сигнала.

Следующий это трех-битный вход адреса памяти команд DataPath. Мы присваиваем этому входу регистр состояний state. Далее идут выходные сигналы UDB: ce0 это значение выводимого бита. При создании конфигурации DataPath мы включили маску 0 и присвоили ей значение 0x80, получается операция send_bit=(A0 & 0x80==D0) 1 : 0;

Флаг z1, проверяет на равенство 0 регистра A1, это у нас счетчик отправляемых бит, присваиваем ему сигнал z_count_bit.

Следующий флаг ff1, он устанавливается в 1 при равенстве регистра A1 - 0xFF. Этот флаг мы используем при формировании импульса сброса для WS2812, присваиваем ему имя сигнала end_ws2812_reset.

И последний флаг f0_blk_stat, он устанавливается в 1, когда FIFO 0 пуст. Присваиваем ему имя сигнала fifo_empty.

Нам осталось объявить используемые регистры и флаги, и прописать машину состояний.

    localparam IDLE = 3'h0;    localparam WS2812_RESET = 3'h1;    localparam LOAD_A0 = 3'h2;    localparam CHECK_BIT = 3'h3;    localparam SEND_BIT = 3'h4;    localparam DEC_BIT_CNT = 3'h5;    localparam SHIFT_DATA = 3'h6;    localparam NOP = 3'h7;    reg [2:0]state;//Адрес команды    reg out;//Регистр выходного сигнала    reg send_tic;//Регистр дополнительного такта    wire fifo_empty;//Флаг пустого FIFO    wire send_bit;//значение отправляемого бита    wire end_ws2812_reset;//Флаг равенства 0xFF регистра A1    wire z_count_bit;//Флаг равенства 0 счетчика бит    assign irq=fifo_empty;//Присваиваем выходу прерывания флаг пустого FIFO    assign ws2812=out;//Присваиваем выходной сигнал регистру выходного сигналаalways @(posedge clk or posedge rst )//beginif (rst)begin       // Асинхронный сбросstate <= IDLE;            out<=1'b1;endelsebegincase (state)IDLE://Ожидание поступления данных в FIFObeginif(fifo_empty==1'b0)beginstate <= WS2812_RESET;//Если данные в FIFO поступили,                     out<=1'b0;//переходим к команде формирования импульса сброса, выходной сигнал в 0endelsebegin                    out<=1'b1;//Если данных в FIFO нет, выходной сигнал в 1                endendWS2812_RESET://Формирование импульса сбросаbegin                if(end_ws2812_reset)//Ждем равенства 0xFF регистра A1                begin                    state <= LOAD_A0;//Если A1=0xFF, переходим к команде загрузки данных из FIFO                    out<=1'b1;//Выход в 1                endendLOAD_A0://Загрузка байта из FIFObegin                state <= CHECK_BIT;//Переходим к команде проверки значения выводимого битаendCHECK_BIT://Команда проверки значения выводимого битаbegin                send_tic <= 1'b0;//Обнуляем регистр дополнительного такта                state <= SEND_BIT;//Переходим к команде отправки бита данных                if(send_bit==1'b0)                begin                    out <= 1'b0;//Если выводимый бит 0, устанавливаем выход в 0                endendSEND_BIT://Команда отправки бита данныхbegin                if(send_tic)//Если дополнительный такт уже был                begin                    state <= DEC_BIT_CNT;//Переходим к команде декремента счетчика бит                    out <= 1'b0;//Устанавливаем выходной сигнал в 0                end                else                begin                    send_tic <= 1'b1;//Если дополнительного такта не было, устанавливаем флаг дополнительного такта                endendDEC_BIT_CNT://Команда декремента счетчика битbegin                state <= SHIFT_DATA;//Переходим к команде сдвига выводимого байта влевоendSHIFT_DATA://Команда сдвига выводимого байта влевоbegin                out<=1'b1;//Выходной сигнал в 1                if(z_count_bit)//Если счетчик выведенных бит равен 0                begin                    if(fifo_empty == 1'b0)//Если FIFO не пуст                    begin                        state <= LOAD_A0;//Переходим к загрузке нового байта                    end                    else                    begin                        state <= IDLE;//Если пуст переходим в режим ожидания прихода данных в FIFO                    end                end                else                begin                    state <= NOP;//Если счетчик бит не равен 0, переходим к формированию дополнительного такта                endendNOP://Команда дополнительного тактаbegin                state <= CHECK_BIT;//Переходим к команде проверки значения выводимого битаendendcaseendend

Железную часть мы закончили, осталось написать небольшое API, чтобы микроконтроллер мог взаимодействовать с нашим модулем. Сохраняем и закрываем Vetilog файл.

Создадим заголовочный файл, щелкаем правой клавишей мыши на имени нашего компонента и выбираем Add Component Item.

Ищем API Header File, вписываем имя файла и нажимаем Create.

Двойным щелчком по имени файла на панели слева открываем файл и добавляем в него следующие строки.

#include "cytypes.h"#define `$INSTANCE_NAME`_SHIFT_MASK 0x80#define `$INSTANCE_NAME`_NUM_SHIFT_BITS 8#define `$INSTANCE_NAME`_FIFO_LEVELS 4#define `$INSTANCE_NAME`_bit_cnt (*(reg8 *)`$INSTANCE_NAME`_udb8_u0__D1_REG)#define `$INSTANCE_NAME`_shift_mask (*(reg8 *)`$INSTANCE_NAME`_udb8_u0__D0_REG)#define `$INSTANCE_NAME`_data_fifo (*(reg8 *)`$INSTANCE_NAME`_udb8_u0__F0_REG)#define `$INSTANCE_NAME`_actl (*(reg8 *)`$INSTANCE_NAME`_udb8_u0__DP_AUX_CTL_REG)void `$INSTANCE_NAME`_Start(void);

Здесь следует разъяснить, что такое $INSTANCE_NAME. Это то, что мы вводили в свойство Doc.DefaultINstanceName при создании символа компонента. В нашем случае, будет автоматически формироваться имя ws2812_1_bit_cnt, где 1 после ws2812 это автоматическая нумерация компонентов на схеме. И да, на схеме это имя можно поменять на любое другое. Хитрую кавычку можно ввести так: <ALT>+<96>. Имя регистра, генерируемого при компиляции, состоит из трёх частей, $INSTANCE_NAME это имя компонента, udb8 это имя DataPath, которое мы указали при создании нового DataPath и u0__D1_REG это имя регистра. В случае ошибки, можно посмотреть эти имена в файле cyfitter.h после компиляции.

Функцию Start можно было не создавать, так как после сброса микроконтроллера в регистры D0 и D1, загружаются значения по умолчанию. Также мы сможем в программе, в любой момент, записать необходимые данные в регистр простой записью:

ws2812_1_bit_cnt=8;

Запись байта в FIFO выглядит так:

ws2812_1_data_fifo=0xAA;

Но мы сделаем это с заделом на будущее. Снова щелкаем правой клавишей мыши на имени компонента и выбираем Add Component Item. Затем выбираем API C File, вводим имя и нажимаем кнопку Create.

Двойным щелчком на имени файла, на панели слева открываем созданный файл и вводим в него следующий текст.

#include "`$INSTANCE_NAME`.h"void `$INSTANCE_NAME`_Start(void){    `$INSTANCE_NAME`_shift_mask=`$INSTANCE_NAME`_SHIFT_MASK;    `$INSTANCE_NAME`_bit_cnt=`$INSTANCE_NAME`_NUM_SHIFT_BITS;}

Нажимаем Ctrl+Shift+S, чтобы сохранить все изменения. Теперь мы можем добавить созданный компонент на схему проекта. Переключаемся на вкладку Source слева.

Двойным щелчком по файлу TopDesign.cysh открываем схему проекта, справа мы видим набор поставляемых с Psoc Creator компонентов.

Справа щелкаем на вкладку Default, и видим только что созданный нами компонент.

Перетаскиваем его на схему.

Щелкаем справа на вкладку Cypress, затем выбираем в папке Systems компонент Clock и перетаскиваем его на схему так, чтобы квадратик вывода clk компонента ws2812_1 совпал с квадратиком вывода компонента Clock_1, тогда выводы соединяться.

Щелкаем правой клавишей на компоненте Clock_1 и в выпавшем меню выбираем пункт Configure. В этом же меню можно выбрать пункт Open Datasheet и посмотреть datasheet на этот компонент.

Вписываем частоту 5MHz.

Затем в папке Digital библиотеки компонентов берем компонент Ligic Low и перетаскиваем его на схему, и размещаем рядом с выводом rst компонента ws2812_1. Затем нажимаем клавишу W и соединяем вывод rst и Logic Low проводом.

Из папки Ports and Pins берем компонент Digital Output Pin и подсоединяем его к выводу ws2812 нашего компонента, затем щелкаем правой клавишей по компоненту Pin_1, выбираем пункт меню Configure и изменяем имя компонента с Pin_1 на ws2812_port.

Присвоим сигнал ws2812_port порту P1(7), для этого, двойным щелчком по строчке Pins в папке Design Wide Resourse, открываем вкладку назначения выводов и на панели справа, выбираем Port - P1(7).

На вкладке Clocks, двойным щелчком на строчке IMO, открываем страничку конфигурации тактовых частот.

И устанавливаем частоту IMO - 3MHz, так как при такой частоте точность составляет 1%. Частоту PLL ставим 79MHz. На 80MHz IDE будет ругаться, так как с учетом отклонений, частота будет превышать предельно допустимые 80MHz для данного микроконтроллера.

Так как пост уже затянулся, автоматическую загрузку FIFO компонента через DMA я делать не буду, будем отправлять данные по прерыванию. Следовательно из папки System добавляем на схему компонент Interrupt.

Вызываем меню Configure для компонента isr_1, и даем ему имя isr_ws2812.

Нам еще понадобится компонент Timer, возьмём его в папке Digital->Function. К выводу interrupt подключим еще один компонент Interrupt, который переименуем в isr_timer. Также удалим у компонента Timer тактовый генератор и подключим тактовый вход таймера к компоненту Clock_1, переместив предварительно компонент Clock_1 чуть влево.

Теперь вызовем меню Configure для компонента Timer_1, выберем 16 битный режим, поставим период 14999 для прерывания каждые 3ms и поставим галочку напротив прерывания по переполнению. Почему я выбрал период обновления 3ms? Пересылка одного байта занимает 8*1,2s=9,6s всего 100 светодиодов по 3 байта на точку, получаем 2880s+51s на импульс сброса. Получаем 2931s, следовательно, 3ms нам вполне достаточно.

Как видно, компонент таймер может быть создан на базе аппаратного таймера или синтезирован на базе UDB блоков, мы оставим Fixed Function реализацию.

И нам осталось написать небольшой Hello Habr, кстати, нажав Shift +F6 можно скомпилировать проект, компиляция должна завершиться без ошибок.

Демонстрационная программа формирует бегущую строку на экране 10 на 10 светодиодов, подключенных последовательно Z способом снизу вверх, слева направо (со стороны проводов).

Кадры формируются по сигналу прерывания модуля Timer_1, картинка рисуется в предварительном буфере и по флагу окончания передачи данные копируются в основной буфер. Для увеличения скорости, копирование идет 32 битными словами.

int main(void){    ws2812_struct.buffer_ptr=ws2812_struct.buffer;    fillScreen(0);    CyGlobalIntEnable; /* Enable global interrupts. */    Timer_1_Start();    ws2812_1_Start();    isr_ws2812_StartEx(WS2812_HANDLER);    isr_timer_StartEx(TIMER333HZ_HANDLER);        uint16 delay=0;    for(;;)    {        if((delay++)==20)        {            delay=0;            scrollStr(text, sizeof(text), color , BACKGROUND);        }        while(ws2812_struct.wait_tx==0);        ws2812_struct.wait_tx=0;        copyBuffer((uint32*)ws2812_struct.draw_buffer,(uint32*)ws2812_struct.buffer,sizeof(ws2812_struct.buffer)/4);                }}

В заключении приведу screenshot измерителя ресурсов для данного проекта:

Мы израсходовали 4,4% ресурсов UDB. Это означает, что в данном микроконтроллере мы сможем разместить около 20 модулей ws2812. В микроконтроллерах PSOC 4200, например, CY8C4245PVI-482 скорей всего удастся поместить три таких модуля.

И в заключении осциллограммы снятые на работающем макете и небольшое видео.

Проект размещен на Github.

Совсем недавно мне в руки попался один из вариантов отладочной платы с SoC Zynq XC7Z020. Поискав в Интернете материалы, а-ля how-to, и попробовав накидать свой минимальный проект обнаружил, что есть целый ряд подводных камней. Именно об этом я и хотел бы рассказать в статье. Кому интересно - добро пожаловать под кат.

Важно! Перед началом повествования, хотелось бы заранее оговориться, что основная цель которую я преследую при написании этой статьи - показать любителям, с чего можно начать, при изучении отладочных плат на базе Zynq. Я не являюсь профессиональным разработчиком под ПЛИС и SoC Zynq и могу допускать какие-либо ошибки в использовании терминологии, использовать не самые оптимальные пути решения задач, etc. Но любая конструктивная и аргументированная критика только приветствуется. Что ж, поехали

Что за отладка такая? Покажи-расскажи...

Мне очень давно хотелось поиграться с SoC Zynq, но никак не доходили руки. Но в очередной раз погуглив - увидел, что за вполне вменяемый ценник продаётся отладка с Zynq на борту, от компании QMTech, называется она Bajie Board. Выпускается отладка в нескольких вариантах с разными вариантами SoC Zynq. Я выбрал для себя вариант на XC7Z020 и тут же ее заказал, через пару недель она у меня уже была в руках.

После распаковки я был приятно удивлен, комплект поставки порадовал. Это была сама отладочная плата, блок питания на 5В/2А, mini-USB кабель и microSD Flash-карта SanDisk на 16Гб с уже залитым на нее Linux. То есть, сразу после получения вы можете подключить к плате питание, воткнуть USB-шнурок, открыть Putty и получить в свое распоряжение полноценный mini-компьютер с Embedded Linux. О Linux для Zynq, я думаю, расскажу в другой статье, поэтому едем дальше...

Итак, рассматривая плату и попутно документацию на нее я увидел относительно не плохой набор всякого-разного:

• SoC: XC7Z020-1CLG400C

• (datasheet:https://www.xilinx.com/support/documentation/data_sheets/ds190-Zynq-7000-Overview.pdf);

• Осциллятор на 33,333 МГц;

• Оперативная память DDR3 на 512 Мб от компании Micron, MT41K256M16TW-107:P;

• Встроенный слот micro SD;

• Источник питания для FPGA TPS563201 с широким диапазоном входных напряжений (от 4.5V до 17V, 3A);

• Один 50-пиновый и две Digilent PMOD совместимых, гребёнки с пинами, с шагом в 2,54 мм. для пользовательских кейсов (как заверяет производитель, все проводники до пинов выровнены по длине);

• Кнопка для логического сброса процессорной системы (PS);

• Гигабитный RGMII Ethernet-контроллер Realtek RTL8211E-VL, подключенный к PS;

• Два пользовательских светодиода, один подключен к программируемой логике (PL) и другой подключен к процессорной системе (PS);

• Встроенный HDMI-совместимый интерфейс дисплея TI TPD12S016;

• Гребёнка для подключения JTAG-отладчика;

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

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

Установка необходимого набора ПО для разработки

Итак, прежде чем начать работу с платой мне было необходимо установить ПО Xilinx Vivado и Xilinx SDK. Насколько я понимаю, грубо говоря, Vivado используется для конфигурации аппаратной части используемой платы и для работы с программируемой логикой. А Xilinx SDK (ныне именуется Vitis) используется для создания кода непосредственно для процессорной системы.

Поскольку бОльшая часть примеров из документации и репозитория производителя и разнообразных примеров из роликов на YouTube делались в версии Vivado 2019.1 (видимо из-за того, что это последняя версия поддерживающая работу с Xilinx SDK) - я установил именно её, а не последнюю доступную 2020.2.

Все программные продукты необходимые для работы с Xilinx Zynq - можно взять на официальном сайте Xilinx, тут. Сразу же спешу обратить внимание, что те из вас, кто захочет установить самую новую версию Vivado - нужно скачивать версию 2020.2, а не 2020.3 т.к. последняя поддерживает только Versal SoC, и не поддерживает Zynq.

В моём случае, т.к. я работаю в операционной системе Linux - я перешел в меню Vivado Archive - 2019.1 и нажал на кнопку скачивания по ссылке Vivado HLx 2019.1: WebPACK and Editions - Linux Self Extracting Web Installer в списке Vivado Design Suite - HLx Editions - 2019.1. Для пользователей Windows - выбирайте Windows Self Extracting Web Installer.

После скачивания открываем инсталлятор, установив права на исполнение:

chmod +x ~/Downloads/Xilinx_Vivado_SDK_Web_2019.1_0524_1430_Lin64.bin~/Downloads/Xilinx_Vivado_SDK_Web_2019.1_0524_1430_Lin64.bin 

Вся установка состоит из набора стандартных шагов.

1. Вводим авторизационные данные, которые мы указывали при регистрации;

2. Принимаем условия лицензионных соглашений;

3. Выбираем Vivado HL WebPACK;

4. Удостоверяемся в том, что выбран SoC Zynq в списке предложенного оборудования.

   

5. Далее программа скачает порядка 16Гб всякого-разного, установит это и на Рабочем столе появятся иконки нужных нам приложений.

После установки Vivado необходимо установить драйвер для JTAG-программатора. В Linux это делается так:

cd Xilinx2019.1/Vivado/2019.1/data/xicom/cable_drivers/lin64/install_script/install_drivers/sudo ./install_drivers 

Подключаем все 6 пинов от JTAG-программатора в соответствии с шелкографией на плате. И проверяем установлены ли драйвера и определяется ли наша отладочная плата:

cd ~/Xilinx2019.1/Vivado/2019.1/bin./xsdb xsdb% connect -host localhost   xsdb% jtag targets                                                                                                                                                             1  Platform Cable USB 13724327082b01     2  arm_dap (idcode 4ba00477 irlen 4)     3  xc7z020 (idcode 23727093 irlen 6 fpga)

На этом подготовительных этап можно считать завершенным.

Hello, world или Баяны подъехали

Не будем отходить от традиции и попробуем поморгать LED-иком который подключен к программируемой логике.

Запускаем Vivado и создаем новый проект. Нажимаем File - Project - New

Откроется мастер создания нового проекта, нажимаем Next > и пишем название нашего проекта PL-Blink.

Выбираем RTL Project и ставим галочку у пункта Do not specify sources at this time.

Далее в списке ищем наш процессор xc7z020clg400-1.

Жмём на кнопку Finish.

Перед нами открывается главное окно программы Vivado и мы можем приступать к реализации намеченной нами цели!

Первым делом, мы добавим необходимые указания программе, на то, какие физические ножки мы задействуем в нашей моргающей вакханалии =)

Находим меню Sources и нажимаем кнопку Add Sources.

Откроется мастер импорта и нам нужно выбрать Add or create constraints.

В следующем меню нажимаем Create file и пишем название нашему файлу physical_constr. Именно в этом файле мы опишем какие ножки и в каком режиме должны работать.

Нажимаем кнопку Finish и в дереве Sourсes ищем только что созданный нами файл и открываем его:

Обратимся к схеме, которую любезно предоставил нам производитель и найдем какая ножка отвечает за тактирование, а какая за наш светодиод.Бегло поискав, я отметил для себя, что из Ethernet-контроллера RTL8211E-VL выведен опорный тактовый сигнал с его внутреннего PLL, частотой в 125МГц и заведен в ножку H16 (IO_L13P_T2_MRCC_35).Так почему бы нам его и не задействовать в нашем примере? =)

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

Тут же, рядом, на ножке H17 (IO_L13N_T2_MRCC_35) расположен светодиод, которым мы будем моргать.

Итак. Открыв наш constraints-файл запишем в него следующие строки:

# User LED and Clockset_property IOSTANDARD LVCMOS33 [get_ports led_h17_d4]set_property IOSTANDARD LVCMOS33 [get_ports sys_clk]set_property PACKAGE_PIN H17 [get_ports led_h17_d4]set_property PACKAGE_PIN H16 [get_ports sys_clk]

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

В квадратных скобках, после get_ports необходимо указать логическое имя ножки (на ваше усмотрение). Имена стоит придумать осмысленно, потому что мы его будем использовать в Verilog-коде.

Кстати, подробнее о Physical Constraints можно почитать тут в главе 8.

Добавим в наш проект таким же образом Design Source. Находим меню Sources и нажимаем кнопку Add Sources.

Откроется мастер импорта и нам нужно выбрать Add or create design sources. Далее нажимаем Create File, смотрим, что выбран язык Verilog. Нажимаем ОК и Finish.

В следующем меню всё оставляем без изменений и нажимаем ОК и Yes.

Открываем созданный файл и видим небольшую заготовку:

Здесь вместо предложенного кода пишем наш Verilog-код и прокомментируем что значит каждая из строк:

// Директива компилятора, которая определяет единицу времени и точность для моделирования Verilog.// В целом, не очень интересный пункт для нас.`timescale 1ns / 1ps // Определяем стандартный блок-модуль (как класс в С++)module pl_blink(input sys_clk, output led_h17_d4);    // Задаем регистр для хранения записи о текущем состоянии светодиодаreg r_led; // Задаем регистр для хранения значения счётчика, использующегося в задержкеreg [31:0] counter;// Тут мы задаем действия которые должны быть выполнены при старте программыinitial begin    counter <= 32'b0;//  Обнуляем счётчик    r_led <= 1'b0;//  Делаем запись о состоянии светодиодаend// Тут описываем поведенческий блок, который будет реагировать на ниспадающий фронт тактовой частотыalways@(posedge sys_clk)begin    counter <= counter + 1'b1;// Увеличиваем счетчик        if(counter > 12000000)// Если счетчик больше некоторого условного значения    begin        r_led <= !r_led;// Инвертируем запись о значении состоянии светодиода        counter <= 32'b0;// Сбрасываем счетчик    end       endassign led_h17_d4 = r_led;          // Присваиваем текущее состояние ножке (условно)           endmodule

Нажимаем сочетание клавиш Ctrl + S чтобы сохранить код. Смотрим, не подсвечены ли где возможные ошибки. Если нет - то можем приступить к синтезированию, имплементации и генерации бинарного файла который мы потом зальем в нашу плату Zynq и будем наблюдать за морганием светодиода.

Нажимаем кнопку Run Synthesis и дожидаемся завершения синтеза. После окончания программа нам скажет, что синтез успешно завершен и мы можем переходить к следующему шагу:

Выбираем Run implementation и дожидаемся окончания. После выбираем пункт Generate Bitstream для запуска финального этапа:

Тут так же дожидаемся сигнала о том, что всё прошло успешно, выбираем Open Hardware Manager и можем приступать к заливке результата компиляции в нашу плату:

В открывшемся меню Hardware Manager нажимаем кнопку Auto connect, дожидаемся когда произойдет успешное соединение и откроется меню со списком устройств:

В меню слева или через нажатие правой кнопкой по xc7z020_1 в меню Hardware нажимаем пункт Program Device.

В следующем окне убеждаемся, что правильно указан путь к bitstream-файлу и нажимаем кнопку Program.

Программа заливается на нашу плату

И через мгновение на плате загорается светодиод D2, который сообщает нам, что FPGA DONE и в другом конце платы мы видим весело моргающий светодиод. =)

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

Все делают это. Ну ладно, не все, но большинство. Пишут скрипты, чтобы симулировать свои проекты на Verilog, SystemVerilog и VHDL. Однако, написание и поддержка таких скриптов часто бывает довольно непроста для типично используемых Bash/Makefile/Tcl. Особенно, если необходимо не только открывать GUI для одного тестбенча и смотреть в диаграммы, но и запускать пачки параметризированных тестов для различных блоков, контролировать результат, параллелизировать их выполнение и т.д. Оказалось, что всё это можно закрыть довольно прозрачным и легко поддерживаемым кодом на Python, что мне даже обидно становится от того, как я страдал ранее и сколько странного bash-кода родил.

Конечно, я не первый кто задумывается о подобном. Уже даже существует целый фреймворк VUnit. Однако, как показывает практика и опросы в профильных чатах, такие фреймворки используются нечасто. Вероятно потому, что они предъявляют требования к внутренней структуре самих тестбенчей, с чем наверное можно мириться только на новых проектах, без обширной кодовой базы. Ну и вообще, куда ж без таких вещей как "у нас так не принято" и "not invented here".

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

Задачи

Попробую перечислить большинство задач, которые так или иначе возникают в процессе разработки и эволюции HDL проекта. От более простых к более сложным:

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

• Одиночный запуск без GUI. То же самое, но без временных диаграмм, оценить результат по выводу в консоль.

• Параметризированный запуск. Запуск симуляции с GUI или без, но с параметрами (дефайнами), передаваемыми в скрипт из консоли.

• Запуск с пре-/постпроцессингом. Например, для теста должны быть подготовлены данные. Или сам тест порождает данные, которые должны быть проверены вне HDL.

• Массовый запуск. Прогнать симуляцию всех существующих тестбенчей.

• Массовый параметризированный запуск. Прогнать симуляцию всех или группы тестбенчей, при этом отдельные тестбенчи могут запускаться несколько раз с разным значением ключевого параметра (размерность шины, интерфейс и т.д).

• Параллельные запуски. Тесты могут легко идти минуты/часы и последовательное исполнение может занимать слишком много времени. Скрипты должны позволять параллельное исполнение нескольких тестбенчей.

• Поддержка нескольких симуляторов. Сделать так, чтобы всё вышеперечисленное работало в разных симуляторах.

• Поддержка CI. Массовый запуск должен сочетаться в том числе с выбранной стратегией CI (прогон всех тестов после каждого пуша, "ночные сборки" и т.д.).

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

Идея

Все симуляторы запускаются примерно одинаково в большинстве случаев:

• собираем список всех исходников (опционально делим на несколько списков по языку);

• собираем список всех директорий для поиска исходников (нужно для include);

• собираем список всех дефайнов;

• сообщаем имя библиотеки, куда всё будем компилировать (или нескольких);

• сообщаем имя верхнего модуля (обычно это имя тестбенча);

• передаём это всё симулятору в виде ключей, файлов со списками и т.д.

А что если написать модуль на Python, в котором обернуть нужные симуляторы в один класс Simulator, вынести общие вещи в атрибуты и реализовать метод run(), который запустит симуляцию с помощью выбранного симулятора? В целом, именно это я и сделал для Icarus Verilog, Modelsim и Vivado Simulator, используя модуль subprocessпод капотом. Также я добавил класс CliArgs, основанный на модуле argparse, чтобы иметь возможность управлять запуском из консоли. Ну и написал некоторое количество вспомогательных функций, которые пригодятся в процессе. Получился файл sim.py.

Фактически, я постарался свести всё к тому, что в новом проекте нужно всего-лишь закинуть этот файл, создать рядом еще один скрипт на Python, импортировать необходимое из sim.py и начать работу.

Тестовый проект

Для демонстрации я вытянул модуль пошагового вычисления квадратного корня из одного старого проекта, чтобы тестовый дизайн был хоть чуточку сложнее счётчика или сумматора. Код основан на публикации An FPGA Implementation of a Fixed-Point Square Root Operation.

Репозиторий проекта pyhdlsim на GitHub.

Иерархия проекта проста:

$ tree -a -I .git. .github    workflows # Github Actions        icarus-test.yml # запуск всех тестов в Icarus Verilog после каждого пуша на github        modelsim-test.yml # запуск всех тестов в Modelsim после каждого пуша на github .gitignore LICENSE.txt README.md sim # скрипты для запуска симуляции    conftest.py    sim.py    test_sqrt.py src # исходники     beh # поведенчесие описания и модели        sqrt.py     rtl # синтезируемый HDL код        sqrt.v     tb # HDL код тестбенчей         tb_sqrt.sv

Сам тестбенч tb_sqrt.sv тоже довольно примитивен: подготавливается массив входных значений, вычисляются "идеальные" значения с помощью $sqrt(), входные значения проталкиваются в модуль корня, выходные значения сохраняются в массив, происходит сравнение ожидаемых значений и фактических.

В принципе, краткое описание есть в самом репозитории и на этом можно закругляться, однако, думаю что будет гораздо нагляднее, если показать весь путь написания тестового окружения (будем считать что весь HDL и файл sim.py уже написаны). Всё действо будет происходить внутри папки sim. Осторожно, букв много впереди ожидает.

Одиночный запуск

Создадим файл test_sqrt.py для запуска тестбенча.

#!/usr/bin/env python3from sim import Simulatorsim = Simulator(name='icarus', gui=True, cwd='work')sim.incdirs += ["../src/tb", "../src/rtl", sim.cwd]sim.sources += ["../src/rtl/sqrt.v", "../src/tb/tb_sqrt.sv"]sim.top = "tb_sqrt"sim.setup()sim.run()

Тест будем прогонять в Icarus с открытием GTKWave для просмотра диаграмм. Пути до исходников задаются относительно самого скрипта. Задавать директории поиска инклудов для данного проекта не обязательно, и сделано лишь для демонстрации. Чтобы не загрязнять директорию со скриптами - с помощью sim.setup() будет создана рабочая папка work (а если она существовала, то она будет удалена и создана заново) внутри которой симулятор и будет запущен (sim.run()).

Делаем скрипт исполняемым и запускаем:

chmod +x test_sqrt.py./test_sqrt.py

Симуляция должна пройти успешно и должно появиться окно GTKWave.

Одиночный запуск без GUI

Можно конечно без конца править сам скрипт, но более верным решением будет добавить управление деталями запуска из консоли. Добавляем парсер аргументов CliArgs. Тест вынес в отдельную функцию и добавил стандартную проверку, чтобы парсер запускался только когда мы непосредственно исполняем сам файл.

#!/usr/bin/env python3from sim import Simulator, CliArgsdef test(tmpdir, defines, simtool, gui):    sim = Simulator(name=simtool, gui=gui, cwd=tmpdir)    sim.incdirs += ["../src/tb", "../src/rtl", sim.cwd]    sim.sources += ["../src/rtl/sqrt.v", "../src/tb/tb_sqrt.sv"]    sim.defines += defines    sim.top = "tb_sqrt"    sim.setup()    sim.run()if __name__ == '__main__':    # run script with key -h to see help    args = CliArgs(default_test="test").parse()    test(tmpdir='work', simtool=args.simtool, gui=args.gui, defines=args.defines)

Посмотрим что нам доступно:

$ ./test_sqrt.py -husage: test_sqrt.py [-h] [-t <name>] [-s <name>] [-b] [-d <def> [<def> ...]]optional arguments:  -h, --help            show this help message and exit  -t <name>             test <name>; default is 'test'  -s <name>             simulation tool <name>; default is 'icarus'  -b                    enable batch mode (no GUI)  -d <def> [<def> ...]  define <name>; option can be used multiple times

Теперь мы можем запустить тест в консольном режиме:

$ ./test_sqrt.py -bRun Icarus (cwd=/space/projects/pyhdlsim/simtmp/work)TOP_NAME=tb_sqrt SIMiverilog -I /space/projects/pyhdlsim/src/tb -I /space/projects/pyhdlsim/src/rtl -I /space/projects/pyhdlsim/simtmp/work -D TOP_NAME=tb_sqrt -D SIM -g2005-sv -s tb_sqrt -o worklib.vvp /space/projects/pyhdlsim/src/rtl/sqrt.v /space/projects/pyhdlsim/src/tb/tb_sqrt.svvvp worklib.vvp -lxt2LXT2 info: dumpfile dump.vcd opened for output.Test started. Will push 8 words to DUT.!@# TEST PASSED #@!

Или запустить в другом симуляторе:

# как в консоли./test_sqrt.py -s modelsim -b# так и с GUI./test_sqrt.py -s modelsim

Параметризированный запуск

Также теперь можно контролировать дефайны из консоли, и, например, увеличить количество подаваемых данных:

$ ./test_sqrt.py -b -d ITER_N=42Run Icarus (cwd=/space/projects/pyhdlsim/simtmp/work)TOP_NAME=tb_sqrt SIMiverilog -I /space/projects/pyhdlsim/src/tb -I /space/projects/pyhdlsim/src/rtl -I /space/projects/pyhdlsim/simtmp/work -D TOP_NAME=tb_sqrt -D SIM -g2005-sv -s tb_sqrt -o worklib.vvp /space/projects/pyhdlsim/src/rtl/sqrt.v /space/projects/pyhdlsim/src/tb/tb_sqrt.svvvp worklib.vvp -lxt2LXT2 info: dumpfile dump.vcd opened for output.Test started. Will push 42 words to DUT.!@# TEST PASSED #@!

Запуск с пре-/постпроцессингом

Часто бывает так, что сгенерировать данные для теста невозможно внутри тестбенча и должны быть применены внешние генераторы. Сделаем еще один тест, где будем сверять работу модуля на Verilog с идеальной моделью, написанной на Python. Алгоритм работы уже был представлен выше - просто перепишем его на Python, не забывая проверить что он на самом деле работает. Результатом будет файл src/beh/sqrt.py. Оттуда нам нужна будет лишь одна функция nrsqrt().

Переименуем старый тест, который ориентируется на данные, полученные внутри тестбенча, в test_sv. И создадим новый test_py, который будет готовить данные с помощью функции nrsqrt().

#!/usr/bin/env python3from sim import Simulator, CliArgs, path_join, write_memfileimport randomimport syssys.path.append('../src/beh')from sqrt import nrsqrtdef create_sim(cwd, simtool, gui, defines):    sim = Simulator(name=simtool, gui=gui, cwd=cwd)    sim.incdirs += ["../src/tb", "../src/rtl", cwd]    sim.sources += ["../src/rtl/sqrt.v", "../src/tb/tb_sqrt.sv"]    sim.defines += defines    sim.top = "tb_sqrt"    return simdef test_sv(tmpdir, defines, simtool, gui):    sim = create_sim(tmpdir, simtool, gui, defines)    sim.setup()    sim.run()def test_py(tmpdir, defines, simtool, gui=False, pytest_run=True):    # prepare simulator    sim = create_sim(tmpdir, simtool, gui, defines)    sim.setup()    # prepare model data    try:        din_width = int(sim.get_define('DIN_W'))    except TypeError:        din_width = 32    iterations = 100    stimuli = [random.randrange(2 ** din_width) for _ in range(iterations)]    golden = [nrsqrt(d, din_width) for d in stimuli]    write_memfile(path_join(tmpdir, 'stimuli.mem'), stimuli)    write_memfile(path_join(tmpdir, 'golden.mem'), golden)    sim.defines += ['ITER_N=%d' % iterations]    sim.defines += ['PYMODEL', 'PYMODEL_STIMULI="stimuli.mem"', 'PYMODEL_GOLDEN="golden.mem"']    # run simulation    sim.run()if __name__ == '__main__':    args = CliArgs(default_test="test_sv").parse()    try:        globals()[args.test](tmpdir='work', simtool=args.simtool, gui=args.gui, defines=args.defines)    except KeyError:        print("There is no test with name '%s'!" % args.test)

Теперь, когда тестов несколько, можно воспользоваться ключом выбора теста:

# аргумент должен совпадать с именем функции./test_sqrt.py -t test_py

Аналогичным образом можно организовать и постпроцессинг внутри запускающего скрипта при желании.

Массовый запуск

Сейчас у нас уже есть 2 теста, а ведь завтра может быть и 202, а значит уже можно переживать о том, что нужен способ как их все прогнать за раз. И вот тут на сцене появляется pytest.

Нано-ликбез по pytest.

• Начиная с директории запуска, pytest рекурсивно ищёт всё начинающееся на test* и исполняет: модули, функции, классы, методы.

• Тест считается выполненным, если не возникло исключений (типичным является использование assert для контроля).

• Для формирования тестового окружения используются фикстуры (fixtures). Например, что подставлять в тест test_a(a) в качестве аргумента при выполнении как раз определяется фикстурой.

• Можно создать дополнительный файл conftest.py, в котором разместить код для более тонкого контроля выполнения тестов и их окружения.

Типичные сценарии запуска:

• pytest - рекурсивный поиск и исполнение всех тестов, начиная с текущей директории;

• pytest -v - выполнить тесты и показать болеe подробную информацию о ходе выполнении тестов;

• pytest -rP - выполнить тесты и показать вывод в stdout тех тестов, что завершились успешно;

• pytest test_sqrt.py::test_sv - выполнить указанный тест.

Для того чтобы адаптировать текущий скрипт под pytest нужно совсем немного. Импортируем сам pytest. Добавим пару фикстур для таких аргументов теста как simtool и defines. Значение, возвращаемое фикстурами будет использовано в качестве аргумента во всех тестах. Два других аргумента gui и pytest_run снабжаем значениями по умолчанию. Фактически их тоже можно было сделать фикстурами, но т.к. для запуска pytest они не должны принимать никакое другое значение, то сделал так.

Да, кстати, появился аргумент pytest_run который сообщает о том, выполняется ли сейчас pytest, или просто тест запущен отдельно из консоли.

С аргументом tmpdir я схитрил - это имя стандартной фикстуры, которая возвращает путь к временной папке, уникальной для каждого теста. Т.е. сами тесты будут прогонятся где-то во временных директориях и не засорять содержимое sim.

Имена тестов тоже изменять не нужно - они будут найдены pytest, т.к. имеют префикс test_.

Решение о том, прошел тест или нет принимается по состоянию аттрибута is_passed симулятора. Он возвращает истину, если увидел ключевую фразу !@# TEST PASSED #@! в stdout. Очевидно, если компиляция была неудачной, или тест завершился с ошибкой, то этой фразы выведено не будет. Это самый простой способ оценить результат, но возможности для его кастомизации здесь ограничены лишь фантазией. Можно получить stdout через sim.stdout и искать там что угодно.

#!/usr/bin/env python3import pytestfrom sim import Simulator, CliArgs, path_join, write_memfileimport randomimport syssys.path.append('../src/beh')from sqrt import nrsqrt@pytest.fixture()def defines():    return []@pytest.fixturedef simtool():    return 'icarus'def create_sim(cwd, simtool, gui, defines):    sim = Simulator(name=simtool, gui=gui, cwd=cwd, passed_marker='!@# TEST PASSED #@!')    sim.incdirs += ["../src/tb", "../src/rtl", cwd]    sim.sources += ["../src/rtl/sqrt.v", "../src/tb/tb_sqrt.sv"]    sim.defines += defines    sim.top = "tb_sqrt"    return simdef test_sv(tmpdir, defines, simtool, gui=False, pytest_run=True):    sim = create_sim(tmpdir, simtool, gui, defines)    sim.setup()    sim.run()    if pytest_run:        assert sim.is_passeddef test_py(tmpdir, defines, simtool, gui=False, pytest_run=True):    # prepare simulator    sim = create_sim(tmpdir, simtool, gui, defines)    sim.setup()    # prepare model data    try:        din_width = int(sim.get_define('DIN_W'))    except TypeError:        din_width = 32    iterations = 100    stimuli = [random.randrange(2 ** din_width) for _ in range(iterations)]    golden = [nrsqrt(d, din_width) for d in stimuli]    write_memfile(path_join(tmpdir, 'stimuli.mem'), stimuli)    write_memfile(path_join(tmpdir, 'golden.mem'), golden)    sim.defines += ['ITER_N=%d' % iterations]    sim.defines += ['PYMODEL', 'PYMODEL_STIMULI="stimuli.mem"', 'PYMODEL_GOLDEN="golden.mem"']    # run simulation    sim.run()    if pytest_run:        assert sim.is_passedif __name__ == '__main__':    args = CliArgs(default_test="test_sv").parse()    try:        globals()[args.test](tmpdir='work', simtool=args.simtool, gui=args.gui, defines=args.defines, pytest_run=False)    except KeyError:        print("There is no test with name '%s'!" % args.test)

Прогоним все тесты несколько раз:

$ pytest========== test session starts ===========platform linux -- Python 3.8.5, pytest-6.2.1, py-1.10.0, pluggy-0.13.1rootdir: /space/projects/misc/habr-publications/pyhdlsim/pyhdlsim/simtmpplugins: xdist-2.2.0, forked-1.3.0collected 2 itemstest_sqrt.py ..                    [100%]=========== 2 passed in 0.08s ============$ pytest -v========== test session starts ===========platform linux -- Python 3.8.5, pytest-6.2.1, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3cachedir: .pytest_cacherootdir: /space/projects/misc/habr-publications/pyhdlsim/pyhdlsim/simtmpplugins: xdist-2.2.0, forked-1.3.0collected 2 itemstest_sqrt.py::test_sv PASSED       [ 50%]test_sqrt.py::test_py PASSED       [100%]=========== 2 passed in 0.08s ============

Массовый параметризированный запуск

Неплохо было бы прогнать тесты для разной величины ширины данных. Очевидно, что руками запускать тесты N раз, каждый раз анализируя глазами логи в поисках фразы об успешном завершении, довольно утомительно. Нужно использовать pytest.

Модификация будет минимальной, нужно лишь обновить фикстуру defines:

# заменим это@pytest.fixture()def defines():    return []# на это@pytest.fixture(params=[[], ['DIN_W=16'], ['DIN_W=18'], ['DIN_W=25'], ['DIN_W=32']])def defines(request):    return request.param

Теперь фикстура может принимать одно из 5 значений. Запустим тесты:

$ pytest -v================== test session starts ==================platform linux -- Python 3.8.5, pytest-6.2.1, py-1.10.0, pluggy-0.13.1 -- /usr/bin/python3cachedir: .pytest_cacherootdir: /space/projects/misc/habr-publications/pyhdlsim/pyhdlsim/simtmpplugins: xdist-2.2.0, forked-1.3.0collected 10 itemstest_sqrt.py::test_sv[defines0] PASSED            [ 10%]test_sqrt.py::test_sv[defines1] PASSED            [ 20%]test_sqrt.py::test_sv[defines2] PASSED            [ 30%]test_sqrt.py::test_sv[defines3] PASSED            [ 40%]test_sqrt.py::test_sv[defines4] PASSED            [ 50%]test_sqrt.py::test_py[defines0] PASSED            [ 60%]test_sqrt.py::test_py[defines1] PASSED            [ 70%]test_sqrt.py::test_py[defines2] PASSED            [ 80%]test_sqrt.py::test_py[defines3] PASSED            [ 90%]test_sqrt.py::test_py[defines4] PASSED            [100%]================== 10 passed in 0.28s ===================

Как видим, теперь каждый тест запустился по 5 раз с разным дефайном.

Параллельные запуски

Тут тоже всё довольно просто и работает почти из коробки. Ставим один плагин:

python3 -m pip install pytest-xdist

И теперь можем запускать тесты в несколько параллельных потоков, например, в 4:

# можно также использовать значение auto, pytest задействует все доступные ядраpytest -n 4

Для того, чтобы проверить работу этого механизма добавим еще один длительный тест:

def test_slow(tmpdir, defines, simtool, gui=False, pytest_run=True):    sim = create_sim(tmpdir, simtool, gui, defines)    sim.defines += ['ITER_N=500000']    sim.setup()    sim.run()    if pytest_run:        assert sim.is_passed

Запустим последовательное и параллельное исполнение (тестов теперь стало 3*5=15):

$ pytest=================== test session starts ====================platform linux -- Python 3.8.5, pytest-6.2.1, py-1.10.0, pluggy-0.13.1rootdir: /space/projects/misc/habr-publications/pyhdlsim/pyhdlsim/simtmpplugins: xdist-2.2.0, forked-1.3.0collected 15 itemstest_sqrt.py ...............                         [100%]============== 15 passed in 242.74s (0:04:02) ==============$ pytest -n auto=================== test session starts ====================platform linux -- Python 3.8.5, pytest-6.2.1, py-1.10.0, pluggy-0.13.1rootdir: /space/projects/misc/habr-publications/pyhdlsim/pyhdlsim/simtmpplugins: xdist-2.2.0, forked-1.3.0gw0 [15] / gw1 [15] / gw2 [15] / gw3 [15]...............                                      [100%]============== 15 passed in 145.66s (0:02:25) ==============

Результат, как говорится, видно невооруженным взглядом.

Поддержка нескольких симуляторов

Ранее уже было показано, что при выполнении теста без pytest можно было выбрать симулятор с помощью ключа -s. Теперь же добавим выбор симулятора для pytest. Очевидно, нужно что-то сделать с фикстурой simtool.

Тут нам пригодится знание о существовании файла conftest.py, необходимого для кастомизации запусков pytest. Создадим такой файл рядом с sim.py и добавим туда следующий код:

def pytest_addoption(parser):    parser.addoption("--sim", action="store", default="icarus")

В файле теста test_sqrt.py обновим фикстуру simtool:

@pytest.fixturedef simtool(pytestconfig):    return pytestconfig.getoption("sim")

Теперь можно прогнать все тесты в другом симуляторе:

pytest --sim modelsim -n auto

Поддержка CI. Github Actions + (Modelsim | Icarus)

Ну и бонусом будет часть о непрерывной интеграции (CI). В репозиторий добавлены два файла .github/workflows/icarus-test.yml и .github/workflows/modelsim-test.yml. Это так называемые Github Actions - по определенному событию будет выполнено их содержимое внутри виртуального окружения, предоставляемого Github. В данном случае, после каждого пуша будут прогнаны все тесты в двух симуляторах.

В Icarus Verilog:

- name: Install dependencies  run: |    python -m pip install --upgrade pip    pip install pytest pytest-xdist    sudo apt-get install iverilog- name: Test code  working-directory: ./sim  run: |    pytest -n auto

И в Modelsim Intel Starter Pack:

- name: Install dependencies  run: |    python -m pip install --upgrade pip      pip install pytest pytest-xdist      sudo dpkg --add-architecture i386      sudo apt update      sudo apt install -y libc6:i386 libxtst6:i386 libncurses5:i386 libxft2:i386 libstdc++6:i386 libc6-dev-i386 lib32z1 libqt5xml5 liblzma-dev    wget https://download.altera.com/akdlm/software/acdsinst/20.1std/711/ib_installers/ModelSimSetup-20.1.0.711-linux.run        chmod +x ModelSimSetup-20.1.0.711-linux.run    ./ModelSimSetup-20.1.0.711-linux.run --mode unattended --accept_eula 1 --installdir $HOME/ModelSim-20.1.0 --unattendedmodeui none    echo "$HOME/ModelSim-20.1.0/modelsim_ase/bin" >> $GITHUB_PATH- name: Test code  working-directory: ./sim  run: |    pytest -n auto --sim modelsim

Тут кстати очень порадовала последняя версия Modelsim. Они наконец-то починили её! Каждый кто хоть раз устанавливал его на Ubuntu/Fedora поймёт о чём я (вот, например, инструкция для Quartus+Modelsim 19.1 и Fedora 29).

Ну и сравнение времени выполнения после очередного пуша в репозиторий:

Даже не смотря на то, что скачивание 1.3GB установочника Modelsim и его распаковка занимают некоторое время (которое тем не менее, очень мало!), он оказывается в итоге ещё и быстрее моментально развертываемого Icarus.

Тут конечно можно пойти дальше и подготовить Docker-образ с Modelsim, чтобы не качать его каждый раз сайта, но я, пожалуй, здесь остановлюсь.

В целом, мне прям очень зашёл способ организации симуляции и тестирования с помощью Python, это как глоток свежего воздуха после Bash, который я чаще всего применял до этого. И надеюсь, что кому-нибудь описанное пригодится тоже.

Все финальные версии скриптов лежат в репозитории pyhdlsim на GitHub.

Применяемая, в настоящее время, для проектирования СБИС, методология с использованием языков описания аппаратуры, обладает общепризнанными недостатками, а именно:

• Разработка сложных СБИС требует сотни квалифицированных инженеров, несколько лет работы и затрат в миллиарды долларов.

• До половины времени разработки, уходит на поиск и устранение ошибок в программной модели проектируемого микропроцессора.

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

Отечественные и зарубежные идеи, решения проблем проектирования СБИС, лежат в рамках общепринятой парадигмы, применения языков программирования для описания проектируемой аппаратуры. Все эти решения используются в реализуемых, в настоящее время, программах DARPA.

Программы DARPA

В рамках программы Electronics Resurgence Initiative, объявленной DARPA, поставлена задача преодолеть проблемы применяемой методологии проектирования микропроцессорных систем. С этой целью реализуется следующие подпрограммы:

• CRAFT предполагает создание средств высокоуровневого синтеза СБИС;

• IDEA направлена на создание автоматического генератора компоновки SoC, многокристальных микросхем, печатных плат;

• POSH нацелена на создание жизнеспособной экосистемы проектирования аппаратуры и верификации, с открытым исходным кодом, которая позволит экономически эффективно проектировать ультра-сложные SoC.

В случае успешного выполнения указанных программ полученные результаты должны быть объединены в перспективных САПР. Предполагается достичь 10 кратного роста в скорости разработки над ручным созданием RTL кода. Кроме того, ставится цель принципиально изменить практику разработки микропроцессорных устройств. Итоговая цель преобразования инженерной практики описана так:

• Разработка СБИС становится частью инструментария разработчика программного обеспечения.

• Каждая компания разработчик ПО, получает возможность разрабатывать СБИС.

Описывая ситуацию в отрасли разработки микропроцессорных систем, DARPA говорит о следующих проблемах (на основе Electronics Resurgence Initiative Page 3 Investments Design Thrust). Интеллектуальные системы следующего поколения, в областях искусственного интеллекта, автономных транспортных средств, связи, радиоэлектронной борьбы и радиолокации, потребуют на порядок большей эффективности обработки, чем та, которую предлагает современная коммерческая электроника. Достижение требуемых уровней производительности, потребует разработки очень сложных платформ SoC, использующих самые передовые технологии интегральных схем. В последние годы сложность микросхем быстро росла, произошел взрыв затрат и времени, необходимых для разработки усовершенствованных SoC, печатных плат и многокристальных сборок (SiP). Предлагаемая инициатива создаст новые парадигмы для интеллектуального физического проектирования и уменьшит барьеры для проектирования высокопроизводительных, высокоэффективных специализированных интегральных схем.

Исследовательский подход в программе CRAFT (из доклада Khailany Brucek CRAFT Final на ERI Summit 2019):

1. Поднять уровень абстракции при разработке аппаратуры:

   a. Использовать языки более высокого уровня, например, C ++ вместо Verilog;

   b. Использовать инструменты высокоуровневого синтеза;

   c. Использовать библиотеки и генераторы, например, MatchLib.

2. Применение методологии AGILE в разработке СБИС:

   a. Небольшие команды, совместно работая над архитектурой, реализацией, VLSI (Very Large Scale Integration);

   b. Непрерывная интеграция и средства автоматической верификации;

   c. AGILE методы управления проектами;

   d. Круглосуточная генерация из С++ в схему.

Предложен высоко продуктивный подход к разработке цифровых СБИС для создания сложных SoC. Маршрут проектирования включает средства высокоуровневого синтеза, объектно-ориентированные библиотеки синтезируемых компонентов на языках SystemC и С++. И модульный подход к физическому проектированию СБИС основанный на мелкозернистом глобально асинхронном и локально синхронном (GALS) тактировании. Методология проектирования была продемонстрирована на 16-нм тестовом чипе FinFET, предназначенном для машинного обучения и компьютерного зрения. (A Modular Digital VLSI Flow for High-Productivity SoC Design, Khailany et al., DAC 2018)

Рисунок 1. Вариант маршрута проектирования предложенный для программы CRAFT [1].

Программа IDEA состоит из двух этапов. На первом этапе будет создан генератор макетов, для создания автоматизированной платформы проектирования печатных плат, SoC и SiP. На втором этапе должна быть создана программная система, которая на основе функционального описание высокого уровня и заданных ограничений, будет создавать печатные платы и микросхемы правильной конструкции на основе обширной библиотеки коммерческих компонентов (COTS). Примеры компонентов COTS включают в себя коммерчески доступные микросхемы для печатных плат, кристаллы для SiP и IP-модули для SoC. Созданный список цепей, будет поступать на вход генератора макетов, разработанного в первой части программы. Таким образом будет создана сквозная автоматизированная платформа проектирования для печатных плат, SoC и SiP.

Рисунок 2. Схема применение искусственного интеллекта для решения задачи проектирования СБИС, по замыслу программы IDEA [5].

При этом признаётся, что для достижения поставленных, программой IDEA, целей потребуется прорыв в алгоритмах машинного обучения и оптимизации. Предполагаемый вид маршрута проектирования программы IDEA показан на рисунке 3.

Рисунок 3. Концепция маршрута проектирования программы IDEA [5].

В программе POSH предлагается использовать практику разработки ПО с открытым кодом, в области разработки микропроцессорных систем. В документах DARPA говорится следующее. Появление экосистемы программного обеспечения с открытым исходным кодом позволило создать глубокую иерархию программного обеспечения со многими уровнями абстракции, что значительно повысило производительность в проектах разработки сложных программных систем. Модель абстрагирования программного обеспечения позволяет программисту сосредоточить свои усилия в одной конкретной области, игнорируя при этом большое количество деталей, которые в противном случае были бы слишком сложными для обработки. Чтобы создать устойчивую экосистему разработки аппаратуры с открытым исходным кодом, программа POSH создаст технологии, методы и стандарты для эффективной разработки SoC с открытым исходным кодом. Предполагается, что критически важным компонентом этих усилий станет разработка технологий проверки, обеспечивающих доверие к строительным блокам (IP блокам) аппаратного обеспечения с открытым исходным кодом.

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

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

Рисунок 4. Экосистема с открытым исходным кодом для разработки SoC по замыслу программы POSH [4].

Программа POSH предполагает создание необходимых компонентов экосистемы для широкого использования в разработке SoC, блоков с открытым исходным кодом. Главными компонентами экосистемы являются программные средства, обеспечивающие моделирование, верификацию, валидацию, отладку отдельных IP блоков и собранных на их основе SoC.

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

Промежуточные результаты программ, представленные на ERI Summit 2019, подтверждают возможность достижения заявленной цели.

В частности, в рамках программы CRAFT показаны следующие результаты:

• Снижение трудоёмкости в 8-11 раз для аналоговых и цифровых интегральных схем.

• Сокращение трудоёмкости в 4.3-5.3 раза при переносе на технологию 16-нм GF, продемонстрированное на цифровых и цифро-аналоговых ASIC.

Однако существует ряд проблем:

• При обсуждении программы POSH признаётся, что абсолютно безошибочное проектирование невозможно: Качество платформы моделирования, по своей природе, ограничено качеством используемых моделей системы и векторов испытаний, и вполне вероятно, что ряд критических ошибок будет пропущен.

• Так же отмечается, что для достижения поставленных, программой IDEA, целей потребуется прорыв в алгоритмах машинного обучения и оптимизации. Для чего создаваемая платформа должна использовать прикладные методы машинного обучения для непрерывного развития, по мере появления новых наборов данных (примеров проектирования).

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

• Кроме того, увеличение уровня абстракции на котором человек описывает проектные решения, создаёт предпосылки для снижение качества проекта по транзисторному бюджету, потребляемой мощности, быстродействию. И в настоящее время нет оснований утверждать, что предлагаемые решения обеспечат незначительное снижение качества, по сравнению с ручным проектированием.

Обратим внимание на методы повышения производительности проектирования, используемые в программах DARPA:

• При разработке аппаратуры поднять уровень абстракции на котором человек описывает проектируемую систему. Все ниже лежащие уровни абстракции передать автоматическим средствам.

• Минимизировать участие человека в решении задачи проектирования, за счёт применения средств искусственного интеллекта.

• Создать условия для повторного использования качественных строительных блоков аппаратного обеспечения.

Парадигма проектирования остаётся прежней использование языков программирования для описания проектируемой аппаратуры.

Описанные программы опираются на базу существующих решений, готовые к использованию компоненты COTS, IP блоки, программные средства с открытым исходным кодом. Однако, опираясь только на готовые компоненты невозможно достичь высшей производительности или минимального энергопотребления. Разработка новых архитектур, максимально сложных SoC и SiP с использованием новых технологий производства, для этих задач остаётся всё та же методология проектирования, которая критикуется в программах DARPA.

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

В декабре 2019 года компания NVIDIA представила перспективную платформу для самоуправляемых автомашин и роботов [6]. Анонсированный процессор NVIDIA Orin появится не ранее 2022 год. Для обеспечения пятого уровня автономности самоуправляемого автомобиля, потребуется сочетать пару процессоров Orin и два не названных, перспективных, дискретных графических процессора NVIDIA [32]. Уровень быстродействия в этом случае составит до 2000 триллионов операций в секунду, при энергопотреблении до 750 Вт.

Очевидно, что для перспективных роботов, которые должны не просто перемещаться в пространстве, но и совершать полезную работу, необходима ещё большая производительность, при существенно меньшем потреблении энергии.

Другим примером могут служить современные программы создания суперкомпьютеров максимальной производительности, которые реализуют Евросоюз, США, Китай, Япония и другие страны. Эти программы, в частности, реализуемые DARPA и DOE, фокусируются на решении следующих задач [25]:

• Существенный рост производительности при умеренном энергопотреблении;

• Повышение надежности аппаратуры и программ;

• Рост продуктивности программирования.

Увеличение реальной производительности на разных типах задач требует создания принципиально новых SoC и SiP с использованием передовых архитектур и технологий производства, не основанных на ранее использовавшихся решениях.

Например, суперкомпьютер Neocortex, создаётся для задач классов DCIGN и RNN это более точное прогнозирование погоды, анализ геномов, поиск новых материалов и разработка новых лекарств. Предположительно, будет введено в эксплуатацию до конца 2020 года [37]. Он объединяет серверы Cerebras CS-1 и HPE SuperDome Flex в единую систему с общей памятью. Сервер Cerebras CS-1 основан на уникальном процессоре Cerebras. На изготовление одного процессора уходит целая 300-мм пластина [2].

Основой для роста сложности микропроцессорных систем, в ближайшем будущем, станет развитие технологии 3D TSV. Например, концепция, предложенная IBM [16], к настоящему моменту, изготовление микроканалов продемонстрировано в кремнии [22].

Рисунок 5. Концепция построения перспективных микропроцессорных систем предложенная IBM [16].

Краткая характеристика современной методологии, ключевые проблемы

К настоящему времени в проектировании сложных микропроцессорных систем сложилась практика, представленная на рисунке 6, в изложении Brucek Khailany (Director of research, ASIC & VLSI NVIDIA Corporation).

Рисунок 6. Использование языков программирования в проектировании СБИС [1].

В процессе проектирования используются различные языки программирования, как специализированные, в частности языки описания аппаратуры (HDL), так и языки высокого уровня общего назначения.

Создаваемое изделие описывается в виде программы на языке описания аппаратуры (HDL). Созданная программа, обычно, представляет собой модель уровня регистровых передач (RTL), которая должна быть преобразована в логическую схему посредством автоматического синтеза (Logic Synthesis). Далее созданную схему необходимо превратить в описание физического изделия. Для чего выполняется последовательность этапов проектирования, которую принято называть физическое проектирование (physical design).

Упрощённая схема маршрута проектирования СБИС, с выделением этапов физического проектирования, представлена на рис. 7.

Рисунок 7. Типовой маршрут проектирования с выделением этапов физического проектирования СБИС [23].

Здесь важно отметить, что инженерная задача разработки вычислительной системы (SiP) разделена на две задачи с разным понятийным аппаратом. Для логического проектирования - математический понятийный аппарат, а для физического проектирования - понятийный аппарат описывающий физические процессы.

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

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

Взаимосвязи понятий отрасли, в виде распространения задаваемых ограничений, на возможные варианты инженерных решений, показаны на рис. 8.

Рисунок 8. Распространение ограничений на варианты реализации, между понятийными компонентами отрасли вычислительной техники.

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

Трудоёмкость проектирования, например, для NVIDIA Xavier оценивается в 8000 человеко-лет [1].

По слова Jensen Huang, на создание NVIDIA V100 потребовалось несколько тысяч инженеров, ушло несколько лет, при примерной стоимости разработки в 3 миллиарда долларов [7].

При этом качество автоматического синтеза остается невысоким, а количество ошибок растет, опережая рост сложности проектируемых систем. На рис. 9 показана одна из оценок сложности верификации, в стоимостном выражении.

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

Рисунок 9. Стоимость разработки СБИС в зависимости от их сложности [7].

Следует отметить, что современная методология проектирования сложилась и развивалась на основе инструментов и их возможностей, а человек должен был подстраиваться под предлагаемые ему условия работы. И на современном этапе ситуация не изменилась. Предлагаемые в программах DARPA решения опираются на прогресс в инструментах, то есть методологии программирования, прикладной математике и развитии систем искусственного интеллекта. А человек, будет вынужден адаптироваться к новым условиям труда, которые будут навязывать новые средства проектирования.

Мышление человека в инженерной практике

Изложенный выше подход к созданию методологии проектирования принято называть инструментальным. То есть методология строится на возможностях инструментов, к работе с которыми человек должен адаптироваться. Возможен и противоположный инструментальному подход к созданию методологии проектирования [30].

Предполагая, что человек будет решать задачу проектирования, создание методологии возможно с опорой на современные знания, накопленные науками о человеке. То есть сама методология и её инструментарий создаются на основе знаний о том, как человек решает конкретную задачу.

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

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

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

Для каждой отрасли техники (технической системы) исторически сложилась своя последовательность этапов проектирования, т.е. уровней абстракции на каждом из которых рассматривается некоторая часть задачи проектирования. На каждом уровне абстракции (этапе разработки) используется специфичный набор понятий, описывающий решаемую на данном этапе проблему и её решение.

Понятийный аппарат технической отрасли, также, как и декомпозиция задачи, т.е. количество уровней абстракции и содержание решаемой на каждом уровне задачи, обусловлены физической природой создаваемых изделий.

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

Методология проектирования и реализующий её инструментарий, определяют порядок проектирования (последовательность этапов) и набор понятий в которых описывается задача и её решение. Таким образом, методология навязывает инженеру способ решения задачи проектирования, набор понятий, форму их представления, а, в итоге, и определённый стиль мышления. Однако, чрезмерный отрыв от иерархии абстракций и понятийного аппарата отрасли (замена или исключение понятий и уровней абстракции) может привести к потере качества решения и провоцирует человека совершать ошибки.

Происходит это в силу особенности работы человеческой психики в процессе решения инженерных задач.

Мозг (память и мышление) оперирует комплексами, объединяющими все известные субъекту знания о некотором объекте и его ассоциативные связи с другими объектами [20]. То есть визуальное и вербальное представление понятий взаимосвязаны. Но восприятие вербальных и визуальных объектов имеют разные физиологические механизмы и объединяются только на уровне высших психических процессов.

Установлено, что в силу личных особенностей мышления, некоторые люди легче оперируют вербальными понятиями, а другие визуальными [33].

Изучение человека в процессе трудовой деятельности привело к выделению в психологии отраслей инженерной психологии и психологии труда. Также, с развитием вычислительной техники, сформировалась область психология программирования [34].

В частности, в рамках психологии программирования, установлено, что профессиональные программисты обладают, отличными от представителей других профессий, особенностями мышления. В том числе, развитыми вербальными способностями. То есть быстрее и с меньшей умственной нагрузкой осваивают новые языки, в том числе искусственные, и работают с текстами [17, 27].

Длительная профессиональная деятельность может приводить к психологической профессиональной деформации личности, которая выражается, в частности, в формировании стереотипного мышления о проблематике отрасли и методах работы, используемых при решении задач отрасли [15].

Ошибка - неизбежный результат деятельности человека. Вероятность совершения ошибки определяется многими факторами среди которых сам человек, его физическое и психоэмоциональное состояние, уровень знаний и навыков, а также факторы условий, в которых совершается деятельность [30].

Любая работа ума создаёт умственную нагрузку, которая постепенно утомляет нервную систему, что снижает концентрацию и повышает вероятность ошибки. Умственная нагрузка, при решении одной и той же задачи, может различаться в зависимости от условий в которых человек должен эту задачу решать. Например, слепая игра в шахматы (не глядя на доску) или решение ханойской головоломки в уме (без физического перемещения дисков) создают большую умственную нагрузку, чем те же задачи находящиеся в поле зрения [10, 12].

Мышление в процессе решения задачи проектирования представляет собой последовательность интеллектуальных действий.

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

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

Восприятие информации предполагает установление соответствия между формами представления информации (установлены методологией) и известным человеку понятийным аппаратом отрасли. Тогда возникает понимание условий задачи и выполняется поиск решения.

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

Решение формируется как последовательное описание взаимодействия компонентов присущих данной отрасли техники. То есть, решение задачи является протяжённым во времени процессом в течении которого создаётся описание решения.

Именно в этом процессе и происходит создание информации, когда понятия отрасли, в которых человек мыслит о задаче, преобразуются в описание решения, в установленной методологией форме.

Таким образом, в процессе решения задачи проектирования, восприятие и создание информации повторяются многократно. Что требует от человека преобразования понятий отрасли, в которых он мыслит о задаче, в установленные методологией формы представления информации и обратно.

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

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

Дополнительная умственная нагрузка определяется особенностями методологии и реализующих её инструментов (т.е. САПР и др.). Например, необходимость учитывать, в процессе проектирования, понятия отрасли, которые в методологии отсутствуют, создаёт дополнительную умственную нагрузку и повышает вероятность ошибок.

Связь между формой представления понятий и скоростью восприятия понятий (условий задачи), установлена экспериментально. Следствием этого стало введение терминов образный интерфейс, когнитивная графика, экологический интерфейс. Создание таких интерфейсов внедрено в инженерной практике, прежде всего в операторской работе по управлению сложными промышленными объектами [29].

В некоторых отраслях исторически сложилось и внедрено в САПР введение процесса решения в поле зрения, что упрощает восприятие понятий (т.е. процессов и взаимосвязей) и поиск решения.

В качестве примера можно привести отрасль авиастроения. Для примера рассмотрим, выполненный не профессионалом, проект тяжёлого конвертоплана созданный в САПР T-FLEX CAD 16 (см. рис. 10). Проект состоящий из более чем 60000 тел был создан одним инженером, исключительно на основе информации из открытых источников и собственного опыта проектирования. На исследование предметной области ушло около 2-х месяцев и ещё примерно 6 месяцев периодической работы на реальное проектирование [31].

Рисунок 10. Проект летательного аппарата в САПР T-FLEX CAD 16.

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

Описание решения ведётся в визуальной среде, где объекты прямо соответствуют понятиям в которых человек мыслит о задаче. Взаимодействие объектов также легко воспринимается и прямо соответствует физическим процессам отрасли. Промежуточные этапы описания и конечное решение доступны для многократного анализа на предмет улучшения и выявления ошибок. Используемые в проектировании САПР и другие программные средства позволяют наблюдать поведение проектируемых систем и физические процессы (см. рис. 11).

Рисунок 11. Визуализация обтекания модели самолёта в виртуальной аэродинамической трубе.

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

В проектировании СБИС точным решением является описание физической структуры изделия, которая будет создана в процессе изготовления СБИС.

В отличии от приведённого примера отрасли авиастроения, отрасль вычислительной техники, имеет существенно иные физические основания и сложно организованную структуру понятийного аппарата (см. рис. 8), который носит более абстрактный характер.

Источники проблем методологии проектирования

Анализ методологии на предмет поиска источников проблем проведён с точки зрения условий, создаваемых методологией, для работы мышления человека.

Конфликт формы представления понятий

Используемая методология проектирования требует от разработчика представить физическое изделие в форме программы. На всех этапах разработки создаваемое изделие описывается средствами языков программирования, то есть алгоритмическими понятиями, в форме программ (см. рис. 6).

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

Требуется всё многообразие не алгоритмических понятий отрасли, представить их алгоритмическим выражением (средствами используемых языков программирования). В то время, как разработка вычислительных систем и СБИС не тождественна программированию, на уровне понятийного аппарата. Понятийный аппарат программирования лишь подмножество понятийного аппарата отрасли вычислительной техники.

Такая ситуация создаёт конфликт формы представления понятий, а значит и дополнительную умственную нагрузку.

На практике установлено, что текст, далеко не всегда, лучшая форма представления понятий, в том числе алгоритмических. Примером могут служить медицинские алгоритмы. Практика показала, что их текстовое описание не лучший способ представления, потому, в настоящее время, используются схемы алгоритмов, в частности визуальный язык ДРАКОН [21].

Разрыв целостности маршрута и понятийного аппарата

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

Применительно к существующей технологии производства СБИС выделяют следующие проблемы логического синтеза [23]:

• Задержка на межсоединениях становится доминирующей, что требует совмещения этапов sizing/physical/logic synthesis. Логический синтез без учета реализации схемы в кремнии неэффективен.

• Изготовление транзисторов усложняется, что делает критическим методы проверки, рассеиваемая мощность становится определяющим фактором.

Многие задачи физического проектирования NP-трудны решаются при помощи эвристик, которые, обычно, находят почти оптимальные решения [24]. Необходимо заметить, что при использовании эвристик, важным является наличие на выходе фильтра здравого смысла оценки результата человеком. Без развитых средств визуализации, эффективный контроль качества синтеза человеком не возможен.

Для решения этой проблемы, в программе IDEA, предлагается использовать, на этапе логического синтеза и физического проектирования СБИС, обученные модели искусственного интеллекта (см. рис. 2). При этом результаты должны контролироваться человеком (см. рис. 3).

Любой из HDL является, прежде всего, языком программирования и, как следствие, инструментом более высокого уровня абстракции, чем понятийный аппарат этапа схемотехнического проектирования. Кроме того, языки программирования применяются на всех этапах проектирования, как средство описания решения (см. рис. 6). Тем самым подталкивая человека мыслить лишь об алгоритмах.

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

В рамках применяемой методологии логический синтез и схемотехническое проектирования становятся частью этапа физического проектирования СБИС. Понятийный аппарат этапа схемотехнического проектирования вытесняется на этап физического проектирования, а на ранних этапах разработки человек мыслит на уровне алгоритмов. Как следствие, навыки схемотехнического проектирования становятся частью этапа физического проектирования СБИС.

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

Разрыв маршрута проектирования (последовательного уточнения решения) выражается, в том числе, в трудностях понимания между разными специалистами. Люди, выполняющие решение задачи на разных её этапах, разделены на уровне навыков, то есть им труднее понять друг друга, в силу владения разным понятийным аппаратом.

Требования к личным навыкам

В силу применения языков программирования для описания создаваемого устройства, основная форма представления информации, с которой работает человек тексты на искусственных языках (см. рис. 12).

Рисунок 12. Описание двухвходового мультиплексора на языке SystemVerilog [13].

Как следствие, основная часть умственно работы, т.е. восприятие и создание информации, связанна с восприятием и созданием текстов на искусственных языках (текстов программ).

Работа с текстом с минимальной умственной нагрузкой требует развитых вербальных навыков, которые формируются далеко не у всех взрослых людей [33].

Для формирования развитых вербальных навыков (навыков работы с текстами), необходимо соответствующее обучение. Установлено, что такие навыки формируются у профессиональных программистов [17, 27]. Но далеко не у всех людей, прошедших профессиональное обучение по специальностям программная инженерия (software engineer) или прикладная математика.

Применяемая методология требует, чтобы разработчики микропроцессорных систем обладали навыками программистов. Фактически методология превращает разработку СБИС в программирование. Однако, микропроцессорная система является физическим объектом, создание которого требует существенно больших знаний, чем приобретают программисты в процессе обучения. В разработке сложных микропроцессорных систем должны принимать участие инженеры разной специализации, то есть люди с разными знаниями и навыками. И далеко не все из них будут обладать развитыми вербальными навыками. А значит, при работе с текстами, они будут неизбежно испытывать повышенную умственную нагрузку и допускать большое количество ошибок.

Вывод

Все выше описанные особенности методологии с применением HDL, ставят человека в такие условия труда, что в процессе решения инженерной задачи существенно повышается вероятность ошибки. Кроме того, создаётся повышенная умственная нагрузка, ведущая к увеличению трудоёмкости инженерной задачи. А значит растёт требуемое количество инженеров и времени на решение задачи. Тем более при необходимости достижения предельных параметров разрабатываемого изделия.

Проблема и предлагаемое решение

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

Известно лишь два подхода к построению методологии проектирования инструментальный и человеко-ориентированный (антропоцентрический).

Первый лежит в основе программ реализуемых, в настоящее время, DARPA. Сомнения вызывает сам принцип решения проблемы - исключить человека из процесса проектирования.

Во-первых, инженерное дело изменчиво, как по условиям задачи, так и по способам её решения. Например, в процессе развития технологий полупроводникового производства изменились характеристики технологии производства СБИС (соотношение задержек на вентилях и проводниках, существенно снизились размеры транзисторов и уровень рассеиваемой мощности), что изменило способы решения задачи проектирования. И в ближайшем будущем, технология производства микропроцессорных систем, неизбежно, претерпит существенные изменения.

Во-вторых, прогресс ИИ (машинного и глубокого обучения) достигнут в условиях постоянного контекста задачи, т.е. компоненты задачи и критерии качества решения со временем не меняются. Но в инженерном деле, в частности в проектировании СБИС контекст задачи изменчив. При том, что качество решения задачи проектирования СБИС оценивается по нескольким критериям, и в разных областях применения СБИС значимость критериев различна. И кроме того, для обучения ИИ требуется большое количество примеров, но в области проектирования СБИС таких примеров может оказаться недостаточно.

В связи с этим, некоторые успехи в достижении поставленных в программах DARPA целей, не дают гарантии дальнейшего роста производительности проектирования на основе предлагаемой парадигмы. Прежде всего, применительно к микропроцессорным системам (SoC & SiP) предельных параметров.

Второй подход для создания методологии проектирования, в отрасли вычислительной техники, ранее не применялся.

Однако, инженерная практики в других отраслях техники и личный опыт автора говорят о том, что человеко-ориентированный подход может дать хороший результат в повышении производительности труда при решении инженерных задач.

Автор предлагаемого проекта, наблюдал на практике эффективность схемного проектирования при разработке микроархитектуры микропроцессора. В рамках проекта суперкомпьютера Ангара, под руководством Эйсымонта Л.К., автор участвовал в разработке микропроцессора с массовым параллелизмом, где применялся метод схемного проектирования. Разработка микроархитектуры выполнялась одним человеком, обладавшим большим опытом схемотехнического проектирования. Применение схемного проектирования показало существенно меньшее количество ошибок, допускаемых человеком, при разработке микроархитектуры и схемотехнической реализации функций блоков. При этом, описание уже готовых схем, на языке Verilog, приводило к появлению ошибок, отсутствовавших в схемном описании. Для сравнения, работая в INTEL Corp., автор участвовал в разработке микропроцессора Kevet (проект закрыт). В проектировании RTL модели микроархитектуры, относительно простого микропроцессора, участвовало 6 инженеров. Для верификации RTL кода, только на микроархитектурном уровне, было задействовано 20 человек.

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

Ранее упомянутый пример, проект тяжёлого конвертоплана выполненный в САПР T-FLEX CAD 16, интересен тем, что проектирование ведётся в визуальной среде, дающей явную связь между понятиями, в которых мыслит инженер, и объектами, составляющими проектируемую систему.

Другой пример из области ракетостроения. При создании космической системы Энергия-Буран, для повышения производительности программирования, были созданы проблемно-ориентированные языки, основанные на терминах, понятиях и форме представления алгоритмов управления и испытаний, используемых разработчиками корабля. Такой подход позволил повысить производительность программирования и надёжность программного обеспечения. В дальнейшем, на основе когнитивно-эргономического подхода, был создан графический язык ДРАКОН. Применение его для создание различных ракетно-космических систем доказало эффективность идей, положенных в его основу [14, 28, 39].

Эти практические примеры, позволяют говорить о том, что возможности человека, по решению инженерных задач, полностью не раскрыты. При построении методологии проектирования, с применением современных знаний о когнитивной деятельности и подходов инженерной психологии, можно ожидать существенного роста производительности труда.

Литература

1. A modular digital VLSI flow for high-productivity SOC design. Brucek Khailany director of research, ASIC & VLSI NVIDIA CORPORATION. ERI Summit 2018.

2. Cerebras процессор для ИИ невероятных размеров и возможностей. Геннадий Детинич. 20.08.2019. https://3dnews.ru/992698 (дата обращения: 11.11.2020)

3. DARPA мечтает радикально упростить проектирование чипов. 04.07.2018 https://3dnews.ru/972103 (дата обращения 07.05.2019)

4. IDEA & POSH program updates. Andreas Olofsson. DARPA MTO program manager. ERI Summit 2019.

5. Intelligent Design of Electronic Assets (IDEA) & Posh Open Source Hardware (POSH) // Andreas Olofsson Program Manager, DARPA/MTO. Proposers Day Mountain View, CA. 9/22/17.

6. NVIDIA Introduces DRIVE AGX Orin Advanced, Software-Defined Platform for Autonomous Machines. Tuesday, December 17, 2019. https://nvidianews.nvidia.com/news/nvidia-introduces-drive-agx-orin-advanced-software-defined-platform-for-autonomous-machines (дата обращения: 11.11.2020)

7. Silicon Compilers - Version 2.0 // Andreas Olofsson Program Manager, DARPA/MTO. International Symposium on Physical Design. March 25-28, Monterey, CA. 2019.

8. Будылина С.М., Смирнов В.М. Физиология сенсорных систем и высшая нервная деятельность: Учеб. пособие для студ. высш. учеб, заведений. М. 2003.

9. Бухтев А. Методы и средства проектирования систем на кристалле. // Chip News 2003. -4.

10. Гигиена труда : учебник / под ред. Н. Ф. Измерова, В. Ф. Кириллова. -2-е изд., перераб. и доп. -М. : ГЭОТАР-Медиа, 2016.

11. Горбунов В., Елизаров Г., Эйсымонт Л. Экзафлопсные суперкомпьютеры: достижения и перспективы. Открытые системы. СУБД 2013. -07 http://www.osp.ru/os/2013/07/13037342/ (дата обращения 05.11.2013)

12. ГОСТ Р ИСО 10075-2011 Эргономические принципы обеспечения адекватности умственной нагрузки. Основные термины и определения.

13. Дональд Томас. Логическое проектирование и верификация систем на SystemVerilog / пер. с анг. А. А. Слинкина, А. С. Камкина, М. М. Чупилко; науч. ред. А. С. Камкин, М. М. Чупилко. М.: ДМК Пресс, 2019.

14. ДРАКОН [электронный ресурс]: Википедия. Свободная энциклопедия. https://ru.wikipedia.org/wiki/ДРАКОН (дата обращения: 11.11.2020)

15. Ильин Е. П. Дифференциальная психология профессиональной деятельности. СПб.: Питер, 2008. 16. Инновационные суперкомпьютерные технологии и проблемы создания отечественной перспективной элементной базы. / Л.К.Эйсымонт, В.С.Горбунов. Доклад на 5-м Московском суперкомпьютерном форуме. 21 октября 2014 года.

17. Исследование способности к усвоению искусственных языков у программистов. Орел Е. А. ОРГАНИЗАЦИОННАЯ ПСИХОЛОГИЯ. Т. 2. 2. 2012.

18. Как устроена универсальная разумная система? Анохин К.В. Наука о поведении: четыре главных вопроса Школа молодых ученых, 7-13 октября 2015. https://scorcher.ru/articles/images/3678/anokhin.pdf (дата обращения 08.09.2019)

19. Канышев В., Шагурин И. Применение языка SystemC и средств разработки на его основе для проектирования Систем на кристалле. // Chip News 2006. -9.

20. Когнитом: разум как физическая и математическая структура. К.В. Анохин. Семинар Социофизика. 27 сентября, 2016.

21. Космический ДРАКОН. Как заброшенный проект "Роскосмоса" подарил язык литовской медицине. Николай Воронин. BBC NEWS Русская служба. 5 августа 2019. https://www.bbc.com/russian/features-48583773 (дата обращения: 11.11.2020)

22. Кремниевый радиатор с микроканалами с жидкостью в 100 раз лучше металлического. 01.03.2019 https://3dnews.ru/983605 (дата обращения: 05.05.2019)

23. Ложкин С.А., Марченко А.М. Математические вопросы синтеза интегральных схем. [электронный ресурс] http://mk.cs.msu.ru/index.php/Математические_модели_и_методы_синтеза_СБИС (дата обращения: 15.10.2013)

24. Марков И. Проектирование интегральных схем: от разбиения графов до временной оптимизации систем. Лекции на факультете ВМК МГУ. 2013.

25. На пути к экзафлопсному суперкомпьютеру: результаты, направления, тенденции. / Горбунов В.С., Эйсымонт Л.К. Доклад на третьем Московском суперкомпьютерном форуме 01.11.2012

26. Общая психология : учебник для вузов / В. В. Нуркова, Н. Б. Березанская. 3-е изд., перераб. и доп. М. : Издательство Юрайт, 2017.

27. Особенности интеллекта профессиональных программистов. Орел Е. А. BECTH. MOCK. УН-ТА. СЕР. 14. ПСИХОЛОГИЯ. 2007. 2.

28. Параджанов В. Д. Как улучшить работу ума: Алгоритмы без программистов это очень просто! М.: Дело, 2001.

29. Представление информации для поддержки когнитивной деятельности человека-оператора. Анохин А. Н. // Актуальные проблемы психологии труда, инженерной психологии и эргономики. Выпуск 6 / Под ред. А. А. Обознова, А. Л. Журавлева. М.: Издательство Институт психологии РАН, 2014.

30. Применение концепций инженерной психологии к профессиям, традиционно не считающимся операторскими. С.А. Дружилов // Электронный журнал Психологическая наука и образование 1 2011.

31. Проект тяжёлого конвертоплана в T-FLEX CAD 16 (более 60000 тел). T-FLEX CAD. 25.11.2019. https://3dtoday.ru/blogs/topsystems/proekt-tyazhelogo-konvertoplana-v-t-flex-cad-16-bolee-60000-tel (дата обращения: 11.11.2020)

32. Процессор NVIDIA Orin шагнёт за пределы 12-нм технологии с помощью Samsung. Алексей Разин. 19.12.2019. https://3dnews.ru/1000054 (дата обращения: 11.11.2020)

33. Психология мышления. Гурова Л.Л. М.: ПЕР СЭ, 2005.

34. Психология программирования: цели, проблемы, перспективы. Рожников В. А. ОБЩЕСТВО: СОЦИОЛОГИЯ, ПСИХОЛОГИЯ, ПЕДАГОГИКА 3 2014.

35. Стасевич К. Человеческий мозг похудел на 14 миллиардов нейронов. 01.03.2012 года. http://compulenta.computerra.ru/archive/neuroscience/664455/ (дата обращения: 15.10.20013)

36. Стрелков Ю.К. Инженерная и профессиональная психология. 2-е изд. - М.: Издательский центр Академия, 2005.

37. Суперкомпьютер Neocortex: 800 тыс. ядер Cerebras для ИИ. Юрий Поздеев. 09.06.2020. https://servernews.ru/1013005 (дата обращения: 11.11.2020)

38. Финский суперкомпьютер получит 200 тысяч ядер благодаря 7-нм CPU AMD EPYC Rome. 15.12.2018 https://servernews.ru/979696 (дата обращения: 07.06.2019)

39. Энергия Буран [электронный ресурс]: Википедия. Свободная энциклопедия. https://ru.wikipedia.org/wiki/Энергия__Буран (дата обращения: 11.11.2020)

Если вы прочитали мою статью, то вы слышали про технологию Skywater 130nm. Google сделала анонс второй программы Multi-project-wafer, и вы можете произвести свою микросхему за бесплатно. С несколькими оговорками

• Проект должен быть по технологии 130нм Skywater

• Проект должен быть доступен всем

• Проект должен находиться под лицензией из списка одобренных

• Проект должен быть готов к июню 18 числа 2021-го года.

Несмотря на то, что 130нм очень древняя технология почти 20 летней давности, тем не менее с ней можно разработать самые разнообразные и интересные проекты.

Меня поправили в коментариях

130 нм мэйнстрим в части микроконтроллеров, многих видов автомобильных и высоковольтных силовых микросхем, а вовсе не древняя технология. Не надо все мерить по процессорам для песональных компьютеров, современные 130 нм так же похожи на 130 нм из Pentium III, как Tesla 3 похожа на Ford T. И там, и там четыре колеса, на этом сходство заканчивается.

Для изготовления микросхем Google и её партнер efabless выбрали компанию Skywater Technology Foundry, ранее известную под названием Cypress Semiconductor. Производство первых микросхем будет окончено в декабре.

Ранее бывшую собственным производством Cypress и выделенную в независимую компанию. Сама Cypress продолжает существовать в fabless режиме.

Кхм, меня попровляют в личных сообщениях, спасибо @amartology.

Технология имеет слой для полупроводников и 5 металлических слоёв. Заказчики проектов получат 50 экземпляров в корпусе WCLSP 6x10.

Из проектов прошлого года мне понравился вот этот. Это проект передатчика-приёмника для любительских спутников AMSAT.

Для того чтобы вы смогли разработать свою микросхему гугл также выпустила Process Development Kit доступный по ссылке вот тут. Важно сказать, чтобы гугл вашу микросхему вообще одобрил она должна быть собранна по проекту Caravel user project.

Если у вас есть готовый проект написанный на Verilog, его можно собрать используя OpenLANE.