Чудя се дали DDR контролерите (както интелските и тези в микроконтролерите) поддържат функция за инициализация на паметта during run time? Т.е. не става въпрос за първоначалното инициализиране на регистрите на контролера след power on, reset и calibration, а за възможността да запишеш 0-и в дадено адресно пространство без да хабиш процесорно време. Някой има ли опит по темата?

А, кое налага тази инициализация?
И защо е фатално ако при инициализация на конторлера процесора загуби и още малко време да инициализира и паметта....?

Най-различни причини

1. Ринг буфер до чиито write pointer нямаш достъп. Т.е. единственият начин да разбереш колко информация е записана в него е да го инициализираш със стойност, която не се среща в потока от данни и когато дойде време да четеш данните разбираш до къде е стигнал на базата на това на кой адрес са записани само нули.
2. Подобрена сигурност при споделяне на паметта. Не искаш следващият процес да знае какви променливи си съхранявал и затова нулираш след себеси
3. Пунктиране - когато структурата с данни съдържа голямо количество нули, процесора може да си спести писането по паметта ако е гарантирано, че същата е била инициализирана с нули. При процесори с малко ресурси за outstanding access това подобрява дирецтно CPI-то

Идеята е, че ако конторлера на паметта поддържа такава функционалност би могъл да
а. освободиш процероса да върши смислена работа от вътрешната памет вместо да се занимава да инициализира външната
б. подобриш ефективността на алокацията на DDR BW като инициализираш само в свободни цикли, когато никой не ползва външната памет
ц. намалиш разхода на енергия, като елиминраш прехвърлянето на данни по вътрешната мрежа между процесора и контролера

В мануала на STM32F1xx пише , че DMA-то заема макс 50% от шината, в мануала на MSP430F5xx пише че процесорът изпълнява 2 инструкции на всеки 4 трансфера на DMA - при такава задача.
ПС.нямам опит по темата

DMA ще се настрои за прехвърляне от памет в памет, единият адрес с автоинкремент, другият - без.

Мисля си че таково животно няма.

то не било DMA ми DDR
Чукча писател....

няма

Мисля си че ако забраниш рефреша и температурата е над 30*С градуса то след около 10 секунди почти цялата памет ще е само нули, но никой не ти го гарантира това.

ike интересна идея, но често резолюцията е в микро до милисекунди.

ДедоБоре, а защо няма? Подобна функционалност се резлизира много компактно, а под 10 нм силиконът е буквално безплатен. В смисъл жиците които се опъват изискват толкова място, че не е никакъв проблем да се турят няколко хиляди транзистора тук и там, особено ако не са масивно навързани. Аз дори си мисля, че е странно DDR контролерите в днешно време да нямат вградени DMA или дори Sequencer-и, достъпни до ниското ниво на FW или дори до крайния потребител, ако се вземат съответните мерки за сигурност.

Никой не го прави по-скоро защото няма особена файда. Така или иначе докато забърсваш RAM-а
никой друг няма да има достъп до него, можеш спокойно да го забършеш и ползвайки за това време
някой от DMA каналите, някой, който инак би чакал да го забършеш. Или някое ядро, което би чакало.
Защо да си причиняваш всичките арбитражи и подобни когато това не ти купува практически нищо?
Освен ако нямаш някакъв по-странен сценарий при който да ти трябва баш това разбира се, нещо
нестандартно което не ми идва на ум.

От гледна точка на енергийната ефективност няма смисъл да лашкаш цяло ядро за подобна работа. Особено в модерните SoC архитектури, където броят на ядрата надминава пръстите на двете ръце и DDR BW-a съответно е щедро димензиониран. Освен това самият контролер на паметта е най-доброто място да повиши ефектиността на достъп, като му дадеш някоя друга ниско приоритетна задача да запълва свободните цикли. Да не говорим, че често е по-лесно да направиш нещо в хардуера отколкото да отвориш АПИ-то между софтуерните агенти на отделните ядра... парадоксално нали?

При "race to idle" архитектури, където ядрата бързат да свършат работата и да заспят, можеш да офлоаднеш инициализацията върху контролера на паметта и да ги преспиш по-рано. Ако това ти позволи да приспиш и кешевете файдата е още по-голяма.

При "race to Fmin" архитектурите можеш да офлоаднеш инициализацията и да използваш освободеното процесорно време за да свалиш честотата на ядрото. Ако това ти позволи да намалиш и напрежението файдата е голяма защото именно то влиза квадратно в енергийната смета.

Не знам дали това е функция на качеството на фирмуера или природна константа, но понякога се чудя тези които го пишат дали не им се плаща повече ако успея да запълнят ядрата без оглед ефективното използване на наличния или възможния от концептуална гледна точка хардуер.

Бях ти чел изначалния пост по-рано и съм го забравил. Мислех, че става дума за еднократно забърсване след инициализация.
Забърсвалка каквато искаш би могла да е полезна наистина, примерно когато деалокираш парче да го забършеш.
Май бих предпочел обаче самият DDRAM да го можеше, предполагам би било по-ефикасно да се бърше на цели
редове вместо на думи - ама не знам всъщност как ги правят вътре. Ако направиш собствено ДМА да бърше
както ти искаш (или както аз искам) остава въпросът как ще арбитрираш достъпа до парчето докато се забърсва,
това не е тривиално - всяко от ядрата и всяко от ДМА-тата трябва да не пипа през това време.

Виж на това ще трябва да обърна внимание. Най-малкото едно асършън ако някое от ядрата тръгне да баря докато върви инициализацията иначе ще е кошмар да се дебъгва подобно нещо. Т.е. арбитрация няма да има. Когато се стартира инициализацията се блокира региона и ако някой опитва да баря там следва асърт. Иначе казано всякаква синхронизация на достъпа до този регион спрямо процесът на инициализация трябва да бъде реализирана на по-високо, софтуерно ниво.

Въобще концепцията на хардуерните механизми на защита, профайлинг и дебъг трябва да е толкова добре изпипана, колкото и самата имплементация. Добър съвет

e, аз поне не съм виждал.

във FPGA DDR 'контролерите' в същност искат обгрижване, обикновено с някакво просто процесорче (от вида на pico blaze). то се грижи да инициализира пиновете и самите DDR чипове, но да прави температурните компенсации на терминирането по време на работа. евентуално там би могъл да барнеш и да допишеш такава фунция. но сорсовете на това контролрче, ако въобще ги има, са такава салата от стари и нови спагети, че....

в по-класически SOC, това вероятно е реализирано по подобен начин, но там нямаш много варианти да бараш баш този 'фърмуер', дори и да е в RAM, а да не е зашит твърдо.