Автопилот в авиации изобрели лет 20 тому назад. Но летчики и по сей день им редко пользуются. Вайбкодинг - это когда вместо пилота за штурвал садят обезьяну и включают автопилот.
Чем плохо для компании "отбывать номер" качественно и в срок закрывая задачи и обучая менее опытных?
Речь не о таких специалистах, а скорее о тех, кто не напрягается, когда комаде нужно чуть "поднажать" и каждый должен показать больше, чем от него требуют 90% времени, чтобы не подвести коллег. Это не только временный овертайм, но и необходимость временно решать более сложные задачи.
Ну и бывает так, что сотрудник явно может и хочет больше, а текущая позиция его по большей части демотивирует и ведет не туда. В этой ситуации лучше этому сотруднику сразу и прямо все сказать, а дальше уже пусть он сам для себя решит.
Очень хорошая статья на злободневную тему. Спасибо автору. Сам нередко сталкивался с ситуацией, когда проявление добродушия и гуманности вело только к бОльшим проблемам. Если человек явно не вписывается в команду, то лучше ему об этом сказать и попросить его поискать новую работу, которая позволит ему лучше раскрыть свои навыки и способности.
Уже лет 5 как AI громко "заменяет" программистов, но пока это не более чем продвинутый поисковик, который позволяет держать еще меньше мусора в голове и больше думать о задаче.
К слову про верификацию "моделей" на Scala. Как-то начал писать на Scala поведенческую модель относительно сложного алгоритма, проверить разные реализации, потом взять лучшую и перенести ее в RTL. Поведенческую модель ведь писать быстрее чем RTL. Когда закончил отладку "модели", внезапно осознал, что это уже тот самый RTL, который без каких-либо изменений пойдет на кристалл :) и верификация на Verilog уже особо не нужна.
смесь С++, Go и Ocaml. Причём, нужно понимать все три :)
Это миф. Чтобы писать на Chisel, достаточно освоить 20% книги "Scala для чайников" + сам Chisel.
Чем больше пишешь на Chisel, тем больше отношение к старым HDL именно как к assembler. На них пишутся только небольшие низкоуровневые участки кода, которые на Chisel написать нельзя. Например, тех ячейки, ассерции, модели памятей и аналоговых блоков.
Дерево сравнения и без рекурсий на SV будет "лаконичным". Просто на Chisel я написал reduceTree и пошел дальше, так как оно гарантировано работает, а на SV эту штуку предстоит еще отлаживать.
Ну, и в маршруте ASIC: synthesis tool - далеко не единственный инструмент, которому на вход передается RTL.
Более того, если Вы пишете универсальный IP на продажу, а не под конкретный набор САПР, метод с рекурсией заблокируют уже на этапе code review.
Запустить эти скрипты занимает примерно 0.1% времени, а подготовить для них данные - остальные 100%. Вот Chisel ускоряет именно подготовку этих нужных данных.
Может в SpinalHDL иначе, или я что не так делал, но peek/poke - явно не располагает к чему-то сложному. sequencer - неплох, но после перевода Chisel на verilator он пропал. С multi-clock domains какой-то огород нужно городить. VCD - не лучший формат для больших тестов. Та и большие монолитные дизайны JVM не очень любит.
Программы, в основе которых лежит ФП, тоже очень требовательны к ресурсам процессора и памяти. Думаю, это одна из причин его ограниченного использования. Но мы же не программу в итоге получаем, а схему. Для нас все эти ООП и ФП - это не более чем дополнительные инструменты, чтобы быстрее получить нужную нам схему в кристалле.
Все он кончено же не заменит, но жизнь упростит. Более того сама привязка к этим всем legacy "Tcl, Perl, Bash, Python, Verilog" нередко неплохо так тянет назад, так как в Chisel/Scala можно сделать многие вещи проще. Так, чтобы дизайнер фокусировался на разрабатываемом функционале, а не на конфигурации и запуске зоопарка из кустарных скриптов на всевозможных языках. Никто не говорит о полном отказе от Bash и даже от Python, но вызывать Bash для того, что легко сделать прямо из Chisel - тоже как-то странно.
Если на Chisel и на SystemVerilog описывать одну и ту же схему, то результирующая логика будет иметь одну частоту и прочие характеристики (схема-то одна и та же). Просто описание на Chisel будет проще, его напишут быстрее и оно быстрее заработает. Вот и вся разница. И чем сложнее схема тем больше эта разница.
Chisel не имеет инструментов для генерации SDC и UPF. А вот в ChipYard (на основе Chisel) есть инструментарий для генерации и этих штук и еще много чего. Можно для своих нужд подобный упрощенный фреймворк сделать.
Чизел как бы избавляет от одних проблем но добавляет другие
Все верно. Но они все решаемы.
Chisel больше подходит для крупных IP, которые не зависят от технологии и должны легко портироваться с технологии на технологию. Те, части IP которые зависят от технологии, как правило лежат отдельно, и пишутся на том же System Verilog, при этом основная логика IP остается на Scala/Chisel.
На самом деле, Verilog с самого начала разрабатывался как язык, который будет использоваться как для синтеза
Википедия не согласна: Originally, Verilog was only intended to describe and allow simulation; the automated synthesis of subsets of the language to physically realizable structures (gates etc.) was developed after the language had achieved widespread usage. Собственно, поэтому 90% стандарта посвящено не синтезируемым конструкциям, ну а те 10% которые синтезируется, видно, что они изначально были про что-то другое (всякие RS-триггеры и т п).
Что там авторы указывали в своих маркетинговых документах - это уже десятое.
Если Вы хотите тестировать большую процессорную систему, то это лучше делать на SystemVerilog/UVM и т. п. Если в составе Вашего большого дизайна есть относительно небольшой блок, который реализует сложный алгоритм, то его можно быстро и легко покрыть тестами на 100% прямо в Chisel. Основные проблемы сложных тестов: ресурсы Chisel в плане тестирования очень ограничены (в сравнении с возможностями Verilog), в версиях ниже 6.0 использовался какой-то безумно медленный симулятор. Сейчас его заменили на verilator, но первая проблема осталась, и не думаю, что в ближайшее время что-то изменится.
Есть библиотеки Chisel, позволяющие моделировать относительно простые блоки прямо на Chisel с использованием verilator. Там тоже происходит генерация, но она скрыта от пользователя. Иногда этот инструмент даже более удобен чем стандартные симуляторы, так как он понимает Scala и интегрирован с библиотеками Scala для запуска юнит-тестов. Можно запустить один тест, а можно много и в параллель и выдать общий отчет - все это идет из коробки. Очень удобно для тестирования маленьких компонент проекта со сложной логикой работы (декодеры, арбитры, алгоритмы обработки данных и т п).
Очень интересная статья. Спасибо. Иногда коммутаторы отбрасывают фреймы с неизвестным MAC адресом. Это поведение разрешено в 802.1Q и настраивается в таблицах коммутатора.
Это да. Хороший руководитель все-таки должен соображать в том, что делает команда. В идеале ранее он должен был быть на месте членов команды, чтобы понимать их на 100%. Часто именно такому руководителю-технарю не хватает софт-скилов, о которых говорит автор.
Как-то небезопасно. Банальные ioRegWrite() и ioRegRead() будут лучше в плане читаемости кода и его поддержки. В драйверах сложных устройств, куда более важна последовательность доступа к регистрам, правильное расположение барьеров и правильная работа с кэшем (в случае с DMA). Здесь запутанность кода с названиями вроде pllConfig.set(), содержащими неявную запись в биты HW регистров только вредит. А вот на уровне выше, да, здесь работа с классами/методами вроде pllConfig.setFrequencyMhz() будет куда удобнее.
Автопилот в авиации изобрели лет 20 тому назад. Но летчики и по сей день им редко пользуются. Вайбкодинг - это когда вместо пилота за штурвал садят обезьяну и включают автопилот.
Речь не о таких специалистах, а скорее о тех, кто не напрягается, когда комаде нужно чуть "поднажать" и каждый должен показать больше, чем от него требуют 90% времени, чтобы не подвести коллег. Это не только временный овертайм, но и необходимость временно решать более сложные задачи.
Ну и бывает так, что сотрудник явно может и хочет больше, а текущая позиция его по большей части демотивирует и ведет не туда. В этой ситуации лучше этому сотруднику сразу и прямо все сказать, а дальше уже пусть он сам для себя решит.
Очень хорошая статья на злободневную тему. Спасибо автору. Сам нередко сталкивался с ситуацией, когда проявление добродушия и гуманности вело только к бОльшим проблемам. Если человек явно не вписывается в команду, то лучше ему об этом сказать и попросить его поискать новую работу, которая позволит ему лучше раскрыть свои навыки и способности.
Уже лет 5 как AI громко "заменяет" программистов, но пока это не более чем продвинутый поисковик, который позволяет держать еще меньше мусора в голове и больше думать о задаче.
К слову про верификацию "моделей" на Scala. Как-то начал писать на Scala поведенческую модель относительно сложного алгоритма, проверить разные реализации, потом взять лучшую и перенести ее в RTL. Поведенческую модель ведь писать быстрее чем RTL. Когда закончил отладку "модели", внезапно осознал, что это уже тот самый RTL, который без каких-либо изменений пойдет на кристалл :) и верификация на Verilog уже особо не нужна.
Это миф. Чтобы писать на Chisel, достаточно освоить 20% книги "Scala для чайников" + сам Chisel.
Чем больше пишешь на Chisel, тем больше отношение к старым HDL именно как к assembler. На них пишутся только небольшие низкоуровневые участки кода, которые на Chisel написать нельзя. Например, тех ячейки, ассерции, модели памятей и аналоговых блоков.
Дерево сравнения и без рекурсий на SV будет "лаконичным". Просто на Chisel я написал reduceTree и пошел дальше, так как оно гарантировано работает, а на SV эту штуку предстоит еще отлаживать.
Ну, и в маршруте ASIC: synthesis tool - далеко не единственный инструмент, которому на вход передается RTL.
Более того, если Вы пишете универсальный IP на продажу, а не под конкретный набор САПР, метод с рекурсией заблокируют уже на этапе code review.
Запустить эти скрипты занимает примерно 0.1% времени, а подготовить для них данные - остальные 100%. Вот Chisel ускоряет именно подготовку этих нужных данных.
Может в SpinalHDL иначе, или я что не так делал, но peek/poke - явно не располагает к чему-то сложному. sequencer - неплох, но после перевода Chisel на verilator он пропал. С multi-clock domains какой-то огород нужно городить. VCD - не лучший формат для больших тестов. Та и большие монолитные дизайны JVM не очень любит.
Программы, в основе которых лежит ФП, тоже очень требовательны к ресурсам процессора и памяти. Думаю, это одна из причин его ограниченного использования. Но мы же не программу в итоге получаем, а схему. Для нас все эти ООП и ФП - это не более чем дополнительные инструменты, чтобы быстрее получить нужную нам схему в кристалле.
Все он кончено же не заменит, но жизнь упростит. Более того сама привязка к этим всем legacy "Tcl, Perl, Bash, Python, Verilog" нередко неплохо так тянет назад, так как в Chisel/Scala можно сделать многие вещи проще. Так, чтобы дизайнер фокусировался на разрабатываемом функционале, а не на конфигурации и запуске зоопарка из кустарных скриптов на всевозможных языках. Никто не говорит о полном отказе от Bash и даже от Python, но вызывать Bash для того, что легко сделать прямо из Chisel - тоже как-то странно.
Если на Chisel и на SystemVerilog описывать одну и ту же схему, то результирующая логика будет иметь одну частоту и прочие характеристики (схема-то одна и та же). Просто описание на Chisel будет проще, его напишут быстрее и оно быстрее заработает. Вот и вся разница. И чем сложнее схема тем больше эта разница.
Chisel не имеет инструментов для генерации SDC и UPF. А вот в ChipYard (на основе Chisel) есть инструментарий для генерации и этих штук и еще много чего. Можно для своих нужд подобный упрощенный фреймворк сделать.
Все верно. Но они все решаемы.
Chisel больше подходит для крупных IP, которые не зависят от технологии и должны легко портироваться с технологии на технологию. Те, части IP которые зависят от технологии, как правило лежат отдельно, и пишутся на том же System Verilog, при этом основная логика IP остается на Scala/Chisel.
Википедия не согласна: Originally, Verilog was only intended to describe and allow simulation; the automated synthesis of subsets of the language to physically realizable structures (gates etc.) was developed after the language had achieved widespread usage. Собственно, поэтому 90% стандарта посвящено не синтезируемым конструкциям, ну а те 10% которые синтезируется, видно, что они изначально были про что-то другое (всякие RS-триггеры и т п).
Что там авторы указывали в своих маркетинговых документах - это уже десятое.
Если Вы хотите тестировать большую процессорную систему, то это лучше делать на SystemVerilog/UVM и т. п. Если в составе Вашего большого дизайна есть относительно небольшой блок, который реализует сложный алгоритм, то его можно быстро и легко покрыть тестами на 100% прямо в Chisel. Основные проблемы сложных тестов: ресурсы Chisel в плане тестирования очень ограничены (в сравнении с возможностями Verilog), в версиях ниже 6.0 использовался какой-то безумно медленный симулятор. Сейчас его заменили на verilator, но первая проблема осталась, и не думаю, что в ближайшее время что-то изменится.
Есть библиотеки Chisel, позволяющие моделировать относительно простые блоки прямо на Chisel с использованием verilator. Там тоже происходит генерация, но она скрыта от пользователя. Иногда этот инструмент даже более удобен чем стандартные симуляторы, так как он понимает Scala и интегрирован с библиотеками Scala для запуска юнит-тестов. Можно запустить один тест, а можно много и в параллель и выдать общий отчет - все это идет из коробки. Очень удобно для тестирования маленьких компонент проекта со сложной логикой работы (декодеры, арбитры, алгоритмы обработки данных и т п).
Очень интересная статья. Спасибо. Иногда коммутаторы отбрасывают фреймы с неизвестным MAC адресом. Это поведение разрешено в 802.1Q и настраивается в таблицах коммутатора.
Это да. Хороший руководитель все-таки должен соображать в том, что делает команда. В идеале ранее он должен был быть на месте членов команды, чтобы понимать их на 100%. Часто именно такому руководителю-технарю не хватает софт-скилов, о которых говорит автор.
Как-то небезопасно. Банальные ioRegWrite() и ioRegRead() будут лучше в плане читаемости кода и его поддержки. В драйверах сложных устройств, куда более важна последовательность доступа к регистрам, правильное расположение барьеров и правильная работа с кэшем (в случае с DMA). Здесь запутанность кода с названиями вроде pllConfig.set(), содержащими неявную запись в биты HW регистров только вредит. А вот на уровне выше, да, здесь работа с классами/методами вроде pllConfig.setFrequencyMhz() будет куда удобнее.