Начинаю проэктик стыкующий видео выход под OLED на выход на TFT. Нужно переформатировать данные, стыковать тайминги (которые разные под OLED и под TFT) и т.д..
В плане стыковки таймингов нужен FIFO солидного размера, по подсчетам примерно 160-170 kBit.
Пробегая по specs разных FPGAев (буду работтаь на Lattice), там предлагаются различные виды конфигурируемой памяти типа ditsributed single port/dual port RAM, ROM, и т.д...
Что такое за distributed RAM ? (дословный перевод не нужен, с английским дружем плотно...нухно понять что оно означает на практике, плюсы и минусы и т.д.)
Обратил внимание что размеры встроенной памяти в упомянутом выше размере уже граничат с пределами в больших FPGAях. Может тогда стоит подумать насчет небольшого FPGA в паре с отдельным чипом памяти (FIFO либо SRAM) ?

distributed RAM значит, что память будет собрана из триггеров ПЛИС. Соответственно, если вы соорудите большую по объему distributed RAM - она съест много ресурсов ПЛИС и на реализацию
полезной логики места не останется. Именно поэтому в ПЛИС (по крайней мере у Xilinx) есть специально
предназначенные для этих целей модули Block RAM.

Я мыслю, что distributed RAM - это память, равномерно распределенная по площади кристалла FPGA. Т.е. имеется туева хуча небольшх по объему блочков памяти, которые равномерно расположены на кристалле. У альтеры в качестве примера можно привести блоки MLAB в Stratix III.
В противоположность распределенной памяти - блочная память (к примеру блоки MRAM, M4K, M9K в альтеровских стратиксах и циклонах). Т.е. имеется некоторое кол-во блоков памяти довольно большого объема, которые располагаются локально (как правило, образуют столбцы ).
Аналогичная картина и ПЛИСах других фирм (Xilinx, Lattice и др.).


Не факт. Блочки могут быть и специалирированные. К примеру в Atmel AT40KAL.

Распределенная память (в отличие от блочной) реализуется на LUT'ах. Т.е. LUT'ы логических элементов вместо реализации логики используются для нужд памяти - это возможно благодаря тому, что сами LUT'ы есть не что иное как память. Например, 4-входовой LUT - это память 16х1 (либо может быть сконфигурирована как две памяти 8х1, что используется в арифметических/счетных режимах, когда одна половинка вычисляет сумму, а вторая в это же время перенос). Распределенная память есть не у всех семейств - например, у альтеровских FPGA ее нет, там только блочная.

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

Минусы - большой объем памяти съест много логики, не выгодно, большой объем выгоднее делать на блочной.

ксайлинксовская память делается на лутах или триггерах а у альтеры действительно только на триггерах

o-henry ответил Вам правильно.
Формулировка ditsributed подчеркивает что память будет реализувана на LUT, т. е. общий ресурс.
Не так важно как, главное LUT будет занят.
В lattice есть блоки -EBR - чистая SRAM. Т. е. именно память.
Наверняка и у других то же самое.

Например для серии EC (старенькая) последовательно от модели объемы в килобитах
18 55 92 276 350 424 498
Т. е. ЕС10 имеет 276 килобит памяти. Макс - 498 килобит.
ПРи dual port объем пересчитывается, смотрите даташит.
Нет смысла использовать ditsributed если есть EBR, которая через соответствующую IP core (входит в софт) легко объвязывается в FIFO, правда надо принимать во внимание латентность из за pipeline структуры.
Насчет смысла, это конечно спорно, согласен - зависит от задачи.

В Xilinx под distributed RAM понимается несколько другое (не скажу за остальные). У него есть возможность использовать LUT таблицу как память, посколько LUT у него четырех-входовой то соответственно можно получить память 16х1, из 16 LUT получиться память 16х16 ну и так далее.
Сам этим пользовался в Xilinx много раз, если было нужно сделать мелкое FIFO или небольшую память для фильтра.

Большое спасибо за ответы, картину проясняет более-менее.
Vladimir, по моим подсчетам понадобиться примерно 165-170 kBit конфигурированные либо побайтно, либо как 18 бит на данное.
По прикидкам, на данный момент кол-во логики будет относительно небольшое, (несколько счетчиков разной длинны + небольшие state machines и небольшая управляющая логика). Исходя из этого, вероятно distributed память может подойти, т.е. чип с относительно небольшой блочной памятью но с порядочным кол-вом LUTs, так ?

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

Учитывая эти факторы, будет ли целесообразным ориентироваться на чипы с большой блочной памятью и экономить на LUTах (либо насколько возможно блочной + комбинировать с distributed) ?

Для экономии времени, буду говорить о Lattice EC.
Ну и пусть небольшое, но если на чипе уже есть SRAM, и по тиммингам и разрядности/глубине Вы впишитесь, то какие аргументы чтобы делать на логике?
Посмотрите, для EC в самом толстом чипе можно теоретически иметь только 131килобит в ЛОГИКЕ.
И при этом сидеть на чипе BGA с 480 пинами, оно надо?
Плюс стоимость чипа.
С другой стороны, Вы получаете 276 килобит SRAM в 30 блоках (т.е. 30 независимых модулей памяти)
при разрядности 512 x 18 (на большую разрядность меньше блоков останется) каждый
И у Вас еще есть немногим менее 10 КLUT (менее потому как расходуется логика на FIFO организацию)
Делайте на ней что хотите сейчас или потом.
Это можно вытянуть уже на 208 PQFP - легче работать.


Не совсем понятно - " добавляя в нее подгонку видео под TV".

1. Делайте эскизный проект - текущий - расширенный.
2. Считайте потребности ресурсов.
3. Просто откройте дата шит и смотрите таблицы.
4. Исходите из минимального потребности/запаса по пинам.
5. Смотрите объем памяти EBR (кроме общего смотрите и количество блоков)

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

Да, спасибо за дельные советы. Сейчас глянул datasheetы на ECM2/M чипы там оказывается более чем надо блочной памяти (несколько десятков блоков по 18кбит каждый, при конфигурации 18 бит ширины данных, мне понадобится примерно 7-8 блоков). Значит distributed - отпадет.

Насчет вашего совета не увлекаться перспективой - в приципе оно еще связано с покупкой подходящего evaluation board. Думаю есть смысл брать под более-менее большой чип, с надеждой что-б подошел и ан второй этап проэкта. А пока делать на нем первый (более простой) этап, затем после debugа синтезировать его под нужный размер чипа (вероятно более мелкий чем на evaluation board) и делать систему на том более мелком чипе. Это я к тому что надеюсь дизайн и debug на большом чипе даст рабочую версию и для более мелкого (но подходящего по ресурсам) чипа. Я ошибаюсь ?

В целом, вроде нет, тем более у LATTICЕ, если мне не изменяет память, самый маленький чип на evaluation board - EC20 (но не гарантирую), это вполне достаточно.
Вы можете взять у них схемы evaluation board, на EC они точно есть на сайте.
Другие чипы я уже год не смотрю, у меня EC серия.
Хотя при переходе с большего на меньший все не совсем однозначно.
Размещение и трасировка в меньшем чипе - это совсем другие условия (могут оказаться, после большего чипа) и если чип уже будет заполнен очень сильно - надо быть готовым к потенциальным засадам.
Т. е. переход вниз, в общем случае, заранее, 100% гарантировать нельзя, даже если "чисто арифметически" он корректен.

Понял, спасибо.
Кстати, как насчет их flash-based чипов ? Не пробовали XP серию ? Заманчиво избавиться от внешнего EPROMа (или им подобного)...

Ничего не могу сказать, это хорошая штука.
Я тоже хотел делать на XP, но потом пришлось перейти на обычную.
По комплексу моих критериев это было лучше.
Чем хорош еще Lattice - у них можно ставить стандартную SPI флэш.

стандартную не альтеровскую флэш можно ставить и на альтеру - много раз обсуждалось 50 рублей против 500

Да, бегло сравнил ECP2/M с XP2 - все-таки первый более емкий по каждой категории, да и evaluation board с ECP2 идет с более емким чипом (+ больше prototyping area что мне важно) чем борд под XP2 борд последнего почемуто ограничем -17 чипом, тогда как ECP2 борд идет с -50 чипом).
А жаль, XP2 серия была-бы заманчивой...

Представляется, что при использование любых ПЛИС, любого производителя, при таком требуемом объеме памяти, это будет весьма дорогой кристал. Не дешевле ли, взять кристал FIFO, например, от IDT или Cypress и самый маленький FPGA?

Не проще ли в таком случае SRAM+CPLD?

Отдельный чип FIFO либо SRAM с CPLD/FPGAем - тоже варианты.
Но вроде чипы серий ECP2 предлагают вполне адекватное кол-во блочной памяти внутри при приемлимой цене (скажем 20-40 US$). Данный проэкт рассчитан на весьма небольшое кол-во конечного девайса (примерно 3-5 приборов) для нашегу внутреннего лабораторного использования, посему цена в плане массового производства не сильно актуальна.

Но как я упоминал, будет второй этап проэкта, где видео будет подгонятся под стандартный TV выход и там кроме всего прочего с этим связанного будет deinterlacing. Последний потребует памяти как минимум на пол фрейма, по моим подсчетам примерно от примерно 0.5 до 1 MB. Тут есно без внешнего SRAMма (или даже DRAMа) не обойтись...

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

Тут я с вами никак не соглашусь, сорри .
Выход идет на TV (телевизор либо TV monitor), должен соответствовать стандарту, т.е. типу сигнала который ожидает стандартный ТВ монитор. Это значит interlaced, определенное кол-во строк в fieldе и соотв. в кадре, и т.д. и т.п. соответственно NTSC либо PALу по требованию. Частоты разверток обязаны соответствовать стандартам тоже.
Отправляя на ТВ монитор fieldы в качестве кадров получаем полный бардак на экране. Посему не вижу альтернативы interlacingу.

То что вы предлагаете, может подойти например для выхода на небольшой TFT/OLED дисплей у которых вертикальная резолюция примерно равна половине ТВ. Тогда действительно, можно гнать каждый field на дисплей в качестве полного фрейма (т.е. подогнав соответственно VSYNCs), да и многие дисплеи такого типа как раз и рассчитаны на frame rate в 2 раза выше чем стандартный ТВ. Ессно, потеря вертикальной резолюции в 2 раза, но во многих случаях это приемлимо (например как preview). Кроме того, думаю в таком случае нужно уменьшать соотв. в 2 раза и горизонтальную резолюцию перед выводом на дисплей, иначе получим серьезное искажение aspect ratio...

Тут вы пишете, что надо deinterlace, соответственно думается, что TV - на входе. И поэтому предлагается deinterlace.

А тут уже TV на выходе. Так что я в непонятках.

Тут я видимо не совсем ясно выразился - задача в том чтоб гнать выход на TV, внутри системы идет progressive с резолюцией которую нужно интерполировать под TV выход, затем нужно превращать в interlaced. В кратце - на выходе - TV.