v_mirgorodsky

Summator s registrom na vihode - eto s'hema *universal'nogo* schetchika. On rabotaet pri lyuboy skvazhnosti taktovogo signala i obespechivaet polnost'yu sinhronniy vihod. V drugoy modificatsii - eto posledovatel'no vklyuchennie triggera, gde na Clk vhod sleduyuschego triggera podaetsya signal s vihoda prediduschego. Nedostatok etoy s'hemi - assinhronnost' po vihodu. Sootvetstvenno, sintezator obuchen delat' polnost'yu sinhronniy vihod, vot on i generit summator s registrom po vihodu.

Hm-m-m, sorry, ne obratil vnimaniya. Voobsche govorya, ne rabotal ya s AF_UNIX tipom socketov. Odnako takaya oshibka harakterna esli server i klient pitayutsya zabindit'sya na odin i tot zhe socket. V sluchae AF_INET pomogaet ustanovka SO_REUSEADDR optsii na socket. Poprobuyte, mozhet i vam pomozhet. A pochemu bi ne ispol'zovat' AF_INET? V etom sluchae edinstvennoe chto budet nuzhno eto bindit' klientov na lyuboy svobodniy address i obschat'sya s serverom napryamuyu. Odnako dlya etogo dolzhen bit' skompilirovan i skonfigurirovan loopback interface.

Klient dolzhen vizivat' connect(), a ne bind().

Esli opita net, to luchshe ih ne trogat'. Tam est' i takie, chto esli ih zapretit', to mashina tupo ne podimetsya. Ozhivit' ee pri etom mozhno tol'ko vosstanovleniem kopii reestra do pravok. Potomu moy sovet - ih luchshe ne trogat'. Mozhno utyanut' chudo xpAntiSpy - ona znaet kakie servisi mozhno otklyuchit' bezboleznenno. Hochu odnako zametit', chto viklyuchenie servisov ne skazhetsya na bistrodeystvii nikak. Servisi pishutsya ochen' gramotnimi programmerami i v osnovnom spyat v ozhidanii sobitiy. Mesta v *fizicheskoy* pamyati oni tozhe ne zanimayut, t.k. visvoplivayutsya na disk kak bol'shinstvo polu-neaktivnih processov. Takim obrazom, obkornav XP do nulya mozhno poluchit' "lishnih" paru meg pamyati, s riskom ugrobit' mashinu vo vremya eksperimentov. IMHO, ne stoit ono togo.

Est' variant ot PMC Sierra, no eto takaya bol'shaya gadost' na 4 sotni nozhek i razmerami poryadka 35x35 mm. Mi rassmatrivali ee kak variant, no FPGA + PHY poluchaetsya ser'ezno men'she po ploschadi na plate i mnogo funktsional'ney. BTW, v CPLD GMAC prosto ne vlezet. To, chto ya real'no videl viglyadelo kak 1000 le v minimal'noy konfiguratsii. FPGA na takoy ob'em budet vsyako deshevle.

A pochemu bi ne vspomnit' starika Okkama? Menee chem dva schetchika sdes' vse ravno ne budet, vichisleniye funktsii ot i, j nikuda tozhe ne denetsya, telo tsikla tozhe ostanetsya. Takim obrazom poluchaem spisok osnovnih deystvuyuschih lits etoy sceni. Kak ih soedinit' i kak rassmatrivat' s'hemu - eto uzhe vopros esteticheskih soobrazheniy, a ne inzhenernih. Voobsche govorya, chem dal'she vi uydete ot zheleza, tem menee optimal'no skompiliruet vashe opisanie sintezator. Sdes' vidna analogiya s pervimi C/C++ kompilyatorami. Poka vichislitel'naya moschnost' komp'yuterov bila slaboy ochen' chasto primenyalis' optimiziruyuschie vstavki na Assemblere, po mere rosta vichislitel'noy moschnosti processorov i ob'emov pamyati Assemblernaya optimizatsiya stanovitsya vse bolee redkim yavleniem. Nuzhno, odnako, otmetit', chto i kompilyatori stanovilis' "umnee". Tak proizoydet i s VHDL/Verilog/... i drugimi sintezatorami. Kogda schet yacheek v nebol'shoy po stoimosti PLIS poydet na desyatki tisyach, a taktovie chastoti osnovatel'no perevalyat za gigaherts, togda i mozhno budet izobretat' proekti na grani sinteziruemosti - effectivnost' PLIS v kupe s taktovoy chastotoy "s'edyat" ne optimal'nost' sintezatora, a do togo vremeni vse zhe luchshe poblizhe k zhelezu.

Спасибо всем откликнувшимся. А можно немного подробнее о QPSK-QAM модуляции? Я слышал отдельно QPSK и отдельно QAM. Теперь более предметно о QPSK и QAM модуляции. Я неоднократно встречал в конференции утверждение, что декодирование QPSK и QAM модулированных сигналов - очень трудоемкая задача. Ни в коем случае не ставлю под сомнение данный факт, однако в следствие отсутствия опыта не вижу в чем состоит сложность данного просесса. На сколько я понимаю, необходимо АЦП, цифровой фильтр, декодер и блок, контроллирующий ошибки. Есть ли какая-то литература, освещающая данный вопрос более подробно? Безусловно, часть прошивки FPGA будут составлять готовые ядра. К примеру, в качестве кода, контроллирующего ошибки планируем использовать готовые решения на базе кодов Рида-Соломона.

Здравствуй, глубокоуважаемый ALL! Возникла такая задача. Есть два устройства, находящихся на сравнительно большом удалении друг от друга. Эти устройства соединены между собой каналом передачи данных с полосой пропускания порядка 12-15MHz, среда передачи данных может модулироваться как по частоте, так и по амплитуде. Необходимо создать надежный канал передачи информации между двумя такими устройствами с пропускной способностью порядка 8-9MBit/s. Практически сразу приходит на ум амплитудно-фазовая модуляция, однако опыта создания устройств с ее применением нет. Не подскажет ли глубокоуважаемый ALL какие трудности ждут на этом пути и на что следует обратить внимание в первую очередь? Вариант замены канала передачи информации на нечто готовое, уже цифровое к сожалению не приемлем, т.к. необходимо с минимальными доделками вписаться в уже готовую среду.

Podderzhivayu ideyu po povodu Intel C++ compilyatora. Eta shtukovina integriruetsya napryamuyu v Visual Studio 6.0 ili .NET. Posle pri kompilyatsii ispol'zuet Intelovskiy kompilyator, a ne podobie onogo, napisannoe M$. Est', odnako, podvodniy kamen'. Nekotorie osobennosti ishodnogo teksta M$ traktuyutsya kak oshibki, a Intel C++ kak warningi. V nekotorih sluchayah poluchaetsya kompilyatoro-zavisimiy kod.

Драйверами под PCI не занимался, но занимался драйверами под Win. 2000 прерываний в секунду - не слишком большая частота для работы по прерываниям в среде Win. Однако, я бы предусмотрел накопление результатов в некотором буффере если система все же не будет успевать. Документа, подобного описанию на QNX на Win вы не найдете, потому как Win не OS с гарантированным временем отклика. Время отклика Win сильно зависит от факта работы CD/DVD-ROM приводов, общей загрузки системы пользовательскими приложениями и т.п. Как результат, ваше устройство может периодически пропускать прерывания и сбиваться.

1. Проверьте включен-ли режим ECP-EPP в биосе компьютера (нужно включить!) 2. Разберитесь с TCK. Это тактовый сигнал JTAG. В момент загрузки конфигурации никаких третьих состояний на нем быть не может. 3. Попробуйте изменить резисторы подтяжки на 4.7КОм (у меня была такая проблема как-раз с MAX7000S семейством) Удачи.

Метну ка и я свои пять копеек :) Для Вашей задачи ничего кроме статической памяти не подходит, хотя предыдущие ораторы не раз это говорили Вам до меня. Даже в простейших случаях синхронная динамическая память чрезвычайно геморойна в управлении, а микросхем на два мегабита Вы сейчас нигде не найдете. Минимум начинается с 4-8 мегабит на корпус. И что Вы будете с этим объемом памяти делать? По поводу burst режимов. На сколько я помню, их можно и не использовать. В зависимости от того, будете Вы использовать ADSP или ADSC и будет выбираться burst режим или одиночное чтение. По моему, так, точно не помню, поскольку давно уже дело было. Burst режим хорошо использовать для экономии мощности. Дернуть (перезарядить входные емкости входов и выходов) 18-20 линий адреса каждый такт намного менее выгодно, чем дернуть их же один раз в четыре такта. Еще в Вашем случае могут быть вопросы с частой сменой с чтения на запись. Каждый такой переход потребует одного такта задержки. Избежать его можно используя ZBT SRAM. У нее этот вопрос решается за счет симметричной ковееризации в обе стороны.

Во время синтеза самой сложной команды отдельно, Synplify рассматривает этот блок как единое целое и не уделяет его оптимизации достаточно внимания, если блок вписывается в констраины клока с большим запасом или заведомо не вписывается в них, тоже с большим запасом. Если же синтезировать все устройство целиком, то остальная часть устройства как более быстрая вынуждает синтезатор "подтягивать" скорость более медленного блока к стандартам более быстрой части, положительно влияя на результирующую частоту. Такое у меня возникло впечатление во время работы с этим синтезатором. Теперь откуда берется более высокая скорость. Просто используются более быстрые роутинговые ресурсы в микросхеме. Сумматор, входящий в состав счетчика можно скомпоновать/развести по разному. Квартус всегда использует самые быстрые переносы для синтеза, Synplify, обычно, пытается с начала экономить и использует высокоскоростную реализацию только если это совершенно необходимо. Потому при синтезе Synplify в нетлисте больших перекосов по скорости обычно нет, тогда как Квартусом обычно получается самый быстрый проект, страдающий некоторой неравномерностью быстродействия блоков и ассинхронных путей.

Добрый день, всеуважаемый ALL! Хотелось бы обсудить возможности выше упомянутого пакета по исследованию конкретных сигналов в описании схемы, тонкости реализации специфических блоков схемного описания (описание в такой форме будет реализовано лучше, а в токой - хуже, хотя с точки зрения функциональности блоки идентичны), возможные глюки и более эффективные методы работы. По своему опыту могу сделать заключение, что очень большое количество разработчиков используют именно этот пакет для синтеза. Думаю, что тема будет интересна широкому кругу посетителей форума.

Это регистр валидности данных в каждом из 12-разрядных регистров. На пример, в строке кеша находится строка 50 и она валидна, т.е. соответсвует информации находящейся под ней памяти. При сбросе бита валидности те же самые 50 уже не будут приниматься в расчет и функция должна будет генерировать неравенство по любому входящему операнду. Строки памяти могут принимать все значения, от нуля до 4095, потому необходим отдельный бит валидности. Похожим образом обстоят дела и с нашим устройством. Так вот введение бита валидности в сравниватель как еще одного разряда позволило повысить скорость работы блока. Такое я видел уже несколько раз, когда пытался отклониться от RTL-уровня описания схемы :) После чего принял решение больше не делать таких экспериментов. Я четко знаю на каких элементах следует собрать мою схему и не его (синтезатора) собачье дело учить меня как это сделать лучше :twak: потому как на сегодняшний день у него получается значительно хуже, по крайней мере, с точки зрения быстродействия схемы, а в некоторых случаях и с точки зрения количества ресурсов.

Как оказалось, не все так плохо, как казалось изначально. Просто надо подсказывать синтезатору для каких блоков какие примитивы лучше использовать. Приведу пару "свежих"/"сегодняшних" примеров. Были четыре 12-разрядных регистра и сигналы валидности информации в каждом из регистров. Был сигнал входной 12-разрядный. Требовалось сравнить входной сигнал с одним из регистров и выдать управляющий сигнал на FSM в случае равенства/неравенства операндов. Невалидный операнд в одном из четырехразрядных регистров считался неравенством величин. Изначально стоял 12-разрядный компаратор и его выход наворачивался битом валидности логическим И. Скорость этой части дизайна "плавала" в пределах 150-160MHz. После этого был выкушен 12-разрядный компаратор и применен 13-разрядный, 13-м разрядом регистров стал бит валидности, для входного операнда - '1'. Таким образом количество уровней логики не изменилось, но один уровень логики был заменен быстрым мультиплексором сравнивателя, что в свою очередь выкинуло данный кусок схемы из критического пути, повысив частоту именно этого куска схемы до "запредельных" 167MHz :) Второй пример. Был очень "занятый" триггер со сложной системой управления Set/Reset. Этим триггером рулила машина, но при этом о его переключении надо было знать в тот же такт, как он переключался. Ассинхронные Set/Reset отпадали в следствие возможных глитчей на выходах FSM в реальной схеме. Потому Set складывался по ИЛИ с выходом триггера и дальше шел на управляющие входы других триггеров следующего слоя, т.е. уровней логики на управляющем сигнале было два - триггер и выход FSM по ИЛИ. Быстродействие схемы упало до 145MHz или что-то в этом роде. Из FSM был вынут сигнал побуждающий машину перейти в состояние, где устанавливался триггер и отправлен на Set этого триггера - т.е. машина из машины Мура стала машиной Милли по паре сигналов. В результате частота блока выросла до 163MHz. Оказывается машина Милли - это не всегда плохо :ninja: Еще один результат. Если сказать синтезатору, что Set/Reset не бывают активными одновременно, то вместо D-триггера он родит RS-триггер, эффективно убрав еще один уровень логики :cranky: При этом всем мы еще не поставили ни одного платформенно-зависимого элемента <_< Просто надо как-то синтезатору подсказать что тонко именно в этом месте, именно на этом ассинхронном пути, но я еще не до конца разобрался как. Synplify большая умница с точки зрения компиляции, однако иногда и он делает глупые вещи.

Ну чтож, и на том спасибо :) Жаль, что не получилось с законченным проектом :( Основная идея была как бы поиграться в пределах фиксированного базиса, поизменять циферки в констраин-файле и понять взаимосвязь последних с пректом, потому как "свои" констрейны на данный момент просто не выполняются. Более того, я вижу где же он конкретно лажается, но подсказать ему (синтезатору) правильно не могу, а глобальный констраин PERIOD он тупо не выполняет. Будем разбираться :)

2 3.14: А Вы как-то в этой нити обещали запостить какой-нибудь свой не самый тривиальный проект с прикрученными к нему констраинами. Что-то не получается или просто нет времени? Просто мы уже подходим к финалу разработки одного из наших модулей и хотелось бы к нему в качестве последнего аккорда прилепить файл описания констрейнов, дабы заставить работать его на нужной скорости. PERIOD на него мы уже навернули, но этого ему явно не достаточно, т.к. он это требование иногда выполняет, иногда нет. Частота зависит в основном от фазы луны и плавает в диапазоне 10MHz даже если просто добавить инвертор в совершенно не связанном с ним блоке. Был даже курьез. С блока на блок через два сигнала/проводочка шла связь - понятно, что один можно было выбросить, выбросили и частота упала с 160 до 153MHz. Понятно, что наличие одной связи между блоками позволило синтезатору каким-то образом слить похожую логику двух блоков, что в результате привело к падению производительности. И это при том, что в обоих случаях констраин PERIOD не менялся, блок по входам и выходам имеет триггера, раскладывается в единственном экземпляре в FPGA и занимает всего 10% ее ресурсов :cranky: Еще заметил странное поведение. То что хорошо для Виртекса второго, совсем плохо для Спартана третьего и наоборот. Одна и та же схема, написанная на RTL-уровне работает в Спартане на 99MHz, в Виртексе - на 160. Меняю в схеме логику с триггерами местами, т.е. общий путь остается одинаковым и получаю результат с точностью до наоборот. Правда Виртекс работает всеж на 130MHz, зато Спартан разганяется до 140. При этом оба чипа показывают РАЗНЫЕ критические пути во всех четырех случаях. Еще одна странность. Введение более сложной ассинхронной логики между парой триггеров приводит к резкому падению рабочей частоты схемы, при этом эта логика никуда больше не идет, а критический путь остается неизменным. Еще заметили странность. Синтезируем схему в Synplify, видим длинный ассинхронный путь с одного триггера на другой. Два раза щелкаем на элементах этого пути и оказывается, что Synplify подсвечивает логику, совершенно даже не относящуюся к этому блоку, а лежащую от него за двумя слоями триггеров :maniac: Понятно, что это есть некоторый глюк синтезатора, но по началу мы пару раз перепахали схему в поисках ошибки :) Теперь я четко понимаю, что при необходимости выжать последние мегагерцы из дизайна его надо оптимизировать под конкретное семейство и даже, в некоторых случаях, под конкретный синтезатор :angry2:

2 3.14: До следующей недели терпит :) Ага, так и делал NET Clk PERIOD = 7.0 ns; ISE после PAR'а сказал, что костраин не выполнен. Я посмотрел где он не выполнен и попытался прикрутить MAXDELAY констраин на тонкие места. Ну было у меня такое впечатление, что если на управляющий сигнал, который идет на машину сказать MAXDELAY, то PAR сможет более оптимально их разводить и уменьшит задержки на сам роутинг, т.к. задержки на логику уменьшить все равно не получится. Тексту было просто море а результат никакой - все равно Fmax сильно не изменилась. Вот потому и хочется посмотреть на правильно законстраиненый проект, поиграться с ним, поменять циферки и увидеть как это влияет на результирующую частоту. С синтезатором я дружу. Сказывается рисовальческое прошлое. Я хоть и пользуюсь VHDL но реально думаю триггерами, счетчиками, мультиплексорами и т.п. Потому если я говорю, что там есть триггер, то она обычно со мной соглашается. Потому чтобы найти элемент в схеме обычно достаточно написать его имя и поставить * в конце :) edf2srs - попытка иметь один констраин для ISE и Synplify. Вроде бы что-то получилось, но говорить о чем-то доведенном до уровня технологии еще рано.

Даже самые лучшие DC-DC имеют уровень выходных пульсаций порядка 20-30 миливольт, что неприемлемо для многоразрядных АЦП. Самый простой способ решения этого вопроса в связке DC-DC, а непосредственно за ним - LDO. DC-DC делает уровень напряжения для линейного стабилизатора, линейный стабилизатор фильтрует помехи и создает условия работы для Ваших АЦП и остальной аналоговой начинки. Можно выкинуть DC-DC и использовать только линейный стабилизатор, но тогда на нем может быть сравнительно большое падение напряжение и надо будет предпринимать специальные меры по его охлаждению. На сколько я понимаю, Вам необходим уровень пульсаций/помех по линиям питания в единицы миливольт или лучше. По своему опыту и прочитанным даташитам выводить питающее напряжение до такого качества доставабельными танталами малоэффективно - слишком высок их ESR. Для улучшения ситуации надо несколько штук ставить параллельно. Что-то более конкретное сказать сложно - посмотрите даташиты Analog Devices на их линейные стабилизаторы напряжения.

В Вашем случае bottleneck будет не PCI, а среднестатический HDD, потому как скорость записи на блины среднестатистического ХОРОШЕГО HDD составляет 50-55MB/s из которых необходимо вычесть накладные затраты на файловую систему, свопинг и т.д. и т.п., что на круг даст Вам порядка 45-47MB/s чистой пропускной способности для записи данных. Отсюда и считайте. Можно еще пробовать писать в RAW-режиме, но для этого придется нагородить нехилый драйвер, что само по себе будет проблемой. Если же речь идет о непродолжительных сеансах накопления данных и неспешный сброс их на диск в паузах - то такое возможно. Может кто-то попозже скажет что-то более конкретное о скоростных возможностях самой PCI, но мне кажется что двойного запаса по пропускной способности PCI должно хватить даже в самом плохом случае.

Ну по поводу исходника - так тут все прото. Хотелось бы увидеть нечто не совсем тривиальное, с тройкой-четверкой слоев регистров и с ассинхронной логикой между ними. Пользуясь предыдущим объяснением я попытался написать констраин для модуля. Он представлял собой два слоя регистров между которыми крутилась нетривиальная FSM. Периодически Synplify раскладывает эту схему на 172MHz при требуемых 166MHz, а остальное время говорит, что буду работать на 157MHz. Я накрапал UCF файл для ISE и странслировал его для Synplify утилиткой edf2srs. Короче говоря, ничего не получилось :( Кроме того, не вполне понятен принцип написания констрейнов. Т.к. во время своего опыта я просто замахался распределять все цепи по группам :( Мне почему-то кажется, что должно быть это как-то проще. На днях видел файл констраинов к Gigabit Ethernet MAC - так там всего пара строчек. Вот совсем и не понятно откуда они там взялись и как всего парой строчек зажали блок более 1000 слайсов размером :cranky:

Со ссылочкой сложно :( Этот thread попался мне на глаза в то время, когда мы только начинали заниматься Xilinx, посему ссылочка не сохранилась, однако факт небольшого уменьшения рабочей частоты при упаковке отложился у меня в голове однозначно. Еще раз перечитал Ваш пост и понял в чем несоответствие. Если асинхронная логика включена на вход своего же триггера, тогда все хорошо, однако в реальном проекте так получается не всегда. В реальной жизни схема содержать больше логических функций, чем триггеров, или асинхронная функция зависит более чем от четырех переменных. Потому добавляется необходимость на выныривание/заныривание сигнала в ЛЯ, а быстрых линий связи для этого в слайсе уже не хватает. Как результат, частота падает при упаковке. Приблизительно такие рассуждения приводились в той статье об упаковке, о которой я говорил. Таким образом наши посты не противоречат друг другу и все логично.

Вот на счет упаковки я с Вами не соглашусь. Упаковка ВСЕГДА понижает частоту. Происходит это в следствие того, что магистральные (скоростные) связи между ячейками заменяются на локальные с несколько худшими характеристиками. Это не мое мнение и не мое заключение. Информация была получена от кого-то из Xilinx несколько месяцев назад на гуглях в comp.arch.fpga. Этим, к стати, объясняется более низкая частота плотно упакованных кристаллов.

А чего же тогда при синтезе родным ISE синтезатором проект занимает реально меньше места в кристалле? В нашем случае это 512 slices при синтезе Synplify и 360 slices при синтезе ISE. Так где же правда? Или Вы хотите сказать, что когда PAR'у не будет хватать места в кристалле он начнет паковать триггера и LUT'ы в одни slices? Просто Quartus в этом смысле подобных вольностей себе не позволял. Ему можно было сказать - паковать триггера и логику в одну и ту же макроячейку и он только это и делал, если возможно, при этом честно сообщая, что частота в результате будет ниже. А у ISE получается, что рассчитываеш на одну частоту, отлаживаеш все модули под нее, а когда упакуеш все в кристалл, увидиш, что частота упала в следствие упаковки. Свинство это с его стороны :maniac: Я лично предпочитаю видеть все с самого начала в условиях,максимально приближенных к боевым. Знать бы как это ему включить :cranky: