v_mirgorodsky

Мы будем подключать к VCCINT, потому как миграционные пины в меньших чипах обычно NO CONNECT. Таким образом никакой неопределенный уровень здесь возникнуть не должен. Как будут живые платы - поделимся впечатлениями :)

Вот меня всегда интересовал вопрос, на сколько можно считать эти клоки синфазными ? Ведь все равно разбег по фазе будет, хотя по идее Xilinx смело рекомендует дробить блоки на клок домены, но при этом ничего о согласовании фаз клоков не говорит. Или я что не так понимаю :glare: Угу, и правильно не говорит :) Синтезатор вместе с PAR'ом умные, если и есть небольшой разбег фаз, то он остается постоянным и может быть легко учтен при вычислении setup/hold триггеров, работающих на границах клоковых доменов :cheers: Оба клока генерятся одним блоком. BTW, Xilinx DCM позволяет компенсировать задержку от входного пина до входа DCM, эффективно выравнивая фазы тактовых сигналов внутри и вне микросхемы. Если включить его в такой режим, то его выходы CLK0 и CLK2X должны удовлетворять всем Вашим требованиям. Единственное что Вы теряете в этом случае - это одну или две глобальных плоскости, что в современных чипах не критично.

Всегда решали подобные проблемы через clock-enables. Да, получается high-fanout сигнал разрешения, однако он обычно триггерный, потому Synplify просто дублирует выходной триггер несколько раз, удерживая временные показатели на должном уровне. Еще одна неприятность связана с низкоскоростной частью схемы. Часть ее обычно не работает на столь высоких частотах и синтезатор начинает ругаться, однако этот момент при необходимости прибивается мультициклами. В результате получается абсолютно синхронный дизайн. В Вашем случае еще можно попробовать поднять частоту на DCM. Если моя память мне не изменяет, то DCM может генерить синфазные клоковые сигналы удвоенной частоты практически на шару. В этом случае даже clock-enables не понадобятся :)

Ну не был бы я так категоричен в данном вопросе ;) Пишут так КА :) Это называется полностью синхронный КА с регистровыми выходами. Несколько извращенный способ написания, но любители используют. К особенностям относится некоторая тормознутость реакции - 2 такта на реакцию на внешнее воздействие и полная синхронность выходов. Это все равно как в двухпроцессном описании поставить по регистру на каждый выход КА.

Добавлением Reset'а должно полечиться. У вас машина ходит по циклу s1-s8, выходя из s0 только в самый первый момент времени. В то же время Quartus очень плохо относится к начальной инициализации переменных, потому и выбргосил состояние s0, а все остальное оставил в соответствии с кодом. Короче, или добавьте s0 в цикл или добавьте синхронный или ассинхронный Reset.

Рассматриваются различные варианты построения системы защиты от копирования. Один из рассматриваемых вариантов - использование Secure FLASH Memory. Знает ли кто-нибудь механизмы защиты данного вида памяти ? Есть ли опыт работы и применения подобных микросхем в целях защиты устройства от копирования? Если да, то каких производителей?

Х-м-м, в теории - должно подняться, но Вам по идее 10GBit линк не нужен, если не все устройства будут работать одновременно, можно попытаться более аккуратно расписать потоки и желания обрабатывающих машин. По существу, все делали в ПЛИС, PowerPC не использовали, да и на таких обьемах и частотах от него будет проку совсем мало :( Самый быстрый PowerPC разгонится до 450MHz, таким образом 4.5 такта на байт, разрядность шины PowerPC - 64 бита, таким образом порядка 36 тактов на слово. В теории - вполне достаточно для поддержки вышеуказанной скорости, но не для поддержки любой из могущих работать на нем ОС. Можно еще заставить PPC формировать только заголовки пакетов, а данные пакетов лить из ПЛИС, однако такой подход потребует очень глубоких разборок с внутренностями ОС.

Занимались разработкой собственного коммуникационного интерфейса на Gigabit Ethernet Virtex4 FX. По тестам получили 120MB/s, использовали самописный протокол и самописный драйвер под Windows XP SP2. На трехметровом медном кабеле пакеты не теряются, потому с восстановлением проблем быть не должно. В Вашем случае все будет зависеть от растояния и ситуации с внешними помехами. 10 Gigabit порт в компьютере - забавно, а такие сейчас есть? А что Вы собираетесь делать с 1000 мегабайтов в секунду в компьютере? Даже простое копирование этого массива данных из одного места в другое сьест ВСЮ доступную пропускную способность памяти компьютера :blink: не говоря уже о том, чтобы сделать что-нибудь еще более осмысленное.

Доброго времени суток :) Есть такой вопрос. Разработано собственное 33MHz PCI ядро. Есть ACEX1K100 speed grade 3. При синтезе Synplify 8.2.1 показывает порядка 70-75MHz тактовую частоту всего этого добра при необходимых 33MHz. После раскладки Quartus 5.0 Fmax уменьшается на не критичных 5-10MHz, однако времена Setup/Hold для входных и выходных сигналов стандарту PCI не соответствуют. Попытки задать более жесткие ограничения на tsu/tso/th результатов не дали никаких. Просто большее или меньшее количество путей в отчете не выполняют заданные ограничения. При этом практически все входные триггера, на которые не выполняются ограничения просто разбросаны по всему кристаллу :maniac:. При "ручном" перемещении триггера к интересующему пину все приходит в норму по конкретному пути, однако очень не хочется выполнять всю разводку вручную. Есть ли способ как-нибудь объяснить Quartus, что задержка на входной сигнал должна быть не больше заданной? Тот же вопрос и о выходных сигналах?

Если не использовать нерегистрированные FRAME и IRDY сигналы, то Target забирает у пользователя "лишние" данные. Фактически регистрированные данные необходимо выставить на внутреннюю шину за такт до того как они попадут на шину PCI, а регистрированная реакция мастера на эту фазу данных - IRDY будет готова для анализа еще на такт позже. Это было бы ничего, если ограничить количество фаз данных по PCI до одной и после каждой давать дисконнект, но в данном случае это приведет к резкому падению производительности. Дело скорее даже не в скорости, а в самом факте необходимости использования нерегистрированных версий сигналов, что раньше никогда не практиковалось.

Есть еще интересная идея - назывется SMBus. Ставим небольшой контроллер с I2C интерфейсом и на новых Intel'овских материнках получаем все просто и без всякого гемороя. При этом работа по SMBus не зависит от того имеется ли прошивка в FPGA или нет. Единственный минус - нужны НОВЫЕ Intel'овские мамки :cranky:

Доброго времени суток :) Возникла необходимость разработки собственного PCI контроллера на FPGA. Есть несколько причин, по которым не подходят существующие решения и, надеемся, достаточно опыта для разработки собственного ядра. В процессе проектирования ядра выяснилась необходимость работы с нерегистровыми сигналами шины PCI. При этом необходимость диктуется не столько эффективностью работы контроллера, как самой логикой формирования выходных сигналов по реакции на входные воздействия. Весь опыт предыдущей разработки говорит о ошибочности такого подхода, но похоже, для решения синхронизации передачи данных по шине другой альтернативы нет. Камнем преткновения стали сигналы FRAME и IRDY. Реально входная Target машина просто не успевает управлять логикой пользуясь регистровыми версиями этих сигналов :maniac: Существующий контроллер от PLDA, который мы исследовали для ознакомления не имел входных регистров на эти сигналы, однако имел множество примитивов типа LCELL на различных стадиях работы с этими сигналами. Как мы думаем, они использовались для устранения гонок на сигналах :ohmy: В первом приближении для использования нерегистровых версий сигналов для машин, логики и всего остального необходимо ограничить время распространения сигнала от пина до входа триггера через остальную логику. Выглядит так, что по стандарту PCI на сигналы накладываются жесткие ограничения на Setup. Таким образом, если время распространения сигнала плюс Setup триггера меньше времени Setup шины, то все должно быть шорошо :cranky: Есть ли у кого опыт написания собственных PCI ядер и кто как решал выше описанные проблемы? Какие есть мысли по данному поводу? Хелп ас, плииииз, а то :smile3046:

Уже все так и сделали, но не сильно это помогло. Если поставить black-box, то все становится нормально, синтезатор не ругается, показывает нормальную частоту. Однако проблема оказалась в самих умножителях. 162МГц это для некоторых идеальных условий. Реально умножитель не хочет нормально работать если на вход его регистра подать комбинаторные сигналы. Можно конечно поставить перед входом еще один регистр, но это расточительно по ресурсам.

Есть следующая проблема: есть Sy*np*lify 8.2.1, в коде описан 18x18 умножитель, не интантиирован как элемент, а описан как операция умножения двух знаковых чисел. Это удобно для обеспечения переносимости кода на разные семейства микросхем. При синтезе этот Sy*np*lify выдает тактовую частоту порядка 86МГц. После имплементации решения в Cyclone II частота показываемая Квартусом достигает рассчетных 160МГц - скорости работы умножителя для восьмого Cyclone II. Пытались запретить анализировать собственно операцию умножения, обозвать ее false_path, объявить ее как мультицикл и т.д. Синтезатор упорно ругается на умножитель и не показывает реальную частоту работы схемы. В Technology Mapper стоит именно аппаратный умножитель с внутренними регистрами на входе и выходе. Знает ли кто с чем это может быть связано?

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

Да CABAC это Context-Based Adaptive Arithmetic Coding. Там сначла проводиться бинаризация входных данных, а затем бинарное кодирование с адаптацией конекста. Но алгоритм без деления, только сумматоры и сдвиги. Дико интересно :) А можно как нибудь посмотреть на описание алгоритма? Понятно, что деления можно заменить сдвигами, если делить на степень двойки, но как избежать умножения :cranky: Тут вы меня действительно озадачили :cranky: Мы будем реализовывать нечто похожее на то, что описано в той книге, о которой я говорил. Конечно, обращайтесь. Чем смогу - помогу, поскольку все равно будем работать по параллельной тематике :) Мыло у меня такое же как и мой ник на форуме "собака" yahoo (dot) com

А что вы подразумеваете под входным словом ? какова разрядность этой величины? 2-4 такта это на одном проходе ? В моем случае у меня на входе поток бинарны данных разядностью восемь или более бит. По входным данным строится гистограмма входных данных и подсчитывается их количество. Сами данные кладутся в память. После чего все коэффициенты масштабируются до шестнадцатибитной арифметики, данные подымаются из памяти и идет собственно процесс кодирования. Так вот, кодер на каждое входное восьмибитное слово тратит от двух до четырех тактов. Развитием идеи арифметического кодирования является идея интервального кодирования. Там нормализацию можно производить заметно реже, однако для ее реализации нужна 32-битная арифметика и 32-битные аппаратные умножители, что не реализуемо на FPGA на данный момент - у нас скорость входящих данных обычно составляет от 100 до 160 мегаслов в секунду - будем ставить 3-4 ядра кодирования и разбивать данные на блоки. К счастью, мы не реализовываем один из стандартных алгоритмов кодирования, потому нам легче в смысле представления данных и формы их кодирования. О CABAC ничего не знаю :( По тому что будете использовать контекстную модель - выглядит как адаптивный алгоритм :( Адаптивный алгоритм для 8-битных входных слов потребует после получения каждого слова пересчета таблицы вероятностей и редко - масштабирования. Самым не приятным в этом случае будет необходимость реализации деления на любое число. У нас на FTP лежит замечательная книга, правда на английском, Mark Nelson, The Data Compression Book. В ней можно почерпнуть множество информации о компрессии данных, в том числе и арифметическим способом.

Добро пожаловать в клуб. Фактически через пару недель мы тоже будем заниматься этой проблемой. Было решено заниматься двухпроходным алгоритмом, т.к. адаптивный алгоритм получается ОЧЕНЬ медленным. На данный момент отработали внутреннюю структуру и написали пару тестовых приложений на С++ для проверки идей кодирования. В первом приближении выглядит так, что на обработку каждого входного слова будет тратиться от двух до четырех тактов. Всего остального пока сказать не могу, потому как мы только собираемся этим заняться :) BTW, кодирование Хаффмана получается гораздо более производительным - просто pipeline на три-четыре стадии на частоте поступающих слов, однако процедура построения дерева по данным гораздо более сложная, чем для арифметического кодера.

Надо на некоторые сигналы поставить резисторы, подтягивающие к неактивному уровню, иначе проблем не избежать, особенно, если клок подается не с Virtex'а, а с внешнего генератора. К важным пинам относятся CS и CKE, если имеется в виду SDR SDRAM. Еще могут быть проблемы в момент выключения чипа.

А кто нибудь реально использовал эти корки от Xilinx и Altera в реально работающих проектах? Те, что отдаются на шару после простой регистрации? Нормальный быстрый и функциональный SDRAM контроллер "весит" не менее 700-800 триггеров, 300-400 логических функций, а его исходники занимают никак не меньше 400-500kB. Просто так, за регистрацию, такие исходники никто не отдает.

Это всегда была синтезабельная конструкция, по крайней мере для Xilinx FPGA. Для компилятора нет никаких проблем в Xilinx FPGA поставить начальное состояние триггера в bit-файле равным определенному значению. У нас на этом принципе была написана пара модулей, которые не требовали изначального ресета. В Альтере ситуация с этим похуже :( Там синтезатор просто игнорирует эту конструкцию и триггер по умолчанию всегда установлен в нуль. С этим связана разница в one-hot КА кодировании. У Альтеры первое состояние всех триггеров всегда нулевое, у Xilinx - произвольное. Если КА для Альтеры имеет ненулевые биты состояния стартового состояния (такой себе каламбурчик), то компилятор генерирует предупреждение, что мол схеме для корректной работы необходим стартовый ресет. <{POST_SNAPBACK}> Насчет синтезабельности этой конструкции. В языке Верилог объекты reg не являются триггерами. И вышепривденный объект 'a' может быть как триггером, так и простой логичекой связью (node, если по AHDL'ному). Во втором случае смысла в начальной инициализации просто нет. Сейчас уже не помню, давно было, когда разбирался, но, afair, присваивания (в том числе и начальные) к объектам reg можно делать только в поведенческих блоках initial и always. При этом блоки initial являются несинтезабельными - синтезатор в лучшем случае их игнорирует. Сам же всегда синтезуруемые объекты привожу к исходному состоянию явно в описании логики - для этого (и только для этого) использую асинхронный сброс триггеров непосредственно после влючения ПЛИС. Что касается исходного состояния триггеров в ПЛИС от Альтеры, то и тут, насколько помню, не так, как Вы сказали. Есть там возможность установить их при загрузке, сам пользовался этим несколько лет назад, когда работал на AHDL, это был какой-то из ACEX'ов. <{POST_SNAPBACK}> Оки, тогда расскажу как я это делал и делаю на VHDL под Xilinx. У меня там есть объявления сигналов, поведение которыч в последствии описывается как триггер. По VHDL - помещается в process() blah-blah-blah, чувствительный к клоковому сигналу, по Verilog - аналогом должна быть конструкция вида always() blah-blah-blah. Так вот, фактическим триггерам описанным данным сигналом можно присваивать конкретные логические значения, которые в случае Xilinx будут внедрены в сгенерированный bit-файл. При этом триггер будет установлен в начальное состояние без любых воздействий на логику прошивки из вне. Похожий фокус для Altera тоже возможен, но для этого необходимо дернуть DEV_CLRn внешним устройством, о чем и предупреждает компилятор во время сборки прошивки. Во время написания кода для FPGA на HDL был выработан определенный стиль, который подразумевает абсолютно однозначное указание синтезатору как нужно трактовать тот или иной сигнал. В нашем случае разговор о преимуществах одного синтезатора перед другим имеет скорее академический характер, чем практический. В схеме в любом случае есть только те триггера/регистры/мультиплексоры и т.п., которые были явно описаны в исходнике. В моем случае инициализация логична/возможна только для сигналов, описывающих регистры, счетчики или триггера, потому я и подумал, что вопрос относится в первую очередь к инициализации триггеров, потому как для других применений это бессмысленно.

Логически все будет работать, главное чтобы электрически все было в порядке. Ни CS, ни DM не участвуют активно в протоколе работы памяти, потому логически все будет хорошо. Естественно, будут небольшие ограничения по функциональности по сравнению с полным подключением, но для вас они, возможно, не критичны.

Это как это "инициализированных при декларации регистров в Verilog"? Что, уже можно написать: reg a = 1; и это будет синтезабельная конструкция? Или тут что-то другое имелось в виду? <{POST_SNAPBACK}> Это всегда была синтезабельная конструкция, по крайней мере для Xilinx FPGA. Для компилятора нет никаких проблем в Xilinx FPGA поставить начальное состояние триггера в bit-файле равным определенному значению. У нас на этом принципе была написана пара модулей, которые не требовали изначального ресета. В Альтере ситуация с этим похуже :( Там синтезатор просто игнорирует эту конструкцию и триггер по умолчанию всегда установлен в нуль. С этим связана разница в one-hot КА кодировании. У Альтеры первое состояние всех триггеров всегда нулевое, у Xilinx - произвольное. Если КА для Альтеры имеет ненулевые биты состояния стартового состояния (такой себе каламбурчик), то компилятор генерирует предупреждение, что мол схеме для корректной работы необходим стартовый ресет.

С CY7C68013 реально получить до 46MB/s. Для реализации сего чуда был написан очень оптимизированный драйвер под Windows XP и использовалась двухпроцессорная мамка на i865 или что-то подобное. Реально, двухпроцессорность здесь не нужна, важен только ICH5 или более поздний южный мост. Загрузка 2.4GHz процессора составляла около 10%. Со стандартными драйверами реально получить порядка 37-38MB/s, но их плюс в том, что они есть. О самом CY7C68013 впечатления самые положительные, за исключением того, что сильно греется. Проблему решили переводом CY7C68013 на 12MHz клок, а источник данных - в нашем случае FPGA - работал на 48MHz. Таким образом производительность самого CY7C68013 была абсолютно не важна для проекта.

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