v_mirgorodsky

Угу, и сколько ресурсов и какого кристалла это заняло и на какой частоте запустилось :o) Деление всегда было самой ресурсоемкой и медленной операцией во всех FPGA, майнстрим процессорах, ASIC'ах и других цифровых устройствах. Как обстоит дело в этом случае ?

Виталий А вам все еще будет интересно это устройство года этак через полтора? Где-то с полгодика надо будет осваивать основные премудрости ПЛИС, еще месяца четыре займут эксперименты с масштабированием, еще месяца два займет контроллер видеобуффера и так далее. При этом Вы вероятно где-то работаете и не сможете уделять этому занятию слишком много своего времени. Посему поддерживаю мнение oval экономически выгоднее просто купить подобное решение, если оно есть в продаже, или таки найти место для телевизора, или смириться с использованием компьютера.

Это как запустить Linux на софтовом процессоре на Microblaze на Xilinx - очень круто и навороченно, но пока не нужно. Нет, я понимаю, что можно найти задачу, под которую это будет оптимально и необходимо, но по большому счету Linux там - излишество. Так и с SystemC - пока что потеря 20-30% быстродействия и 10-15% емкости кристалла не оправдывает то увеличение скорости разработки, которое способен обеспечить SystemC. Но ведь и винды не сразу стали стандартом де-факто на персоналках. Выросла мощность компьютеров, увеличились объемы памяти, снизилась стоимость винтов и все получилось. Так и с SystemC - его начнут использовать тогда, когда емкость и скорострельность FPGA чипов будет позволять компенсировать недостатки, связанные с этой технологией. Думаю, что это произойдет в районе удвоения существующих показателей по емкости и скорострельности для FPGA при сохранении существующей на сегодняшний день цены.

В SDRAM'е он есть, но у Блэкфина его нет :( ну а оно и не надо - так как SDRAM пайплайновая штука, то затраты на смену адреса внутри страницы (если банк не закрывается, что верно для BF, и страница не меняется - что верно для последовательного доступа) равны 0 то есть если бы и был FULL PAGE BURST, то страница была бы считана ровно за то же самое время Так-то оно та-а-ак, да не совсем. Для столь красивого оптимистичного сценария контроллер памяти фина должен каждым тактом знать адрес следующего читаемого слова. Тогда затраты на выставление следующего адреса будут прятаться по мере вычитывания предыдущих. Однако затраты на открытие следующей страницы памяти, пречарджи и регенерацию никуда не денутся. При длинне бурст в одно слово можно получить порядка 85% (не могу ручаться за абсолютную точность цифры - давненько все это было) пропускной способности при чтении даных линейными большими чунками. Если же случится, что паттерн чтения будет несколько другой, то от пропускной способности может остаться один пшик. Даже 85% пропускной способности подсистемы памяти должно за глаза хватить для RGB 1024x768x50, поскольку суммарный поток составляет всего 56,25MB/s. PPI порта также должно хватать, поскольку есть еще ~6.5% запаса по пропускной способности. Однако в Киеве также упоминали о не 100% эффективности внутренней периферийной шины. Похоже, затык происходит именно в ней. Потому двойная буфферизация здесь возможно не поможет. Как вариант, можно попытаться данные хранить в памяти в 4:2:2 YUV формате и интерполировать их непосредственно перед выводом в PPI порт. Я подозреваю, что современные видеокарты используют 4:2:2 YUV по похожим причинам.

Вообще говоря, есть у Cignal'а такой себе аппнот, в котором они описывают USB радиоприемник. На чип самого приемника документацию пока получить не удалось, но для ваших целей это и не требуется. В аппноте описан цигналовский МК, ацепирующий данные от аналогового FM приемника и отправляющего их на комп по USB для проигрывания. По идее, начать можно с этой стороны. 6 мбит для USB это даже не вопрос, так что с этой стороны все должно быть нормально. Точность АЦП/ЦАП преобразований может быть проблемой.

Это в общем-то напоминает ситуацию с процессорами лет на 15 раньше. Тогда, в эпоху 286 машин все, что надо было делать быстро писали на Ассемблере, потом появился МакроАссемблер - некая переходная грань между языком совсем низкого уровня и начальным уровнем абстракции, потом появились сравнительно "умные" компиляторы с языков высокого уровня. Так и в FPGA. Сначала языки программирования просто отмечали связи между физическими компонентами на кристалле - очень маленькая и предельно быстрая реализация алгоритмов - естственно, в пределах компетенции разработчика. По мере развития алгоритмов размещения и трассировки стало возможным понизить специфичную квалификацию разработчика и повысить абстракцию процесса - переход на уровень поведенческих описаний на VHDL или Verilog. Синтезированная схема занимет места немного больше, работает не так эффективно, но времени на разработку устройства тратится значительно меньше. Дальше будет SystemC - практически полностью абстрактный язык описания схем. На сегодняшний день получаемое быстродействие весьма посредственное, количество ресурсов - значительное, но скорость разработки значительно выше. Я думаю, что по мере роста ресурсов в FPGA все большая и большая часть проектов будет разрабатываться на SystemC и лишь высокоскоростные блоки будут все также писаться на поведенческом VHDL или Verilog. Такая практика повсеместно используется в разработке програмного обеспечения и дает наилучшее сочетание цена/производительность получаемых решений.

Ну 32-разрядную SDRAM память от Micron с производства уже сняли, а остальное можно попытаться поискать на www.efind.ru. С XC3S1500 FG-320 будут небольшие проблемы со стоимостью, поскольку в единичных количествах такие чипы практически не поставляются, а потому придется переплачивать. Ничего не могу сказать о TMS320. Даже не пытался его никогда покупать. А вообще, к такому вопросу неплохо указывать регион в котором планируется проводить закупку компонентов.

В этом и весь вопрос. Просто необходимо адекватно подходить к выбору чипов и пассивных элементов обвески и проблем не будет. По определению блокировочный конденсатор должен быть максимально близко расположен к ножке микросхемы или соединен с ней очень малоиндуктивным проводником. К сожалению второе под BGA корпусом выполнить проблематично, поскольку полигоны оказываются сильно "порваны" переходными отверстиями.

Угу, а конденсаторы, небось, 0603 юзаем, дабы доставать легче да и паять руками проще - так? В этом и заключается проблема с этим подходом. Если делаете плату на таком BGA то позаботьтесь о соответствующей остальной элементной базе. Конденсаторы 0402 легко ставятся прямо между выводами BGA корпусов с шагом 1 мм. В нашем конкретном случае есть положительный опыт разводки Virtex 4 в 672 ногом корпусе - не 1152 шарика, но проблемы сопоставимы. Сложность ручного монтажа 0402 конденсаторов также переоценена. Ответственно могу сказать, что они монтируются обычным паяльником с тонким жалом без особых проблем.

А если навставлять регистров почем зря, то очень сложно будет добиться адекватной производительности :( К сожалению, PCI ядро, особенно мастер, это такой себе огромный клубок компромисов, которые очень сложно соблюсти без наличия достаточного опыта :( 2 buggy Ну, зависаете вы потому, что устанавливаете answer по любому падению на irdy в нуль. Это в свою очередь приводит к появлению логического нуля на trdy и devsel. Так делать нельзя. Прежде чем включать драйвера на trdy и devsel необходимо быть увереным, что транзакция направлена именно вам. Далее - включить tri-state и задрайвить нуль на выходную шину - очень дохлое занятие - все тайминги идут лесом. Надо включать tri-state, драйвить на нем '1' и только следующим тактом выводить '0'. Это касательно trdy и devsel, аналогично необходимо поступать и с шиной даных. В литературе данный прием по отношению к AD шине называется adress/data stepping. P.S. Не хочу сбивать ваш боевой настрой, но исходники полнофункционального PCI master ядра на 33MHz в нашем исполнении занимают "всего" 170kB, не считая тест-бенчей, на их написание был потрачен почти месяц рабочего времени двух инженеров с несколькими годами опыта в разработке цифровых схем, их окончательная отладка заняла еще 2 недели. Может, вам попытаться упростить себе задачу? К примеру, ограничиться однотактными пересылками по шине? Не реализовывать мастера? P.P.S. Неиспользуемые выводы достаточно драйвить константным 'Z' - конфликтов на шине не будет.

Если вдаваться в тонкости, то 3) не совсем правильно. Драйвить один сигнал из нескольких процессов можно при условии, что активный уровень - '0' или '1' выставляется только в одном из процессов. Остальные должны выдавать нечто типа "слабая единица", "слабый нуль" или "hi-z". К стати, совершенно не вижу никаких проблем с синтезируемостью данной конструкции - все выше перечисленные примитивы есть на выходных буферах современных FPGA, а некоторые семейства от Хилых и вообще имеют внутренние tri-state драйверы.

Если уж растекаться мыслью по древу, то проще сделать мажоритарную схему на трех корпусах памяти ;) Будет гораздо проще и гораздо надежнее, нежели всякие схемы контроля ошибок :)

Вот потому человек и собирается использовать CPLD ;) CoolRunner II использовать не стоит, поскольку он есть урезанная FPGA со встроенным флешом. Хилые тоже умеют контроллировать целостность своей конфигурационной памяти. Сам с этим близко не работал, однако знаю, что это возможно. 2 araglin: Поскольку память выбрана ассинхронная, то будут серьезные проблемы с тем, чтобы прикинуться чипом памяти для внешней системы, пусть и с четырьмя дополнительными выводами. Чтобы прикинуться памятью придется сформировать контрольную сумму по восьми битам за 2ns - это просто очень круто для CPLD. Иначе необходимо вводить корректировку в алгоритм работы блока памяти - выставлять данные заранее, а лишь потом выставлять адрес и сигналы по записи, что уже нарушение таймингов, рекомендованых производителем. Впрочем, выбор синхронной памяти все равно ничем не поможет - все равно будут необходимы такты для перемещения даных между стадиями конвеера.

Stratix II и Cyclone II - два очень разных чипа. altclkctrl - есть просто абстракция на кусок кремния физически присутствующий в кристалле FPGA. При его проектировании были заложены определенные принципы функционирования и обойти их не возможно - в кристалле просто нет соответствующих роутинговых ресурсов. К слову сказать, тактовые ресурсы в Cyclone II спроектированы не самым оптимальным образом. К примеру, PLL нельзя каскадировать, опроной частотой PLL может быть только тактовый сигнал, физически заведенный на определенный пин, для разных PLL эти пины разные и так далее. Вывод - необходимо аккуратно изучать принципы функционирования выбранного кремния дабы не заложить в схему физически нереализуемых решений.

По поводу овершотов и андершотов у Хилых был некий аппнот или white paper - сейчас уже не вспомню. Там было популярно разъяснено, что даже если кламп-диод и не выгорает сразу, то это все еще не решает проблему, поскольку при длительной работе в таком режиме деградируют и со временем выходят из строя выходные транзисторы выходного каскада. Т.е. получается такая себе мина замедленного действия - устройство отработало полгода-год и все, дальше начинает сбоить или вовсе перестает работать. Потому, если планируется серийное производство к вопросам согласования необходимо подходить со всей возможной ответственностью. Всецело поддерживаю Paul - при серийном производстве необходимо полностью понимать режимы работы схемы и взвешивать возможные риски связанные с экономией на слоях разводки, блокировочных конденсаторах или последовательных терминаторах.

Этого делать не нужно. Просто необходимости в этом нет. Ну увеличите вы сетап на адреса/данные на сотню пикосекунд, но при окне семплирования в 3-4 наносекунды это существенно никак не отразится. О прецезионном выравнивании дорожек необходимо начинать заботиться для DDR памяти при рабочих частотах порядка 266MHz и выше - там это реально необходимо, поскольку там окно семплирования сужается до 1.5-2 наносекунд и задержка в 100 пикоскунд становится уже заметной, особенно в пределах одной группы.

Выглядит так, что растояние между слоями у вас составляет 10 mil. Ориентировочно, разводку придется выполнять дорожками по 10 mil или немного шире - могут быть проблемы при плотной упаковке корпусов на плате. Еще, такой дорожкой вы вряд ли пройдете между ногами TQFP корпуса - могут быть сложности с трассировкой.

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

Полученный сигнал практически идеален, только частота в вашем случае 100MHz, а не 133 ;) Шучу, поскольку для согласования линий частота в вашем случае не критична. При моделировании обязательно необходимо ставить вопрос о чистоте эксперимента и соответствия реальности выбранной модели. Иначе HyperLynx покажет замечательные результаты, а в реальности будет кака. По поводу конкретно разводки - думаю, что сигнал на таких частотах обязательно должен иметь референсную заливку под ним и/или над ним. Более того, HyperLynx не умеет считать импедансы дорожек, если они не имеют под собой никакой заливки. По выбору слоев для разводки - линии данных лучше располагать по верхним слоям только потому, что вам не надо будет ставить переходные отверстия для выхода на контактные площадки согласующих резисторов. Во всех остальных смыслах никаких предпочтений по слоям для разводки линий данных нет. Шинную топологию по разводке сигналов управления я посоветовал из собственного положительного опыта - у нас шина работает и не сбоит. Правда, еще не в серии.

33 Ома сборки - это для плат с дорожками с волновым сопротивлением порядка 50 Ом. В современных реалиях - слабодостижимая цифра - слишком уж много слоев на плате получается ;) С приемлемыми технологическими нормами и разумным количеством слоев (не более 6 или 8) импеданс на внутренних слоях получается в районе 65-70 Ом и немного меньше на внешних. Потому сопротивление резисторных сборок возможно надо будет увеличить. Особо аккуратно следует разводить шину данных - лучше по одному слою, максимально компактно, подальше от чувствительных к помехам цепей. Микроновский выходной драйвер - это дюже мощная штука. Всякие прелести с овершотами и андершотами с ними практически неизбежны. В следствие этого следует очень серьезно отнестись к блокировочным конденсаторам и разводке земли. Иначе словите очень трудно детектируемый ground-bounce. Это когда все работает хорошо, но при определенной комбинации бит на шине начинает сбоить Разброс длин дорожек в вашем случае менее чем критичен. Окно семплирования на 133MHz составляет порядка 3-4ns, что достаточно для компенсации практически любого разумного разброса длин между трассами. Шина управления требует гораздо менее пристального внимания к себе. Сложности в вашем случае могут возникнуть из-за шинной топологии - каждая дорожка должна идти к двум корпусам. В принципе, ничего особо страшного здесь нет, но попытайтесь сделать их длинну минимальной. Как показывает опыт, согласование управляющих линий резисторами не требуется, память имеет неплохие запасы по овершотам и андершотам, а работа на две нагрузки дополнительно улучшает ситуацию. Однако следует проконсультироваться с мануалами производителя на процессор - возможно его драйвера тоже сделаны с большим запасом по мощности. Разумный разброс длин в этом случае тоже не критичен. На сколько я понимаю, с ОЗУ работает только процессор. Вы же не пытаетесь обучить ACEX 1K50 работать с SDRAM на частоте в 133MHz?

Деление - это самая большая головная боль в проектах на FPGA. Остальные простейшие арифметические операции (суммирование, вычитание и умножение) реализуемы, хотя все зависит от входных разрядностей и рабочих частот. Реально, существует несколько библиотек деления в FPGA - названий не помню, потому пользуйтесь поиском, однако любая из них либо слишком медленная, либо создает абсолютно неприемлемый делитель размером под тысячу логических функций, либо требует большого и нефиксированного числа тактов на выполнение операции. Так обстоят дела с делением на нефиксированную константу. Деление на фиксированную, или загружаемую константу аппроксимируется умножением. R = Y / X трансформируется в R = (Y * K) >> 16, где K = 65536 / X + 1 Подробнее об аппроксимации лучше почитать у классиков жанра, на пример, "Алгоритмические трюки для программистов", Генри Уоррен, младший. Входным параметром для SHR есть bitvector. Не самый распространеный тип представления данных в VHDL. Гораздо проще снять информацию с тех битов, которые вас непосредственно интересуют без формального использования SHR или SHL. За все мое время использования VHDL мне только один раз пришлось использовать SHR и SHL - это было синтезируемое описание баррел-шифтера.

Огромное спасибо за информацию ;) Будет теперь чем заняться длинными зимними ночами ;)

Это не совсем так... Дело в том, что деблокинг в H.264 встроен внутрь дифференциального цикла непосредственно перед блоком компенсации движения. Доподлинно известно, что изображение, обработанное деблокинг-фильтром имеет более высокую степень сходства с оригиналом, а значит является более "правильным" источником для алгоритмов компенсации движения - вот вам и реальное увеличение степени сжатия видеоряда. Для MPEG4 в качестве референса я использовал реализацию XVID. C ней и сравнивал свои результаты по степени компрессии. А где такая штука берется для H.264? Существуют ли open-source кодеки, реализующие этот стандарт кодирования? На сколько я понимаю - референсная реализация включает только декодер - верно?

Буквально сегодня разговаривал с представителем компании Альтера по нашему региону. Если по простому - то Stratix не рассчитаны на массовые устройства, а потому стоить дешево не будут - просто незачем. Еще ему было очень интересно понять, почему я считаю, что Virtex по потребительским свойствам лучше чем Stratix ;) К сожалению времени детально обсудить эту тему у нас не хватило.

В MPEG4 есть предсказание по предыдущему и следующему кадрам. Похоже, это ему не сильно помогает, поскольку размеры кадра все равно остаются большими. Был бы дико благодарен за копию стандарта, если возможно. Очень хотелось бы прояснить некоторые тонкости реализации кодирования. Особенно интересуют вопросы внутрикадрового предсказания. Если я правильно понял, то они предказывают текущий кодируемый блок на основании нескольких предыдущих, чем существенно уменьшают энергию картинки даже без межкадрового предсказания. Еще интересный вопрос по поводу деблокинга. Из того, что я видел выглядит очень интересно. Да и ресурсов требует немного. Ричардсон рассказывает много о том как это делается, однако не дает деталей. Был бы дико благодарен за копию стандарта, если возможно.