Jump to content

    
Sign in to follow this  
Мур

О философии HDL-дизайнера

Recommended Posts

Начинал с контроллеров, потом были ПЛИС, сейчас АСИКи.

 

Какая разница как это называть? У вас есть инструмент решения задачи, среда и правила игры. Что думаете программисту контроллеров недоступна схемотехника? Или человек с высшим образованием не постигнет работу триггера?

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

 

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

 

Не старейте товарищи, нечего брюзжать :)

 

 

Share this post


Link to post
Share on other sites

Вернемся к теме. По обычному программированию написано много книг по стилю написания программ: паттерны, структурирование, рефакторинг, рекомендации по оформлению хорошо читаемого текста. Есть ли что-то подобное по HDL?

Share this post


Link to post
Share on other sites
Начинал с контроллеров, потом были ПЛИС, сейчас АСИКи.

 

Какая разница как это называть? У вас есть инструмент решения задачи, среда и правила игры. Что думаете программисту контроллеров недоступна схемотехника? Или человек с высшим образованием не постигнет работу триггера?

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

 

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

 

Не старейте товарищи, нечего брюзжать :)

 

А к какому Госту, по Вашему мнению, можно привязать проект на ПЛИС, До сих пор все отбиваются от понятия программный продукт.

 

 

 

Вернемся к теме. По обычному программированию написано много книг по стилю написания программ: паттерны, структурирование, рефакторинг, рекомендации по оформлению хорошо читаемого текста. Есть ли что-то подобное по HDL?

 

К сожалению, нет.

Share this post


Link to post
Share on other sites
Вернемся к теме. По обычному программированию написано много книг по стилю написания программ: паттерны, структурирование, рефакторинг, рекомендации по оформлению хорошо читаемого текста. Есть ли что-то подобное по HDL?

Я бы посоветовал прочитать Краткий курс HDL. Например по оформлению кода - http://www.kit-e.ru/articles/circuit/2008_07_140.php очень многие пренебрегают этими простыми правилами и порой смотришь на чужой код и волосы встают дыбом, как вообще можно ЭТО читать ? И в итоге прежде чем начать разбирать чужой код сидишь и приводишь его в читаемый вид.

А то как описывать на HDL читайте "recommended hdl coding styles" от производителей ПЛИС. И много и много практики.

Share this post


Link to post
Share on other sites
рекомендации по оформлению хорошо читаемого текста. Есть ли что-то подобное по HDL?

Есть конечно и немало...

Да хотя бы книга о 1000 и 1 ошибке, Сазерленд...

На сайтах производителей ПЛИС... У меня немного...

 

Share this post


Link to post
Share on other sites

Если уж автор поднимает тему о "философии HDL-дизайна", то обсуждать ее надо с философами :-)

А тут чаще обсуждают практические вопросы реализации...

 

Share this post


Link to post
Share on other sites
А к какому Госту, по Вашему мнению, можно привязать проект на ПЛИС, До сих пор все отбиваются от понятия программный продукт.

Это понятие как раз и требует разделить архитектуру от алгоритма на этой архитектуре.

К сожалению, нет.

Есть. Это оговаривается стандартом предприятия индивидуально. Без этого работать не возможно.

....По теме

1.Вынужден повторить простую аналогию..

Микросхема контроллера, только что прошедшая корпусирование у производителя и не имеющая пока целевую заливку имеет ПО? Вот и ПЛИС, с залитой конфигурацией, пока только архитектура. Её предстоит использовать.

Она без ПО внешнего управляющего контроллера никак не интересна(если в ПЛИС ядро процессора, а сама программа вовне). Кусок пластмассы с кремнием внутри.

2. Финалом работы с дизайном на ПЛИС есть этап "оптимизации кода", когда проверяется запас надежности при разных температурах. Если этот запас маленький,- переписывается код, чтобы новая архитектура(на базе нового кода) работала быстрее на уровне одного такта(!). Есть ли аналогия в контроллерах?

3. SoC, появившиеся недавно, как раз сделали вопрос рельефней. Та часть, что соответствует FPGA, становится зоной проблемно-ориентированной периферии,где разработчик дизайна закладывает регистры управления, данных, фоновые расчетчики CRC, буферы данных, диагностику событий...и т.п. Все это мертво без самого процессора. Именно он "алгоритмичен" по отношению к периферии. Ему поручено менять на ходу режимы работы по мере необходимости основной задачи.

 

А тут чаще обсуждают практические вопросы реализации...

Я видел эволюционирующих из традиционного программирования в HDL-дизайн, которые лихо(аж завидно!) генерировали конструкции, которые достигали цели за счет синтезатора, не утруждая себя рассмотрением RTL. Но в определенный момент наступает ситуация, что дизайн "тормозит" и надо срочно менять что-то в семантике кода, чтобы убрать слои логики...

...Видимо вас это не коснулось.

Когда человек имеет навыки в одной области, а его бросают по разным направления, где все новое(от системы команд, разрядности, документации и средств отладки),- это многократная нагрузка.

 

Современный мир построен на разделении труда.

Share this post


Link to post
Share on other sites
Современный мир построен на разделении труда
.

 

Это старый "современный" мир... Сейчас стало модно менять специальности, человек 10 лет может программировать, а потом уходит в асики или вообще маркетинг....

 

Человек генерит задачи синтезатору и не смотрит в РТЛ это не от того что он программист, а от того что у него еще нет опыта или для решения его задачи хватает ресурса. Студенты которые еще вообще никто делают так же.

 

То что парадигма не укладывается в ГОСТ, это проблема госта и архаичного подхода....

Share this post


Link to post
Share on other sites
Это старый "современный" мир... Сейчас стало модно менять специальности, человек 10 лет может программировать, а потом уходит в асики или вообще маркетинг....

Весь пар уходит в свисток...(это об эффективности использования потенциала специалиста) Бытие(з\п) определяет сознание...

Человек генерит задачи синтезатору и не смотрит в РТЛ это не от того что он программист, а от того что у него еще нет опыта или для решения его задачи хватает ресурса. Студенты которые еще вообще никто делают так же.

Чтобы так резвиться надо платить за такую возможность(современная элементная база не дешева)

То что парадигма не укладывается в ГОСТ, это проблема госта и архаичного подхода....

Вот это хорошая мысль! Архаизм,- считать создание архитектуры при помощи HDL программированием. HDL - все-таки язык описания схем! А цель - создание архитектуры (аналог куска кремния, где топология I8086 ,к примеру)

 

Как говорил нам лектор по Альтере с Чехии,- SoC - то место, где появляются незаменимые люди, поскольку специалист должен владеть обоими областями ОДНОВРЕМЕННО. И я тут полностью согласен...

 

Плохо, что сейчас я имею дело не с ARM, а с TMS320. SoC сейчас в подавляющем большинстве имеет на борту именно ARM. Так что буду деградировать...

Share this post


Link to post
Share on other sites
Вот это хорошая мысль! Архаизм,- считать создание архитектуры при помощи HDL программированием. HDL - все-таки язык описания схем!

Первая программа на C++ студента-сишарпщика завесила мой комп (new без delete), а ведь переход программист->программист. И я так же маялся с ошибкой multiple assignments, даже зная схемотехнику, просто рассчитывал что это как-то разрулится языком. Просто это набор правил, и я мало думаю о схемотехнике, больше думаю о том что позволяет язык, и что может просадить тайминги (равно как программист думает какие вызовы или алгоритмы просадят производительность).

Share this post


Link to post
Share on other sites
..... и я мало думаю о схемотехнике, больше думаю о том что позволяет язык, и что может просадить тайминги (равно как программист думает какие вызовы или алгоритмы просадят производительность).

 

У меня это врожденное. Гарантируемая синтезабельность только в случае, если постоянно думаю о схемотехнике и макроячейке конкретной ПЛИС. CPLD, к примеру, имеет малый ресурс и каждый триггер на счету... "Жмет" фантазии с ходу...

 

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

Share this post


Link to post
Share on other sites
У меня это врожденное. Гарантируемая синтезабельность только в случае, если постоянно думаю о схемотехнике и макроячейке конкретной ПЛИС. CPLD, к примеру, имеет малый ресурс и каждый триггер на счету... "Жмет" фантазии с ходу...

 

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

 

 

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

Share this post


Link to post
Share on other sites
Встречал аспиранта, который зарекся с FPGA не связываться по причине, огромного времени компиляции проекта (даже более суток). От себя добавлю - при больших проектах(и бенчах) огромное время в симуляции ради просмотра крохотного места в дизайне... А все из-за параллельного принципа работы архитектуры(сжирающего ресурсы симулирующей машины).

Так это не зеркало кривое, а голова...

Нужно делать два набора параметров в проекте и к ним "дебаг-релиз"... Вот и все... Если скажем тактовая в проекте 100Мгц, а какой-нибудь SPI - 1Мгц и надо при старте проекта получить пяток кадров по SPI? Так вот, просто ставим для "дебага" параметр для клока SPI в 2-4 такта от тактовой... Ну и так во всех остальных случаях.

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

Share this post


Link to post
Share on other sites
Заменяйте симуляцию на FPGA тест, день помучится с синтезом и потом ехать с ветерком.

С ветерком вы доедете до своей лаборатории, где обложившись логическими анализаторами и всякими

чипскопами будете долго грустить, разбираясь почему 1000 раз алгоритм отработал правильно,а на 1001 почему то нет :(

 

Синтез больших проектов по 8-12 часов это нормально, для этого делаются специальные выделенные мощные сервера, где

запускается несколько инстенсов с разными сидами.

Большое время синтеза и P&R так же может говорить о оверконстрейнинг, то есть, так понакручены констрейны, что тулзовина

не может разобраться, что же вы от нее хотите.

Естественно и "кривой" RTL может быть причиной длительного синтеза. Тут всегда полезно делать поблочный синтез перед системным билдом,

что бы быть уверенным, что все модули по отдельности корректно синтезируются.

 

Многочасовое моделирование это вообще норма, нужно обеспечить определенный coverage, вот вы и гоняете часами constrain random tests, что бы

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

Если в допотопном симуляторе типа ISIM моделировать тяжелые проект с PCIe корками, корками контроллерами памяти и прочее,

то чего тут удивляться, что все долго.

Тут так же полезно делать поблочное моделирование. Интенсивное поблочное моделирование позволяет на системном уровне моделирования ставить,

упрощенный набор тестов.

 

Ну и 5 копеечек по самой теме,

ПЛИС программисты must die, выживут только дизайнеры с разделением по специализациям :-)

 

Share this post


Link to post
Share on other sites
Так это не зеркало кривое, а голова...

И добавлю...

Это не только кривая голова студента...

но еще беда в том, что его никто не смог научить тому, как надо..

Поэтому фраза: "Встречал аспиранта, который зарекся с FPGA не связываться ", тоже кое о чем говорит... Не научили на кафедре - это понятно. Академики и сами этого не знают. Но вот не научили на фирме, где он работает? Это уже говорит о "фирме"... :(

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this