Комментарии 10
Спасибо, понравилось!
Хотя, как человеку, знакомому только с софтверной частью PCI, разбираться тяжело с VHDL — общая концепция ясна, какие сигналы за какими ходят по шине и как синхронизируются. Когда говорится, что инициатор — южный мост — имеется ввиду транзакция от процессора, пришедшая из северного моста в южный?
И про прерывания тоже интересно услышать кстати.
Но то что всё это компилируется, заливается в FPGA и работает в винде — реально круто!!!
Хотя, как человеку, знакомому только с софтверной частью PCI, разбираться тяжело с VHDL — общая концепция ясна, какие сигналы за какими ходят по шине и как синхронизируются. Когда говорится, что инициатор — южный мост — имеется ввиду транзакция от процессора, пришедшая из северного моста в южный?
И про прерывания тоже интересно услышать кстати.
Но то что всё это компилируется, заливается в FPGA и работает в винде — реально круто!!!
Когда говорится, что инициатор — южный мост — имеется ввиду транзакция от процессора, пришедшая из северного моста в южный?
Да. Точнее инициатор — контроллер шины pci, входящий в состав южного моста.
И про прерывания тоже интересно услышать кстати.
С прерываниями не густо. Как дадут проект, в котором я буду реализовывать интерфейсную часть с pci — напишу.
Это вы все сделали в рамках тестового задания при трудоустройстве? Сильно…
Спасибо за статью!
круто конечно.
А ваше устройство поддерживает блочную передачу? Ну когда FRAME# длинный, занимает несколько тактов?
Только с блочной передачей можно получить более-менее хорошую скорость.
А ваше устройство поддерживает блочную передачу? Ну когда FRAME# длинный, занимает несколько тактов?
Только с блочной передачей можно получить более-менее хорошую скорость.
Нет, у меня обрабатывается только FRAME# длиной в 1 такт.
это нужно бы сделать.
вы когда драйвер начнете писать к устройству можете столкнуться с проблемой, что при любом (чтении/записи) последовательном обращении к памяти устройства на шине появляются «длинные фреймы». Их просто трудно избежать.
А вот обращение к портам ввода-вывода я бы вообще не делал. Какой-то рудимент былых времен.
Даже не представляю себе как можно это использовать.
Если нужны I/O регистры — отобразите их в память и обращайтесь как к памяти.
вы когда драйвер начнете писать к устройству можете столкнуться с проблемой, что при любом (чтении/записи) последовательном обращении к памяти устройства на шине появляются «длинные фреймы». Их просто трудно избежать.
А вот обращение к портам ввода-вывода я бы вообще не делал. Какой-то рудимент былых времен.
Даже не представляю себе как можно это использовать.
Если нужны I/O регистры — отобразите их в память и обращайтесь как к памяти.
Тем не менее все современные (и более того — будущие) интеловские чипсеты и девайсы содержат часть I/O Base Address регистров — т.е. отображают регистры в пространство портов. Наверное пока рано отказываться от этого в реализации PCI-библиотеки
я думаю это просто тяжелое наследие совместимости, которую они вынужденны поддерживать.
Если сами себе делаете девайс для своего приложения, то использовать порты нет никакой необходимости.
Использование портов не дает никаких преимуществ, не очень кроссплатформенно и занимает дополнительную логику в девайсе.
Если сами себе делаете девайс для своего приложения, то использовать порты нет никакой необходимости.
Использование портов не дает никаких преимуществ, не очень кроссплатформенно и занимает дополнительную логику в девайсе.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Выполнение транзакций на шине PCI. Реализация на VHDL