паузы при доступе к статической RAM в i.MX51 от DiGi Опции

[andrewg]

Имеем плату от Digi i.MX51.
К ней у нас вешается Альтера как 16 бит асинхронная статическая память с временем доступа записи 30 нс. и чтения 40 нс. Из управления нужны только CS, RD, WR и 8 проводов адреса. Всё это удалось настроить и для первых раз терпимо работает.
Но есть проблема. Между циклами доступа (неважно, RD или WR) процессор вставляет паузы по 170нс. Т.е., CS в нуле 30 нс, в единице 170 нс, в нуле 30 нс ... и т.д. Соответственно, время периода выполнения учебного цикла:

for (i=0;i<XXXX,i++)
{ data16= INREG16(pPORT); }

200 нс а не 30нс.

где pPORT - отмапленное на нужный адрес значение ... (и всё такое правильное, CS то дёргается и данные правильные...). Так же не важно, цикл RD или WR, 8 бит или 16 - разумеется надо инициализировать по разному для конкретного набора. Все равно, пауза 170 нс. между двумя последовательными циклами обращения железно держится.

Однако, изучение даташитов НЕ показывает, что пауза между (да ещё такая) циклами должна быть.
Замучались искать засаду. Даташиты огромные. Есть ли у кого какие идеи в какую область посмотреть?

[SFx]

кроме чтения из порта, проц должен i инкрементировать (обычно один машинный такт), сравнить с числом XXXX (ну тоже такт, наверное) и перейти по адресу данной подпрограммы наверняка (еще пара тактов). если i это переменная в оперативной памяти (не в регистре) - значит ее надо еще считать записать (еще такты проца).
думается от сюда эти 140ns и набегают...

подробно понять можно только по ASM коду, который компилятор создаст.

попробуйте объявить i регистровой переменной ( register int i=0; ) чтобы жестко держать ее в регистре у процессора под рукой... кроме того data16 наверное тоже гдето в памяти хранится в оперативной... но тут то задачи вашей.

еще можно попробовать вечный цикл while (true) {} и поглядеть сколько CS будет дергаться...

[zhevak]

Измените цикл вот так

Код

for (i = 0; i < XXXX, i++)
{
  data16 = INREG16(pPORT);
  data16 = INREG16(pPORT);
}

и посмотрите осциллографом. Если 170 нс тратятся на возврат по петле цикла, то Вы должны увидеть пару рядом стоящих импульсов и эту паузу (170 нс). Можете поиграться и сделать цикл из большего количества однотипных команд INREG, тогда вообще должны присутствовать пачки импульсов. Не бойтесь экспериментировать.

Извините, если я посоветовал очевидные вещи, я не знаю Вашего уровня, не знаю что Вы знаете, а что нет.

[_3m]

Имеем плату от Digi i.MX51.
...
Но есть проблема. Между циклами доступа (неважно, RD или WR) процессор вставляет паузы по 170нс. Т.е., CS в нуле 30 нс, в единице 170 нс, в нуле 30 нс ... и т.д. Соответственно, время периода выполнения учебного цикла:
for (i=0;i<XXXX,i++)
{ data16= INREG16(pPORT); }
200 нс а не 30нс.
...
Замучались искать засаду. Даташиты огромные. Есть ли у кого какие идеи в какую область посмотреть?

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

[andrewg]

SFx, zhevak
Тесты, которые Вы предлагаете, мы пробовали (в числе большого числа прочих). Свой уровень я бы оценил как достаточно компетентный (за 25 лет работы).
Время на обработку всяких переменных в этих циклах совершенно не существенно. Это абсолютно точно. CORTEX-А-8 на 800 МНz с оптимизацией кода делает все промежуточные операции за (от балды) 5-15 тактов ядра, что даст 7-20 нс. если подходить тупо. Никак не 170. Но ведь работает конвеер, всё берётся из кэша и т.д. Проведённые осциллографом оценки на разных тестах дают оценку ожидаемого проядка непроизводительной задержки 2-5 нс, что, если грубо, не очень намного превосходит нашу погрешность измерения.
_3m
Сейчас, к сожалению, многого уточнить строго не могу, попозже. Ядро на 800 МГц, кэши включены, мму тоже включено. Программа выполняется из DDR2 (коих установлено 512 МБ) на 200 МГц. Конечно, понятно, что реально при таком объёме всё берётся из кэша.
Проблема НЕ в том, что накладные расходы на фетч отъедают много. Проблема в том, что именно процессор добавляет 170 нс. между различными циклами обращения. Это должно задаваться в какой-то из "CPU engine" (типа задержка - 17 тактов (скорее 16)), только не понятно где именно даже смотреть.

Устройство висит, разумеется, не на DDR шине. Используется отдельная шина, на которую у DiGi вешается, например, ethernet 100 MBit (в другом исполнении тестовых плат).

Сообщение отредактировал andrewg - Jul 16 2011, 19:42

[zhevak]

Тесты, которые Вы предлагаете, мы пробовали (в числе большого числа прочих).

Результат такой же? -- пауза 170 нс между итерациями?

Свой уровень я бы оценил как достаточно компетентный (за 25 лет работы).

И все же чувствую, что я должен извиниться. Даже в мыслях не было оскорбить. Просто на форуме ни кого толком не знаю и както студентов нужно отделять от профи. Мои извинения На этом, наверно, и замнем эту тему.

Я вот тут что еще подумал, если весь код находится в кэше, то он, разумеется, выполняется быстро. Но операция ветвления в конце цикла, наверняка сбрасывает кэш, и ему риходится заново набирать коды из DDR-а. За это приходится платить 170 нс времени. Это всего лишь предположение.

[andrewg]

Да, во всех случаях при всех экспериментах имело место 170 нс. между нарастающим и спадающим фронтом -CS.
Различным программированием разных регистров предсказуемо меняется длительность -CS, положение data/address valid внутри (и даже снаружи ! при некорректном программировании), гуляют фронты -WR и -RW... и т.д. Но пауза между нарастающим и спадающим фронтами -CS стоит железно - 170 нс...

Ещё появилась мысль, для благородного общества. С большой вероятностью можно ожидать, что весь код цикла ядром процессора будет выполняться во время цикла шины (40, 30 и даже 20нс) и вообще отсутствие паузы между соседними циклами шины на данном процессоре вполне возможная вещь. Меня бы и это устроило - фронтов -WR / -RD хватит.

Но мы упорно видим 170...
-----------------------------
Да простят меня модераторы за оффтоп. Не могу удержаться от всяких улыбок... Господа, вы будете смеяться, но я пишу из кардиологической реанимации, где чувствую себя уже превосходно

[Dron_Gus]

Как я понимаю из беглого просмотра доки, EMI и NFC шарят обшие пины. И между ними есть арбитраж. Я бы на это внимательней посмотрел. Т.е. и на настройки NFC тоже.
И еще. На некоторых EMI есть параметр, отвечающий за паузу между обращениями к разным CS и к одному и тому же CS. Иногда называется turnaround cycles, инода idle cycles. Находится, зачастую, в неожиданных местах.

З.Ы. скорейшего выздоровления.

[Samum 095]

Купите плату IMX51 за 119 евро от Voipac. Они вроде неплохо все делают и хорошо демпингуют на европейском рынке.