Имеется устройство с LPC2468 на борту. К CS2 LPC246816-и разрядной шиной подсоединена ПЛИС, доступ к ресурсам которой должен производиться с максимальной скоростью с использованием EMC микроконтроллера.
Настройки таковы:


Имеется тест, в котором производится запись и чтение 16-и разрядных слов (разрядность совпадает с физической разрядностью шины и настройками EMC). С записью проблем нет, все работает вполне предсказуемо. А вот с чтением наблюдается странная картина: вместо чтения по одному адресу, происходит чтение по двум последовательным адресам, т.е. если читать по адресу 0, то на шине будет наблюдаться транзакция чтения с непрерывными CS/OE и двумя адресами (0 и 1). С точки зрения работы ПЛИС проблемы нет, логика работы не нарушается. Однако скорость обмена при чтении падает в два раза, т.к. каждый раз читается "лишнее" слово. Бит включения буферов не установлен.

В Users Manual есть интересное примечание на эту тему:


Т.е. получается, что нас честно предупредили. Но вот как с этим бороться пока не ясно. Единственным путем сейчас видится настройка EMC на 32-х разрядную шину при фактическом использовании только 16-и разрядов. Но это как-то совсем некрасиво получается. Может есть другие пути?

Так а может обратить сие на пользу? Раз все заточено под вынимание именно 32х бит, так и сделать транзакцию 32хбитной, но по 16тибитной шине? Или никак?

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

Если Вы сделаете именно 32-х битное чтение по 16-битной шине, то эффект будет на 100% предсказуем на всех процессорах.

Да, но не будет-ли он при этом читать лишнее 32-х разрядное слово? Хотя проведённые проверки показали, что имеющийся процессор не читает. В общем понятно, легитимного пути борьбы с burst'ом нет. Придётся приноравливаться.

Это маловероятно: burst на 16-битном чтении еще можно объяснить оптимизацией для работы с 32-х разрядной внутренней шиной, а вот 64 бита деть будет некуда.

Да, согласен. Это возможно. Хотя и странно, т.к. AMBA имеет все средства для задания размера транзакции и при записи они отрабатывают правильно, в отличие от чтения.