Pull to refresh

Comments 33

А если пустить uart поверх jtag, то и проводов бы лишних не пришлось тянуть...
Во многих платах я использую встроенный UART без лишних проводов, например на Digilent Basys 3 и Nexys 4 DDR (обе с Xilinx Artix-7).

Я использовал для данного примера плату Terasic DE0-CV c Altera Cyclone V, так как ввоз плат с Xilinx в Россию сейчас непрост (прошлой весной Xilinx сделал ограничения и процесс занимает 3-4 месяца).

Как делать UART поверх JTAG на Альтере я перед поездкой в конце прошлого года разбираться не стал, так как у меня было мало времени. Но если вы покажете (и особенно если вы сами вставите это на гитхаб), я буду благодарен — https://github.com/MIPSfpga/mipsfpga-plus
Если делать переносимое решение (и Altera и Xilinx), тогда не удобно. Если только под альтеру, то у них есть готовый компонент JTAG UART (на шину AvalonMM) к которому приделывается простенький мастер берущий данные из регистров. Со стороны компьютера можно пользоваться имеющимся альтеровским терминалом для засылки данных.
Вообще с этими проводами беда. На каждый чих ставится по собственному мосту usb-uart и количество проводов стремительно растет. А уж если соединять несколько плат… В самую пору ставить usb hub стандартно на всех платах и от него уже тянуть интерфейсы куда надо ;)
Спасибо.

Со стороны компьютера можно пользоваться имеющимся альтеровским терминалом для засылки данных.

А можно ли без альтеровского терминала? Чисто "type filename COMnn" в командной строке Windows (cp на tty в Linux) ?
Насколько я знаю нет. У них есть библиотека (.dll), которую с некоторыми мучениями можно прикрутить к своему приложению, но драйвера в чистом виде нету. Разве что самому придумывать какую приблуду с перенаправлением в виртуальный порт.
Есть такая вещь как http://www.alterawiki.com/wiki/System_Console.
Если вставить в Qsys модуль "JTAG to Avalon Master Bridge", а затем написать tcl-cкрипты, которые дергают функции вида master_write/read_8/16/32, то можно писать/читать в FPGA через USB-Blaster (который в Вашем случае уже находится на плате). Дергание функций происходит "через" квартусовские программы, поэтому какого-то быстродействия не будет, но для отладки может сойти.

Так же есть In-System Memory Content Editor, который, как понятно из названия, позволяет редактировать значения памяти (указанных до компиляции FPGA, естественно) в реал-тайме через JTAG/USB-Blaster.

Если честно, не очень понял мотивацию делать парсер текста в FPGA, когда можно было бы эту задачу переложить на компьютер, с которого шьется эта прошивка (сделать скрипт/утилиту, который конвертит текст в бинарник).
Ну это уж для совсем эстетствующих ;) Тут ведь желание обратное — отвязаться от альтеровской инфраструктуры.
Спасибо за информацию.

Если честно, не очень понял мотивацию делать парсер текста в FPGA, когда можно было бы эту задачу переложить на компьютер, с которого шьется эта прошивка (сделать скрипт/утилиту, который конвертит текст в бинарник).


Мотивация крайне простая: до поездки в Россию я представлял, что в 9 местах будет потенциально зоопарк из пары сотен компьютеров с разными версиями Windows (7, 8, 10, 32-битным, 64-битным) и Линукса (32-битным, 64-битным), административными опциями, версиями всяких перлов, динамических библиотек и т.д. Так как у меня не было возможности воспроизвести это в Калифорнии и так как я намучался до этого с зоопарками машин в других ситуациях, я решил минимизировать риск переносом всего в хардвер (чтобы на компьютере делалась ровно одна операция — копирование текста в com-порт). Для меня написать 250 строк на верилоге проще, чем собрать в одном месте все возможные платформы для тестирования. И даже если делать бинарник на компьютере, его все равно нужно как-то распихать по памяти синтезированной системы.

Вообще если вы можете взять мой код на гитхабе и показать, как сделать это проще и чтобы работало на всех платформах, было бы хорошо.
Внутри Ардуино стоит вполне фон-неймановский процессор

Там AVR, и у него гарвардская архитектура.
Да, но в контексте всего пространства возможных организаций вычислений цифровой схемотехники, так сказать с высоты птичьего полета, гарвардская архитектура — это небольшая вариация фон-неймановской архитектуры (ее было бы правильнее называть архитектурой Экерта-Мочли, но это другое обсуждение). Обе являются частными случаями того, как можно построить вычислительное устройство.
"Парсировать" очень мешает получать удовольствие от статьи. Parse переводится как "парсить". А статья интересная.
Я завтра поправлю. В моей советской юности в компиляторных книжках издательства "Мир" по-моему переводили слово parse как "разбирать", "синтаксический разбор", "лексический разбор". Но сейчас слово "разбор" по-моему перегруженное.
Да, я имел ввиду переводится в кавычках. Может нелитературно и тд, но это общеупотребительное слово.
Заодно, сделайте, пожалуйста, что-нибудь с "софтвером" и "хардвером". Глаз об эти слова спотыкается, читать очень трудно.
Попробую писать "программное обеспечение" и "аппаратное обеспечение" или "программы" и "схемотехника" в другой статье. Какие еще слова лучше?
по-моему лаконично и доступно описывают сии слова суть смысла
Да, еще переводили как "синтаксический анализатор", "лексический анализатор".
Можно просто Парсер (правда возможна путаница) и Лексер.
Мне кажется Parse официально так не переводится =)
Да, я имел ввиду переводится в кавычках.
В любом случае от слова «парсинг» можно образовать глагол «парсить», но никак не «парсировать».
Мм, ожидал в статье что-нибудь про парсинг финансовых данных (для более быстрого выставления ордеров на покупку-продажу, обычно для этого ПЛИС пытаются прикрутить сейчас все) но вместо этого просто потерял мысль о том зачем и что парсим. :(
Интересно, нет ли варианта генератора парсеров типа yacc(bison) с hdl вместо "с" на выходе? По идее не только финансистам, но и в нагруженном вебе было бы интересно.
Это одна из вещей, которые сделать можно, но пользы от которых может быть меньше, чем кажется вначале. Аппаратный стек и несколько lookup-таблиц — и получаем LALR(1) парсер а-ля Yacc, но в хардвере. Но cразу приходят в голову две проблемы:

1) На FPGA, из-за более низкой тактовой частоты, такая реализация может быть медленнее процессора (хотя будет быстрее если делать ASIC).

2) Проблему более низкой тактовой частоты можно компенсировать большей параллельностью (несколько парсеров одновременно) и конвейеризацией, но с последним не совсем понятно как это конвейеризировать.
1) Частоту надо сравнивать с пропускной способностью канала
2) Зачем конвеёер? один такт- один входной символ. Идея в том чтобы реализовать множество состояний парсера на hdl как конечный автомат (fsm). На входе автомата — текущий символ, верхушка стека состояний и возможно, предпросматриваемый символ. (если грамматика с предпросмотром).
1) Да

2) Я это понимаю. Но для большой грамматики и большого стека — и автомат будет большой, и далее если делать все операции по доступу к стеку и суммировать все требуемые задержки, то такт может получиться длинным по времени, что означает низкую тактовую частоту. В обычных условиях с длинными тактом борются, разрубая его на небольшие такты и делая конвейер. Но тут там может не получиться. В общем, тут нужно сделать эксперимент с какой-нибудь небольшой грамматикой.
Ожидал увидеть парсинг протоколов, типа HTTP, но SREC… Не из пушки ли это по воробьям? Зачем вообще нужен этот формат, что мешало сконвертировать SREC в двоичный формат и далее загружать его уже без сложностей с парсингом?

Но тема очень интересная. Спасибо вам, автор.
что мешало сконвертировать SREC в двоичный формат и далее загружать его уже без сложностей с парсингом?

Но тогда бы не было этого поста :-) Также см. https://habrahabr.ru/post/278681/#comment_8801127
Ничего не понял, а времени разбираться нет, но вспомнилось босоногое детство и реверс-инжиниринг контроллера дисковода БК-0010, поэтому ловите плюс ;)
Занятно, разве что малость напрягает голосование с лидирующим вариантом про построение FSMов.
Это же практическая базовая вещь для hdl/verelog.
По-моему, правильнее было бы прикрутить что-нибудь на основе JTAG.
Sign up to leave a comment.

Articles