у меня на пересылку 16-битного слова во внутреннюю память 19 тактов уходит =( Это нормально ?
vadimuzzz
Apr 9 2010, 14:25
скорее всего сама пересылка идет быстро, большой оверхед на вызов обработчика прерывания. ну и от системы зависит, если память общая, то доступ устройствам по очереди дается. тут надо в конкретном контексте рассматривать, вариантов с настройками много
не.. я на большой пачке проверял - оверхед там роли уже не играет. Читаю с MM-Slave , всякие тайминги у него выствлены практически по нулям . Кстати наврал, не 20 с чем-то, а под 40 тактов... бред какой-то =(
DASM
Сложно сказать.
У нас причины были следующие:
- выполнение кода CPU из внешней памяти одновременно с обменом с ней по DMA;
- невыровненный адрес памяти (доступ по 32 бита) - при записи по 16-бит;
Код из SSRAM , DMA - в SDRAM... А какую Вам скорость в итоге то удалось получить ?
vadimuzzz
Apr 11 2010, 09:18
Цитата(DASM @ Apr 11 2010, 15:49)

DMA - в SDRAM
а burst`ы включены? вообще стоит сигналтапом посмотреть, куда столько времени уходит. с on-chip memory несколько проще: как арбитраж настроил, такую пропускную способность и получил.
burst выключены ? А зачем они ? Стандартный драйвер SDRAM burst не поддерживает =( Или я путаю что-то ? А арбитраж как настроить ? Не видел что-то в мануалах (плохо читал наверное)
Кстати попутно еще вопрос.. Из серии "что же это такое было"... С этого MAC чипа принимаю пакет. Как он выглядит я знаю. Когда читал просто чип через IORD - усе пучком. Но как начал через DMA .... Изначально пакет выглядит допустим как N0, N1...., Nn-1, Nn. Но приняв его по DMA в памяти увидел его как N0, N2, N4, N6, а вот через 20 байт появились N1, N3, N5 и т п

Пересобрал ядро без кеша данных - стало нормально. Но что самое интересное - когда собрал назад с кешем - все по прежнему осталось нормальным.. Очень похоже на какое-то ускорение записи путем чередования адресов, но куда оно пропало, и что это вообще на НЛО могло быть ?
vadimuzzz
Apr 11 2010, 09:53
ну, у SDRAM при произвольном доступе скорость будет не фонтан, надо обязательно проверить шину. насчет драйвера SDRAM не понял - там же все прозрачно и драйвера никакого нет. арбитраж настраивается в SOPC-билдере, обычно меню скрыто, надо ПКМ ткнуть и выбрать Show Arbitration. подробности в 4-м томе квартус-хендбука, "Arbitration for Multimaster Systems" на стр. 29.
Цитата(DASM @ Apr 11 2010, 16:51)

Но что самое интересное - когда собрал назад с кешем
с кешами надо аккуратно обращаться, замечены случаи явных багов в реализации. каждый шаг проверять хотя бы в м-симе. для систем же с DMA польза от него вообще неочевидна.
ммм.. ну в SOPC builder есть компонент SDRAM. Так вот в хелпе про него написано, что burst mode в SDRAM он не поддерживает, то есть всегла будем вести себя так, будто идет рандомная запись-чтение, и соответвенно никакого выигрыша от возможностей бурстого режима такого типа памяти мы не получим.
PS про арбитраж вроде понял, да и о бурстах мы видимо разных говорили. Завтра буду играться на железе =)
vadimuzzz
Apr 11 2010, 10:49
хм, смотрим последнюю версию, в описании корки сказано:
Цитата
Under optimal conditions, the SDRAM controller core’s bandwidth approaches one
word per clock cycle. However, because of the overhead associated with refreshing
the SDRAM, it is impossible to reach one word per clock cycle. Other factors affect the
core’s performance, as described in the following sections.
правда, это наверное на операциях чтения, но 40 тактов на слово - явный перебор. а к SDRAM кто еще подключен кроме DMA? в принципе, контроллер SDRAM можно и свой наваять, с burst`ами и т.п., но надо все-таки посимулировать в моделсиме/посмотреть в сигналтапе что происходит, может там и в других блоках такое непотребство творится.
да в том то и дело, что к этой SDRAM только DMA и подключено. Вернее к ней подключены и другие слейвы, но обращениий (пока что) они к ней не ведут, так что арбитраж то тут нужен (вернее не замедляет) как я понимаю.
vadimuzzz
Apr 11 2010, 11:48
Цитата(DASM @ Apr 11 2010, 18:23)

но обращениий (пока что) они к ней не ведут, так что арбитраж то тут нужен (вернее не замедляет) как я понимаю.
черт его знает, теоретически может и не мешают, но проверить стоит. вот довольно занимательное чтиво
http://www.altera.com/literature/hb/nios2/edh_ed51008.pdf. рекомендуются буферы на SRAM, а к SDRAM доступ всемерно ограничивают. несколько лет назад производительность контроллера SDRAM серьезно критиковалась, так что написание своей корки не выглядит совсем уж бредовой идеей.
к сожалению, пока мои познания Verilog да и NIOS в частности близки к первокласснику в начальной школе. Попробую еще SDRAM to SDRAM скорость DMA измерить - в DE-70 ките как раз их две штуки независимо висят
да, мы немного отклонились - ведь во внутреннюю память скорость такая же (вернее быстрее на 0.4 %) Измерею так - перед началом DMA транзакции alt_time_stamp, после нее тоже... Ну и разницу на UART кидаю. Тут подвохов явно нету.
vadimuzzz
Apr 11 2010, 12:58
Цитата(DASM @ Apr 11 2010, 19:31)

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

для начала просто все остальные слейвы от DMA отключу - погляжу
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.