vik0

А это уже интересно. Спасибо!

При повышении температуры уменьшается slew-rate сигнала и увеличивается время его распространения. Что, в свою очередь, и влияет на setup/hold. http://download.micron.com/pdf/technotes/ZT09.pdf

Я бы поставил отдельную SRAM для кода (если финансы/габариты позволяют). Все-таки две независимые шины - большое преимущество, которым грех не воспользоватся. В 54х это решается с помощью urgent dma request (для ppi, как минимум). Попробую на следующей неделе поигратся с этим, о результатах сообщу. Да, прямо в DDR. Нет, управление трафиком настроено по-умолчанию.

У меня получалось вводить данные на 55 МГц (реальный поток ~40 МБ/с), выводить на 27 (~20 МБ/с) и гонять данные между DDR и L1 (~60 МБ/с). При увеличении входного потока, начинались проблемы. При этом я специально складывал все данные в один(!) банк DDR и не использовал urgent dma. Т.е. это еще совсем не предел. НО. Ядром в SDRAM я вообще не лез. Нет, только color conversion. Использование композитора вышеописанную картину никак не меняло. Вы DMA давали приоритет над ядром? Насчет именно этих фифо не скажу, но в 54х есть еще "DDR Queue Manager", который, как обещают, "Optimize requests to the DDR controller to achieve maximum utilization of the DDR memory bus" PS. Еще можно как-то использовать тот факт, что 54х имеют отдельную внешнюю асинхронную шину (SRAM, к примеру, прицепить).

РФ900 Они от температуры зависят.

В каком смысле "запускали"? Конкретезируйте чуть-чуть. А так, да, активно работаем с видео. Ввод/вывод/обработка. Разрешения - разные (user-selectable), от 320х240 до (примерно) 2500х2000. 10-12 бит, преимущественно grayscale, с цветом только баловались. Плюс стандартный itu656 на вывод.

Ба! Знакомые все лица :) В смысле, использовали ваше оборудование. Мы для себя решили эту проблему переходом на 54х серию с ddr памятью ;) setup/hold времена от частоты не зависят. Золотые слова. Перед тем как нарушать спецификацию, нужно четко и однозначно осознавать к чему это может привести, а не делать по принципу "у всех работает - и у меня заработает". В принципе, я на 99% уверен, что у denebopetukius'а тоже все нормально заработает, но все равно буду рекомендовать использовать 2х16. Вот за это я и люблю родную медицину

В каких температурных условиях? Какая цена сбоя вашего оборудования?

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

А у вас стек большой? Не хотите разместить его в scratchpad-е?

А в мануал заглянуть? Только я все равно не могу понять, зачем вам кэшировать L2 память? Неужели вы оттуда данные выгребаете каждый такт?

Видимо что-то где-то у вас "глюкануло". У меня эти закладки работают с 4-й версии и по сегодняшний день (со всеми апдейтами). А вот тут я с вами соглашусь на 1000% :maniac:

Вы хотите сказать, что AD на странице http://www.analog.com/en/embedded-processi...grades/fca.html предоставляет неправдивую информацию? Каких страниц? К каком GUI?

Стр. 20, примечание 2 к таблице 10

У Micron-а есть достаточно интересная апп-нота. Интересный документ, спасибо.

Давайте конкретизируем - какой дисплей? И ссылку на datasheet, пожалуйста. Без проблем. От 1х1 до 65535х65635 с шагом в один пиксель по любой оси. Не понял. Какая развертка? dma запустили и занимайтесь другими делами. Не вижу проблемы. Нет, вы меня не поняли. Делайте прорисовку в буфер как и сейчас, после этого маленьким быстрым циклом преобразуйте это буфер в rgb, и, с помощью dma, отправляете его на дисплей (а в это время начинаете прорисовку следующего кадра). Т.е., условно, цикл прорисовки выглядит следующим образом: while (true) { draw_frame(); // draw_sprite0(); draw_plane0(); и т.д. convert_frame_to_rgb(); if (!first_frame) wait_for_output_done(); start_frame_output_via_dma(); } +100

Полу- :bb-offtopic: А совсем правильно так: *pSPI_CTL = TDBR_DMA | GM | EMISO | CPOL | SPE; Суть та же (за исключением slave select enable - не понятно на кой оно тут). Но, согласитесь, мой вариант намного наглядней. PS. Скажу честно, когда я вижу в посте "magic numbers", в 90% случаев я этот пост дальше не читаю :laughing:. И, как мне кажется, я не один такой.

Обсуждалось недавно.

Объясните, все-таки, почему? На первое ядро А кто мешает сформировать rgb буфер в l2 памяти и его по dma отправлять на LCD? А в это время формировать палитровый буфер нового кадра (к примеру).

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

Для написания загрузчика для BF достаточно вдумчивого прочтения раздела "system reset and booting" мануала на процессор и апп-ноты, посвященной процессу загрузки данного процессора. Исходник есть. Поделится не могу, ибо не имею права. Будут конкретные вопросы - спрашивайте, поможем.

:) Там совсем не два... К примеру, можно глянуть на эту оценочную плату от Xilinx. Она мало в чем уступает современной материнской плате. Ее схему и трассировку (22 слоя) можно взять тут.

Вот чего не знаю, того не знаю :unsure: Непонял. Можете проиллюстрировать?

У меня issi нормально работает. Попробуйте по прямой ссылке: http://www.issi.com/pdf/42-45S32160B.pdf Micron тоже подох? ;) http://download.micron.com/pdf/datasheets/...6MbSDRAMx32.pdf Вероятно, узкое место по производительности было в вычислительных ресурсах, а не в пропускной полосе. Либо доступ к памяти производился по таким схемам, что ширина шины не играла значительной роли (read-write-read из одного банка, дикий random access и подобные вещи)

Не стоит снижать [потенциальный] прирост производительности урезая шину в два раза... Ставьте 2 по 16 бит (например, MT48LC16M16 - 4Мбит х 16 х 4 банка). С разводкой _никаких_ проблем нет (в крайнем случае подскажем ;))