Думаю, 32 года не такой возраст, когда нельзя прокачать некоторые скиллы.
К тому же Вы из относительно близкой сферы — системного программирования.
Если бы Вы пришли из гуманитарного направления, было бы сложнее.
И всё равно это было бы возможно.
В общём, главное это желание, усердие, и некоторое количество времени по вечерам/выходным.
Готовность софтверной экосистемы к моменту выхода разрабатываемого процессора «Байкал-М» позволит оперативно создавать востребованные рынком конечные устройства на его базе. Мы будем и дальше развивать наше партнёрство — поделилась генеральный директор «Байкал Электроникс» Светлана Легостаева
На данный момент завершен первый этап взаимодействия «Байкал Электроникс» и «Базальт СПО», в ходе которого разработана система сборки и репозиторий для систем на базе процессора Байкал-М, построенного на основе архитектуры ARMv8 (AArch64). Репозиторий включает примерно 10 тысяч пакетов, основанных на наработках проекта Sisyphus, и уже доступен для тестирования.
На втором этапе сотрудничества предполагается тестирование пакетов на различных системах AArch64. На третьем этапе планируется сборка дистрибутивов различного назначения и тестирование на опытных образцах процессора «Байкал-М». В настоящий момент «Байкал Электроникс» и «Базальт СПО» рассматривают перспективные проекты сотрудничества в создании систем для аппаратной платформы процессора «Байкал-T1» (32-битный MIPS).
Михаил Махсон назначен генеральным директором АО «Байкал Электроникс»…
На посту генерального директора Михаил сменил Светлану Легостаеву.
Зачем писать новостные статьи, которые состоят из копипасты обрывков новостей 3-х летней давности?
При этом писать в настоящем времени вещи, которые неактуальны более 2-х лет?
Ценность таких статей — она в чём? В информации? Или в рейтинге на Хабре?
К сожалению, во втором…
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 большие скорости, придётся прилагать большие усилия.
«Но я глубоко уверен, что если человек начинает настолько уставать или становится невнимательным, что делает ошибки в коде (которые не замечает после первого перечитывания на свежую голову) — ему пора менять род деятельности»
«Или вот этот замечательный материал из университета Berkeley (сразу предупреждаю, их материал про конечные автоматы устарел — их следует писать в одном always блоке, а не в двух или трёх)»
Если не затруднит, можно ссылку на материал, подтвеждающий эти слова?
Спасибо!
Не использую задержки в исходном коде.
Естественно, за исключением случаев, когда они необходимы (например, в моделях внешней памяти и т.п.).
Согласен с приведёнными выше аргументами про «выстрел в ногу» и маскирование ошибки.
Поэтому повторяться не буду.
Дополню только следующими пунктами:
Для синтезируемого подмножества 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.
Там авторы не настолько категорично настроены против использования задержек. В качестве доводов «за» они называют следующее:
Более удобную отладку с временными диаграммами
Решение некоторых проблем при смешанной RTL/Gate-level симуляции
Доводов «против» также хватает.
Мое мнение по первому пункту «за» — неудобство отладки по временным диаграммам без использования дополнительной задержки полностью уходит примерно через неделю практики. И для инженеров с серьёзным опытом это точно не должно быть причиной для использования задержек.
По второму пункту — да, это так. Но в статье и комментариях разбирается не этот случай.
Общий вывод по статье.
Самое плохое, на мой взгляд, то, когда начинающих FPGA-разработчиков вместо понимания сути вещей (как именно работают симулятор и синтезатор, какие конструкции есть в языках и когда и как их нужно правильно применять) учат «хитростям», которые позволяют избегать проблем, если повезёт. И которые дают ложное ощущение безопасности.
Именно такое впечатление у меня сложилось после прочтения материала.
Поэтому поставил статье минус, хоть обычно я двумя руками «за» все статьи по тематике FPGA.
Я уже говорил свою позицию лично Дмитрию (dsmv2014).
Он взрослый адекватный инженер, поэтому нормально воспринял мою критику.
Надеюсь, что он также не будет на меня в обиде за то, что я написал своё мнение в комментарии.
Думаю, всем очевидно, что все ребята, которые победили в конкурсе, имеют приличный опыт разработки на FPGA.
Максим, например, так вообще руководит у нас FPGA группой, хоть и стесняется про это упоминать :)
Хорошая статья, спасибо!
Жаль, что на Хабре про Haskell пишут крайне редко.
Автору -- респект и пожелание писать ещё!
Статья просто отличная!
Большое спасибо!
Сколько примерно ушло времени на сам проект и сколько на подготовку статьи?
www.youtube.com/watch?v=mucbupZ9rOY
www.youtube.com/watch?v=Ay2r_6KvVPM
www.youtube.com/watch?v=OFuR_ZQVnj8
www.youtube.com/watch?v=4KFARUjfWN4
К тому же Вы из относительно близкой сферы — системного программирования.
Если бы Вы пришли из гуманитарного направления, было бы сложнее.
И всё равно это было бы возможно.
В общём, главное это желание, усердие, и некоторое количество времени по вечерам/выходным.
Удачи!
На мой взгляд, действительно, полезная фича.
В новостях от 26 января 2016 года
В новостях от 15 ноября 2016 года (официальный сайт):
Зачем писать новостные статьи, которые состоят из копипасты обрывков новостей 3-х летней давности?
При этом писать в настоящем времени вещи, которые неактуальны более 2-х лет?
Ценность таких статей — она в чём? В информации? Или в рейтинге на Хабре?
К сожалению, во втором…
И станет понятно:
По скриншоту с двумя строчками много понять, к сожалению, непросто.
Просто в сообщении выше Вы написали:
И как вывод:
А это не совсем верно (точнее, совсем не верно) — топовые FPGA позволяют получить поддержку 40G/100G. Для этого придётся использовать шины шириной порядка 256/512 бит и частоты порядка 312.5 МГц.
Конечно, такая разработка:
Но, как говорится, C'est la vie.
Если хочется поддерживать на FPGA большие скорости, придётся прилагать большие усилия.
Ребята, сворачиваемся.
Если не затруднит, можно ссылку на материал, подтвеждающий эти слова?
Спасибо!
Естественно, за исключением случаев, когда они необходимы (например, в моделях внешней памяти и т.п.).
Согласен с приведёнными выше аргументами про «выстрел в ногу» и маскирование ошибки.
Поэтому повторяться не буду.
Дополню только следующими пунктами:
В этом стандарте, в Annex B, пункт B.12 Timing delays сказано:
www.sunburst-design.com/papers/CummingsSNUG2002Boston_NBAwithDelays.pdf
Там авторы не настолько категорично настроены против использования задержек. В качестве доводов «за» они называют следующее:
Доводов «против» также хватает.
Мое мнение по первому пункту «за» — неудобство отладки по временным диаграммам без использования дополнительной задержки полностью уходит примерно через неделю практики. И для инженеров с серьёзным опытом это точно не должно быть причиной для использования задержек.
По второму пункту — да, это так. Но в статье и комментариях разбирается не этот случай.
Общий вывод по статье.
Самое плохое, на мой взгляд, то, когда начинающих FPGA-разработчиков вместо понимания сути вещей (как именно работают симулятор и синтезатор, какие конструкции есть в языках и когда и как их нужно правильно применять) учат «хитростям», которые позволяют избегать проблем, если повезёт. И которые дают ложное ощущение безопасности.
Именно такое впечатление у меня сложилось после прочтения материала.
Поэтому поставил статье минус, хоть обычно я двумя руками «за» все статьи по тематике FPGA.
Я уже говорил свою позицию лично Дмитрию (dsmv2014).
Он взрослый адекватный инженер, поэтому нормально воспринял мою критику.
Надеюсь, что он также не будет на меня в обиде за то, что я написал своё мнение в комментарии.
Думаю, всем очевидно, что все ребята, которые победили в конкурсе, имеют приличный опыт разработки на FPGA.
Максим, например, так вообще руководит у нас FPGA группой, хоть и стесняется про это упоминать :)