Комментарии 12
Вообще, идея притянуть ООП в проектирование аппаратуры мне не очень нравится. Хотя вопрос, конечно, спорный.
Я нуб и извините, если скажу чушь, но всё же...
Чтобы не приходилось играть со средой разработки в игру «кто кого умнее».
Когда я читал книгу Harris&Harris, у меня сложилось впечатление, что на Verilog тоже нужно писать не просто по стандарту, а по идиомам, иначе компилятор не поймёт. В этом смысле язык, в котором бы идиомы явно записывались в коде, был бы, наверное, шагом вперёд (не утверждаю, что это Chisel). Ну и здесь это поведение, во всяком случае, детерминированное, а не какие-то эвристики.
автоматическое своевольное добавление chisel-ом логики тактовой частоты и ресета мне кажется странной практикой.
Со своей, программистской, колокольни: ассемблер нагляднее C с точки зрения того, что в итоге получится, и можно, например, в каждую функцию предавать параметры, как в данном случае удобно. Можно договориться о calling convention и аккуратно везде её соблюдать. А можно писать на C, и там нужно исхитриться, чтобы не соблюсти calling convention. Последнее мне кажется более безопасным, хотя и может помешать, например, написанию низкоуровневого кода ядра ОС — ну так на то и ассемблерные вставки и отдельный ассемблерные файлы.
Переусложнение и интеллектуализация технологий разработки софта (плюс, конечно же, идеологическая победа ООП) уже привели к тому, что те программы, для которых хватало мегабайта, теперь еле помещаются в сто. Такого же эффекта в аппаратуре как-то совсем не хочется.
Под связкой C-ассемблер я имел в виду просто два языка программирования разного уровня. То есть не "напишем всё на Чизеле, а потом вручную поправим ниже уровнем". Я имел в виду "что удобно, быстро напишем на Чизеле, что неудобно — допишем на Verilog/VHDL" — я же не предлагаю выкинуть классические HDL-языки и заменить их на Chisel. А вот с количеством ресурсов — это да, остаётся надеяться разве, что компилятор выкинет всё лишнее (как компилятор C вычисляет константные выражения и т.д., образовавшиеся после раскрытия макросов). Ну и на то, что взамен это хотя бы даст то железо (или FPGA-дизайны), которое раньше было сильно сложно сделать (ну или простое, но полезное и много видов) за счёт упрощения процесса разработки.
Упрощение процесса разработки — да, чрезвычайно ценно. Рабочее время на вес золота, а туда-сюда гигабайт — копейки. Но поговаривают, что нужно потихоньку отвыкать закладываться на развитие элементной базы.
Переусложнение и интеллектуализация технологий разработки софта (плюс, конечно же, идеологическая победа ООП) уже привели к тому, что те программы, для которых хватало мегабайта, теперь еле помещаются в сто. Такого же эффекта в аппаратуре как-то совсем не хочется.
Ну это явно не про chisel. Это скорее про HLS. Вот эта штука действительно более чем спорная. А chisel остается как-бы очень очень высокоуровневым верилогом. Т.е. в коде можно использовать весьма высокоуровневые абстракции, но думать тем не менее приходится на уровне регистровых передач. А значит неконтролируемое разрастание реализации тут скорее всего не грозит. Хотя ещё раз напоминаю, что с chisel я не знаком. Просто желающий познакомиться и опробовать его в самое ближайшее время.
Не знаю кому как, но мне пример на Verilog кажется и проще, и нагляднее.
Да, мне то же самое показалось. Но сколько тут привычки и сколько свойств самого языка, судить не берусь. Надо пробовать.
Кроме того, автоматическое своевольное добавление chisel-ом логики тактовой частоты и ресета мне кажется странной практикой.
Да, и это тоже…
Вообще, идея притянуть ООП в проектирование аппаратуры мне не очень нравится
А вот тут не знаю… Проектирование аппаратуры это как раз та область, где объекты вполне очевидны и выделимы. И ООП тут должно рулить. Будете долго смеяться, но свою первую прогу на С++ (имеется в виду абсолютно добровольное и сознательное использование ООП, а не потому что такой стиль навязали разработчики библиотек), я написал когда понадобилось конвейризовать алгоритм Кули-Тюки (быстрое преобразование Фурье), для запихивания оного в FPGA.
Chisel — (не совсем) новый подход к разработке цифровой логики