Перейти к содержанию
    

STM32H7+SDRAM пара вопросов

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

 

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

 

Собственно вопрос в том, как будет обработан байтовый доступ CPU к кэшируемой области SDRAM? С чтением понятно, все будет нормально (об этом в Reference manual есть информация), а вот с записью? Я так понимаю кэш по любому будет сбрасывать содержимое в SDRAM словами?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Собственно вопрос в том, как будет обработан байтовый доступ CPU к кэшируемой области SDRAM? С чтением понятно, все будет нормально (об этом в Reference manual есть информация), а вот с записью? Я так понимаю кэш по любому будет сбрасывать содержимое в SDRAM словами?

Там вроде на шине есть сигналы (или сигнал), название их точно не помню. Которые говорят что доступ идёт только к байту (старшему или младшему) из слова.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Там вроде на шине есть сигналы (или сигнал), название их точно не помню. Которые говорят что доступ идёт только к байту (старшему или младшему) из слова.

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

 

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

Изменено пользователем Шаманъ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Про запись ничего не сказано, думаю здесь кэш-память спасет...

Вот для записи они как раз и нужны.

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

Для проверки запишите что-нить в слово по данному адресу, сбросьте кеш, запишите байт туда-же, опять сбросьте кеш, прочитайте, сравните.

 

Но, как-то запамятовал, что есть байтовый доступ :laughing: .

Кроме байтового есть ещё и невыровненный доступ (если Вы конечно его используете в ПО). Для него тоже эти сигналы должны использоваться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

post-39839-1502895589_thumb.png

 

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

post-39839-1502895630_thumb.png

post-39839-1502895638_thumb.png

 

Дальше интересней - отключил кэш и проверил это дело без кэша - байтовый доступ на запись просто проигнорирован, а вот невыровненный доступ как ни странно прошел нормально:

post-39839-1502895549_thumb.png

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

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

 

Дальше интересней - отключил кэш и проверил это дело без кэша - байтовый доступ на запись просто проигнорирован, а вот невыровненный доступ как ни странно прошел нормально:

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

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

Возможно в этом и причина успешных тестов: сбрасываете кеш, а содержимое write buffer остаётся, объединяется со значением из предыдущей записи слова, и как будто всё ок. Хотя на самом деле...

 

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

Тестить надо имхо на случайном паттерне, да ещё в несколько итераций со сменой паттерна.

И не один адрес писать, а писать сразу массив, заведомо превосходящий размер кеша.

Например:

1. Заполнить регион ОЗУ (больше размера кеша) 16-битными записями случайного паттерна.

2. В этот же регион записать побайтовый случайный паттерн (с шагом == 2 - например только все младшие или только старшие байты).

3. Верифицировать.

4. Повторить пп.1-3 с несколькими другими случайными паттернами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

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

 

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

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

 

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

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

 

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

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

 

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

А Вы внимательно посмотрите какие значения используются ;) Как раз все единицы и должны переписаться. Но то лирика. Задачей теста было удостовериться, что байтовый доступ работает с кэшем, и не работает без него - как и ожидалось. Невыровненного доступа к SDRAM у меня нет (его вообще у меня нет). В реальности здоровая программа, которая использует почти всю SDRAM вполне нормально работает при включенном кэше и такой конфигурации памяти, что не может не радовать, ибо платы уже в производстве.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Т.е. - write buffer аналогичный тому, что в Cortex-M4.

Или вы всё-таки между записями данных делали DSB/DMB? Из описания этого не следует.

 

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Я не знаю как обстоит дело в данном МК, но допускаю наличие небольшого write buffer-а либо в ядре либо где-то на межшинных гейтах.

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

post-39839-1502951470_thumb.png

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

 

Кстати про буфер:

DDI0489D_cortex_m7_trm_5.8.2.pdf

 

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

Да, редко, но бывает. В принципе основные нюансы выяснил, и теория в общем-то совпадает с практикой. Остался один "скользкий момент" описанный в п.5.8.1 Cortex-M7 TRM:

DDI0489D_cortex_m7_trm_5.8.1.pdf

 

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

 

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

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

 

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

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

 

Основной вопрос был, как будет обработан байтовый доступ в этом случае - ответы найдены. Всем спасибо!

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

а где автор добыл STM32H743?

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

 

P.S. Только учтите эксперименты описанные были сделаны на STM32F745, но плата делалась под STM32H743, просто она еще не готова, ну а я в спешке как-то профтыкал момент с перестановкой линий ШД на плате. Разницы по идее не должно быть - как сделают плату проверю :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

 

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

Изменено пользователем Шаманъ

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Сваял я девайс с 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:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...