Comments 15
«кастомный» микроконтроллер
Вопрос в массовости изделия. "Печать" маской выгоднее программирования чего угодно - без разницы это ПЛИС или микроконтроллер.
А у Вас есть возможность напечатать свой микроконтроллер? Поделитесь способом пожалуйста.
Производство Эльбрусов на Тайване у TSMC как пример. Печатать "могут не только лишь все". В 1980-х например могли заказывать версию микроконтроллера с масочной ПЗУ вместо флешпамяти. Как пример контроллер клавиатуры бытового компьютера 1988 года:
Schneider Keyboard MCU "Schneider ZC86115P" which turns out to be a mask programmed MC6805U2
Штука в том что в промавтоматизации некоторые конечные изделия (например станок расточной) выпускаются не такими уж большими сериями, а время эксплуатации изделия превышает время поддержки конкретного микроконтроллера, а требования к частотам - низкие. Поэтому гипотеза @checkpoint выглядит работоспособной. Он отвязывается от ядра, и если завтра появится Risc-VI, то он просто пересоберет все под новое ядро, компилятор и т.д.
время эксплуатации изделия превышает время поддержки конкретного микроконтроллера
Кстати, в недавнем анонсе Spartan Ultrascale+ (достаточно бюджетной плисины) Xilinx акцентировала внимание на 15+ годах поддержки своих моделей.
Если через короткий период времени выйдет третья подобная статья от автора, то мы будем предполагать, што у него уже готова настоящая книга, апробация которой происходит на хабре. И вероятно через некоторое непродолжительное время мы увидим полноценное печатное издание с исправлениями и рекомендациями подчерпнутыми из комментариев.
Нет, книги никакой нет. :))) Но вообще, осталось очень много недосказанного, т.е. третья часть вполне может быть, но не скоро - времени на её написание нет совсем.
Кстати интересный момент что SRAM глючил на 60 мгц н работал правильно на 75. Это скорее всего из за различных задержек внутри FPGA для разных битов, Обычно в Lattice есть CLOCK_TO_OUT constraint или сказать placer чтобы выходные регистры располагались прямо в драйверах пинов.
Ну я выразил в статье предположение, что сигналы по шине приходят в разнобой и если их выровнять, то все будет ок. Как называется этот аппаратный блок ? Пробежался по мануалу на ECP5 и на вскидку не нашел. В yosys-е есть такая обертка, по смыслу должно быть оно:
techlibs/ecp5/cells_io.vh:module OBCO (input I, output OT, OC); OLVDS olvds (.A(I), .Z(OT), .ZN(OC)); endmodule
techlibs/ecp5/cells_io.vh:module OLVDS(input A, (* iopad_external_pin *) output Z, output ZN); TRELLIS_IO #(.DIR("OUTPUT")) _TECHMAP_REPLACE_ (.B(Z), .I(A)); endmoduleНо присмотревшись можно увидеть, что сигнал OC не используется.
В документации описан блок DQSBUF для работы с DDR (блок конфигурибельных задержек), можно попытаться задействовать его. Но как осуществить его калибровку я не знаю. И тут уже возникает сильная аппаратная зависимость от производителя ПЛИС, а мне хочется этого избегать как можно дольше. :)
Еще я подозреваю, что у nextpnr-а должен быть какой-то способ обьяснить ему, что определенный блок сигналов нужно рутить совместно. Возможно это решит проблему.
С yosys я не сильно знаком. Все что смог найти : https://github.com/YosysHQ/nextpnr/issues/399
Там говорят про OFS1P3DX
Разработка цифровой аппаратуры нетрадиционным методом: Yosys, SpinalHDL, VexRiscv (ч. 2)