Коробит, конечно, что по мнению TM FPGA и микроконтроллеры используются для разработки «гаджетов».
Может из статей такое ощущение и складывается, потому что «железный» продакшен люди иногда не могут показывать в сети, т.к. много вещей закрытых/военных. Поэтому и если хотят что-то показать, то делают дома DIY и показывают миру.
Системы связи или измерительное оборудование это далеко не гаджеты.
И с самого начала меня поражало малочисленность информации по данному вопросу.
Не соглашусь.
Прошивка FPGA является программным обеспечением (хотя тут можно поспорить, но в данном контексте сравнение уместно), следовательно её верификация сходна с верификацией любого другого ПО. По тестированию ПО есть достаточное количество статей, книг, методологий и пр.
Однако прошивка является «необычной» программой, и у нее есть нюансы, как её тестировать. И здесь нам помогают книги типа «SystemVerilog for Verification» и «Writing testbenches using systemverilog», а так же сайты типа testbench.in, ну и такие методологии верификации как UVM, которые заточены под RTL.
Так что, на мой взгляд, информация есть в сети есть :)
Мне кажется, полезнее для сообщества будет показать свой тестбенч (или его часть), рассказав, что, как и почему вы делаете, т.к. реальная жизнь в большом серьезном проекте очень часто расходится с советами из книжек и статей в интернете)
Может, в той компании, где вы разрабатывали онлайн-игру, просто было всё в порядке с мотивацией и управлением?
И все разработчики знали, что и как надо делать, были мотивированы работать, а не «страдать фигней», и не хотели тратить время на различные «длинные и бесполезные» собрания, с менеджерами проекта и продукт-оунером?
А, если Вы только о студентах с «хорошими знаниями», то я, наверно, соглашусь: по редкой специальности в гипотетический Intel проще уехать, чем программисту .NET в Microsoft ).
Я скорее про «всех» студентов спрашивал: они же куда-то идут работать. Если все в военку или в полузакрытые предприятия — то понятно. Официальной информации (ну либо хотя бы пары статей на Хабре) о том, что и как они делают мы не получим. Все руководствуются следующей мыслью: те, кому надо, о нас знают, зачем что-то еще делать?
Мне кажется, в сфере микроэлектроники происходит не так.
Не верю, что сотня питерских студентов, о которых говорит valeriyk чуть выше, сразу же после получения диплома получают офферы от Intel'a, AMD, IBM и прочих гигантов. Для интереса из-за рубежа студенты должны обладать нужной квалификацией и опытом. В сфере микроэлектроники опыт намного сложнее получить, т.к. необходима работа с реальным железом/оборудованием, чем в сфере «обычного» программирования, типа .NET, Python, Java. Плюс выше порог вхождения. Насколько оборудованы университеты такими местами (лабораториями, китами), и какой квалификации там работают люди, и какие проекты делают — я информацией не владею.
Я общался со студентами старших курсов (некоторые приходили на собеседование (RTL-кодинг под FPGA), некоторая приходила на FPGA-курсы): их знания нас не особо устроили на позицию junior'a: фактически их надо учить этому с нуля, хотя курс Verilog'a в университете у них был. Однако, разработка чего-то это не просто знание языка или CAD-программ, но еще и понимание правильных подходов и просто опыт.
Есть студенты, которые обладают хорошими знаниями, однако они их приобрели засчет того, что где-то работают параллельно с учёбой.
А много ли вакансий для стажеров в сфере микроэлектроники в компаниях, где можно получить опыт разработки?
Микроэлектроника это такая сфера, что результат ты редко видишь сразу.
Разумеется, студенты и молодые специалисты, которые хотят быть как Цукерберг или Дуров, идут в веб-разработку или делают приложения под смартфоны, надеясь выстрелить своей идей и проснутся знаменитыми (и богатыми).
Сложно представить, что пара-тройка хороших выпускников из топовых Российских университетов объединятся в стартап для того, чтобы писать свой процессор. Тут можно спросить, какой будет рынок сбыта у этого процессора, если военные себе итак что-то пилят (Эльбрусы, и пр.), а для гражданского использования цена на него должна быть сопоставима с гигантами из-за океана). Возможно, мы страдаем от того, что частных фирм, занимающихся электроникой в России очень мало.
Да и рынок труда диктует свои условия (spb.hh.ru) количеством вакансий:
verilog — 16
python — 184
java — 371
c# — 167
Крик души
С завистью смотрю на ивенты типа «moscow „some_popular_language“ meetup» или highload, где собираются люди из коммерческих компаний и открыто рассказывают кто, что и как делает. Идет обмен опытом, а следовательно развитие сотрудников и компаний в целом.
Я не припомню аналогичных встреч по тематике FPGA/ASIC в Москве или Питере. Возможно они и проводятся, но в закрытом кругу среди госфирм.
Если честно, не очень понимаю, как можно сравнивать «шансы в микроэлектронике» у двух стран :)
Из статьи можно сделать вывод, что для разработки чипов (процессоров, микропроцессоров) нужны следующие вещи:
1. люди, которые умеют писать RTL-код (еще, наверно, нужны люди для верификации).
2. фабрики.
3. деньги (которые могут вливаться как в пункт 1, так и в пункт 2).
С фабриками в России более менее всё ясно: есть Зеленоград, с 65-90 нм. Есть TSMC, который не в России, но чипы там тоже можно производить.
А вот сколько (и где) студентов в России хорошо обучают Verilog'у, так что они могли бы пойти сразу писать процессоры? Где все эти люди? Какими студенческими проектами занимаются? Уходят работать сразу на военку после старшего курса?
Если вдруг кто-то обладает информацией, поделитесь, сколько в США, Китае, России и Мексики (для сравнения) в год выпускается специалистов, которые могут разрабатывать чипы (или микроэлектронику)? Тогда можно хоть какие-то делать сравнения)
В открытом доступе я не нашел данных бенчмарков по пропускной способности fpga2sdram от Альтеры (хотя интересно глянуть :) ).
Еще скорость будет зависеть от частоты самого DDR и того, что делает процессор (читай, операционная система) в момент теста (что она пишет/читает в/из DDR).
Там (см. стр. 16) можно увидить числа ~100Gbps для Cyclone V. (Видимо, это получено перемножением 256 * 200 * 10^6 * 2 [Read + Write] ).
Числа, скорее всего, маркетинговые :)
Зависит от того, как сделать. :)
Можно, например, с процом взаимодействовать через PCIe (как и GPU): заливать туда обьемы данных, FPGA шифрует и отдает обратно.
Если хочется Ethernet шифровать сразу, то можно Ethernet завести на FPGA и сразу пакетики шифровать/дешифровать. Либо даже совместить это и сделать свою 10G/40G сетевую карточку на FPGA [либо купить готовый кит, и написать под нее софт] с шифрованием.
На opencores.org есть две корки ГОСТа, можно их собрать под топовые чипы и посмотреть производительность. И если не устроить, то писать их самим :)
По поводу нагрузочного тестирования:
В sendpfast просто используется стандартный tcpreplay: сначала создается файл, который необходимо отправлять, а потом он отправляется tcpreplay, так что по поводу производительности здесь не надо беспокоиться :)
Простой пример: у нас есть 4-битный счётчик, но нам нужно досчитать только до 9, затем счётчик всегда сбрасывается. Но оказывается, что инкремент на бОльших числах задействует пути со значительными задержками.
Пример, конечно, неплохой, но ИМХО, такая оптимизация не нужная (да и вредная, т.к. не особо интуитивная).
Чаще всего проблемы в других вещах, чем в счетчиках.
TCP действительно обеспечивает доставку данных, однако гарантий, что весь видепоток дойдет до потребителя всё равно нет. :)
Сколько серверов (и каких) надо иметь, чтобы писать 100 Гбит/c видео?
А как происходит обратная связь с операторами? К примеру, какая-то из камер зависла и перестала передавать поток. Вы об этом факте сообщаете операторам (каким-то SNMP-трапом(?)), и они должны её починить в течение какого-то времени? Или наоборот, ДИТ занимается починкой/ресетом/заменой камер?
Хотелось бы узнать:
Как обеспечивается прием и обработка 120 тысяч видеопотоков? Какие трюки были применены? Как происходит передача? RTP/UDP, RTSP? Сколько всего трафика приходится системе съедать?
Как гарантируется «качество» картинки? На некоторых картинках с камер были видны характерные «синие экраны». Как это детектируете, как это исправляете (через какое время)? Есть ли какие-то SLA по доступности/недоступности потока?
Как думаете, статьи какой детализации будут интересны? На уровне блок-схем и просто идей (научно-популярно), или с разбором кода внутри (для hdl-гиков)?)
Если на уровне блок-схем, то у меня как-то руки не поднимаются писать [про те проекты, в которых я участвую], кажется что, материала на хорошую статью не особо хватит. Если разбирать код, то руководство может сделать атата, если буду сливать исходники в интернетах)
Не так давно вместе с коллегой были в гостях у Марата eucariot ( habrahabr.ru/post/246753/ ), где я рассказывал о применении FPGA в конкретном проекте: 100G Ethernet балансировщик ( с функцией фильтрации ). Позволю себе привести слайд из презентации «блок-схемы»:
Скрытый текст
Если будет интересен рассказ о проектах в формате похожих блок-схем (ну или чуть подробных ), то почему нет? :)
Коробит, конечно, что по мнению TM FPGA и микроконтроллеры используются для разработки «гаджетов».
Может из статей такое ощущение и складывается, потому что «железный» продакшен люди иногда не могут показывать в сети, т.к. много вещей закрытых/военных. Поэтому и если хотят что-то показать, то делают дома DIY и показывают миру.
Системы связи или измерительное оборудование это далеко не гаджеты.
Не соглашусь.
Прошивка FPGA является программным обеспечением (хотя тут можно поспорить, но в данном контексте сравнение уместно), следовательно её верификация сходна с верификацией любого другого ПО. По тестированию ПО есть достаточное количество статей, книг, методологий и пр.
Однако прошивка является «необычной» программой, и у нее есть нюансы, как её тестировать. И здесь нам помогают книги типа «SystemVerilog for Verification» и «Writing testbenches using systemverilog», а так же сайты типа testbench.in, ну и такие методологии верификации как UVM, которые заточены под RTL.
Так что, на мой взгляд, информация есть в сети есть :)
Мне кажется, полезнее для сообщества будет показать свой тестбенч (или его часть), рассказав, что, как и почему вы делаете, т.к. реальная жизнь в большом серьезном проекте очень часто расходится с советами из книжек и статей в интернете)
И все разработчики знали, что и как надо делать, были мотивированы работать, а не «страдать фигней», и не хотели тратить время на различные «длинные и бесполезные» собрания, с менеджерами проекта и продукт-оунером?
www.youtube.com/watch?v=m3zvVGJrTP8
Я скорее про «всех» студентов спрашивал: они же куда-то идут работать. Если все в военку или в полузакрытые предприятия — то понятно. Официальной информации (ну либо хотя бы пары статей на Хабре) о том, что и как они делают мы не получим. Все руководствуются следующей мыслью: те, кому надо, о нас знают, зачем что-то еще делать?
Не верю, что сотня питерских студентов, о которых говорит valeriyk чуть выше, сразу же после получения диплома получают офферы от Intel'a, AMD, IBM и прочих гигантов. Для интереса из-за рубежа студенты должны обладать нужной квалификацией и опытом. В сфере микроэлектроники опыт намного сложнее получить, т.к. необходима работа с реальным железом/оборудованием, чем в сфере «обычного» программирования, типа .NET, Python, Java. Плюс выше порог вхождения. Насколько оборудованы университеты такими местами (лабораториями, китами), и какой квалификации там работают люди, и какие проекты делают — я информацией не владею.
Я общался со студентами старших курсов (некоторые приходили на собеседование (RTL-кодинг под FPGA), некоторая приходила на FPGA-курсы): их знания нас не особо устроили на позицию junior'a: фактически их надо учить этому с нуля, хотя курс Verilog'a в университете у них был. Однако, разработка чего-то это не просто знание языка или CAD-программ, но еще и понимание правильных подходов и просто опыт.
Есть студенты, которые обладают хорошими знаниями, однако они их приобрели засчет того, что где-то работают параллельно с учёбой.
А много ли вакансий для стажеров в сфере микроэлектроники в компаниях, где можно получить опыт разработки?
Разумеется, студенты и молодые специалисты, которые хотят быть как Цукерберг или Дуров, идут в веб-разработку или делают приложения под смартфоны, надеясь выстрелить своей идей и проснутся знаменитыми (и богатыми).
Сложно представить, что пара-тройка хороших выпускников из топовых Российских университетов объединятся в стартап для того, чтобы писать свой процессор. Тут можно спросить, какой будет рынок сбыта у этого процессора, если военные себе итак что-то пилят (Эльбрусы, и пр.), а для гражданского использования цена на него должна быть сопоставима с гигантами из-за океана). Возможно, мы страдаем от того, что частных фирм, занимающихся электроникой в России очень мало.
Да и рынок труда диктует свои условия (spb.hh.ru) количеством вакансий:
verilog — 16
python — 184
java — 371
c# — 167
Я не припомню аналогичных встреч по тематике FPGA/ASIC в Москве или Питере. Возможно они и проводятся, но в закрытом кругу среди госфирм.
Из статьи можно сделать вывод, что для разработки чипов (процессоров, микропроцессоров) нужны следующие вещи:
1. люди, которые умеют писать RTL-код (еще, наверно, нужны люди для верификации).
2. фабрики.
3. деньги (которые могут вливаться как в пункт 1, так и в пункт 2).
С фабриками в России более менее всё ясно: есть Зеленоград, с 65-90 нм. Есть TSMC, который не в России, но чипы там тоже можно производить.
А вот сколько (и где) студентов в России хорошо обучают Verilog'у, так что они могли бы пойти сразу писать процессоры? Где все эти люди? Какими студенческими проектами занимаются? Уходят работать сразу на военку после старшего курса?
Если вдруг кто-то обладает информацией, поделитесь, сколько в США, Китае, России и Мексики (для сравнения) в год выпускается специалистов, которые могут разрабатывать чипы (или микроэлектронику)? Тогда можно хоть какие-то делать сравнения)
Еще скорость будет зависеть от частоты самого DDR и того, что делает процессор (читай, операционная система) в момент теста (что она пишет/читает в/из DDR).
Наткнулся на видение SoC от 2011 года:
www.arrownac.com/offers/vision/files/ppt/altera-soc-fpga.pdf
Там (см. стр. 16) можно увидить числа ~100Gbps для Cyclone V. (Видимо, это получено перемножением 256 * 200 * 10^6 * 2 [Read + Write] ).
Числа, скорее всего, маркетинговые :)
Можно, например, с процом взаимодействовать через PCIe (как и GPU): заливать туда обьемы данных, FPGA шифрует и отдает обратно.
Если хочется Ethernet шифровать сразу, то можно Ethernet завести на FPGA и сразу пакетики шифровать/дешифровать. Либо даже совместить это и сделать свою 10G/40G сетевую карточку на FPGA [либо купить готовый кит, и написать под нее софт] с шифрованием.
На opencores.org есть две корки ГОСТа, можно их собрать под топовые чипы и посмотреть производительность. И если не устроить, то писать их самим :)
В sendpfast просто используется стандартный tcpreplay: сначала создается файл, который необходимо отправлять, а потом он отправляется tcpreplay, так что по поводу производительности здесь не надо беспокоиться :)
Пример, конечно, неплохой, но ИМХО, такая оптимизация не нужная (да и вредная, т.к. не особо интуитивная).
Чаще всего проблемы в других вещах, чем в счетчиках.
Сколько серверов (и каких) надо иметь, чтобы писать 100 Гбит/c видео?
А как происходит обратная связь с операторами? К примеру, какая-то из камер зависла и перестала передавать поток. Вы об этом факте сообщаете операторам (каким-то SNMP-трапом(?)), и они должны её починить в течение какого-то времени? Или наоборот, ДИТ занимается починкой/ресетом/заменой камер?
Есть и 100G ;)
Как обеспечивается прием и обработка 120 тысяч видеопотоков? Какие трюки были применены? Как происходит передача? RTP/UDP, RTSP? Сколько всего трафика приходится системе съедать?
Как гарантируется «качество» картинки? На некоторых картинках с камер были видны характерные «синие экраны». Как это детектируете, как это исправляете (через какое время)? Есть ли какие-то SLA по доступности/недоступности потока?
Если у нас, расскажете за счет чего произошло ускорение?
Мультиплексоры, демультиплексоры, фифошки?
Если на уровне блок-схем, то у меня как-то руки не поднимаются писать [про те проекты, в которых я участвую], кажется что, материала на хорошую статью не особо хватит. Если разбирать код, то руководство может сделать атата, если буду сливать исходники в интернетах)
Не так давно вместе с коллегой были в гостях у Марата eucariot ( habrahabr.ru/post/246753/ ), где я рассказывал о применении FPGA в конкретном проекте: 100G Ethernet балансировщик ( с функцией фильтрации ). Позволю себе привести слайд из презентации «блок-схемы»:
Если будет интересен рассказ о проектах в формате похожих блок-схем (ну или чуть подробных ), то почему нет? :)