реклама на сайте
подробности

 
 
2 страниц V   1 2 >  
Reply to this topicStart new topic
> STM32H7+SDRAM пара вопросов, перетасовал выводы на ШД и ША...
Шаманъ
сообщение Aug 16 2017, 10:10
Сообщение #1


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Приветствую всех!

Возник не совсем "нормальный" вопрос. В процессе упаковки STM32H743 и SDRAM на двухслойку (только не говорите, что так низзя - это для экспериментов rolleyes.gif ). Получилось весьма неплохо с этим справиться, если перетасовать младший байт ША и всю ШД. По идее проблем это не должно доставить (учитывая то, в каких режимах FMC работает с SDRAM). Но, как-то запамятовал, что есть байтовый доступ laughing.gif . Короче теперь память может работать только словами по 16бит.

Собственно вопрос в том, как будет обработан байтовый доступ CPU к кэшируемой области SDRAM? С чтением понятно, все будет нормально (об этом в Reference manual есть информация), а вот с записью? Я так понимаю кэш по любому будет сбрасывать содержимое в SDRAM словами?
Go to the top of the page
 
+Quote Post
jcxz
сообщение Aug 16 2017, 11:00
Сообщение #2


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Шаманъ @ Aug 16 2017, 13:10) *
Собственно вопрос в том, как будет обработан байтовый доступ CPU к кэшируемой области SDRAM? С чтением понятно, все будет нормально (об этом в Reference manual есть информация), а вот с записью? Я так понимаю кэш по любому будет сбрасывать содержимое в SDRAM словами?

Там вроде на шине есть сигналы (или сигнал), название их точно не помню. Которые говорят что доступ идёт только к байту (старшему или младшему) из слова.
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Aug 16 2017, 11:05
Сообщение #3


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Цитата(jcxz @ Aug 16 2017, 14:00) *
Там вроде на шине есть сигналы (или сигнал), название их точно не помню. Которые говорят что доступ идёт только к байту (старшему или младшему) из слова.

Да, NBL_0, NBL_1 (со стороны STM32), и я их даже развел, но толку от них нет, т.к. на ШД переставлены сигналы между младшим и старшим байтами (профтыкал я этот момент однако). В мануале написано, что при чтении NBL_x не используются - вычитывается сразу слово, лишнее не используется. Про запись ничего не сказано, думаю здесь кэш-память спасет...

Проверил на плате с STM32F7 - отключил NBL_x (сконфигурировал как GPIO выдающий все время "0"). Работает все как будто ничего и не менялось. По идее в H7 должно также работать.

Сообщение отредактировал Шаманъ - Aug 16 2017, 11:06
Go to the top of the page
 
+Quote Post
jcxz
сообщение Aug 16 2017, 12:12
Сообщение #4


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Шаманъ @ Aug 16 2017, 14:05) *
Про запись ничего не сказано, думаю здесь кэш-память спасет...

Вот для записи они как раз и нужны.
А как кеш тут может спасти? Думаете, что при записи (при отсутствии данного адреса в кеше), контроллер выполнит чтение-запись вместо просто записи с этими сигналами? Сильно сомневаюсь в этом.
Для проверки запишите что-нить в слово по данному адресу, сбросьте кеш, запишите байт туда-же, опять сбросьте кеш, прочитайте, сравните.

Цитата(Шаманъ @ Aug 16 2017, 13:10) *
Но, как-то запамятовал, что есть байтовый доступ laughing.gif .

Кроме байтового есть ещё и невыровненный доступ (если Вы конечно его используете в ПО). Для него тоже эти сигналы должны использоваться.
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Aug 16 2017, 15:02
Сообщение #5


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Цитата(jcxz @ Aug 16 2017, 15:12) *
А как кеш тут может спасти? Думаете, что при записи (при отсутствии данного адреса в кеше), контроллер выполнит чтение-запись вместо просто записи с этими сигналами? Сильно сомневаюсь в этом.

У меня параметры кэширования выставлены WBWA - последнее обозначает Write Allocate, т.е. при записи произойдет выделение и заполнение (=чтение) линии кэша (32байта). Соответственно кэш-контроллер с памятью общаются только словами (точнее блоками по 8 32битных слов).

Попробовал записал 0xEEEEFFFF по адресу 0x7000_0000, потом байт по адресу 0х7000_0000, потом слово по адресу 0х7000_0001 (невыровненный доступ, у меня такой доступ не используется, но проверить было интересно sm.gif), потом сбросил кэш - результат все записалось в точности как и должно было быть sm.gif.
Прикрепленное изображение


На всякий случай проверил с промежуточным сбросом и инвалидацией кеша. Работает как и ожидалось:
Прикрепленное изображение

Прикрепленное изображение


Дальше интересней - отключил кэш и проверил это дело без кэша - байтовый доступ на запись просто проигнорирован, а вот невыровненный доступ как ни странно прошел нормально:
Прикрепленное изображение
Go to the top of the page
 
+Quote Post
jcxz
сообщение Aug 16 2017, 15:20
Сообщение #6


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Шаманъ @ Aug 16 2017, 18:02) *
У меня параметры кэширования выставлены WBWA - последнее обозначает Write Allocate, т.е. при записи произойдет выделение и заполнение (=чтение) линии кэша (32байта). Соответственно кэш-контроллер с памятью общаются только словами (точнее блоками по 8 32битных слов).

А как же эффективность? Это-ж при случайном произвольном доступе будет каждый раз вместо записи 1го байта по шине сначала производиться 16 операций чтения, потом ещё 1 запись!

Цитата(Шаманъ @ Aug 16 2017, 18:02) *
Попробовал записал 0xEEEEFFFF по адресу 0x7000_0000, потом байт по адресу 0х7000_0000, потом слово по адресу 0х7000_0001 (невыровненный доступ, у меня такой доступ не используется, но проверить было интересно sm.gif), потом сбросил кэш - результат все записалось в точности как и должно было быть sm.gif.

Ну - это не корректная проверка, так как перед записью байта не было сброса кеша: байт просто обновит предыдущие записанные данные, находящиеся ещё во write buffer-е.

Цитата(Шаманъ @ Aug 16 2017, 18:02) *
На всякий случай проверил с промежуточным сбросом и инвалидацией кеша. Работает как и ожидалось:

Хм... видимо сигналы эти (NBL_0, NBL_1) опциональны и можно и без них пожертвовав производительностью произвольной записи.

Цитата(Шаманъ @ Aug 16 2017, 18:02) *
Дальше интересней - отключил кэш и проверил это дело без кэша - байтовый доступ на запись просто проигнорирован, а вот невыровненный доступ как ни странно прошел нормально:

А это странно. Как такое может быть? Если кеш реально выключен, то откуда взялись данные из немодифицируемых байтов?
Опять-же - Вы выключили кеш, а выключили-ли write buffer? laughing.gif
Возможно в этом и причина успешных тестов: сбрасываете кеш, а содержимое write buffer остаётся, объединяется со значением из предыдущей записи слова, и как будто всё ок. Хотя на самом деле...

PS: Да и выбор такого шаблона для тестов некорректен - у Вас при записи байта на неиспользуемых этим байтом линиях будут например все '1' и в результате эти единицы перепишутся поверх старых, а Вы и не заметите.
Тестить надо имхо на случайном паттерне, да ещё в несколько итераций со сменой паттерна.
И не один адрес писать, а писать сразу массив, заведомо превосходящий размер кеша.
Например:
1. Заполнить регион ОЗУ (больше размера кеша) 16-битными записями случайного паттерна.
2. В этот же регион записать побайтовый случайный паттерн (с шагом == 2 - например только все младшие или только старшие байты).
3. Верифицировать.
4. Повторить пп.1-3 с несколькими другими случайными паттернами.
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Aug 16 2017, 18:29
Сообщение #7


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Цитата(jcxz @ Aug 16 2017, 18:20) *
А как же эффективность? Это-ж при случайном произвольном доступе будет каждый раз вместо записи 1го байта по шине сначала производиться 16 операций чтения, потом ещё 1 запись!

У меня нет в программе случайного байтового доступа. Пишется все довольно большими блоками (минимум по 400байт). В таком режиме это вполне нормальная стратегия работы кэша, по крайней мере работает быстрее WT режима, т.к. данные в SDRAM сбрасываются/читаются блоками. Т.е. если бы "не поехало", то можно было бы переделать на выровненный доступ.

Цитата
Хм... видимо сигналы эти (NBL_0, NBL_1) опциональны

То, что они опциональны это очевидно - тот же куб позволяет выбрать режим FMC с SDRAM без них. Весь вопрос был в байтовом доступе в такой конфигурации.

Цитата
А это странно. Как такое может быть?

А как ядро разруливает невыровненный доступ? Почитал ARM v7 Architecture Manual, как-то не особо прояснилось - судя по псевдокоду идет серия байтовый транзакций на шине, но вопрос как себя ведет шина в обсуждаемой ситуации неясен. То, что наблюдается выглядит несколько иначе.

Цитата
Если кеш реально выключен, то откуда взялись данные из немодифицируемых байтов?

В смысле? Там все ок за исключением записи байта - ее просто нет, как и ожидалось, и невыровненного доступа - он на удивление сработал...

Цитата
Опять-же - Вы выключили кеш, а выключили-ли write buffer? laughing.gif

О каком write buffer речь? FMC не буферизирует запись в SDRAM. В варианте с выключенным кэшем оставлен исходный режим работы процессора после сброса.

Цитата
PS: Да и выбор такого шаблона для тестов некорректен - у Вас при записи байта на неиспользуемых этим байтом линиях будут например все '1' и в результате эти единицы перепишутся поверх старых, а Вы и не заметите.

А Вы внимательно посмотрите какие значения используются wink.gif Как раз все единицы и должны переписаться. Но то лирика. Задачей теста было удостовериться, что байтовый доступ работает с кэшем, и не работает без него - как и ожидалось. Невыровненного доступа к SDRAM у меня нет (его вообще у меня нет). В реальности здоровая программа, которая использует почти всю SDRAM вполне нормально работает при включенном кэше и такой конфигурации памяти, что не может не радовать, ибо платы уже в производстве.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Aug 16 2017, 19:06
Сообщение #8


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(Шаманъ @ Aug 16 2017, 21:29) *
О каком write buffer речь? FMC не буферизирует запись в SDRAM. В варианте с выключенным кэшем оставлен исходный режим работы процессора после сброса.

Я не знаю как обстоит дело в данном МК, но допускаю наличие небольшого write buffer-а либо в ядре либо где-то на межшинных гейтах. Вы выполнили запись 0xFFFFEEEE, оно лежит в этом wb, в контроллер EMC не поступает. Потом пишете байт, он заменяет мл. 0xFF в wb. Слово продолжает лежать в wb. Пишете полуслово в байты 1,2, они заменяются новыми в wb. Записи в EMC всё нет. Делаете сброс кеша. И вот тут только реально происходит запись полного слова. Естественно, что это будет только одна транзакция из 2-х 16-битных записей на шине. И содержимое памяти будет правильным.
Т.е. - write buffer аналогичный тому, что в Cortex-M4.
Или вы всё-таки между записями данных делали DSB/DMB? Из описания этого не следует.

Цитата(Шаманъ @ Aug 16 2017, 21:29) *
байтовый доступ работает с кэшем, и не работает без него - как и ожидалось. Невыровненного доступа к SDRAM у меня нет (его вообще у меня нет). В реальности здоровая программа, которая использует почти всю SDRAM вполне нормально работает при включенном кэше и такой конфигурации памяти, что не может не радовать, ибо платы уже в производстве.

Иногда так бывает. А потом когда немного изменишь алгоритм и вдруг начинает глючить совершенно неожиданно в неожиданных местах. И потом думаешь "а как оно вообще работало?" rolleyes.gif

PS: А байтовый DMA в эту область работает нормально? Если конечно он есть в ПО...
Go to the top of the page
 
+Quote Post
skripach
сообщение Aug 16 2017, 23:41
Сообщение #9


■ ■ ■ ■
*****

Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443



Биты ШД можно менять только впределах байта.


--------------------
Делай что должен и будь что будет.
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Aug 17 2017, 07:23
Сообщение #10


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Цитата(jcxz @ Aug 16 2017, 22:06) *
Я не знаю как обстоит дело в данном МК, но допускаю наличие небольшого write buffer-а либо в ядре либо где-то на межшинных гейтах.

Да, в варианте с выключенным кэшем про dsb/dmb как-то я забыл, а буфер таки есть - если все сбросить в память, то и невыровненный доступ не работает:
Прикрепленное изображение

Вот теперь полный порядок sm.gif - все работает точно, как должно быть в теории.

Кстати про буфер:
Прикрепленный файл  DDI0489D_cortex_m7_trm_5.8.2.pdf ( 612.04 килобайт ) Кол-во скачиваний: 36


Цитата
Иногда так бывает. А потом когда немного изменишь алгоритм и вдруг начинает глючить совершенно неожиданно в неожиданных местах. И потом думаешь "а как оно вообще работало?" rolleyes.gif

Да, редко, но бывает. В принципе основные нюансы выяснил, и теория в общем-то совпадает с практикой. Остался один "скользкий момент" описанный в п.5.8.1 Cortex-M7 TRM:
Прикрепленный файл  DDI0489D_cortex_m7_trm_5.8.1.pdf ( 329.98 килобайт ) Кол-во скачиваний: 54


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

Цитата
PS: А байтовый DMA в эту область работает нормально? Если конечно он есть в ПО...

Нет, несколько DMA с SDRAM только 32битными словами у меня работают. Да и как он может на запись напрямую работать без NBL_x? Тут как по мне все очевидно.

Цитата(skripach @ Aug 17 2017, 02:41) *
Биты ШД можно менять только впределах байта.

Если в общем случае, то да, но если доступ к памяти будет только 16битными словами, то не вижу проблем. Более того в этом случае NBL_x у SDRAM можно просто посадить на землю и освободить две ноги у МК.

Основной вопрос был, как будет обработан байтовый доступ в этом случае - ответы найдены. Всем спасибо!
Go to the top of the page
 
+Quote Post
dachny
сообщение Aug 17 2017, 07:32
Сообщение #11


Частый гость
**

Группа: Свой
Сообщений: 82
Регистрация: 7-07-04
Пользователь №: 284



немного не в тему... а где автор добыл STM32H743??? ато я тоже тоже такую хочу..
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Aug 17 2017, 09:43
Сообщение #12


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Цитата(dachny @ Aug 17 2017, 10:32) *
а где автор добыл STM32H743?

Это инженерные образцы - попросите у СТМ/представителей.

P.S. Только учтите эксперименты описанные были сделаны на STM32F745, но плата делалась под STM32H743, просто она еще не готова, ну а я в спешке как-то профтыкал момент с перестановкой линий ШД на плате. Разницы по идее не должно быть - как сделают плату проверю sm.gif
Go to the top of the page
 
+Quote Post
skripach
сообщение Aug 17 2017, 19:21
Сообщение #13


■ ■ ■ ■
*****

Группа: Свой
Сообщений: 1 100
Регистрация: 9-08-06
Пользователь №: 19 443



Цитата(Шаманъ @ Aug 17 2017, 10:23) *
Если в общем случае, то да, но если доступ к памяти будет только 16битными словами, то не вижу проблем. Более того в этом случае NBL_x у SDRAM можно просто посадить на землю и освободить две ноги у МК.

А как планируется заставть контроллер SDRAM работать только 16битными словами?


--------------------
Делай что должен и будь что будет.
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Aug 18 2017, 13:13
Сообщение #14


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Цитата(skripach @ Aug 17 2017, 22:21) *
А как планируется заставть контроллер SDRAM работать только 16битными словами?

Не писать в SDRAM байты и не использовать невыровненную запись в SDRAM sm.gif Вроде выше все наглядно продемонстрировано. Естественно не везде это будет удобно сделать - у меня ПО позволяет с минимальными усилиями отказаться от байтового доступа. Кэш память по идее тоже решает вопрос, но есть нюансы (вся информация выложена выше).

P.S. А платы наверное придется переделать, но по другой причине laughing.gif ...

Сообщение отредактировал Шаманъ - Aug 18 2017, 13:14
Go to the top of the page
 
+Quote Post
Шаманъ
сообщение Sep 21 2017, 22:34
Сообщение #15


Знающий
****

Группа: Участник
Сообщений: 758
Регистрация: 27-08-08
Пользователь №: 39 839



Приветствую всех!

Сваял я девайс с STM32H743. Есть проблема. Шина адреса SDRAM у меня подключена тоже "не православно", вот так:
Код
SDRAM Processor
A0 ------- A7
A1 ------- A6
A2 ------- A4
A3 ------- A5
A4 ------- A0
A5 ------- A1
A6 ------- A2
A7 ------- A3

Учитывая, что FMC у STM32 использует бурсты с длиной 1, т.е. фактически их не использует, это не должно вызывать проблем (при программировании Mode Register я учел такую разводку). Я прав, или что-то упустил?

В реальности тесты памяти проходят, ядро пишет/читает все нормально, а DMA2D выдает хрень - такое впечатление, что он умеет работать с SDRAM только блоками по 8 байт (AXI шина кстати 64битная, что как бы намекает). Тот же код для DMA2D нормально рисует на F746 и на H743 если буфер в AXI SRAM.

Собственно вопрос - есть у кого мысли, что может происходить? Или DMA2D+FMC на H7 "не едет"?

P.S. Камень как бы это сказать...своеобразный rolleyes.gif
Go to the top of the page
 
+Quote Post

2 страниц V   1 2 >
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th July 2025 - 00:45
Рейтинг@Mail.ru


Страница сгенерированна за 0.01545 секунд с 7
ELECTRONIX ©2004-2016