v_mirgorodsky

Кто знает как можно увидеть сие чудо забугорной мысли? Книгу Иана Ричардсона я уже прочитал. К сожалению изложенной там информации не достаточно для составления целостного представления о сжатии изображений при помощи H.264 - опущено очень много подробностей. В Интернете тоже можно найти некоторые разрозненные куски информации, страдающие тем же недугом, что и книга ;) Хочется понять как H.264 добивается такого превосходства над MPEG4 по размеру сжатого файла. Вот и вопрос - нет ли у кого копии стандарта на посмотреть?

А есть ли возможность приобрести одно из сих чудес в розницу в Киеве? И каков примерный диапазон цен на такой датчик? Просто хочется сделать некий индикатор необходимости проветривания помещения. Если летом окна практически всегда открыты, то зимой холодно и убедить несколько человек в необходимости проветрить комнату бывает сложно. А так будет надежный аргумент в споре ;)

Собственно, $subj ;)

А вы попытайтесь его еще по частоте "нагнуть" почти до насыщения выбранного семейства, и удовольствие превратится в ниже среднего - будет тех самых 20 минут а то и больше. Да и используемый вами Stratix это все таки машинка немного другого порядка нежели Cyclone II. Если я правильно вас понял, то никаких фичей типа инкрементальной компиляции или back-annotation использовать не получается? Жаль, поскольку в документации обещают серьезное уменьшение времени компиляции без ухудшения результатов.

Так 64-битный Квартус дает существенный выигрыш по быстродействию? А под какой ОС собираете? У нас тоже можно добиться 10 минут, если повыключать оптимизацию Квартуса - особенно много занимает комбинаторный ресинтез и ретайминг регистров. Однако проект после этого не работает на требуемых частотах. У нас используется самый медленный чип семейства, а рабочие частоты все в районе 130MHz. Вот и приходится извращаться с оптимизацией и ресинтезом. У нас проект синтезированный с VHDL Квартусом разгоняется до 125MHz, то же самое после Synplify - 130 с лишним. После имплементации Quartus only занимает в среднем на 5-10% ячеек больше, чем после Synplify. Ну не умеет Quartus нормально синтезировать VHDL :cranky: Устройство большое, или скорее, разноплановое. Обычно мы стараемся в одном файле размещать не более одного entity, но даже и в этом случае средний размер файла редко меньше 10-15kB - ну болтливый язык VHDL - ну что с ним сделаешь ;) Может быть он и маленький, но опыта работы с более крупными у нас еще не было. Потому и пытаемся научиться.

RandI, а можно поподробнее? Очень уж интересная тема. В каком КАДе необходимо разводить плату, как указывать активность тех или иных элементов на схеме/плате?

Есть ActiveHDL 7.1, Synplify 8.4 и Quartus 5.1. Все это хозяйство используется для создания firmware для EP2C8F256. На ранних стадиях проекта все было хорошо, поскольку синтезировались/компилировались только небольшие части всей системы. Ближе к завершению все больше и больше блоков подключается в финальную сборку для отработки вопросов совместного функционирования в пределах всей системы и все больше и больше времени уходит на компиляцию. Проект, как обычно, затянут констрейнами по самое "не могу". Синтез Synplify занимает, обычно, до 5 минут, раскладка в чип Quartus'ом - еще 20 минут. Попытки включить инкрементальную компиляцию в Quartus приводят просто к невыполнению требований по рабочим частотам. В теории, с этим можно было жить - сильно страдает эффективность работы, но сама работа не останавливается. Однако пару часов назад Synplify "подарил" еще один подарок. На пятом десятке исходных файлов он начал ругаться на переполнение внутренних таблий маппера и вылетать с критической ошибкой. Попытка синтезировать части проекта Synplify, а окончательную сборку производить самим Quartus из ранее генеренных VQM ни к чему не привела - VQM пересекаются по именам используемых примитивов, а это в свою очередь выводит Quartus из душевного равновесия. Конечно, можно ручками поменять названия нескольких примитивов в VQM'ах и добиться сборки проекта, однако это отнимает значительную часть времени и не всегда безопасно, поскольку контекстный поиск и замена одних имен на другие может сработать не правильно. Да и сборка проекта из VQM результируется в увеличении занимаемых ресурсов, поскольку Quartus все же не так эффективно вырезает "лишнюю" логику из проекта. Что-то подсказывает, что мы что-то делаем неправильно. EP2C8F256 - не самая большая микросхема, а рабочая станция на P4 3GHz с гигом памяти на борту не самый медленный компьютер. Во время компиляции Quartus использует порядка 800МБ памяти и дисковый своп не трогает, т.е. на данном этапе увеличение количества памяти ни к чему не приведет. Использование двухпроцессорных конфигураций также бессмысленно, поскольку компиляция в Quartus однопоточная. Возможно, ситуацию может улучшить новый Core 2. Изучая его микроархитектуру в своей программистской ипостаси мне очень понравились его растактовки по машинным инструкциям и возможностям параллелизма вкупе с внеочередным исполнением инструкций. Да и мой кодек, оптимизированный под P4, показал более чем двойное увеличение увеличение производительности на Core 2 на каждом ядре. Может и Quartus'у с Synplify'ем полегчает? Вот, собственно, и вопросы: 1. Кто как борется с большими проектами - более 6-7 тысяч логических ячеек для чипов Altera? 2. Кто какое железо использует под разработкой и есть ли реальные впечатления от использования Core 2? 3. Как помирить Synplify с большим количеством файлов исходников?

Все делается именно так. GUID берется из заголовочных файлов или из библиотеки guid.lib - если мне память не изменяет, то называется она именно так. На ходой конец можно просто захардкодить GUID в текст поскольку он однозначно меняться не будет.

Ну, это просто. Контроллер для SDR SDRAM несколько проще, SDR SDRAM требует только одного питания и DDR SDRAM экономит только пины на устройстве, ничего по скорости она не добавляет. IMHO, DDR память получит широкое распространение тогда, когда появится достаточное количество 2.5В периферии. На данный момент это самая большая проблема, поскольку надо разделять банки на ПЛИС, городить дополнительные источники питания и т.п. В наших реалиях, когда за минимальные деньги надо слепить устройство с максимальными характеристиками - это не допустимо.

Имел опыт сотрудничества с вышеупомянутой компанией. Ушел от них немного меньше года назад в следствие регулярных и длительных задержек заработной платы.

Есть немного нестандартное использование пинов Cyclene, если говорить о PCI. В нашем случае было EP2C8F256. Так на один из глобальных клоков был заведен PCI_CLK, на второй - ресет, а на третий - IDSEL. PCI_CLK действительно может плавать по частоте. По спецификации в сторону уменьшения, вплоть до DC, в реале не изменяется. Были старые матери, на которых можно было наблюдать фокусы с PCI_CLK до 41МГц, но сейчас вы таких уже не найдете. Скоро приедет плата - попробую растолкать PLL с PCI_CLK - о результатах сообщу ;)

вроде бы parts per million - частей на миллион, хотя смысл и так понятен. :) А можно немного поподробнее? Частей чего на миллион? Если у меня есть кварц на 10МГц, то его точность в 50ppm/°C что значит? ±500Гц на градус Цельсия или что-то другое? P.S. Sorry за чайниковский вопрос, просто необходимости разбираться с этим по роду деятельности не было, а узнать хочется.

Я совсем небольшой спец в вопросах передачи информации по радиоканалам, но имею впечатление, что в ТТХ охранной системы RS-202 в предыдущем посте вкралась досадная ошибка порядка этак на 2. На сколько я знаю, мощность электромагнитной волны ослабляется обратно пропорционально квадрату растояния от источника излучения. Таким образом при удалении источника излучения на 100 километров базовая станция должна различать сигнал мощностью порядка 10^-12 Вт, что значительно меньше уровня собственных тепловых шумов известных пассивных и активных компонентов ;) Я где-то неправ?

Сожалею :( Это очень крупная тема :( Могу попытаться ответить на какие-то конкретные вопросы, но рассказать на что обращать внимание просто очень сложно, поскольку обращать внимание необходимо на все. Ваша проблема, возможно, имеет корни в недостаточности блокировочных конденсаторов возле пинов питания или в их отсутствии. Возможно слишком тонкие дорожки питания. К стати, можно попробовать кинуть к пинам питания просто несколько толстых проводочков от блока питания просто навесным монтажем. Это поможет перекантоваться на первое время. Дальше разводите плату. Ресурсов по разводке есть очень много. Однако они в целом очень часто противоречат друг другу, поскольку разводка печатной платы - это умение найти компромис между противоречивыми требованиями. Это умение приходит просто с опытом. Потому не бойтесь, если вы читаете противоречивые рекомендации в разных источниках. Просто разные люди ставят во главу угла разные требования к разводке и используют разные стратегии. Удачи вам на этом нелегком пути :)

А кто пробовал посмотреть на контроллер SDRAM от Филлипова? Несомненно - рабочее устройство - это рабочее устройство. Оно доказывает работоспособность всех его компонентов. Однако это абсолютно не доказывает, что взяв отдельный кусок кода из прошивки Филлипова можно по его образу и подобию сделать что-то свое. Код Андрея Филлипова отличается крайней оптимизированностью под его конкретную задачу. Его просто так переиспользовать не получится, придется конкретно перерабатывать. Плюс, необходимо помнить о GPL лицензии. Использование любой части кода под GPL лицензией требует публикации исходников всего устройства :( Коеффициенты, приведенные уважаемым Golikov A. действительно целочисленные и не требуют никаких аппаратных извратов для своей реализации. Однако при внимательном изучении стандарта на JPEG2000 можно заметить, что использование этих фильтров рекомендуется только для безпотерьных реализаций, поскольку изображение, разложенное по этому базису и отквантованное может содержать дополнительные артефакты. Для работы в loosy режиме рекомендованы фильтры Добеши, обеспечивающие более качественную картинку для сжатия с потерями имеют нецелые коеффициенты в количестве 15 штук. Вот тут все и начинается.

На 100 MHz вы видите только средние уровни сигналов, поскольку реальные выбросы находятся гораздо выше. Плюс - их убивает емкость щупа осциллографа. По характеристикам осциллограф похож на младший Tektronix - угадал? В черной магии для измерения шумов и прочих артефактов на входных сигналах использовали осциллограф с пропускной способностью канала порядка 4-5GHz. Для того, чтобы проверить предположение о ground bounce необходимо запустить выходную шину на циклическое постоянное переключение из всех нулей во все единицы и оставить ей ту же нагрузку на выходах, как в рабочем режиме. Если есть этот глюк, то счетчик засбоит гораздо чаще. Если частота сбоев не изменится, то надо искать проблему в клоковых сетях.

По поводу 1) - ситуация вполне нормальная. Драйвера потребляют практически фиксированный ток, а пики потребления во время переключения выходов и на перезарядку емкостей на нагрузках обычно сглаживаются блокировочными конденсаторами. Да и обычными средствами зарегистрировать эти пики весьма сложно - фронты у Cyclone очень крутые, а значит токовый "всплеск" будет очень коротким. Рост потребления по IO питанию можно сделать нагрузив часть выводов просто на емкостные нагрузки ;) По поводу 2) - ничего определенного сказать не могу :( Странно :-\ Одно можно сказать с уверенностью - это не статика. После статики устройство не оживает, т.к. происходит невосстановимый пробой структур в кристалле. По поводу 3) - cчетчик может сбоить если на клоке есть некоторая "борода". "Борода" на клоке является следствием несогласованности волновых сопротивлений линии клока и драйвера. Распространенное мнение, что низкочастотные клоки согласовывать не надо - ошибочно. ADSP может генерить весьма крутые фронты сигналов на своих выходах, а Cyclone вполне в состоянии по быстродействию трактовать это как двойной импульс. Если используете TQFP корпус, то возможно столкнулись с ground bounce - весьма неприятная штука - возникает как следствие плохой разводки шин питания на двухслойных платах. Обычно проявляется как double clocking при переходе всей или большей части шины данных из одного состояния в другое. Например, из всех нулей во все единицы.

Угу, с вейвлетами все выглядит просто до тех пор, пока нет достаточно жестких требований по скорости и по количеству используемых ресурсов. Как только надо поместиться в выбранную FPGA с определенным быстродействием так сразу и начинаются танцы с бубном, поскольку внутренней памяти мало, а изображение большое. Таким образом для полнокадрового вейвлета изображения в разрешении 720x576 необходимо выполнить каких-нибудь 14 миллионов умножений для пяти уровней декомпозиции. Далее умножаем это дело на три для каждой цветовой плоскости и получаем абсолютно нетривиальную задачу по управлению пинг-понг буферами и остальными обслуживающими структурами. После этого стоит вспомнить, что 720x576 это очень маленькое разрешение и что реально возникает необходимость обработки гораздо более "мегапиксельных" структур. Учитывая вышеизложенное, не получится сделать желаемое малой кровью :) Все равно помучиться придется очень серьезно.

Поищите по форуму... Ссылки точно есть... _http://www.elphel.com/ - это исходная страница пректа. Все остальные материалы, включая гербера, можно найти по ссылкам с сайта.

Задача выглядит очень простой и стандартной :) Для ее решения достаточно "задержать" входные данные на n тактов на регистрах, принять все необходимые решения за эти такты и скорректировать направление движения потока. Если вычисления требуют значительных временных затрат, то можно поставить FIFO, если одного-двух тактов достаточно, то проще поставить пару регистров. Подобного плана задачи возникают с высокоуровневыми протоколами. Как обычно, нужное поле находится десятком байт позже от начала пакета и решение об обработке пакета может быть принято только после инспекции этого поля. n-ти сатдийный конвеер в этом случае является одним из приемлемых решений проблемы. Подобное решение очень хорошо ложится в Xilinx, потому как сдвиговые регистры в этой архитектуре сравнительно дешевы.

На практике эти резисторы можно вообще не ставить. По крайней мере существует реально работающий дизай от Андрея Филлипова и у него резисторов подтяжек к VTT нет. При симуляции картинка получается вполне приемлемая. Главное, чтобы overshot и undershot не достигали критических величин для SSTL режима работы выводов.

Предлагаю ввести наказание (вплоть до пожизненного бана) за любое публичное обсуждение действий администрации форума. Дополнительно предлагаю ввести наказание за флуд и несодержательные сообщения. А еще запретить гостям создавать сообщения. Люди! Вам ничего не должны! Модераторы и админы в свое личное свободное время тратят свои силы и деньги на поддержку форума. Админы и модераторы форума видят действия друг друга и не допустят действий одного из них, направленных во вред форуму. Если вы не удосужились прочитать Правила Форума и получили штраф - значит заслужили.

vetal А для какого семейства и какая версия Synplify? Мы столкнулись с проблемами при синтезе под Altera EP2C8F256-C8. В то же время под Xilinx или под Stratix синтез проходит без особых вопросов.

Synplicity FPGA Synthesis Reference Manual и так стоит в закладках :) И его внимательное изучение не всегда помогает избежать проблем :( В ходе обсуждения возникло несколько вопросов. 1. А как подключить Synplify библиотеки временных параметров для аппаратных макросов? На пример, где указать что в проекте используется та же altsyncram или что-то подобное? des00 буду очень признателен за ссылку на тему, в которой это обсуждалось. 2. Кто и как борет проблему окончательной сборки проекта из VQM модулей? Мы попытались поставить два VQM'а в проект, так Quartus нашел в них одинаковые имена элементов и сказал, что это лажа. Пришлось открывать нетлист и ручками патчить имена. Однако такой подход вряд ли можно назвать оптимальным для больших проектов. В то же время создать из нескольких VQM один большой VQM Synplify не умеет :( В то же время VQM'ы созданные самим Quartus не содержат пересекающихся имен.

vetal @W:MT246 : blah_blah.vhd(95) | Blackbox synplicity_altsyncram5_r_w_blah_blah is missing a user supplied timing model. This may have a negative effect on timing analysis and optimizations (Quality of Results) Это сообщение с вариациями можно видеть всякий раз, когда устанавливаешь память в дизайн. При этом этот идиот считает, что этот самый BlackBox имеет чуть ли не константный выход и выполняет оптимизацию - ретайминг и пайплайнинг исходя из этого предположения. При этом начисто игнорирует факт использования/отсутствия выходного регистра внутри самого блока памяти. С констраином "block_ram,no_rw_check" - знаком. Однако работает он только для Xilinx, для Altera надо ставить "M4K,no_rw_check". Теперь об памяти с ассинхронным выходом и внешней линейке регистров по выходу. Quartus, по возможности, "втягивает" их внутрь блока памяти, что приводит к значительному приросту скорости и уменьшению внешней логики. А пробовал ли кто раздельно управлять енейблами входного и выходного регистров памяти? Или память с разной шириной по разным портам? В большинстве случаев Synplify рассказывает, что блок памяти слишком сложный и заменяет его на туеву хучу регистров и потом плачет, что дизайн не помещается в кристалл. А чего стоит вот такой варнинг: @W:BN116 : blah_blah.vhd(95) | Removing sequential instance mem_38 of view:PrimLib.dff(prim) because there are no references to its outputs хотя все выходы памяти использованы и работают, что было подтверждено симуляцией и работой реального устройства. Или такой случай. Строили мы гистограмму непрерывно поступающих данных. По выходу памяти с выходным регистром стоит mux 3-в-1, 18-ти разрядный сумматор с единицей и после сумматора mux 2-в-1, короче сумматор с насыщением. При начальном продумывании схемы был собран макет арифметики между регистрами. Ретайминг запретили, засинтезировали и имлементировали - скорость работы схемы более 150MHz. Написали блок, поставили реальную память - меньше 130. Просто в первом случае Synplify ответственно подошел к синтезу этой логики, а во втором посчитал память константным выходом, показал при синтезе скорость около 180MHz и расслабился. Скоростные параметры выходного регистра памяти позволяют ему функционировать на частотах до 180MHz - т.е. дело в неряшливом синтезе. К слову сказать, для Xilinx Spartan 3E скорость работы блока не превышает 86MHz :( В приципе не могу понять такую разницу в скорости :maniac: Код полностью RTL, никаких проблем при синтезе под Spartan не было. Mad Makc Уложить умножитель в сам DSP блок нет никаких проблем. Только вот попробуйте попереключать знаковые/беззнаковые умножения на ходу, поиспользовать внутренние входные и выходные регистры самого умножителя с их енейблами и все станет понятно. Умножитель, как ассинхронную структуру, он использует, регистры к ней прилепит внешние и покажет скорость порядка 62MHz, хотя реально дизайн разгоняется до 162MHz. Было бы не обидно, что он так делает, если бы он остальную часть схемы возле умножителя синтезировал в соответствии с заданными временными требованиями, а так он говорит, что 62MHz - это предел и не оптимизирует расположение остальных компонентов схемы, что результируется в проблемах при имплементации дизайна в кристалл. Пока Quartus не умел делать ресинтез и ретайминг приходилось эти цепи выносить в игнор, разгонять остальную часть схемы и лишь после этого получался приемлемый результат. P.S. Для тех, кто не знает - 162MHz - это предельная частота работы умножителей в EP2C8F256. Просто было необходимо разогнать эту часть схемы по максимуму. --------------------------------------------------------------------------------------------- Я понимаю, что начальный вопрос, возможно, показался чайниковским, однако проблемы с синтезом c Synplify все же существуют и решений для них Synplicity не предлагает. Эта лабуда уже тянется несколько последних версий Synplify. Каждый раз когда я скачиваю новый билд, я надеюсь, что все уже поправили, однако при запуске все оказывается также плохо, как и в предыдущих версиях. Вот потому и возникла идея перейти на сопоставимый по качеству синтеза продукт, но не глюкавый, как Synplify. Потому и спрашиваю о менторовских продуктах. Может у них получше с выше описанными аспектами, а качество синтезированного кода сопоставимо ? Quartus очень погано синтезирует VHDL. Все еще не умеет распознавать RTL описание памяти, имеет проблемы с функциями и разрадностями параметров. Проект после Quartus'а занимает обычно больше места и работает намного медленнее. Однако Quartus по уже синтезированному нет-листу очень неплохо справляется с доводкой до требуемых параметров по скорости, ретаймингом и ресинтезом ассинхронных цепей. Так и работаем - синтезируем Synplify, потом затягиваем параметры Quartus'у по самое немогу и получаем приемлемый результат. К сожалению, глюки Synplify мешают картине быть совсем идеальной, однако такой подход себя оправдывает. С ужасом ожидаю полной сборки проекта - по прикидкам чип будет забит процентов на 90 :(