Pull to refresh

Comments 50

Не хватает варианта: "Ни в каких! Нужно сделать упор на изучении внутреннего устройства ПЛИС"

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

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

Есть пласт AI на ПЛИС.

Без понимания как устроен ПЛИС не возможно написать работающий код для всего что я описал выше. В симуляции может и будет работать но в чип не "везет". Или же будут проблемы с timing. Нужно понять что работа с ПЛИС это не программирование. Это описание того как чип должен быть устроен после прожига.

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

Чего только стоит их высокомерное "Ни в каких! Я усмирил гордыню и признал, что дизанить железо могут только в Америке!". Только за это отправлял бы в бан.

А что вы ожидаете прочитать в статье? Синтаксис языка описания аппаратуры Verilog? Описание маршрута синтеза? Рассказ про алгоритмы статического анализа тайминга? Стили написания конечных автоматов? Я вообще описал техническую часть примера игры в другом посте - https://habr.com/ru/post/501502/ - там сначала сообщение про лабник, а потом расписан пример игры. Тот пост для вас более информативен?

И строка, которую вы процитировали - это часть выбора в опросе.

А что вы ожидаете прочитать в статье? 

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

Не знаю. Тема FPGA это то [самоцензура], в которое я только-только наступаю. Имея за плечами опыт схемотехника и построения реально больших плат на 1533/1554 сериях, и далее опыт системного программиста (С, ассемблер).

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

До того, как выполнять дизайн, человек должен четко усвоить основы RTL. Типовые грабли с этим следующие:

  1. Человек не понимает кухню с блокирующими и неблокирующими присваиваниями. Лечится чтением главы 4.5.4. Блокирующие и неблокирующие присваивания учебника Харрис & Харрис (новое издание) с последующим чтением главы Главы 14. Работа симулятора книги Дональда Томаса .

  2. Человек не понимает valid/ready интерфейсы (пишет дизайны так, что не может обрабатывать данные, приходящие в каждом такте). Это нигде хорошо не описано, но если бы вы пришли на занятия секции 2 на ChipEXPO в сентябре, там этот вопрос полностью разбирался. К сожалению эта тема выглядит для многих начинающих слишком абстрактной и на этой теме, в отличие от FPGA для начинающих, было очень мало народу. Помогает только наличие тьютора, которые закрывает комнату с учеником и не выпускает, пока тот не поймет и пока его дизайн не заработает корректно на симуляторе. Пример задачки - см. эту ветку https://habr.com/ru/post/593377/#comment_23786647

  3. Человек не понимает концепции конвейера - эту тему я разобрал в предыдущем посте - https://habr.com/ru/post/593377

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

Тут начинается тонкий момент - чтобы пройти интервью в электронные компании, человеку нужно подучить всякие вещи, которых в учебниках мало, но спрашивают на интервью - skid buffer, credit-based flow control, арбитры итд. Это расбросано по статьям, мы пробовали рассказывать об этом на ChipEXPO, но это вызывает вялый интерес - то ли все убежали на data science, то ли люди не верят, что на этом дизайнят айфоны.

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

Вот основные хаки

Спасибо, но... Боюсь мы разговариваем на разных языках.

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

Моя сфера интересов - цифровые автоматы где уровень скорости процессора общего назначения или микроконтроллера явно не достаточен. Скажем bit-stream поток Wi-Fi интерфейса, конвертирование или наложение видео интерфейсов (LVDS/FPD-Link -> HDMI, MIPI DSI -> HDMI) или что-то подобное. Но у меня именно первые шаги в этом направлении и четкое ощущение "совы и глобуса". Синтаксис VHDL/Verilog букварей в какой-то момент совершенно неожиданно превращается в процессорные ядра, контроллеры кешей или что-то подобное. А где искать потерявшуюся середину?

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

P.S.

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

*** Мой актуальный уровень не позволяет мне уверенно сказать, что я понимаю кухню с блокирующими и неблокирующими присваиваниями (хотя мне кажется, что понимаю). Потому проектирование CPU/GPU это совсем не моя цель ***

Все что я написал - относится не только и даже не столько к CPU и GPU, сколько именно к задачам обработки потока. Я делал дизайн блока в магистральном роутере Juniper, где на вход валятся куски пакетов, которые нужно собрать и заменить у них заголовок. Поэтому все что я написал прямо относится.

А с каким вузом вы работаете? ВШЭ МИЭМ, ИТМО, еще кто-нибудь?

То есть насколько я понимаю, у вас три приоритета:

  1. Подучить механику RTL (blocking/nonblocking, valid/ready).

  2. Credit-based flow control, арбитры, FIFO, хранение данных в промежуточных памятях, банки - это вот то, про что у нас были доклады на ChipEXPO, но народ на это не валил особо.

  3. Детали конкретных протоколов.

Или не так?

По ВУЗу - ЛЭТИ. Впрочем, не думаю что это сильно принципиально.

По приоритетам.

Первый наверняка. Просто потому что я не уверен в том, что мы думаем об одном и том же.

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

Третье наверняка нет. Эта информация всегда должна быть доступна и основательно изучена перед началом решения задачи. Впрочем... MIPI D-PHY, Ethernet, PCI-E client или что-то такое как типовой выделенный блок и методика работы с ними. А равно что-то попроще типа I2C/SPI/UART - но именно синтез с примерами использования. Пожалуй было бы интересно. Правда писать про это или скучно, или слишком железо-специфично. Наверное именно по этой причине и нет ничего такого.

Пишите. У вас получается очень неплохо. Только побольше кода и его анализа, и поменьше "вау" как в этой статье.

А по ChipEXPO... Там место такое. Туда одним днем и точно не учиться. Изжила она себя (строго IMHO). Да и в целом разработка, увы, не самое востребованное направление. А уж разработка связанная с железом и подавно. Тут плюсы собирает позиция "не работайте в компаниях, где ПО не единственный выходной продукт". Так что позиция низкоуровневых программистов и разработчиков железа далеко не в топе. Со всеми отсюда вытекающими. И я не вижу причин по которым в (ближайшем?) будущем что-то поменяется.

Если вы считаете, что с FIFO у вас проблем нет, сразу вам три интервьюшные вопроса:

  1. Допустим, вы используете для хранения данных в FIFO не регистровый файл, а блок статической памяти с латентностью 3 такта. Можете ли вы построить FIFO таким образом, чтобы оно не переполнялось, когда вы делаете push и pop каждый такт?

  2. Напишите код для FIFO, в которое на каждом такте вы можете вталкивать или 1 или 2 куска данных, а также выталкивать или одно или два куска. Чтобы все работало если вы делаете например push1 push2 pop2 push 2 pop1 pop1 pop2.

  3. Нарисуйте микроархитектурную диаграмму FIFO, в которой push на тактовом сигнале 1 гигагерц, а pop - на тактовом сигнале 1.3 гигагерц.

  4. Бонусный вопрос: если (3) используется с кредитными счетчиками, каким механизмом вы будете возвращать кредиты?

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

Пока ситуация выглядит примерно так:

  1. Наверняка нет. Разве что юлить и придумывать вариант передачи данных со входа на выход минуя SRAM (естественно при условии пустого FIFO). Но в общем случае это не решение задачи. И вообще в первом приближении задача (как она сформулирована) выглядит нерешаемой.

  2. Сильно напоминает доступ к невыровненным данным из прикладного программирования. Во времена ARM7TDMI это был бич, попивший очень много крови, и крайне здорово что в Cortex'ах его поправили. Решения, казавшиеся очевидными, после некоторых раздумий были отметены. Но эта задача точно взята в проработку. Ибо интересна. Но сегодня я точно не готов решать ее на интервью.

  3. А вот тут, честно говоря не понял. FIFO и FIFO. Пусть и с раздельным такированием входа и выхода. Другое дело, что возможность работы с гигагерцами на каждая микросхема потянет. Но ведь это не вопрос конструкции самого FIFO. Или?

  4. Хм... Простите мою серость (это исправится, хоть и не сразу) - а что есть кредитный счетчик?

Я на всякий случай напоминаю. У меня опыт проектирования цифровых железок закончился лет 20 назад на уровне чуть выше, чем стандартная логика. В промежутке была схемотехника и програмирование. ПЛИСы возникли сейчас и вынужденно. Есть задачи, которые можно решить только ими. Я не то что не претендую на звание мастера, я вполне отдаю себе отчет что сегодня и в подматерья-то гожусь с трудом. Да и цели именно здесь мастером стать вроде нет. Достичь уровня ремесленника меня бы вполне устроило. Во всяком случае пока.

  1. Для ответа на этот вопрос интервьируемый должен задать три разъяснительных вопроса:

    1) идет речь о блоках SRAM которые ставят на ASIC от вендоров типа MediaTek ?

    2) это память однопортовая, двухпортовая или псевдодвухпортовая (позволяет одно чтение и одну запись в одном такте)?

    3) это память конвейерная? То есть можно ли запускать в нее адрес один за другим каждый такт и с задержкой в три такта получать ответ?

    Если ответ на все три вопроса "да", то ответ на первый вопрос "да".

  2. попробуйте.

  3. Разбор вопроса 3 - в статье http://www.sunburst-design.com/papers/CummingsSNUG2002SJ_FIFO1.pdf

    *** Хм... Простите мою серость (это исправится, хоть и не сразу) - а что есть кредитный счетчик? ***

    А это главная метода работы с потоком данных в сетевых и других компаниях. Не описано в учебниках но все время спращивают на интервью. А народ на ChipEXPO по этому приему доклад не ходил. На картинке оно выглядит вот как. Допустим у вас есть данные слева (upstream), конвейер для их обработки, FIFO, куда кладутся результаты обработки и блок справа (downstream) который может принимать данные из этого FIFO. Как организовать все так, чтобы 1) конвейер не простаивал 2) FIFO не переполнялось и не стояло полупустым и 3) данные шли back-to-back:

Короче записывайтесь на школу - про это будет на занятии в январе.

попробуйте.

Обязательно. Но все же вынужден уточнить ТЗ. Как разбираться с ситуациями записи WORD'а при свободном объеме в BYTE? У меня два разных статуса BYTE_READY и WORD_READY или пишу как могу, но выставляю FIFO_OVERRUN? И аналогично с чтением - просят WORD, а есть только BYTE. BYTE_EMPTY и WORD_EMPTY или добивать нулями и выставлять FIFO_UNDERRUN?

За развернутые ответы спасибо. И за приглашение тоже. Не факт что удастся воспользоваться (с некоторых пор у меня привычка работать на работе, а дома исключительно отдыхать), но... Я попробую. А там посмотрим.

Я пишу такое примерно с такой шапкой для общего случая (от 1 до N push или pop). Но вы можете ограничится случаем n=2 и сигналами byte/word ready итд:

module multi_push_multi_pop_fifo
# (
  parameter w = 13,  // fifo width
            d = 19,  // fifo_depth
            n = 2,   // max number of pushes or pops
            nw = $clog2 (n)
)
(
  input                      clk,
  input                      rst,
  input  [nw - 1:0]          push,
  input  [nw - 1:0][w - 1:0] push_data,
  input  [nw - 1:0]          pop,
  output [nw - 1:0][w - 1:0] pop_data,
  output [nw - 1:0]          can_push,  // how many items can I push
  output [nw - 1:0]          can_pop
);

*** Как разбираться с ситуациями записи WORD'а при свободном объеме в BYTE? У меня два разных статуса BYTE_READY и WORD_READY или пишу как могу, но выставляю FIFO_OVERRUN? ***

ТЗ от меня: Это ошибочная ситуация. Писатель должен проверить до записи (в комбинационной логике), что can_push == 1 и следовательно ставить push = 2 нельзя. В изготовленном чипе такого допускать нельзя (ошибка дизайна), при симуляции это должно быть assertion.

*** И аналогично с чтением - просят WORD, а есть только BYTE. BYTE_EMPTY и WORD_EMPTY или добивать нулями и выставлять FIFO_UNDERRUN? ***

Аналогично - если can_pop < 2, pop не может быть 2

Спасибо. ТЗ понято. Буду упражняться.

Как вариант развивающего упражнения могу предложить написать обработку команд с PS2 клавиатуры подключенной скажем к DE1.

А после - передача допустим букв на lcd который воткнут в один из портов через flat.

Если слишком легко - на VGA.

Для всяких там HDMI и иже с ними давно написано Cores и работа с ними скучна. Писать заново и вручную - занятие не благодарное :)

Кстати, да, клавиатуру с PS2 стоит добавить к упражнениям школы, хотя такие клавиатуры становятся атавизмом. DE1 избыточен, дорог и стар, для новых дешевых плат можно использовать вот такой переходник https://digilent.com/shop/pmod-ps2-keyboard-mouse-connector/

Или вот такой дешевый https://aliexpress.ru/item/1005003324832576.html

Правда упражнение с PS/2 комментатору выше вряд-ли поможет, при обработке потока встают другие задачи

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

Принять-то, думается, сложно не будет. А вот дальше что с этим делать.

Что до VGA, то там проблема разве что тайминги и аналоговый выход. R-2R матрица подключенная к FPGA звучит как-то странно, а цифровой выход просто не интересно (да, сигма-дельта скорее всего тоже мимо).

C выводом на VGA как таковой проблем никаких нет, это просто модуль генерации vsync, hsync и RGB. Прикол таких задач - это построение сцены из объектов (фигурок/спрайтов) и фона, вычисление их цветов и координат в зависимости от текущего состояния итд. Без софтвера, процессора и frame буфера. Как вы понимаете, эта задача может быть довольно сложной, вплоть до растеризации трехмерной графики.

Юрий. Вот кстати вопрос который у меня сейчас обозначился. Долго не мог сформулировать, но вот чейчас с 3ей книгой нашелся.

Вот есть книга 1 - МИПС, книга 2 - АРМ и вот третья теперь - РискV

Судя по оглавлениям разница там только в последних главах про архитектуру и микроархитектуру.

Посоветуйте плз. в какую архитектуру углублятся. Ну с МИПС понятно - это скорее уже вчера, а вот что перспективнее АРМ или Риск. Я совсем новичок (как раз игры пишу, аркады) и пока не секу четко в какую сторону бежать.

Чисто по вашему вкусу. Если хотите заодно научиться программировать на армовском ассемблере, чтобы писать обработчики прерывания для STM32 - берите про ARM. Если хотите задизайнить открытый процессор или пойти работать в Syntacore / Ядро или CloudBear (в который недавно инвестировал Байкал) - берите RISC-V.

Что угодно, для чего нужна именно ПЛИС, например частотомер с 12 разрядами, видеокарта для Ардуино, аппаратная часть мозга частотника, аппаратная часть SDR приемника, аппаратная часть осциллографа и т.д.

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

Видеокарта для Ардуино - ну это вполне себе задание для тех, кто прошел занятие по играм на VGA и последующее занятие по аппаратно-программному интерфейсу с schoolRISCV. Но это скорее домашний проект - на занятии можно рассказать про frame buffer и пустить в плавании, но идти по этому пути дальше, вплоть то преобразований координат в 3d графике и pixel pipe - это опять, отвлечение от приемов RTL - register transfer level.

SDR - тоже самое.

Вообще лично я (это мой персональный угол зрения, как разработчика ASIC-ов) скорее рассматриваю лабы на FPGA как тренажёр перед тем, как давать учащимся микроархитектурные задачки которые нужны для ASIC design . См. например занятия:

  • 22 января 2022: 10. Стандартные блоки и приемы проектирования: очереди FIFO и кредитные счетчики.

  • 29 января 2022: 11. Стандартные блоки и приемы проектирования: арбитры, банки и разделение памяти.

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

Последний пункт гениален - ткнул в него )) Ради того последнего пункта уже стоило написать статью )) Когда был розовощёким студентом баловались без тактовыми комбинационными схемами, золотое было время ;)

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

Было у нас дальнейшее развлечение на курсовой проектировали процессор с примитивной системой команд ( +-, память, ветвление) Забавно но не более, область этих знаний сильно завязана на редких единичных работодателей, если не тащится в СПб/МСк ( широка Россия а ехать некуда ))) и далее по миру (по мере роста), куда эти знания применять в народном хозяйстве замкадья (для выплаты ипотеки например))))? Практически более менее обычное программирование позволяет получать неплохие вознаграждения за труд в любой точке планеты удалённо, а связавшись с электроникой это контейнер барахла нужно возить с собой, и "стартап в гараже" тоже очевидно не светит подобным разработчикам, придётся стать навсегда безликим винтиком больших микроэлектронных корпораций... ФПГА это всётаки для большинства студентов развлечение позволяющее пощупать в живую(на железе) функциональное программирование, но как занятие по жизни удел единиц из десятков тысяч разработчиков.

PS. Занятно наблюдать как безбожно "глючит" игровой автомат но при этом работает ))) https://www.youtube.com/watch?v=86NEGjiPPyU

Какой-то сплошной зелёный виноград у вас. И в России сейчас есть нормальные работодатели - Байкал , который недавно вступил в партнёрство с CloudBEAR, Ядро в партнёрстве с Syntacore, да и на западе какие винтики - в группе проектирщиков в больших компаниях много возможностей для творчества, и есть стартапы в design IP для ML ускорителей например SiMa.ai.

Что касается вашего видео, я не вижу какое оно имеет отношение к моему посту. Там ретрокомпьютинг с микросхемами малой степени интеграции 1970 года. Я в посте специально написал, что это не про это:

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

На HH.ru посмотрел вакансии fpga(по ключевому слову там всё намешано и линкус и микроконтроллеры ну пускай), работодатели конечно есть и скорее всего нанимают людей по знакомствам, потому как общие нужды в работниках по рынку труда весьма и весьма скромные...

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

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

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

но с другой стороны сколько их этих "вьюношей" потом не попадут в Интелы/Байкалы(их просто столько ненужно: рынок - ничего личного)

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

*** Нужно сделать упор на изучении внутреннего устройства ПЛИС ... В симуляции может и будет работать но в чим не "везет". Или же будут проблемы с timing.***

А вы часом не путате устройство ПЛИС (строение и соединение ячеек) с анализом результатов синтеза (static timing analysis и учет утилизации ресурсов). В занятия школы разумеется входит обсуждение тайминга - propagation delay, setup constraint, таксимальная тактовая частота, критические пути. Как и утилизация ресурсов (количество синтезированных CLB и сколько из них элементов состояния).

*** Но ведь есть огромный и интереснейший пласт имплементации digital receivers, например. Или модулей для оборонной/космической промышленности. Там нужны заточенные под определенную цель модули без всяких процессоров ***

Так я же написал - схемы для распознавания звука и для видео игры не используют процессорных ядер. Там все на конечных автоматах.

Дело в том, что "схемы распознавания звука" можно написать по разному. Не имея понятия как ПЛИС устроен имплементация может "скушать" пол чипа. Например потому, что блок памяти описаный в verilog не подходит к блокам памяти в чипе. И будет работать, замечательно работать. На dev board... но для реального проекта такое не подойдет. Да и на интервью лучше не показывать сию имплементацию.

А почему вы собственно решили, что на школе якобы не объясняется, чем block memory в FPGA отличается от встроенной SRAM внутри ASIC и от внешней по отношению к FPGA памяти в SDRAM чипе? Или как правильно написать код чтобы синтез infer block memory? Это будет расписано на Занятии 11. Стандартные блоки и приемы проектирования: арбитры, банки и разделение памяти.

Сайт, на который вы сослались, построен на материале книжки From NAND to Tetris - Building a Modern Computer From First Principles. Эта книжка мне не нравится, я уже про это писал. В частности - зачем автор изобрел свой HDL? Чем он лучше верилога?

Вот например HDL из книги NAND2Tetris:

А вот то же, но на обычном верилоге, в трех вариантах реализации:

// Первый вариант реализации

module top1 (input a, b, output out);

    assign out = (a | b) & (a ~& b);
    
endmodule

// Второй вариант реализации - с промежуточными соединениями

module top2 (input a, b, output out);

    wire w1 = a | b;
    wire w2 = a ~& b;

    assign out = w1 & w2;
    
endmodule

// Третий вариант реализации - через подмодули примитивов

module top3 (input a, b, output out);

    or   or1   (w1, a, b);
    nand nand1 (w2, a, b);
    and  and1  (out, w1, w2);
    
endmodule

Ну и чем HDL из NAND2Tetris лучше, чем любой из этих вариантов? Бесплатностью тулов? Так для верилога есть бесплатный Icarus Verilog. Зачем переизобретать велосипед?

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

Была старая получше, пока, к своему стыду, не нашел. Там только nand разрешался впринципе

А в чем прикол? Как это поможет стать проектировщиком чипов? Научиться строить and-or-xor на nand - это задача для 10-летнего. На интервью на начальную позицию в электронную компанию спросят "напишите на доске код на верилоге для контроллера FIFO" - и куда вы засуните вашу nand?

Еще этот сайт nandgame ссылается на книжку Петзольда, про которую я в свое время написал следующее:

Существуют книги, написанные хорошими людьми с благими намерениями и на важную тему, при этом на пустом рынке. Но, увы, их исполнение вносит разный вред, в частности вместо того, чтобы направить юношу или девушку стать супердизайнером, толкают его или ее в хоббистическое копание во всякой ностальгационной хрени типа регистров hl в Intel 8080 (передовая технология 1974 года, при этом без поучительности других старых машин, например CDC 6600).

Именно к таких хорошим, но местами вредным книгам относится, с моей точки зрения книга Петзольда "Код". До "Кода" автор сделал имя на хорошей книге по программированию Windows 1988 года (я до сих пор помню с каким трепетом я читал ее в московском метро в 1990-м, когда Windows было еще версии 2.0, но я под руководством книги Петзольда написал на него своб первую Windows-программу).

Однако в конце 1990-х у Петзольда случился кризис среднего возраста, и он, вместо того, чтобы топить студенток в Мойке, вспомнил себя в 24 года (когда он делал музыкальные инструменты на микросхемах малой степени интеграции, а также когда вышли описываемые им в книге процессоры 8080 и 6502) и написал книгу "Код". Разбор ее предыдущего издания - в моих комментах ниже.

Я искреннее надеюсь, что найдется какой-нибудь русский патриот или патриотка, которые напишет книгу-эквивалент Петзолда, но без этих старческих пятен дисколорации на коже. Ее можно даже перевести на английский и маркетировать в Китае. Мои комменты по поводу книги Петзольда "Код" в 2017 году:

Мой Коммент 1. 15 мая 2017 года в одной из гугл-групп роственных silicon-russia@googlegroups.com : "Я посмотрел Петзольда. Все до двоичного сумматора можно использовать (причем сумматор построить из вентилей на верилоге), RS-триггеры можно сократить (оставить только D-триггер как черный ящик), петзольдовский процессор в принципе можно легко написать на верилоге (глава «автоматизация»), но я не уверен, что он существенно проще, чем одноцикловый процессор в H&H. Выбор 8080 и 6800 как процессоров для примера в главе 19 был сомнительный даже для 1988 или 2001 года, но сейчас более чем сомнителен (см. напр страницу 328 – ну зачем школьнику объяснять, почему есть mov b, [hl], но нет mov b, [de] – у этого нет никакой образовательной ценности). Исторические примеры на алголе и бейсике тоже стоит обновить, написать на чем-нибудь другом (не обязательно лучше, просто новее – C, Python, Go).

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

Второй коммент, часть 1: 22 мая 2017 года в одной из гугл-групп роственных silicon-russia@googlegroups.com : "Взял в библиотеке оригинал Петзольда и пролистал его внимательнее, чтобы проанализировать возможность его использования в качестве рекомендуемой литературы в курсе для школьников. Подтвердил вывод, что использовать его можно, но примерно наполовину. Дополнительные комментарии к предыдущему емейлу:

1. Обнаружил интересный момент, которые ранее (не видя оригинала) полагал возможной ошибкой перевода. А именно: для хранения текущего состояния своего простейшего процессора («Глава 17 Автоматизация») Петзольд использует не D-триггеры (D-flip-flops), а защелки (latches). Я понимаю, почему он это делает – он все-таки не хардверный инженер, а знаменитый автор книг по программированию Windows, и смотрит на это высокоуровнево, и для него объяснить, что что-то защелкивается по уровню (level-triggered) – это интуитивно проще, чем по изменению уровня (edge-triggered). Я считаю, что вводить защелки в курс для детей неправильно. Лучше их пропустить и вводить D-триггеры, или упомянуть походу, при переходе от изложения SR-latches к изложению D-flip-flop. Дело в том, что защелки в современной практической жизни возникают либо в самом начале курса цифровой электроники, либо в редких асинхронных уголках сильно продвинутых дизайнов, и показывать их детям как мейнстрим – это неправильно. Тем более что синтезатор при попытке создать latch генерирует warning или ошибку. При этом надо сказать, что Петзольдовский процессор можно без проблем переделать с использования защелок на использование D-триггеров, и если кто-нибудь захочет реализовать его на Verilog, это стоит делать именно так.

2. При том, что реализация петзольдовского процессора на верилоге – это хорошее упражнение, но он не намного сложнее версии однотактного процессора в Harris & Harris – если выкинуть из процессора в H&H обмены с памятью данных (load/store) и оставить только регистровый файл. Тогда сложность одного и второго процессора уравнивается, и на них можно исполнять простые программы типа вычислений чисел Фибоначчи или взятие целочисленного квадратного корня итерациями. В принципе, в курсе можно сделать пример и первого и второго простого процессоров – если мы вообще хотим доводить курс до изготовления школьниками процессоров, а не решаем ограничить его простой проследовательностной логикой (счетчики и сдвиговые регистры) и конечными автоматами (улитка на ленте и светофор).

3. Нашел ценную идею в «Глава 13 А как же вычитание?». А именно – реализовать вычисление отрицательной величины на сумматоре и инвертере (это можно сделать как на микросхемах малой интеграции, так и на ПЛИС). Просто исходя из формулы “–a == (~ a) + 1”. Это хорошее упражнение.

4. Сумматор с последовательным переносом (ripple-carry adder) из главы «Глава 12 Двоичный сумматор» также стоит сделать как на логических микросхемах малой интеграции, так и на ПЛИС. Это полезное упражнение. Для особо талантливых школьников (типа победителей олимпиад) можно факультативно добавить сумматор с ускоренным групповым переносом (carry-lookahead adder), последовательностный сумматор (прибавляющий бит за битом каждый такт) и конвейерный сумматор – все на верилоге.

5. Небольшое пояснение, почему использовать как примеры процессоры 8080 и 6800 неудачны для современных школьников. Про 8080 я уже сказал, скажу про 6800. Он представляет собой случай так называемой аккумуляторной архитектуры. Она имела смысл в до 1980-х годов, причем не только из-за ограниченных размеров, но и из-за того, что скорость арифметики была медленнее, чем скорость обмена с памятью. Процессоры такого типа трудно делать конвейерными (для этого лучше использовать register-rich load-store процессоры). Любые современные альтернативы – ARM, MIPS, AVR, которые появились после или в процессе RISC-революции 1980-х годов, в этом смысле лучше.

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

Давайте я вам дам задачку на nand. Кстати интервьюшная задачка для стажеров. Все знают, как строить мультиплексор из nand. А вот как построить nand из мультиплексоров?

module mux_2_to_1
(
    input  d0,
    input  d1,
    input  sel,
    output y
);

    assign y = sel ? d1 : d0;

endmodule

module nand_gate_using_mux
(
    input  a,
    input  b,
    output o
);

    // Напишите код здесь

endmodule

Не даю. С чего укрепилось ограниченность мышления, с чего присвоено себе право кому-то что-то задавать? Я не твой студент, очнись!
(задачко, кстати, гуглиццо левой пяткой)

КДПВ довольно забавна, на ней P-51 Мустанг то-ли реактивный, хотя сбоку явно видны 4 выхлопные трубы, а должно быть 6, то-ли стреляет через свой винт ракетами, сбивая Сейбр.

В оригинале Сейбр сбивает Миг.

А что вы считаете оригиналом? Комикс, по которому Рой Лихтенштейн нарисовал свою культовую картину "У-а-а-м!" ?

Там все на конечных автоматах.

А для игры, которую можно запустить на LED-матрице, например, змейки: как хранить саму змейку (в массиве?) как управлять движением (флаги?)

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

..... процессор аппаратно заточенный под работу с базой данных?

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

Да, где то к тому. Но там нужно прорабатывать концепцию в начале).

А почему Вы сводите в конечном результате к проектировщику CPU. Много интересных тем для ребят можно найти. Например, тех кто заинтересован робототехникой (а кто из ребят не заинтересован) элементы автоматики. Типа балансировка обратного маятника, движение по линии и т.д. Для тех кого интересует радио можно найти темы связанные с DSP. Например приёмники SDR. Думаю, что это не менее занимательно чем CPU строение.

Я не свожу все к проектировщику CPU. Я же написал: "CPU, GPU, NPU и сетевые чипы" - а это не CPU-шные задачи. Я двумя руками за DSP и SDR, если люди готовы освоить связанную с этим математику. Роботехника - это OK, но ее проще делать на микроконтроллерах.

Добавлю ссылку на онлайн ресурс 8 bit workshop, online IDE for MSX and other classic platforms, где кроме классических олдскульных 8-битных компьютеров, имеется раздел работы с Verilog-ом, где размещено большое количество примеров его использования.
Там же, есть ссылка на книгу Steven Hugg «Designing Video Game Hardware in Verilog»
Designing Video Game Hardware in Verilog
This book attempts to capture the spirit of the ''Bronze Age'' of video games, when video games were designed as circuits, not as software. We'll delve into these circuits as they morph from Pong into programmable personal computers and game consoles. Instead of wire-wrap and breadboards, we'll use modern tools to approximate these old designs in a simulated environment from the comfort of our keyboards. At the end of this adventure, you should be well-equipped to begin exploring the world of FPGAs, and maybe even design your own game console.

Вообще даже светодиодами на ПЛИС можно по разному мигать. Например те-же адресные светодиоды довольно тормозные, если делать большой экран. Как выход, поток данных надо распараллелить.

Выше уже упоминали роботов, но не обязательно лезть в сложные алгоритмы, задача управления 2мя десятками серв или шаговиков уже не так просто реализуется на МК, а вот ПЛИС.

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

Only those users with full accounts are able to leave comments. Log in, please.

Articles