Junior FPGA Design Engineer: как стать?

    Всем привет!

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

    Разработка под FPGA (ПЛИС) — это не просто какой-то язык. Это очень объемная область, с огромным количеством подводных камней и нюансов.

    В этой статье вы найдете:
    • список тем, которые должен освоить начинающий разработчик под FPGA
    • рекомендуемую литературу по каждой из тем
    • набор тестовых вопросов и лабораторных работ
    • классические ошибки новичков (и советы по исправлению)

    Добро пожаловать под кат!

    Что надо знать и уметь


    Цифровая схемотехника


    Необходимо:
    • знать базовые цифровые узлы (логические элементы И/ИЛИ/НЕ, шифраторы, мультиплексоры, суммматоры и пр.)

    Литература:
    • David Harris, Sarah Harris. «Digital Design and Computer Architecture» — очень большая книга, рассказывающия от азовов до верхов. Есть версия на русском языке. Я просмотрел русскую версию: читается очень быстро и легко.
    • Угрюмов Е.П. «Цифровая схемотехника» — классический советский учебник, со всеми вытекающими последствиями (некоторые темы объяснены слишком сложно, и нельзя сразу понять нужна ли тебе эта информация сейчас или можно её пропустить). Я читал более старое издание, возможно в издании от 2010 года всё изменилось в лучшую сторону, не смотрел.

    Тестовые вопросы:
    1. Чем цифровая схемотехника отличается от аналоговой?
    2. Какие есть базовые цифровые узлы? В каких из них выход зависит только от входа?
    3. Что такое мультиплексор? Нарисуйте схему мультиплексора 4 в 1 из примитивных элементов И/ИЛИ/НЕ.
    4. Постройте таблицу истинности для выражения: X = A or ( B and C ) or D.

    Синтаксис HDL-языка


    Сюда входит:
    • знание синтезируемых конструкций (синтаксиса) HDL-языка
    • знание, как описывать базовые цифровые узлы с помощью HDL-языка
    • понимание во что (со стороны базовых цифровых узлов) превращается тот или иной кусок HDL-кода
    • умение писать на HDL-языке для получения нужного поведения

    В качестве HDL-языка я рекомендую сначала изучить самые базовые конструкции Verilog'a, а затем переключится на SystemVerilog.

    Литература:
    • Pong P. Chu. «FPGA prototyping by Verilog examples» — расписывается Verilog, начиная с азов. Подробно разбирается синтаксис и есть огромное количество примеров, как простых (счетчики), так и уровнем повыше (UART и VGA).
    • Иосиф Каршенбойм. «Краткий курс HDL» — классический курс на русском языке.
    • www.asic-world.com — сайт с кучей примеров как по Verilog, так и по SystemVerilog.
    • David Harris, Sarah Harris. «Digital Design and Computer Architecture» (см. выше)
    • Stuart Sutherland. «SystemVerilog for Design» — книга про различия Verilog и SystemVerilog. Для чтения необходимы базовые знания Verilog'a. Рекомендуется к прочтению для понимания, какие удобства были внесены в новом стандарте.

    Тестовые вопросы:
    1. Чем блокирующие присваивание отличается от неблокирующего? Когда стоит применять одно, когда другое?
    2. Есть ли разница между следующими тремя описаниями? Если да, то в чём она проявляется?
      // code 1:
      assign a = b + c;
      
      // code 2:
      always @( b or c )
        begin
          a = b + c;
        end
      
      // code 3:
      always @( * )
        begin
          a = b + c;
        end 
              


    Тестовые задания:
    1. Нарисуйте схему из базовых цифровых узлов для следующего кода:
    Скрытый текст
    module test(
      input              clk_i,
    
      input              a_i,
      input        [2:0] b_i,
    
      output reg         x_o
    
    );
    
    reg [7:0] cnt = 8'd0;
    reg [7:0] cnt2;
    
    wire      c;
    reg       d;
    
    always @( posedge clk_i )
      cnt <= cnt + 1'd1;
    
    always @(*)
      begin
        cnt2 = cnt + 1'd1;
      end
    
    assign c = ( cnt < 8'd5 ) && ( a_i == 1'b0 );
    
    always @( posedge clk_i )
      begin
        d   <= c;
        x_o <= c ? ( d ) : ( cnt2[ b_i ] ); 
      end
    
    endmodule
    


    2. Нарисуйте поведение схемы из п.1 (т.е. состояния всех «переменных») при следующих входных воздействиях:


    Скрытый текст
    Времянки нарисованы с помощью онлайн-редактора WaveDrom.


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

    Интерфейс модуля:
    Скрытый текст
    module traffic_light(
      // cинхроимпульс
      input  clk_i,
    
      // асинхронный сброс
      input   rst_i,
    
      // Если 1, то горит соответствующий цвет, если 0 — то он не горит
      output  red_o,
      output  yellow_o,
      output  green_o
    );
    


    Симулирование и верификация HDL-кода


    Необходимо:
    • знать несинтезируемые конструкции Verilog'a и SystemVerilog'a
    • уметь написать простой тестбенч, запустить его в симуляторе (например, ModelSim)
    • понимать, как должен быть устроен «идеальный» тестбенч

    Литература:
    • testbench.in — огромное количество примеров верификации с использованием Verilog'a и SystemVerilog'a.
    • Chris Spear. «SystemVerilog for Verification» — хорошая, большая книга о верификации с помощью SystemVerilog. Читается легко, можно найти ответы на многие вопросы.

    Видеоуроки:

    Тестовые вопросы:
    1. Чем function отличается от task?
    2. Представим, что Вы написали максимально простую HDL-модель 5-стадийного RISC-процессора. Как будете её верифицировать? (Вопрос повышенной сложности).
    3. Чем различается queue от mailbox (типы данных в языке SystemVerilog)?
    4. Чем отличается функциональная симуляция от временной? Когда какую необходимо использовать?


    FPGA


    Необходимо:
    • знать из каких базовых элементов состоит FPGA
    • понимать как происходит workflow разработки под FPGA
    • интуитивно представлять какие операции для FPGA дешевые, а какие дорогие (по частоте и ресурсам)

    Я работаю с чипами Altera, поэтому здесь и дальше название семейств и утилит будет от этого вендора. Если вы знаете аналогичную литературу для Xilinx — напишите в личку или в комментариях — я обязательно добавлю её в статью.

    Литература:

    Видеоуроки:

    Тестовые вопросы:
    1. Чем отличается FPGA от ASIC? Из каких блоков состоит (или может состоять) FPGA?
    2. Попробуйте очертить круг задач, для которых хорошо (экономически целесообразно) использовать FPGA, а для каких MCU и CPU?
    3. Какие аппаратные блоки вы знаете? Для чего они используются? (Под аппаратными блоками здесь имеется в виду Hard IP).
    4. В семействе Y используется LUT с тремя входами и одним выходом. Какое минимальное количество LUT'ов надо для вычисления assign eq = ( a == b );, если a и b это 32-битные целые положительные числа? А если у LUT'a будет четыре (пять, шесть) входов?
    5. Необходимо создать одну-портовую память из 16 слов. Каждое слово шириной 100 бит. Сколько блоков M9K (9216 бит) будет занято? Считаем, что делаем проект под Cyclone III. (*)

    В вопросах, обозначенных (*) , разумеется, не надо помнить всё наизусть, а можно пользоваться даташитами.

    Синхронный дизайн и всё, что связано с таймингами


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

    Литература:

    Тестовые вопросы:
    1. Что такое timing constraints (констрейны)? Где они описываются и для чего нужны (для чего они используются)? Что будет, если их не описать?
    2. Что такое clock domain crossing? Как и когда надо его осуществлять?
    3. В чем разница между синхронным и асинхронным сбросом? Что будет если на вход синхронного сброса завести асинхронный сброс?
    4. Что такое latch (защелка, латч)? Какие последствия использования латча? Приведите пример кода, который создает латч.
    5. Что такое комбинационная петля? Какие последствия использования комбинационной петли?
    6. Что такое метастабильность? Как её достичь? Какие у неё есть плюсы и минусы?
    7. Что такое glitch (глитч)? Нужно ли с этим бороться? И если да, то где и как?
    8. Что такое setup time/hold time у D-триггера?


    САПР


    Необходимо:
    • уметь создавать проект
    • уметь описывать I/O пины и констрейны (хотя бы для простых ситуаций, без сложных I/O интерфейсов)
    • знать какие есть отчеты о сборке, какая информация содержится в каждом из них
    • уметь пользоваться инструментом для отладки на железе
    • уметь пользоваться инструментом для анализа таймингов (STA)
    • знать какие готовые IP-ядра/модули (FIFO, RAM, FFT, DDR, Ethernet и т.д.) предоставляет вендор и как их можно добавить в проект

    Литература:

    Видеоуроки:


    Тестовые вопросы:
    1. Какие этапы сборки происходят от нажатия на кнопку «Собери проект полностью» до получения готового бинарного файла? Что происходит на каждом из этапов?
    2. Как посмотреть удалось ли САПР'у уложить проект в заданные ограничения (констрейны)?

    Лекции и лабораторные


    Я два семестра читал курс «Разработка под FPGA» для студентов старших курсов университетов Санкт-Петербурга. В курс входили как лекции, так и набор лабораторных работ. Лекции основывались на литературе, которую была перечислена выше.

    План курса:
    Скрытый текст
    Введение:
      * Что такое ПЛИС? Области применения.
      * Обзор САПР ( Quartus ).
    
    Изучение языка Verilog:
      * Отличительне черты языков описания аппаратуры ( HDL ).
      * Синтезируемые/несинтезируемые конструкции языка. 
    
      * Изучение синтезируемых конструкций языка:
        * Типы данных и способы их представления.
        * Операции, блокирующие/неблокирующие операции присваивания
        * Управляющие конструкции.
        * Блоки описания узлов комбинационного типа.
        * Блоки описания узлов последовательного типа.
        * Структурное/поведенческое описание проекта.
        * Параметризация.
        * Реализация на Verilog базовых цифровых узлов.
    
      * Изучение несинтезируемых конструкций языка ( +SystemVerilog ):
        * Применение несинтезируемых конструкций языка. Верификация. Testbench.
          Основные принципы создания testbench.
        * Основные функциональные блоки testbench'ей.  
        * Типы данных. Блоки процедурного типа.
        * Структуры данных для верификации ( массивы, очереди и т.д. ).
        * Функции и tasks.
        * Временная модель симуляции.
        * Использование базовых принципов ООП для верификации.
        * SystemVerilog Assertions.
        * Создание testbench для базовых цифровых узлов.
        * Обзор cуществующих методологий ( библиотек ) верификации.
    



    Названия лекций (в 2015 году):
    1. Введение в FPGA.
    2. Внутреннее устройство FPGA.
    3. Введение в Verilog/SystemVerilog. Примеры описания различных типов логики.
    4. Синхронный дизайн. Создание простых тестбенчей.
    5. Описание FSM, массивов и структур в SystemVerilog. Память: создание с помощью Verilog и MegaWizard.
    6. Как работает DCFIFO. Static Timing Analysis. TimeQuest, constraints.
    7. Верификация: coverage, assertions, SystemVerilog interfaces
    8. Интерфейсы семейства Avalon. IP-Cores. Qsys.
    9. Верификация: SystemVerilog OOP, constrained-random tests.


    Слайды к лекциям
    Скрытый текст
    К сожалению, это именно СЛАЙДЫ, которые мне помогали рассказывать лекции (не вся информация курса содержится на слайдах, некоторые я использовал как опору, а материал давался на доске).

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

    Лабораторные работы:

    Классические ошибки


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

    Путаница в присваиваниях (блокирующие и неблокирующие)


    Симптомы:
    • вы не очень уверено ответили на вопрос о блокирующих и неблокирующих присваиваниях (см. выше)
    • вы за собой замечаете, что в случайном порядке меняете "=" на "<=" (и наоборот), надеясь, что заработает
    • симулятор показывает странные вещи, вы начинаете сомневаться, что понимаете как работает D-триггер
    • результаты симуляции стабильно не совпадают с тем, что происходит на железе (где-то что-то плывет на такт)

    Лечение:
    • разобраться в материале по Verilog (см. литературу выше)
    • если вы хотите, чтобы результат симуляции совпадал с тем, что будет синтезировано и воплощено на железе, то запомните простое правило: в блоках, где описывается комбинационная логика (always_comb, always @(*)) вы обязаны использовать только блокирующие присваивания (=). В блоках, которые описывают триггеры (always_ff, always @( posedge clk… )) вы обязаны использовать только неблокирующие присваивания (<=).


    Проблема в таймингах


    Симптомы:
    • результаты симуляции не совпадают с тем, что происходит на железе
    • железо работает нестабильно: иногда явно видны помехи (например, на VGA)
    • «я добавил сигналтап, и после этого схема перестала корректно работать, я убрал сигналтап и всё хорошо»

    Лечение:
    • прописать все необходимые констрейны, (как минимум используемую тактовую частоту (или частоты) в *.sdc файле), подключить этот файл в проект
    • перекомпилировать проект. Зайти в TimeQuest и посмотреть, есть ли отрицательные слаки, и если есть, то дальше разбираться почему это происходи (возможно, достаточно покрутить настройки в Quartus'e, или придется переписывать куски код).

    Если вы видите странности в SignalTap, то перепроверьте, синхронны ли те сигналы, которые вы снимаете с частотой «стробирования».

    Не соблюдение принципов синхронного дизайна (асинхронщина)


    Продолжение первого пункта, но я решил его выделить отдельно.

    Симптомы аналогичные с предыдущим пунктом.

    Почему-то многие любят делать вот так:
    // BAD EXAMPLE
    ...
      input clk_i,
      ...
    
    logic [7:0] sec_cnt;
    logic [7:0] min_cnt;
    
    logic       last_sec_value;
    
    assign last_sec_value = ( sec_cnt == 8'd59 );
    
    always_ff @( posedge clk_i )
      if( last_sec_value )
        sec_cnt <= 'd0;
      else
        sec_cnt <= sec_cnt + 1'd1;
    
    always_ff @( posedge last_sec_value )
      min_cnt <= min_cnt + 1'd1;
    


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

    Или вот так:
    // BAD EXAMPLE
    ...
      input clk_a_i,
      input clk_b_i,
    ...
    
    logic [7:0] cnt_a;
    logic [7:0] cnt_b;
    logic [7:0] sum;
    
    always_ff @( posedge clk_a_i )
      cnt_a <= cnt_a + 1'd1;
    
    always_ff @( posedge clk_b_i )
      cnt_b <= cnt_b + 1'd1;
    
    always_ff @( posedge clk_b_i )
      sum <= cnt_a + cnt_b;
    


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

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

    Я догадываюсь, что это всё идет из 2000х, когда чипы были маленькими и разработчики выживали как могли.
    Скорее всего на маленьких частотах (типа 1 МГц) это прокатывало, но если вы собираетесь попасть в команду, которая делает серьезные вещи на топовых чипах, то за такие трюки можно легко вылететь со стажировки.

    Лечение:
    • пройтись по всему проекту, выписать (на бумажку) какой тактирующий клок (сигнал) используется для каждого триггера.
    • понять как это число можно свести к минимальному количеству (в разумных пределах, разумеется), исправить код согласно правил синхронного дизайна.
    • пройтись по всему проекту и внимательно отследить как происходит clock domain crossing (т.е. переход данных со одной частоту на другую). Исправить, если он происходит некорректно.
    • выполнить все шаги из пункта «Проблема в таймингах».


    Постоянная отладка на железе (игнорирование симуляции)


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

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

    Лечение:
    • написать тестбенч для всего проекта, либо для его частей
    • добиться корректной работы в симуляции
    • собрать проект, проверить на плате

    Если что-то не заработает на железе, то:
    • пройтись по пyнктам, обозначеным выше (тайминги и асинхронщина)
    • если проблемы в таймингах нет, то пытаться понять при каких входных воздействиях это происходит
    • подать эти воздействия в симуляции, убедиться, что проблема воспроизводится
    • исправить ошибку в RTL-коде, проверить в симуляции и на железе
    • обязательно: сделать вывод, почему предыдущий вариант симуляции не смог отловить эту ошибку


    Нет правил разработки (+ код с запашком)


    Симптомы:
    • вы много времени тратите на чтение (разбор) кода, который написали вчера.
    • вы часто пишите однотипный код (самые популярные клавиши на вашей клавиатуре это Ctrl+C и Ctrl+V)
    • вы не можете разобраться в том коде, который написал коллега (если вы работаете вместе над одним модулем/IP-ядром), а он — в вашем.

    Лечение:
    • ознакомиться с литературой, которая рассказывает как надо писать хороший код, например, Макконнелл. «Совершенный код»
    • разработать и описать правила разработки для команды. Или использовать готовые: NetFPGA, обсуждение на electronix #1, обсуждение на electronix #2, или тот, который использую я.
    • отдайте свой код на ревью более опытным разработчикам. Об этом можно попросить на форуме electronix'a в соответствующем разделе. Разумеется, желательно, что-то более серьезное, чем моргание светодиодов, иначе вас просто не поймут :).

    Заключение


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

    Уверен, что если Вы:
    • сможете легко отвечать на тестовые вопросы выше (без зазубривания, разумеется)
    • решите правильно лабораторные работы
    • избавитесь от «классических ошибок»
    • оформите 1-2 проекта на гитхабе и проверите их на железе. (желательно, сложнее, чем моргание светодиодиков и часики).

    то без проблем сможете претендовать на позицию джуниора в серьезной компании.

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

    Спасибо за внимание!
    Как всегда, буду рад вопросам и замечаниям в комментариях или в личной почте.

    P.S.
    Иногда мне в личке пишут:
    Добрый день.
    Я студент 3(4, 5) курса такого-то университета.
    Мне нравится идея писать под FPGA (параллелизм, можешь делать что хочешь, бла-бла-бла) и нравится Java (делал простенькие приложения под Android). Хочу чем-то из этим заняться более-менее серьезно. Что советуете учить?

    Чаще всего я им предлагаю глянуть две ссылочки (FPGA и JAVA) и самостоятельно сделать выводы.
    Метки:
    Поделиться публикацией
    Похожие публикации
    Комментарии 55
    • +1
      Отлично же!
      Спасибо за хороший материал для новичков :) Надеюсь, в наши редкие ряды прибудет пополнение
      • +5
        Надо же было все так в конце испортить! ;)
        • +1
          Могу дополнить: У Xilinx с документацией очень удобно работать используя Document Navigator (DocNav) — локальное приложение, которое содержит обновляемую базу данных всех официальных документов, там есть разные категории документов, можно искать, скачивать, хранить несколько разных версий и т.п. Документы несколько более раздроблены, но смысл тот же, что и у альтеры: есть набор документов, посвященных разным функциональным структурам каждого из семейств FPGA, несколько документов, посвященных процедурам САПР (Synthesis, Implementation, Timing Analysis) и т.д.
          • +5
            Вот, есть еще торт на Хабре, кто бы что ни говорил!
            Большое спасибо за материал, пригодится обязательно.
            • +1

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


              Раз тут такая статья, считаю это отличным местом, чтобы задать сопутствующий вопрос: я отношусь почти к студентам, которые хотят стать… скорее SoC designer, ASIC architector и подобное. Собственно множество вопросов возникает:
              Правильно ли в этом случае сначала выбирать FPGA и изучать хотя бы его основы? Поиск по вакансиям показал, что даже на junior требования очень размазаны, от C++ и, почему-то питона (иногда лиспа) до знания всех подряд интерфейсов, шин, архитектур. Вообще усредненный список знаний пугает. В каком направлении лучше всего двигаться? Какие есть учебные материалы ближе к моему выбору? В конце концов, под это учатся отдельно или как в программировании: сначала ты программист, потом старший программист, а потом уже можешь стать архитектором (не все проходят этот путь и такие архитекторы видны сразу)? Почему решил, что тут можно идти сразу в архитекторы — по наличию inter и junior вакансий у некоторых компаний.


              И стоит ли набирать опыт в виде разработки под arm, avr, x86, etc. на ассемблере (чтобы в тонкостях понимать эти архитектуры) или сконцентрироваться на verilog/vhdl?


              P.S. И почему все и везде лепят матлаб? Я понимаю, что ты не инженер, если не знаешь матлаб, но ума не приложу, как он помогает в проработке архитектуры, а не каких-то конкретных алгоритмов.

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

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

                SoC designer, ASIC architector

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

                И почему все и везде лепят матлаб?

                Чаще всего матлаб лепят те компании, которые занимаются ЦОС'ом.
                • 0

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

                • +3
                  SoC-дизайнер должен знать и уметь и железо, и софт, который будет на нем вертеться. Ни один RTL-дизайнер еще не стал SoC-дизайнером, разрабатывая свистелки по чужим спекам.

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

                    Спасибо за ответ. Т.е. получается, что нужно знать кучу всего и еще немного в присыпку? И не столь важен навык непосредственной реализации RTL, сколько понимание устройства всего, и как это еще должно между собой взаимодействовать? Опять же, не подскажите по литературе?


                    Заодно: для себя я пока пытаюсь реализовать какую-то совсем простую и примитивную SoC. В данный момент есть простейший CPU, который даже умеет что-то считать, а так же простой текстовый GPU, ну и самопальная шина (с подсматриванием в сторону wishbone). И я хочу довести это до этапа, что это действительно синтезируется и работает на плате, и что можно скармливать какой-то код, однако что-то перемудрил с режимами адресации, поэтому подзавис на RTL модуля загрузки данных, но отвлекся. Я двигаюсь в правильном направлении или это тупиковая ветвь и начинать стоит все же с своей реализации уже проверенных временем архитектур, например, OpenRISC? (попытка придумать все самому, в том числе ассемблер, очень хорошо вправляет мозги в плане — почему у других сделано так или иначе)

                    • 0
                      Нет таких книг, нужен опыт.

                      Сейчас свои процесорные ядра никто не делает — все берут ARM за редким, редким исключением.
                      Поэтому лучше изучать шину AXI4. И I2C.
                      • 0
                        Этим и отличается SoC-дизайнер / ASIC-архитектор от инженегров. Он знает, когда использовать ARM (и какой), когда ASIP, когда написать свое ядро. Знает, когда использовать AXI4, а когда можно и AXI3, а когда и AHB пойдет, и когда лучше шину пошире и помедленнее, а когда лучше поуже и побыстрее. Знает, как испортить жизнь своим программистам (например, дать им многоядерный проц с некогерентными кэшами и DMA). Знает, какое IP можно купить на рынке. Знает, как все это должно работать, если надо динамически менять частоту, или выключать питание в части кристалла, и кто будет все это верифицировать.

                        Короче, единственный надежный способ — устроиться к кому-то, кто все это уже знает, подмастерьем.
                        • 0
                          kahi4, Если Вы используете altera, то подойдут cookbook'и и guide'ы, они хорошо рассматривают вопросы, как и бесплатные видеотренинги на официальном сайте, где объясняют основы связи между FPGA и SoC, процесс создания проекта и пр.
                          так же хорошо подойдет портал rocketboards.org
                          Скажите, пожалуйста, а какую плату Вы используете? я сейчас только начал знакомиться с SoC и в качестве учебной получил на выбор Arrow SoCkit, DE1-SoC и DE0-nano-SoC, в прочем, в интернете есть хорошие примеры только на первую и немного на вторую
                          • 0

                            У самого меня алтера циклон 2 на китайской старой плате. Сейчас думаю обновлять, но не хочу брать готовую SoC, потому что вроде как я сам этим собрался заниматься (комбинировать ip-cores), а не брать готовое, поэтому посматриваю на xilinx kinex 7

                            • 0
                              ИМХО для обучения DE1-SoC изначально достаточно разнообразной периферии и есть обычные IDC разъёмы которые спокойно покупаются, что даёт возможность что то своё подключить если потребуется.

                              Arrow SoCkit — тоже хороша но HSMC хрен достанешь если что то своё захочется подключить.

                              DE0-nano-SoC мало периферии но опять же IDC я бы сказал это больше не для обучения а для прототипирования.
                  • +2
                    Чаще всего я им предлагаю глянуть две ссылочки (FPGA и JAVA) и самостоятельно сделать выводы.

                    Что-то, не понял я какие выводы должен студент сделать из этих ссылок? Вроде по Java и вакансий в десятки раз больше и вилка, похоже, что выше, по тем вакансиям что я вижу. Что-то не совсем понял я этой фишки…
                    • 0
                      Вывод простой: если душа не лежит к электронике и к FPGA, то перспективнее выбирать другую сферу.

                      А если и лежит, то надо осознавать, что вакансий в этой сфере не так много даже в больших городах (если мы говорим про Россию, разумеется).
                      • +1
                        Кстати, если исходить только из подобных соображений, то поступление на прикладную математику и информатику в начале 90-х было бы абсолютно идиотским решением :)
                      • +1
                        КО mode ON
                        При меньшем знании материала и знании JAVA на текущем рынке можно проще получить ЗП в 50к и обучением, нежели знать VGA и получить 50к как специалист.
                        КО mode OFF
                        Сам имею образование по проектированию устройств и вычислительной технике, знаю тонны RFC и обработки протоколов как программно, так и аппаратно, но зарабатываю на жизнь андройд разработкой (ведущий спец), работаю как главный инженер по VOIP + 1-2 своих проекта с циклом жизни год-два.
                        Есть огромное желание изучить FPGA, но рынок и жизнь диктует обратное. Речь об идейности.
                      • +1
                        Мне нравится вопрос «Представим, что Вы написали максимально простую HDL-модель 5-стадийного RISC-процессора. Как будете её верифицировать? (Вопрос повышенной сложности)». Буду спрашивать на собеседованиях.
                        • +1
                          Вот так. Умеете вы опустить человека с небес на землю. «Улыбающийся смайл»
                          Замечательная статья. Сжато и в одном месте. Надеюсь будете дополнять.
                          • 0
                            Мечте надо следовать.

                            Начинающему можно советовать книгу The Elements of Computing Systems: Building a Modern Computer from First Principles (неформальное название From NAND to Tetris) и соответствующий курс на Курсере: Build a Modern Computer from First Principles.

                            Там упрощенный (но настоящий) HDL, собственный hardware simulator на Java, средства прогона тестов и так далее. Начинаете с создания базовой логики, сумматоров-мультиплексоров, потом делаете арифметически-логическое устройство, память, в общем, получается настоящий процессор — для которого вы потом пишете ассемблер и так далее.

                            Курс клевый, книга легко читается новичком. Курс пока меньше, чем книга — они его только делают.

                            Если понравилось, покупаете дешевую FPGA-платку для начинающих типа Papilio Pro с Logic Wing, скачиваете официально бесплатный Xilinx ISE WebPack, и начинаете реализовывать то, что делали в предыдущем курсе, на нем (книга Intro to Spartan FPGA в помощь; правда, там используется предыдущая плата, но поменять нужно будет только некоторые значения). Про Марсоход тоже нельзя не упомянуть.

                            Ну а потом уже можно MIPSfpga вместе с упомянутой выше книгой Дэвида и Сары Харрис; сам проект неоднократно упоминался на Хабре.

                            И все получится.
                            • 0
                              После этого курса реализованный процессор с HDL довольно легко переписывается на Verilog, но вот реализация его на HDL — то ещё веселье.
                          • +1
                            На правах рекламы (но полезной и в тему поста) вот ссылка на наш курс "Введение в программирование ПЛИС Xilinx на языке VHDL".
                            Там есть книги, лекции, дз. Базовый курс будет серьезно доработан за лето.
                            • +3
                              Хороший пост.

                              Дополнения: Вот составленные мною зачеты для студентов, которые я тестировал на куче студентов из Индии в небольшом частном университете в Фримонт, Калифорния, где я помогал читать такие курсы по субботам:

                              http://silicon-russia.com/exams_and_quizes/

                              Пример одного из вариантов одного из зачета: http://www.silicon-russia.com/2015/03/19/intro-rtl-fpga-verilog-midterm-1-1/
                              • +3
                                Где бы еще взять время на это всё? Ни у кого случаем нет свободной машины времени?
                                • 0
                                  Добрый день,
                                  я являюсь подобным студентом, правда имею определенный опыт использования fpga и пару проектов на них
                                  тоже пользуюсь altera, но вот в качестве языка выбор пал на VHDL
                                  и соответственно регулярный вопрос: почему Verilog/SV? для себя пока что нашел преимущества в sv:
                                  — тип данных longint длинной в 128 бит
                                  — конструкция a = b? c: d
                                  в остальном vhdl пока кажется приятнее, да и в университете его преподают, однако на многих вакансиях Verilog, и не могу понять: в университете неправы или на производствах неправы или каждый прав
                                  • –1
                                    На verilog писать меньше нужно. И даже он уже неприлично низкоуровневый для текущих задач. Тренд в сторону синтеза C/C++ напрямую в FPGA и схемных редакторов, где единицей дизайна является целое IP-ядро. Сейчас дизайн серьёзных проектов в основном строится на уровне IP-ядер и интерфейсов.
                                    • 0
                                      -Тренд в сторону синтеза C/C++ напрямую в FPGA и схемных редакторов

                                      Не имеете ли вы ввиду случаем под схемными редакторами Simulink и последующую компиляцию HDL-кода из него?
                                      Полагаю, тренд синтеза С/С++ касается опять таки SoCFPGA систем, где это еще как-то разумно использовать
                                      • 0
                                        Vivado HLS, например.
                                        • 0
                                          Под схемными редакторами я имел в виду IP Block Design в том же Vivado
                                      • 0
                                        Вы спрашиваете вопрос из традиционного холивара VHDL и Verilog :)

                                        Мне приятнее SystemVerilog, я знаю, что благодаря ему я более производителен, чем если бы писал на VHDL.

                                        Предлагаю сделать маленький эксперимент:
                                        • Зайдите в директорию, где у вас хранится Quartus, а затем в директорию ip/altera.
                                        • Посчитайте, сколько там Verilog, SystemVerilog и VHDL файлов.

                                        У меня получилось вот так:
                                        ish@xmr:~/altera/15.1/ip/altera$ find . -name *.v | wc -l
                                        17006
                                        ish@xmr:~/altera/15.1/ip/altera$ find . -name *.sv | wc -l
                                        6012
                                        ish@xmr:~/altera/15.1/ip/altera$ find . -name *.vhd | wc -l
                                        1321
                                        

                                        Если оставить только с уникальными названиями файлов, то получается вот так:
                                        ish@xmr:~/altera/15.1/ip/altera$ find . -name *.v -printf "%f\n" | sort | uniq | wc -l
                                        4952
                                        ish@xmr:~/altera/15.1/ip/altera$ find . -name *.sv -printf "%f\n" | sort | uniq | wc -l
                                        2152
                                        ish@xmr:~/altera/15.1/ip/altera$ find . -name *.vhd -printf "%f\n" | sort | uniq | wc -l
                                        1013
                                        
                                        • 0
                                          -я знаю, что благодаря ему я более производителен, чем если бы писал на VHDL.

                                          Вот насчет этого как раз и не могу найти ни подтверждений ни опровержений, как раз хотелось бы узнать что бы подразумеваете под производительностью VHDL и Verilog (:
                                          • +2
                                            Всё банально — для написания одного и того-же модуля на VHDL надо больше символов ввести, чем на *Verilog. Если предположить, что у двух разработчиков одинаковая скорость печати и одинаковые знания их языков (Один гуру в verilog, другой в vhdl), то первый напишет код быстрее.
                                            • 0
                                              Этого ответа я конечно ждал и, с сожалением, дождался
                                              • 0
                                                Всё верно.

                                                P.S. Рекомендую глянуть топик FEC на ПЛИС, где Денис Шехалев (des00) пиарит красоту SV :).
                                                • 0
                                                  Согласен, SystemVerilog с выходом Vivado можно использовать как синтезируемый язык для новых поколений плис Xilinx (думаю Altera тоже не отстаёт). Он обладает функциональностью VHDL (например, можно прокидывать матрицы между модулями) и краткостью Verilog'а. И как плюс, на нём можно писать мощные тестбенчи, а для ASIC верификации под него есть готовые библиотеки для проведения функционального тестирования и тестирования покрытия кодом (например, UVM).
                                                • 0
                                                  Это весьма упрощенная модель. VHDL как язык со строгой типизацией позволяет избежать множества досадных ошибок, тем самым сэкономив время на отладке. Да можно говорить, что мы огородились тестами на все случаи жизни и всегда все проверяем досконально, но все же ситуация не столь однозначна. Да и непосредственно печатание кода вряд ли занимает столь значителньое время во всем времени разработки.
                                                  • 0
                                                    Согласен с вами, но дальнейшее обсуждение наверняка выльется в очередной VHDL vS Verilog холивар.
                                                    • 0
                                                      Ну а зачем мы тут собрались? ;)
                                                  • +2
                                                    Всегда завидовал людям, чья производительность ограничивается скоростью набора символов.
                                            • 0
                                              Человеческое спасибище.
                                              • +1
                                                Большое спасибо за такой шикарный обзорный материал! За wavedrom отдельная благодарность.

                                                А можете привести примеры вопросов, которые задают уже не junior, а senior-ам на собеседованиях? Чтобы было куда стремиться дальше.
                                                • 0
                                                  Да вопросы такие же на самом деле.

                                                  Про что еще можно спросить:
                                                  • оптимизация (по ресурсам и частоте)
                                                  • конвейеризация
                                                  • нюансы САПР'а (его дополнительные возможности, галочки для оптимизаций, например)
                                                  • внутренние интерфейсы (семейства Avalon, AXI)
                                                  • верификация: UVM SVA, coverage, constrained random tests


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

                                                  Плюс чисто RTL-дизайнеру скорее всего не будут задавать вопросы по advanced верификации.


                                                  Ну и разумеется, вопросы по сфере, для которой будет писаться прошивка FPGA.
                                                  Если ЦОС, то можно спросить про фильтры, если Ethernet, то про то как работает свитч или роутер.

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

                                                  Если команда разрабатывает для Ethernet'a на частоте 200 МГц на Stratix V, и приходит человек с годом опыта и он делал аналогичные задачи, то этот человек «опытнее», чем тот, который пять лет делал SPI-контроллеры на частоте 20 МГц на маленьких простеньких чипах.

                                                  Понять, насколько потенциальный кандидат успешно решал задачи, легко, если с ним поболтает час или два технический специалист (читай, другой FPGA разработчик), спрашивая простые вопросы:
                                                  • Как делали? Какая была архитектура всего проекта?
                                                  • Какие IP-ядра использовали готовые (покупные или из опенсорса)?
                                                  • Какие модули конкретно ты разработал? Сколько времени это заняло?
                                                  • Какие вылезли косяки/баги?
                                                  • Какая самая сложная проблема была?
                                                  • Как оптимизировали? Что помогло в оптимизации?
                                                  • Какой интерфейс использовали?
                                                  • Как настраивали [модули или IP-ядра]?
                                                  • Как была построена верификация?
                                                  • Как тестировали на железе?
                                                  • 0
                                                    Для азера 200МГц не нужно :) Гиг работет на 125МГц, 10Гиг — на 156,25 :))
                                                • 0
                                                  Спасибо за статью, очень интересно.
                                                  Но, как показывает практика, работы с железом в СНГ, постсоветском пространстве очень мало — нет почти ничего.
                                                  Вот так это и остается в лучшем случае, как хобби. :)
                                                  Тем, кто работает в этой сфере — поклон!
                                                  • 0
                                                    где ж была ваша статья 3 года назад?) Очень хорошая подборка, спасибо вам большое, сам освежил некоторые тонкие моменты и младшим коллегам показал.

                                                    И хотел бы задать вопрос. Возможно я что-то упустил, но в своей практике столкнулся с очень ограниченной поддержкой SV конструкций САПРом от альтеры. Если это так, то в чем вы тогда моделируете? Сам я Занимаюсь разработкой ASICов и тут таких проблем нет.
                                                    • 0
                                                      Три года назад я сам был джуниором, сорри :)

                                                      SV симулировали в Modelsim, синтезировали родным Квартусом.

                                                      Какие синтезируемые конструкции не работали у Альтеры, а работали для ASIC-синтезатора?
                                                      • 0
                                                        Я сталкивался с двумя проявлениями — inside и динамические массивы. Первое выяснилось в ходе прототипирования модуля, второе случайно сам выяснил. Вообще, нашел вот табличку со списком поддерживаемых конструкций. Есть почти все, но почему-то не упоминаются классы и вещи связанные с constrained random verification.
                                                    • 0
                                                      Может кому-то пригодится. Xilinx Zynq. Много полезной информации почерпнул о нем тут и еще тут
                                                      • +2
                                                        Иван, спасибо за статью!

                                                        Добавлю, что далеко не каждый Junior (и даже Middle) может похвастаться всем тем, что требуется из списка «Необходимо». Особенно, если после нескольких лет работы у человека начинается специализация в то или иное направление (реализация высокоскоростных интерфейсов или углубление в ЦОС, например). Получается, что существенную область разработки человек попросту игнорирует из-за специфики конкретно его работы.

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

                                                        Забавно, но у тех, кто ко мне обращается, тажке зачастую возникает вопрос: "FPGA vs WEB"? И практически всегда люди делают выбор в сторону того, что проще и в конечном счете позволяет иметь бОльшую гибкость. И это правильно.

                                                        P.S. кстати, а где в требованиях умение пользоваться осциллографом? (с железками ведь работаем, как-никак) :)
                                                        • +2
                                                          Эта статья — это мой взгляд на позицию Junior FPGA Design Engineer, и в нем не входит умение пользоваться осциллографом. У Вас может быть другой взгляд и это вполне нормально :)

                                                          Конечно, это очень спорно, потому что многие в эту «должность» вкладывают еще и умение разводить платы (т.е. схемотехника) и пр.

                                                          Я считаю, что FPGA Design Engineer должен быть в первую очередь хорошим RTL-кодером. Конечно, умение пользоваться осциллографом никому не вредит, но я лично предпочту работать с человеком, который знает что такое констрейны и метастабильность и умеет быстро писать код, но не умеет тыкать в резисторы щупом для просмотра сигналов.
                                                          • +2
                                                            Тоже верно, требования везде разные. Даже на hh по вакансии можно заблаговременно предположить, где с железкой будешь иметь дело напрямую, а где хватит встроенных анализаторов (типа ChipScope для Xilinx).

                                                            Кстати, насчет схемотехники. В нашем отделе давно сложилось правило, что опытный разработчик на ПЛИС должен не только прошивки делать и исключительно с ПЛИС работать на уровне написания/верификации кода для поставленной задачи, но еще и схемы рисовать с обоснованным выбором тех или иных компонентов. К счастью, без разводки платы, для этого есть отдел конструкторов. Такие вот дела. :)
                                                        • +1
                                                          По поводу литературы и дополнительных навыков, которые могут потребоваться в той или иной степени разработчику на ПЛИС:

                                                          Сфера ЦОС:
                                                          — Эммануил С. Айфичер, Барри У. Джервис. Digital Signal Processing: A Practical Approach
                                                          — Рабинер и Голд. Теория и практика цифровой обработки сигналов.

                                                          Также при углублении в область ЦОС на ПЛИС очень полезно будет на начальном этапе ознакомиться с даташитами на IP-ядра от тех вендоров, с которыми будете работать. В даташитах подробно описаны основные моменты, без сильного углубления в теорию. Дополнительный плюс таких IP-ядер — легкость моделирования и отладки.

                                                          High Speed Trancsivers:
                                                          — High-Speed Serial I/O Made Simple от Xilinx.

                                                          Книга позволяет получить первичное представление о гигабитных трансиверах и их начинке, дает основные определения и описывает проблемы, возникающие при разработке интерфейсов передачи.
                                                          • 0
                                                            Не плохой список, сейчас как раз из жены делаю плисовода, пригодиться :)
                                                            Но есть и критика.
                                                            Во-первых, не согласен категорически с разделом «Не соблюдение принципов синхронного дизайна». Как говорят классики, шедевр создают только те, кто выходят за пределы правил. Асинхронщина часто помогает сделать тот же кусок кода в 2-3 короче, просто, что бы понимать как работают асинхронные схемы нужно больше опыта и понимания, чем при тупом ваянии синхронных схем. Более того, есть случаи, когда без асинхронных схем не обойтись. Нужно, как в анекдоте, просто уметь их готовить :))
                                                            Насчёт использования STP. «Нет, ребята, всё не так, всё не так, ребята». Во многих случаях гораздо быстрее и удобнее прикрутить STP и посмотреть, что там происходит. Насчёт 5-10 минут, кто вам мешает пересобирать только тот кусок, который не работает, не трогая остальной проект? Я не слышал, что бы в Квартусе оменили опцию частичной пересборки. Или по-вашему для проверки какого-то небольшого тонкого куска лучше и быстрее ваять на 20 страницах верстак (который больше не понадобиться)? А дальше, что бы было (относительно) адекватное моделирование, вы запустите моделсим в режиме вентильного моделирования и этот неповоротоивый монстр будёт её обсчитывать минут 20-30 и в конце-концов тупо свалиться. Ну да, конечно, это явно быстрее, чем в два щелчка прикрутить stp и за 10 мин пересобрать схему :)) И не надо забывать, что stp вам показывает живые сигналы, а моделирование — это некоторое и довольно грубое к оным приближение.
                                                            Ну и, кстати, реально СистемВерилог по-сути не имеет существенных преимуществ на тем же Верилогом-2001. Мало того, как выразился как-то про СистемСи Панчул, — «это очередная попытка изнасиловать мозг разработчика». То же я бы сказал про СистемСи. Единственная полезность для меня там оказалась в упакованных массивах. Всё остальное — нафиг не нужно. Я уже 20 лет ваяю сложнючие схемы обработки сигналов (топовые Стратиксы-4 забиваются под завязку), но ничего сложнее тупого верстака на верилоге, который вычитывает входные данные из файла, сгенерённого Матлабом, прогоняет через Моделлсим и потом пишет выходы для того же Матлаба мне никогда не надо было.
                                                            • 0
                                                              Но есть и критика.

                                                              У каждого свой взгляд на эту сферу и это вполне нормально)
                                                              Спасибо, что высказываете своё мнение по данной теме.

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

                                                              Лучше — да. Быстрее — нет. А вообще ответ зависит от специфики граничного случая.

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

                                                              Я уже 20 лет ваяю сложнючие схемы обработки сигналов (топовые Стратиксы-4 забиваются под завязку), но ничего сложнее тупого верстака на верилоге, который вычитывает входные данные из файла, сгенерённого Матлабом, прогоняет через Моделлсим и потом пишет выходы для того же Матлаба мне никогда не надо было.

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

                                                              У меня другая сфера разработки под FPGA (не ЦОС) и другой опыт, который говорит о том, что лучше студента/джуниора заставлять писать тесты, и сначала на них прогонять данные, а только потом запускать это всё на железе. Возможно, когда у меня будет 20 лет разработки под FPGA, то у меня будет другое мнение по этому вопросу.

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