(Untitled)

[tnt23]

Так вот про регенерацию. Засада с ней вот в чем: корка контроллера считает положенное количество тактов REFRESH_COUNT до следующего цикла регенерации, после чего взводит флаг и ждет, что регенерация волшебным образом случится, после чего снова начнет считать REFRESH_COUNT.

Comments

[jecch]

Регенерация - это когда червяка лопатой н-на!

[tnt23]

Джек, это дегенерация!

[dimas]

эт смотря с какой стороны лопаты посмотреть!

[tnt23]

Червяк после партайген.. партеногенеза может смотреть на лопату с обеих сторон :)

[dimas]

в порядке бреда: а ты длину цикла знаешь? может умышленно прерывать или рубить на более короткие?

ну или слипы вставлять или что там еще даст регенерацию запустить …

[tnt23]

Чертов ЖЖ вчера не давал запостить.

Длину цикла в худшем случае я знаю. Прерывать его в принципе можно, ценой генерации ошибки BUS ERROR и дальше на усмотрение обработчика exception, но это совсем как-то криво. Делить на короткие нельзя, он атомарный (выставили адрес - подождали - забрали данные).

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

[jury093]

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

[tnt23]

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

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

[jury093]

у тебя классическая институтская задача на кафедре ВТ - написать эффективный арбитр доступа к памяти..
имхо, подобные задачи решались еще на Микро80, Спектруме и прочих мелких..
я бы поставил приоритет процесса регенерации на первое место и с приличным запасом по таймингам, т.к. характеристики памяти могут плавать, иначе "рыбки просто сдохнут" и все остальные действия потеряют всякий смысл..
поток со стороны физики вероятно лучше пускать через фифо, чтобы избежать потери пакетов..

ну это я так, теоретизирую - возможно есть и более другие пути..
хех, у меня это все еще впереди :)

[tnt23]

Чем больше народу думает вслух, тем лучше :)

Можно и вообще нахально сделать - прицепить принудительный рефреш к концу каждого обращения процессора. Медленно будет кошмарно, зато надёжно.

C FPGA что приятно - перепаивать ничего не надо. Перекомпилировал-залил-запустил и куришь бамбук.

[tnt23]

http://retroramblings.net/?p=258

[suvorow_]

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

[tnt23]

Все верно, но процессор при плотной работе не обращается ко всем строкам памяти в пределах 64мс, поэтому нет гарантии, что будут перебраны все 8192 строк. Так-то да, само по себе обращение к ячейке памяти требует precharge всей строки.

В принципе, можно вести лог с номерами строк и временем последней регенерации, и рефрешить те из них, кому приспичило.

[suvorow_]

вот последний вариант и кажется мне единственно приемлемым, потому что не зря же пришлось отказаться от квадратных матриц. Если в маленькой памяти 16к матрица ещё была квадратной, и перебирать надо было 128 строк, то уже в 64к пришлось делать неквадратную, чтобы перебирать те же 128 строк. Сейчас, конечно, больше, вот у тебя 8192, но и времени примерно во столько же раз больше - период не 2 мс, а 64

[tnt23]

В общем, тут есть над чем подумать :) Список - это я со зла, но в принципе почему бы и нет? У меня свободно больше половины LE и memory blocks тоже хватает.