LPC2468 EMC, неожиданный burst Опции

[makc]

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

Код

    PCONP |= PCEMC;

    EMC_CTRL = EMC_CTRL_E;
    EMC_CONFIG = 0;
    
    /* FPGA Region (CS2) */
    EMC_STA_CFG2 = EMC_SMC_CFG_MW16 | EMC_SMC_CFG_PB;
    EMC_STA_WAITWEN2 = 0;
    EMC_STA_WAITOEN2 = 0;
    EMC_STA_WAITRD2 = 4;
    EMC_STA_WAITWR2 = 2;
    EMC_STA_WAITTURN2 = 0;

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

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

[2] EMC may perform burst read access even when the buffer enable bit is cleared.

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

[Rst7]

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

[makc]

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

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

[aaarrr]

Проблема в отсутствии объективных оснований считать, что есть заточенность под 32-бита.

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

[makc]

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

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

[aaarrr]

Да, но не будет-ли он при этом читать лишнее 32-х разрядное слово?

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

[makc]

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

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