Функциональные языки в разработке аппаратуры

[@YuriPanchul]

Ценная тема кстати, давно собирался изучить Haskell именно для исследования такой возможности

[@Labunsky]

Так вот как оно начиналось

[@burjui]

Не-а, там под винду на C пишут

[@Khort]

Если говорить о тенденциях, то на мой взгляд сейчас куда перспективнее изучать Chisel/Scala, поскольку на нем написан новый опен-сорс процессор RISC-V. Беркли достаточно авторитетны, чтобы продвинуть этот новый HDL в массы. Впрочем, пока коммерческие тулы Synopsys и Cadence не начнут новый язык поддерживать, все это не серьезно.

[@Daffodil]

Читаю сейчас книгу про Scala и параллельно играюсь с Chisel, но пока не понял чем же он хорош — очень всё низкоуровневое. Можете рассказать чем Chisel лучше чем VHDL/Verilog?

[@Khort]

Своего мнения у меня не сложилось пока, к сожалению. Но вот ответ на Ваш вопрос от разработчика RISC-V https://www.quora.com/What-exactly-is-the-point-of-developing-RISC-V-based-CPUs-in-Chisel-rather-than-Verilog-or-VHDL-What-are-the-pros-and-cons

[@potan]

Scala сейчас основной мой рабочий инструмент :-). Но посмотреть на Chisel я пока не успел. Надо восполнить этот пробел.
Но все равно я думаю, что Haskell сильно проще чем Scala и переход на него пойдет легче.

[@Khort]

У меня есть только 16 лет опыта кодинга на верилоге (из HDL языков), но сложилось следующее мнение: чтобы писать качественный, синтезируемый код на верилоге, используется всего несколько унифицированных конструкций. При этом возможности (и косяки) языка раскрываются только при написании тестбенчей. Из чего следует, что имея хороший транслятор в верилог, можно действительно писать на чем угодно. Но! транслятор должен быть действительно хороший, поскольку есть нюансы, связанные с F-End тулами: должна определенным образом транслироваться стейт машина, определенным образом транслироваться описание триггера, защелки, и т.д. Так же возникают вопросы по поводу автоматической трансляции параметризованных верилог-модулей. Итого, вопрос только в совершенстве транслятора языка.

[@potan]

Транслятор вполне может учитывать особенности и генерировать только эффективно синтезируемое подмножество. По моему, всю параметризацию Clash раскрывает на этапе компиляции. Но я очень мало работал с HDL, что бы проверить качество создаваемого кода.

[@Daffodil]

Основная проблема функциональных HDL языков в том что большинство программистов имеют опыт работы с императивными языками программирования, но не знают как писать программы в функциональном стиле. Человеку с опытом программирования на Си или Java гораздо проще объяснить Verilog чем Clash.

[@OlegYch_real]

когда в универе изучали vhdl было ощущение что императивные привычки только мешают

[@Daffodil]

Да мешают. Мои студенты тоже писали совершенно безумные с точки зрения аппаратуры вещи, например видел сортировку пузырьком в комбинационном процессе :) Но процессы в Verilog, VHDL, SystemC описываются в императивном стиле.
Если посмотреть на моделирование тестового окружения, оно вполне огранично ложится на императивный стиль.

[@potan]

По моему, это повод учить студентов функциональному стилю.

[@kibb]

bluespec относительно используемый промышленный язык, основанный на haskell. На нем, например, написана BERI — реализация MIPS архитектуры, и ее расширение CHERI.

[@burjui]

У вас ссылки битые (отсутствует ":" после http), лучше проверять перед постингом. Правильные:
bluespec
BERI

[@yuklimov]

Интересно! А типизация распространяется только на комбинационные сигналы? Нельзя ли связать типом значения сигнала на разных тактах? Например, можно ли описать сигнал похожий на Either A B, но что не просто приходит сигнал типа A или B, а в более жестком смысле, что данные типов A и B чередуются во времени: A, B, A, B, ...?

Мне часто приходится передавать данные «размазанные» по времени и хочется уметь описывать каком-то образом их типы, чтобы компилятор проверял, правильно ли такие данные генерируются и потребляются.

[@potan]

Да, типизация всегда была сильной стороной Haskell.

etest ::  Either Bool (Bool,Bool) -> Bool -> ((Either Bool (Bool,Bool)), Bool)
etest (Left a) b = ((Right (a,b)), a)
etest (Right (x,y)) b = ((Left b),(x `xor` y))

topEntity = mealy etest (Left True)

компилируется в

systemverilog

// Automatically generated SystemVerilog-2005
module E_mealy(w2
              ,// clock
              system1000
              ,// asynchronous reset: active low
              system1000_rstn
              ,result);
  input logic [0:0] w2;
  input logic system1000;
  input logic system1000_rstn;
  output logic [0:0] result;
  logic [0:0] y;
  E_types::Tup2 result_0;
  logic [2:0] x;
  logic [2:0] x_app_arg;
  logic [2:0] x_0;
  assign result = y;
  
  assign y = result_0.Tup2_sel1;
  
  E_etest E_etest_result_0
  (.result (result_0)
  ,.ds (x)
  ,.b (w2));
  
  // register begin
  logic [2:0] dout;
  
  always_ff @(posedge system1000 or negedge system1000_rstn) begin : E_mealy_register
    if (~ system1000_rstn) begin
      dout <= {1'b0,1'b1,1'b0};
    end else begin
      dout <= x_app_arg;
    end
  end
  
  assign x = dout;
  // register end
  
  assign x_app_arg = x_0;
  
  assign x_0 = result_0.Tup2_sel0;
endmodule

[@vba]

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

[@potan]

За C ниша встраиваемого ПО. И то ее уже начинают теснить Rust и кодогенерация через Ivory.
Я про нишу еще более низкого уровня — hardware description languages (языки описания аппаратуры). Здесь тотально доминируют специализированные HDL — Verilog, Systemverilog и VHDL. Используют так же встроенный в C++ DSL (SystemC), но на мой взгляд он еще менее удобен.
Я описываю подмножество Haskell, которое может транслироваться в работу на фиксированной памяти — сигналы и регистры. И показываю, как оно может транслироваться в синхронную аппаратуру. При этом полноценнфй Haskell остается возможерсть использовать на этапах кодогенетации, тестирования и, возможно, верификации (в Clash я про это ни чего не нашел, но выдел упоренание интеграции с солверами в Lava).

[@a5b]

коммерческий Bluespec

Выложили исходники компилятора: https://github.com/B-Lang-org/bsc + документацию https://github.com/BSVLang/Main + примеры https://github.com/bluespec
https://bluespec.com/2020/01/06/bluespec-inc-to-open-source-its-proven-bsv-high-level-hdl-tools/