Jump to content

    
Sign in to follow this  
andrewg

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

Recommended Posts

Имеем плату от 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 нс. между двумя последовательными циклами обращения железно держится.

 

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

Замучались искать засаду. Даташиты огромные. Есть ли у кого какие идеи в какую область посмотреть?

Share this post


Link to post
Share on other sites

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

думается от сюда эти 140ns и набегают...

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

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

Share this post


Link to post
Share on other sites
Имеем плату от Digi i.MX51.

...

Но есть проблема. Между циклами доступа (неважно, RD или WR) процессор вставляет паузы по 170нс. Т.е., CS в нуле 30 нс, в единице 170 нс, в нуле 30 нс ... и т.д. Соответственно, время периода выполнения учебного цикла:

for (i=0;i<XXXX,i++)

{ data16= INREG16(pPORT); }

200 нс а не 30нс.

...

Замучались искать засаду. Даташиты огромные. Есть ли у кого какие идеи в какую область посмотреть?

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

 

Share this post


Link to post
Share on other sites

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 (в другом исполнении тестовых плат).

Edited by andrewg

Share this post


Link to post
Share on other sites
Тесты, которые Вы предлагаете, мы пробовали (в числе большого числа прочих).

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

Да, во всех случаях при всех экспериментах имело место 170 нс. между нарастающим и спадающим фронтом -CS.

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

 

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

 

Но мы упорно видим 170...

-----------------------------

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

 

 

 

 

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this