Pull to refresh
56
0
Денис Габидуллин @Des333

Директор по разработке ПО

Send message

Хорошая статья, спасибо!
Жаль, что на Хабре про Haskell пишут крайне редко.

Автору -- респект и пожелание писать ещё!

Статья просто отличная!
Большое спасибо!


Сколько примерно ушло времени на сам проект и сколько на подготовку статьи?

Why are you answering in Russian?
А тех, кто не преподаватель из ВУЗа, но имеет опыт чтения курсов о разработке под FPGA, в ревьюверы берёте? :)
Думаю, 32 года не такой возраст, когда нельзя прокачать некоторые скиллы.

К тому же Вы из относительно близкой сферы — системного программирования.
Если бы Вы пришли из гуманитарного направления, было бы сложнее.
И всё равно это было бы возможно.

В общём, главное это желание, усердие, и некоторое количество времени по вечерам/выходным.

Удачи!
Поддерживаю!
На мой взгляд, действительно, полезная фича.
В новостях от 27 января 2016 года:
Готовность софтверной экосистемы к моменту выхода разрабатываемого процессора «Байкал-М» позволит оперативно создавать востребованные рынком конечные устройства на его базе. Мы будем и дальше развивать наше партнёрство — поделилась генеральный директор «Байкал Электроникс» Светлана Легостаева


В новостях от 26 января 2016 года
На данный момент завершен первый этап взаимодействия «Байкал Электроникс» и «Базальт СПО», в ходе которого разработана система сборки и репозиторий для систем на базе процессора Байкал-М, построенного на основе архитектуры ARMv8 (AArch64). Репозиторий включает примерно 10 тысяч пакетов, основанных на наработках проекта Sisyphus, и уже доступен для тестирования.

На втором этапе сотрудничества предполагается тестирование пакетов на различных системах AArch64. На третьем этапе планируется сборка дистрибутивов различного назначения и тестирование на опытных образцах процессора «Байкал-М». В настоящий момент «Байкал Электроникс» и «Базальт СПО» рассматривают перспективные проекты сотрудничества в создании систем для аппаратной платформы процессора «Байкал-T1» (32-битный MIPS).


В новостях от 15 ноября 2016 года (официальный сайт):
Михаил Махсон назначен генеральным директором АО «Байкал Электроникс»…
На посту генерального директора Михаил сменил Светлану Легостаеву.


Зачем писать новостные статьи, которые состоят из копипасты обрывков новостей 3-х летней давности?
При этом писать в настоящем времени вещи, которые неактуальны более 2-х лет?

Ценность таких статей — она в чём? В информации? Или в рейтинге на Хабре?
К сожалению, во втором…
Так Вы напишите про это статью.
И станет понятно:
  1. Интересно это другим разработчикам или нет.
  2. Удобно этим пользоваться или это решение только под Ваши, узкоспециализированные задачи.

По скриншоту с двумя строчками много понять, к сожалению, непросто.
docs.myhdl.org/en/stable/manual/preface.html:

Conversion to Verilog and VHDL
Subject to some limitations, MyHDL designs can be converted to Verilog or VHDL. This provides a path into a traditional design flow, including synthesis and implementation. The convertible subset is restricted, but much wider than the standard synthesis subset. It includes features that can be used for high level modeling and test benches.

The converter works on an instantiated design that has been fully elaborated. Consequently, the original design structure can be arbitrarily complex. Moreover, the conversion limitations apply only to code inside generators. Outside generators, Python’s full power can be used without compromising convertibility.

Finally, the converter automates a number of tasks that are hard in Verilog or VHDL directly. A notable feature is the automated handling of signed arithmetic issues.
Конечно, Вы правы — переход на более широкую шину может привести к значительному усложнению/переделке дизайна.

Просто в сообщении выше Вы написали:
Переход от десяти гигабит на более высокие скорости это уже увеличение тактовой частоты (так как шина уже 64бита куда больше?).

И как вывод:
FPGA не может работать на очень высоких тактовых частотах следовательно выход один — берем схемы из репозитория и выпекаем по ним ASIC

А это не совсем верно (точнее, совсем не верно) — топовые FPGA позволяют получить поддержку 40G/100G. Для этого придётся использовать шины шириной порядка 256/512 бит и частоты порядка 312.5 МГц.

Конечно, такая разработка:
  • Много сложнее и дольше, чем для 1G/10G
  • Может потребовать написания с нуля большого числа модулей. Так как модули для 1G/10G переиспользовать не получится


Но, как говорится, C'est la vie.
Если хочется поддерживать на FPGA большие скорости, придётся прилагать большие усилия.
Больше 64-битной шины, например, 512-битная :)
«Но я глубоко уверен, что если человек начинает настолько уставать или становится невнимательным, что делает ошибки в коде (которые не замечает после первого перечитывания на свежую голову) — ему пора менять род деятельности»

Ребята, сворачиваемся.
«Или вот этот замечательный материал из университета Berkeley (сразу предупреждаю, их материал про конечные автоматы устарел — их следует писать в одном always блоке, а не в двух или трёх)»

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

Согласен с приведёнными выше аргументами про «выстрел в ногу» и маскирование ошибки.
Поэтому повторяться не буду.

Дополню только следующими пунктами:
  1. Для синтезируемого подмножества Verilog есть стандарт IEEE Std. 1364.1 — 2002 «Standard for Verilog Register Transfer Level Synthesis».
    В этом стандарте, в Annex B, пункт B.12 Timing delays сказано:
    Synthesis tools ignore time delay in a model. Adding time delays to a Verilog pre-synthesis simulation can cause a mismatch between pre-synthesis and post-synthesis simulations and in general should be avoided.

  2. Есть ещё статья от всем известных Sunburst Design:
    www.sunburst-design.com/papers/CummingsSNUG2002Boston_NBAwithDelays.pdf

    Там авторы не настолько категорично настроены против использования задержек. В качестве доводов «за» они называют следующее:
    1. Более удобную отладку с временными диаграммами
    2. Решение некоторых проблем при смешанной RTL/Gate-level симуляции

    Доводов «против» также хватает.

    Мое мнение по первому пункту «за» — неудобство отладки по временным диаграммам без использования дополнительной задержки полностью уходит примерно через неделю практики. И для инженеров с серьёзным опытом это точно не должно быть причиной для использования задержек.
    По второму пункту — да, это так. Но в статье и комментариях разбирается не этот случай.


Общий вывод по статье.
Самое плохое, на мой взгляд, то, когда начинающих FPGA-разработчиков вместо понимания сути вещей (как именно работают симулятор и синтезатор, какие конструкции есть в языках и когда и как их нужно правильно применять) учат «хитростям», которые позволяют избегать проблем, если повезёт. И которые дают ложное ощущение безопасности.

Именно такое впечатление у меня сложилось после прочтения материала.
Поэтому поставил статье минус, хоть обычно я двумя руками «за» все статьи по тематике FPGA.

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

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

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Date of birth
Registered
Activity