Последнее время в интернете очень много хайпа по поводу нейросетей. И конечно, у людей работа нейросетей обычно ассоциируется с разными сгенерированными котиками-картинками, нейросетевыми девушками, забавными видео, и ещё появилось много генерированных нейросетевых текстов и статей (которые часто вызывают раздражение).

Сейчас я хочу показать реальный пример, как нейросеть может быть использована в практических целях программистом FPGA. Я буду использовать бесплатные возможности нейросети Github Copilot https://github.com/copilot.

Github Copilot допускает 50 чат запросов в месяц бесплатно.

Для использования Github Copilot потребуется VPN, так как доступ к нему для россиян к сожалению похоже ограничен.

Предположим, есть задача: подключить энкодер к ПЛИС. На самом деле в гугле довольно легко найти готовые исходные тексты для модуля Verilog для подключения энкодера.

Вот есть такой модуль:

module quad(clk, quadA, quadB, count);
input clk, quadA, quadB;
output [7:0] count;

reg [2:0] quadA_delayed, quadB_delayed;
always @(posedge clk) quadA_delayed <= {quadA_delayed[1:0], quadA};
always @(posedge clk) quadB_delayed <= {quadB_delayed[1:0], quadB};

wire count_enable = quadA_delayed[1] ^ quadA_delayed[2] ^ quadB_delayed[1] ^ quadB_delayed[2];
wire count_direction = quadA_delayed[1] ^ quadB_delayed[2];

reg [7:0] count;
always @(posedge clk)
begin
  if(count_enable)
  begin
    if(count_direction) count<=count+1; else count<=count-1;
  end
end

endmodule

Допустим, что я не хочу пока сильно вникать, работает этот Verilog модуль или нет, но мне хочется понять, всё ли тут правильно? Мне нужен тестбенч для симуляции этого модуля. Я попрошу Copilot написать мне модуль Testbench Verilog, чтобы я смог его просимулировать. Важно, что задавать вопросы в чат с Copilot буду на русском языке. Ниже я приведу весь наш диалог с нейросетью. Но сразу напишу, что результат поразительный...

На неделе мне задали вопрос, на который я к своему стыду не смог сразу ответить: "Как стартует RISC-V процессор и как обрабатывает прерывания?". Попробую на него ответить хотя бы сейчас. Но! Мне кажется, чтобы по настоящему разобраться в этом вопросе было бы хорошо пройти отладчиком по шагам весь старт и инициализацию RISC-V SoC. Только так, на деле, можно понять особенности системы команд процессора и нюансы запуска.

Чтобы пройти отладчиком запуск процессора мне нужно этот отладчик подключить к системе на кристалле. Вообще-то я что-то такое уже делал, когда запускал систему с процессором MIPSfpga - тогда к нашей FPGA плате Марсоход3 (Altera MAX10) был подключен дополнительный второй FTDI программатор, через который велась отладка MIPSfpga SoC. Программное обеспечение и HW при этом были в связке GDB -> OpenOCD -> FTDI -> FPGA Altera MAX10.

Честно говоря, сейчас мне не хотелось бы связываться с платами. Могу ли я дебажить с GDB систему RISC-V SoC работающую в симуляторе Verilator? Почему бы и нет? Скорее всего могу. Как это сделать? Пока не знаю, но давайте попробуем.

В предыдущей статье я писал, что у нас появилась новая плата расширения Ethernet 1Gbit и к ней был сделан относительно простой тестовый проект для платы Марсоход3GW2. В этой работе FPGA плата могла принимать UDP пакеты и отправлять UDP пакеты. Этим проектом мы проверили работоспособность нашего шилда Ethernet. Однако, существенный недостаток был в том, что передать пакет в плату можно было только отправляя broadcast широковещательные пакеты. Это пакеты "всем", что создает излишний трафик во всей локальной сети. Дело в том, что компьютер с которого отправляются пакеты не знает физического адреса платы, MAC адреса. Даже если я знаю IP адрес своего устройства этого недостаточно, чтобы осуществлять прямую передачу от клиента к серверу.

Чтобы сделать передачу UDP пакета с компьютера на нашу FPGA плату по всем правилам нужно реализовать ARP протокол, Address Resolution Protocol. Любое устройство в локальной сети имеет в своих драйверах таблицу ARP. В этой таблице хранится соответствие IP адреса его MAC адресу. Когда какая ни будь программа посылает пакет в сеть, стек драйверов ОС прежде всего проверяет в своей таблице известен ли MAC адресата. Если известен, то пакет тут же отправляется на известный MAC адрес. А если MAC неизвестен, то сперва отправляется широковещательный запрос ARP всем устройствам в сети "У кого есть вот такой IP?" и устройство с этим IP адресом должно откликнуться и прислать ARP ответ "Это мой IP, а вот мой MAC адрес". После этого, компьютер, получив ответ уже знает MAC и может действительно послать пакет адрасату. Новый известный MAC адрес помещается в таблицу MAC адресов, и при повторной передаче следующих пакетов ARP протокол уже не используется, ведь физический адрес клиента уже известен.

Сейчас я хочу усовершенствовать наш Ethernet проект для FPGA платы Марсоход3GW2 и добавить поддержку ARP протокола.
Наша плата FPGA теперь будет делать следующее: на неё (конкретно на её статический IP платы) теперь можно будет послать UDP пакет и этот пакет

• зажигает светодиоды платы согласно принятому байту из UDP пакета;
• управляет вращением шагового двигателя с заданной скоростью согласно принятому значению из UDP пакета.

Стенд для испытаний этого проекта показан на фото в начале статьи. На плате расширения Ethernet есть 4 выхода io16, io17, io18 и io19 они идут на драйвер двигателя L298N к которому уже подключен шаговый моторчик.

Далее расскажу чуть подробнее о проекте.

Я беру недорогой гигабитный Ethernet коммутатор и подключаю к нему UTP5 патч кордами мой ноутбук и нашу FPGA плату Марсоход3GW2 (Gowin FPGA). Сделаем простой тестовый FPGA проект с шилдом Ethernet. Попробуем принимать и отправлять пакеты данных.