Как стать автором
Обновить

Комментарии 20

Ценная тема кстати, давно собирался изучить Haskell именно для исследования такой возможности
Так вот как оно начиналось
image
Не-а, там под винду на C пишут

Если говорить о тенденциях, то на мой взгляд сейчас куда перспективнее изучать Chisel/Scala, поскольку на нем написан новый опен-сорс процессор RISC-V. Беркли достаточно авторитетны, чтобы продвинуть этот новый HDL в массы. Впрочем, пока коммерческие тулы Synopsys и Cadence не начнут новый язык поддерживать, все это не серьезно.
Читаю сейчас книгу про Scala и параллельно играюсь с Chisel, но пока не понял чем же он хорош — очень всё низкоуровневое. Можете рассказать чем Chisel лучше чем VHDL/Verilog?
Своего мнения у меня не сложилось пока, к сожалению. Но вот ответ на Ваш вопрос от разработчика 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
Scala сейчас основной мой рабочий инструмент :-). Но посмотреть на Chisel я пока не успел. Надо восполнить этот пробел.
Но все равно я думаю, что Haskell сильно проще чем Scala и переход на него пойдет легче.
У меня есть только 16 лет опыта кодинга на верилоге (из HDL языков), но сложилось следующее мнение: чтобы писать качественный, синтезируемый код на верилоге, используется всего несколько унифицированных конструкций. При этом возможности (и косяки) языка раскрываются только при написании тестбенчей. Из чего следует, что имея хороший транслятор в верилог, можно действительно писать на чем угодно. Но! транслятор должен быть действительно хороший, поскольку есть нюансы, связанные с F-End тулами: должна определенным образом транслироваться стейт машина, определенным образом транслироваться описание триггера, защелки, и т.д. Так же возникают вопросы по поводу автоматической трансляции параметризованных верилог-модулей. Итого, вопрос только в совершенстве транслятора языка.
Транслятор вполне может учитывать особенности и генерировать только эффективно синтезируемое подмножество. По моему, всю параметризацию Clash раскрывает на этапе компиляции. Но я очень мало работал с HDL, что бы проверить качество создаваемого кода.
Основная проблема функциональных HDL языков в том что большинство программистов имеют опыт работы с императивными языками программирования, но не знают как писать программы в функциональном стиле. Человеку с опытом программирования на Си или Java гораздо проще объяснить Verilog чем Clash.
когда в универе изучали vhdl было ощущение что императивные привычки только мешают
Да мешают. Мои студенты тоже писали совершенно безумные с точки зрения аппаратуры вещи, например видел сортировку пузырьком в комбинационном процессе :) Но процессы в Verilog, VHDL, SystemC описываются в императивном стиле.
Если посмотреть на моделирование тестового окружения, оно вполне огранично ложится на императивный стиль.
По моему, это повод учить студентов функциональному стилю.
bluespec относительно используемый промышленный язык, основанный на haskell. На нем, например, написана BERI — реализация MIPS архитектуры, и ее расширение CHERI.
У вас ссылки битые (отсутствует ":" после http), лучше проверять перед постингом. Правильные:
bluespec
BERI
Интересно! А типизация распространяется только на комбинационные сигналы? Нельзя ли связать типом значения сигнала на разных тактах? Например, можно ли описать сигнал похожий на Either A B, но что не просто приходит сигнал типа A или B, а в более жестком смысле, что данные типов A и B чередуются во времени: A, B, A, B, ...?

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

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

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

Публикации

Истории