System Analysis and Design
Haskell
Functional Programming
FPGA
Comments 19
+1
Ценная тема кстати, давно собирался изучить Haskell именно для исследования такой возможности
+3
Если говорить о тенденциях, то на мой взгляд сейчас куда перспективнее изучать Chisel/Scala, поскольку на нем написан новый опен-сорс процессор RISC-V. Беркли достаточно авторитетны, чтобы продвинуть этот новый HDL в массы. Впрочем, пока коммерческие тулы Synopsys и Cadence не начнут новый язык поддерживать, все это не серьезно.
0
Читаю сейчас книгу про Scala и параллельно играюсь с Chisel, но пока не понял чем же он хорош — очень всё низкоуровневое. Можете рассказать чем Chisel лучше чем VHDL/Verilog?
+1
Scala сейчас основной мой рабочий инструмент :-). Но посмотреть на Chisel я пока не успел. Надо восполнить этот пробел.
Но все равно я думаю, что Haskell сильно проще чем Scala и переход на него пойдет легче.
+1
У меня есть только 16 лет опыта кодинга на верилоге (из HDL языков), но сложилось следующее мнение: чтобы писать качественный, синтезируемый код на верилоге, используется всего несколько унифицированных конструкций. При этом возможности (и косяки) языка раскрываются только при написании тестбенчей. Из чего следует, что имея хороший транслятор в верилог, можно действительно писать на чем угодно. Но! транслятор должен быть действительно хороший, поскольку есть нюансы, связанные с F-End тулами: должна определенным образом транслироваться стейт машина, определенным образом транслироваться описание триггера, защелки, и т.д. Так же возникают вопросы по поводу автоматической трансляции параметризованных верилог-модулей. Итого, вопрос только в совершенстве транслятора языка.
0
Транслятор вполне может учитывать особенности и генерировать только эффективно синтезируемое подмножество. По моему, всю параметризацию Clash раскрывает на этапе компиляции. Но я очень мало работал с HDL, что бы проверить качество создаваемого кода.
0
Основная проблема функциональных HDL языков в том что большинство программистов имеют опыт работы с императивными языками программирования, но не знают как писать программы в функциональном стиле. Человеку с опытом программирования на Си или Java гораздо проще объяснить Verilog чем Clash.
+3
когда в универе изучали vhdl было ощущение что императивные привычки только мешают
0
Да мешают. Мои студенты тоже писали совершенно безумные с точки зрения аппаратуры вещи, например видел сортировку пузырьком в комбинационном процессе :) Но процессы в Verilog, VHDL, SystemC описываются в императивном стиле.
Если посмотреть на моделирование тестового окружения, оно вполне огранично ложится на императивный стиль.
0
По моему, это повод учить студентов функциональному стилю.
+2
bluespec относительно используемый промышленный язык, основанный на haskell. На нем, например, написана BERI — реализация MIPS архитектуры, и ее расширение CHERI.
0
У вас ссылки битые (отсутствует ":" после http), лучше проверять перед постингом. Правильные:
bluespec
BERI
+3
Интересно! А типизация распространяется только на комбинационные сигналы? Нельзя ли связать типом значения сигнала на разных тактах? Например, можно ли описать сигнал похожий на Either A B, но что не просто приходит сигнал типа A или B, а в более жестком смысле, что данные типов A и B чередуются во времени: A, B, A, B, ...?

Мне часто приходится передавать данные «размазанные» по времени и хочется уметь описывать каком-то образом их типы, чтобы компилятор проверял, правильно ли такие данные генерируются и потребляются.
+1
Да, типизация всегда была сильной стороной 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
0

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

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