[RobFPGA 27]

2 hours ago, Leka said:

Algodoo, это не язык программирования, это программа физического моделирования с графическим редактором ...

10G контроллер - это как раз самая что ни есть "узкая, частная задача".  
Для физических интерфейсов можно оставить Верилог, для всего остального это слишком специализированный инструмент. 

10G это лишь как пример.  Это может быть любой модуль критичный по разным параметрам. Но как только в вашей концепции появляются "исключения" то уж точно нельзя назвать такие решение универсальными  
В тоже время Verilog (как и VHDL, SV) позволяет решать любые задачи. При желании можно на нем реализовать систему любых расчетов.  Как впрочем и реализовать любой физический интерфейс.  Так что это скорее "слишком" универсальный инструмент. Который естественно требует от пользователя глубоких знаний и понимания.
А вот как раз "костыли" построенные над ним пытаются решать узкие задачи. И одна из таких главных задач - упростить его использование для пользователя, понизить требуемый порог знаний и понимания. Ускорить разработку систем на RTL за счет введение более высоких абстракций при естественно допустимом снижении эффективности в реализации. Что и демонстрируют сейчас успехи в развитии систем генерации кода на том же Python или синтеза с того же самого C/C++. 

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

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

[Leka 0]

2 hours ago, RobFPGA said:

Игнорируя то что эти решения ломают или ограничивают функционал этого языка как для синтеза так и для симуляции. 

Хочется так думать - думайте, не буду переубеждать. Концепцию лаконичного описания конвейеров отлаживал, запуская в Icarus Verilog код "2D-песочницы" после конвертера. Симулятор перестал использовать, как только получил первый приемлемый результат - синтез идет менее минуты, гораздо быстрее оставшиеся мелкие ошибки выловить в железе - получается на порядок быстрее.  

[RobFPGA 27]

4 hours ago, Leka said:

Хочется так думать - думайте, не буду переубеждать. Концепцию лаконичного описания конвейеров отлаживал, запуская в Icarus Verilog код "2D-песочницы" после конвертера. Симулятор перестал использовать, ...

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

[Leka 0]

On 12/31/2021 at 6:38 PM, RobFPGA said:

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

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

On 12/31/2021 at 12:19 PM, RobFPGA said:

В тоже время Verilog (как и VHDL, SV) позволяет решать любые задачи... Так что это скорее "слишком" универсальный инструмент... А вот как раз "костыли" построенные над ним пытаются решать узкие задачи. И одна из таких главных задач - упростить его использование для пользователя, понизить требуемый порог знаний и понимания.

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

[RobFPGA 27]

2 hours ago, Leka said:

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

Опять вы передергиваете - метод эталонной модели универсален, позволяет проверит RTL реализацию и мигалки светодиодом и сложную DSP обработку. И пока ничего другого для того чтобы убедится в вашей "безгрешности" при написании RTL кода не придумали. А вот для больших и сложных дизайнов в FPGA, не говоря уже про ASIC, метод отладки и проверки в железе бывает уж слишком долог и дорог.   

2 hours ago, Leka said:

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

Сейчас тоже так считают. И на asm продолжают реализовывают все то что на ЯВУ эффективно сделать не получается. Но ваш текущий подход к Verilog  ведь не превращает asm в ЯВУ. Вы лишь лепите поверх свой macro-asm. Ломая по ходу много что другое в языке.

[Мур 1]

On 12/31/2021 at 5:38 PM, RobFPGA said:

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

Симулятор - еще не доказательство! Он только помогает уйти от начальной неопределенности, зная что не работающий на симуляторе дизайн  точно не работает "на железе"!  И этот дизайн способен работать.

Помогает убрать мелкую шелуху в исходниках.  Скрытые глюки требуют итерационного подхода в отладке "от железа"(SignalTab) к симулятору.

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

 

Кстати, как вы относитесь к скрытым коллизиям для вариантов, когда сами отладочные вставки нарушают саму работу всего дизайна, либо наоборот,- удаление вставки нарушает?

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

 

[Leka 0]

8 hours ago, RobFPGA said:

Вы лишь лепите поверх

ЯВУ отличается от низкоуровневого asm в первую очередь сокрытием операторов goto и архитектурных регистров (и флагов), те самых неудобных концепций с точки зрения высокоуровневого описания алгоритмов. 

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

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

 

8 hours ago, RobFPGA said:

Ломая по ходу много что другое в языке.

Это называется - поклеп. 

[RobFPGA 27]

1 hour ago, Мур said:

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

Вы говорите про разные уровни доказательства. Уровень сима. доказывает, что RTL разработчик реализовал в коде как минимум то, что его просили сделать в TЗ. И качество и полнота этой проверки зависит лишь от полноты и качества референсной модели. Причем как в плане корректного функционирования, так и функционирования при различных ошибках и проблемах. И часто втрое может иметь больший объем проверок чем первое. И повторюсь, итерационные проверки через железо долги, дороги, часто требуют спец. аппаратные решения, и не всегда позволяют смоделировать и проверить поведения системы во всех возможных случаях. Но даже верификация через железо (для ускорения последнего) требует создание все тех же референс моделей.    
А уровень JTAG/SignalTab/ChipScope ...  лишь позволяет восполнить неполноту референс модели или модели рабочего окружения и только 

 

58 minutes ago, Leka said:

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

Это называется - поклеп. 

А это называется троллинг   

Уже обсуждали с вами это в другой теме.  Ваши модификации языка не решают задачи высокоуровневого синтеза. Вы лишь в чем-то упрощаете себе ввод текста, при этом усложняя его понимание, и ломая заложенный функционал. Выше яркий пример этой ломки когда код написанный “правильно" в вашем стиле работает по разному в симе и синтезе. И это IMHO убивает вашу "концепцию" на корню.   
Концепции V/SV в первую очередь предназначены для возможности языка описать все требуемое многообразие необходимое для разработки железа и верификационного окружения. И если эти концепции языка почему то не удобны вам это не значит что они неудобны всем. Скорее они вам не понятны, так как возможно вы привыкли мыслить более простыми, линейными принципами вычислений. Но, опять же повторюсь, сейчас эти "неудобства" для обычных программистов вполне успешно решаются средствами высокоуровневого синтеза HLS, а не натягиванием поверх языка сомнительных макросов.

    
        

[Мур 1]

1 hour ago, RobFPGA said:

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

Я намеренно обострил картину, чтобы народ не идеализировал симуляцию!

Для сложных проектов в 99% случаев после симуляции "на железе" дизайн НЕ РАБОТАЕТ

...."теория, мой друг, сера, но вечно зелено древо жизни"!

Цитата из трагедии Гете «Фауст», ч. 1, сц. IV

[Leka 0]

1 hour ago, RobFPGA said:

Выше яркий пример этой ломки когда код написанный “правильно" в вашем стиле работает по разному в симе и синтезе. И это IMHO убивает вашу "концепцию" на корню.   

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

Я не приводил код "в моем стиле". 

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

 

 

Изменено 5 января, 2022 пользователем Leka

[RobFPGA 27]

1 minute ago, Мур said:

Для сложных проектов в 99% случаев после симуляции "на железе" дизайн НЕ РАБОТАЕТ

У меня другая статистика. Уже был ряд проектов (и не маленьких) в которых отладка проекта в железе не понадобилась вообще. Ну и на это заявление с ужасом и слезами смотрят все разработчики ASIC     

 

2 minutes ago, Leka said:

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

Я не приводил код "в моем стиле". 

Вы же это писали :

On 12/29/2021 at 3:21 PM, Leka said:

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

2) q1 и q2 всегда будут иметь одинаковые значения, независимо от остального (скрытого) кода.

А  теперь в полном соответствии с  вашим пониманием "правильной" концепции:  

module top(input a1, output q1,q2);
  logic a, q; 
  always_comb begin a <=a1; q1<=a; end
  always_comb begin q <= a; q2<=q; end
endmodule

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

[Мур 1]

10 minutes ago, RobFPGA said:

 Ну и на это заявление с ужасом и слезами смотрят все разработчики ASIC     

Понимаю..  Идеал полезный.

Только для ASIC собирают целые команды(слишком велика цена ошибки), а тут ты один и тебе дают в лучшем случае пол-года на всё.

Успеваешь отработать фрагменты и общую сборку на симуляторе, чтобы увидеть работу всех составляющих.  Далее один-на один с железом...

 

[blackfin 16]

23 minutes ago, Мур said:

Только для ASIC собирают целые команды (слишком велика цена ошибки), а тут ты один и тебе дают в лучшем случае пол-года на всё.

Вопрос в сложности проекта. Тут некоторые и с 18-разрядным счетчиком не могут без "целой команды" справиться.. :)

[RobFPGA 27]

34 minutes ago, Мур said:

Только для ASIC собирают целые команды(слишком велика цена ошибки), а тут ты один и тебе дают в лучшем случае пол-года на всё.

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

К тому же - наработки моделей и сценариев верификаций в симе реюзабельны.  При правильной организации процесса многое из тестового окружения мигрирует из проекта в проект  без изменений. Не зря ведь все топят за UVM в первую очередь именно из за этого. А вот отладка в железе это по большому счету время на ветер. Каждый раз все начинай все по новой.   И видишь ты через "дырочку" JTAG  обычно совсем немного. И как обычно бывает сначала не самое интересное. Да еще и каждая сборка с новым probe норовит поломать и так неработающий дизайн по новому. Вот и получается  что сначала кажется  что "... зачем симить,  по быстренькому сейчас тут printf  ChipScopе повешу и все отлажу".  А по факту месяц два гоняешь "неуловимый" баг по дизайну большей частью не понимая, а что же в нем происходит.  И в результате теряешь время больше чем изначально мог потратить на нормальный сим. Знаю по опыту, когда то я тоже так делал    Ну и как отлаживать дизайн если ты физически не можешь повесить JTAG, либо свободных ресурсов нет, либо например те же CPLD?    

[Мур 1]

1 hour ago, RobFPGA said:

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

К тому же - наработки моделей и сценариев верификаций в симе реюзабельны.  При правильной организации процесса многое из тестового окружения мигрирует из проекта в проект  без изменений. Не зря ведь все топят за UVM в первую очередь именно из за этого. А вот отладка в железе это по большому счету время на ветер. Каждый раз все начинай все по новой.   И видишь ты через "дырочку" JTAG  обычно совсем немного. И как обычно бывает сначала не самое интересное. Да еще и каждая сборка с новым probe норовит поломать и так неработающий дизайн по новому. Вот и получается  что сначала кажется  что "... зачем симить,  по быстренькому сейчас тут printf  ChipScopе повешу и все отлажу".  А по факту месяц два гоняешь "неуловимый" баг по дизайну большей частью не понимая, а что же в нем происходит.  И в результате теряешь время больше чем изначально мог потратить на нормальный сим. Знаю по опыту, когда то я тоже так делал    Ну и как отлаживать дизайн если ты физически не можешь повесить JTAG, либо свободных ресурсов нет, либо например те же CPLD?    

О да!..  Все верно!

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

Пришлось далее каждый проект оснащать бенчами и обрастать заделами по специфике применений, которые пригодились многократно.

...С CPLD все понятно. Там упор на симуляцию и свободные пины для осцила..

 

Не могу сказать, что <отладка в железе это по большому счету время на ветер> ! Вовсе нет.  Особенно, когда находишь ошибки не у себя, а в софте у программиста управляющего контроллера.  Ка правило ошибки 50\50 между нами, но режим точно тик-так!