Beby

Дело в том, что настолько я успел проглядеть внутренние соединения Virtex5FX, у PowerPC есть аппаратная шина к Ethernet MAC (или я заблуждаюсь ?). Начну делать - увижу что необходимо, тогда и решу. Пока вариант с MicroBlase я не отбрасывал. Сейчас изучаю решение соседей... и в нем не используются RocketIO от Virtex4/5 (а я почему-то думал, что именно его то и прийдется использовать), если они действительно не нужны, тогда попробую уйти на заметно более дешёвый на Spartan3E/A. О полученном решении обязательно сообщу. Как обычно с меня требуют решение быстро и с первого раза (совсем работодатель обарзел, привык, что все мои платы для него (9 шт. на каждой по паре ПЛИС - ну не работаем пока с BGA...) работали с первого варианта разводки). С Xilinx работаю около 8 лет, вроде достаточно хорошо работаю, поэтому и плющит, и колбасит (кроме как от их цен); а со средой Lattice пока ну нету времени разбираться, но ничего против этих ПЛИС не имею, и если появиться небольшой передых погляжу на них очень внимательно.

Подведу очередные итоги обсуждения: К сожалению, вынужден констатировать, что: Вопрос 1 - остался без ответа (а сейчас для меня он архиважный), Вопрос 2 - освещён только со стороны трудоёмкости разработки решения (сторона очень важная, я бы даже сказал ключевая), но необходимо всё-таки ответить на вопрос "А нужен ли вообще TCP/IP ??! И чего полезного он действительно может дать ?", т.к. если особой пользы от TCP/IP нет (а пока я склоняюсь к этой мысли), то при обсужденных трудозатратах на его освоение/поддержку тратиться жалко. Вопрос 3 - можно считать более или менее хорошо обсужденным. Пока думаю, что воспользуюсь Virtex5 Gigabit Ethernet MAC (по сравнению с Virtex4 у Virtex5 немного дешевле встроенная блочная память). Использовать PowerPC не хочу, может и ошибаюсь, конечно, но думаю, что проще набросать несколько несложных FSM. чем разбираться с EDK... В крайнем случае, если появиться ощущение, что я заблуждался, то воспользуюсь MicroBlase; конечно такое решение хуже встроенного PowerPC с прямым интерфейсом к Ethernet MAC. Соединения пока планирую делать точка-точка (т.е. от моего комплекса в специально зарезервированную сетевуху). Поэтому сейчас стоит проблема выбора конкретной микросхемы, сейчас в возможных вариантах стоят XC5VSX35T-1FF665C и XC5VLX20T-1FF323C (на случай использования PowerPC XC5VFX30T-1FF665C). SX35T - привлекает неплохим количеством встроенной блочной памяти (заметно более дешёвой, чем у всех остальных представителей VIrtex5), цена в 20 килорублей (практически максимальная розничная цена) несколько омрачает прелести применения этого кристалла - но т.к. оная ПЛИС требуется только одна на весь комплекс, то терпимо. LX20T - привлекает минимальной ценой среди Virtex4/5 с Ethernet MAC (такая ПЛИС стоит в 2 раза меньше, чем SX30, но и ОЗУ в ней в 3.2 раза меньше), а т.к. встроенной блочной памяти мало, то необходимо цеплять что-то внешнее. Теперь новая пачка вопросов (в добавление к неотвеченному вопрос 1 из предыдущей пачки): 1. Применение SX35T позволит хранить данные на 25мс (при 15МБайтном потоке). Достаточно ли этого времени, чтобы гарантировать устойчивую передачу данных в Windows XP ? 2. Какой должен быть размер буфера (в мс), чтобы гарантировать устойчивую передачу данных в Windows XP (и где это можно прочесть) ? 3. Если использовать внешную память, то что лучше использовать ? (с динамической памятью пока не работал, да и что-то не тянет,.. а может зря ?) 4. Какие "неочень дорогие" микросхемы двухпортовой памяти (али даже готового FIFO) можете посоветовать. От двухпортовой памяти требуется иметь один порт для записи, второй - для чтения.

Прочитал. Документ интересный. Добавлю пару предложений (может, конечно, и бестолковых), но не найденных в документе: 1. Для сигналов входящих/выходящих в/из ПЛИС я использую префиксы IN_xxx, OUT_xxx, IO_xxx. После прохождения однонаправленных сигналов через I/O BUF, префиксы IN_ и OUT_ - отбрасываю. Для IO_ сигналов прошедших IOBUF использую суффиксы xxx_IN, xxx_OUT. (буферы ввода/вывода всегда вставляю в проект) 2. Для различных внутренних сигналов использую ряд однотипных суффиксов: _UB - UnBuffered (например, для Clock поданного на вход BUFGMX), _UL - UnLatched (например, для входных сигналов, которые должны быть защелкнуты входным IOB триггером), _L - Latched (например, для сигналов,) _FF - Falling front (применяю для выходного сигнала "детектора" фронта) _RF - Rising front (применяю для выходного сигнала "детектора" фронта) Ну например как-то так: signal AAA_UL: std_logic; signal CLK: std_logic; signal AAA: std_logic := 0; signal AAA_L: std_logic := 0; signal AAA_RF: std_logic; signal AAA_FF: std_logic; AAA <= AAA_UL when rising_edge(CLK); AAA_L <= AAA when rising_edge(CLK); AAA_RF <= AAA and not(AAA_L); AAA_FF <= AAA_L and not(AAA); Единственная заметная разница моего стиля написания и вышепредложенного в названии инверсных сигналов, я вставляю _n между описанием принадлежности сигнала к группе и основным описателем сигнала: Reset -> nReset, RAM_nOE, PCI_nFrame. Мне так удобнее - а далее кому как больше нравиться. Считаю, что наиболее важным в КД является единобезобразие на протяжении всего проекта (лучше конечно во всех работах, но человек учится и потихоньку "улучшает" свои наработки, отклоняясь от первородных версий оформления).

Преимущественно пишу на языке, не гнушаюсь по мере надобности плотненько набивать код constraint'ами (для того, чтобы XST/MAP/PAR делали именно то, что я задумал). С SM полностью согласен. Исходя из этих же соображений применяю компоненты для IBUF/OBUF, BUFG, DLL(DCM), RAMB (чтобы RAMB использовались именно так, как я задумал и не подавались GND сигналы на неиспользуемые входы данных - этот прием достаточно хорошо уменьшает лишнии связи в зоне RAMB). Для описания особо скоростных мест создал свою небольшую библиотеку (кристаллозависимую, очень плотно набитую RLOC), и использую её, чтобы жестко задавать взаимное расположение особых частей проекта.

Фуххх... Вернулся из 2 дневной командировки. После предварительного согласования параметров системы сбора данных с соратниками, выяснилось, что необходима длина кабеля для передачи данных до 30-40 метров с обязательным наличием гальванической (или оптической) развязки, предельный поток данных получается около 15 MByte/s (или 120 MBit/s - так точнее) (к сожалению "сладкое будущее" стало тоскливой реальностью). Поэтому USB отпадает, насколько мне известно он не работает на такое расстояние и не имеет развязки. А жаль, первоначально предполагалось (мною), что удастся ограничиться один метром интерфейсного кабеля. Естественно с таким потоком Ethernet-100 не справиться, соответственно прийдется использовать Gigabit Ethernet. Теперь вопросы: 1. С чего лучше начать знакомство с Ethernet ? 2. Что лучше использовать чистый Ethernet или еще реализовывать и TCP/IP (в чем достоинства/недостатки обоих решений) ? 3. Исходя из 2, какие микросхемы/сборки лучше использовать ? Еще раз повторю особенности этой разработки: 1. Данные необходимо гарантированно доставлять (т.к. у меня - система сбора данных). 2. Необходимо иметь возможность в будущем увеличить поток в 2 (или 2.5) раза, т.е. до 240Mbit/s (или 300Mbit/s - это крайняя цифра, выше неё прыгать не собираемся). 3. Очень важно минимизировать время разработки. 4. Место для аппаратного решения - 1дм2, можно и 1.5дм2 (да, так спроектировал систему - место есть). 5. Желательно чтобы суммарная цена копонентов не превышала десятка киборублей (не килодолларов !). 6. Программа приема данных на компьютере будет работать под Windows XP 32bit (тоже желательно позаботиться о программисте - дабы не сильно пух от проблем с голым Ethernet, или проблем как раз с Windows XP нет ?). Пока видел 2 предложеных решения: 1. FPGA + ARM9 (как я понял, поддержку TCP/IP в ARM9 прийдётся делать самому, али есть готовое и доступное решение ?). 2. V4 Ethernet MAC (+ MicroBlase with LwIP - для поддержки TCP/IP). Может еще какие предложения есть ? Пока, второе предложение кажется более близким т.к. работаю с ISE давно и очень плотно (есть надежда, что и с EDK очень долго разбираться не прийдется), а вот про ARM только приходилось иногда слышать...

На всякий случай опишу чуть подробнее работу имеющихся шин. От блока управления (так я прозвал большую интерфейсную плату) к каждой плате расшинения через Cross идут следующие LVPECL пары: Clock - 50 или 100 МГц, dFrame - синхроимпульс для начала очередного цикла сбора данных и отгрузки данных с предыдущего цикла, dData - данные от платы сбора данных. cFrame - синхроимпульс, обозначающий начало переда данных по шине управления, cFData - данные шины управления к плате сбора данных, cBData - данные шины управления от платы сбора данных. Так сказать подобие 2 SPI портов. В настоящее время данные dData от 10 плат сбора данных, мультиплексируются в блока управления и отгружаются потоком по 3 парам (Clock, dFrame и dData) в PCI плату компьютера. Шина управления работает аналогичным образом, только инициатором является компьютер. Вышеприведенные потоки (текущий - 16 Мбит/с, желаемый для сладкого будущего - 105 Мбит/с и для очень сладкого будущего - 210 Мбит/с) - это предельные суммарные потоки от всех плат сбора данных. В принципе, пока достаточно сделать аналог 16 Мбит/с передачи данных, но по какому-либо стандартному интерфейсу. А т.к. не хочется переделывать интерфейсную плату при развитии датчикового хозяйства, то были указанны у предельные цифры потоков более которых не понадобиться даже при самых больших хотелках заказчика. К сожалению PC используется не только для отображения данных, но и для накопления оных. Поэтому не удается на него сгрузить только задачи отображения данных / управления системой сбора данных. Поток управления действительно смешной от силы 1Мбит/с. Пытаюсь немного отбрыкаться от DSP не потому, что он мне не нравиться, а потому, что хочу более точно представлять как его лучше использовать, а я пока еще не смог представить как его органично вписать в систему. Ммм... вот подумал получше и решил добавить: данные хранятся на PC не только для последующей обработки, но и для сравнения с данными полученными при последующих проездах по этому же месту. Поэтому в реальных условиях данные проезда хранятся и могут быть использованы в течении полугода. Для имеющегося вида данных есть простенький алгоритм компрессии - сжимающий их в 15-20 раз. К своему стыду признаю, что у меня не дошли руки встроить целиком данный алгоритм в систему сбора данных, т.к. достаточно быстро выяснилось, что для улучшения работы комплекса в целом необходимо менять принцип сбора данных, а при новом подходе требуется и другая компрессия потока. Звучит достаточно заманчиво, но т.к. с ARM еще ни разу не приходилось сталкиваться, прошу дать ссылки на то откуда лучше начинать знакомство с этим вариантом. Если у кого есть опыт работы с MicroBlase и Ethernet на базе встроенного MAC ядра Virtex-4, поделитесь своими соображениями чего лучше: MicroBlase + V4 Gigabit Ethernet или вышепредложенный ARM9 ? Замечание интересное, но вот вопрос заключается именно в том при помощи каких микросхем (или даже сборок) заменить текущее корявинькое решение. Может посоветуете чего ? P.S. извиняюсь за "очень много слов", но вот никак не удаётся в 2 словах выразить свою большую округлую мыслю. Как говорил выше, цена микросхем/сборок в несколько тысяч рублей за штуку не отпугивает... (для сравнения, себестоимость PCI платы до кризиса составляла более 5 килорублей - их (или даже большую сумму) можно смело потратить на любой чип/модуль)

В семействе Spartan тоже есть пяток кристаллов со свтроенной Flesh ROM - Spartan3AN. Я не говорю, что они лучше Actel, но они тоже есть...

Направление интересное... Но как с этим USB 2.0 работает PC ?.. Что-то мне подсказывает, что интенсивная работа с USB сопряжена с периодическими замираниями компьютера. А мне необходимо непрерывное гладкое графическое полноэкранное отображение вводимых данных (ну где-то 1280x1024 @ 100Гц - картинка весьма нагруженная). С PCI всё работает нормально... благо Bus mastering помогает. Насколько будет мешать USB 2.0 с потоком 15МБайт/с работать WindowsXP (пока программа написана под эту ОС) ? (Вопрос родился не на пустом месте: у соседей не получилось нормально связать Cypris и PC по USB... периодически подзамирает машина, а в TaskManager'е это ну никак не отображается,.. правда достаточно хорошо отражается в помощи NuMega True Time. Может, конечно, у моих знакомых ребят руки кривые - поэтому так и работает. А поэтому мне и интересно на что именно стоит тратить время - с каким стандартным интерфейсом разбираться ?)

А PC как раз для хранения и отображения записываемых данных (а грамотный опператор по отображаемой картинке может на ходу поменять усиления и т.п. параметры системы сбора данных). Собственно говоря DSP не нужен - нет обработки данных в блоке управления, да и не встречал я DSP с таким количеством последовательных входов/выходов (к каждой плате хотя бы по 2 двунаправленных SPI порта, а плат 10)... А вот по поводу "любым удобным низкоскоростным интерфейсом" - об этом и вопрос - чем соединить с PC и как попроще (удобней для разработчика) прицепить это что-нибудь ?

Тему создал в этой ветке конференции, ибо надо заменить старое ПЛИС решение на новое или на что-то вообще другое. Как лучше модифицировать имеющееся решение: Имеется система сбора данных - ящик 19 дюймовый 4U. Внутри ящика самопальный cross на 10 плат расширения и 1 плата управления. От платы управления шел самопальный канал связи (6 диф. пар по 50МГц) к PCI плате (32бита 5V), втыкаемой в обычный компьютер. Назрела необходимость изменить ввод данных в компьютер (отказаться от самопальной PCI платы, да и аналогичного канала передачи данных). Cross и пачки различных плат расширения переделывать ой как неохота, а поэтому имеем такое схемно-убогое решение: от каждой платы расширения (ввода и обработки данных) к блоку управления тянется по 6 LVPECL пар (если быть более точным, то Xilinx LVPECL аля Virtex-E/Spartan-2E) - по 4 к плате расширения и по 2 к блоку управления, итого 60 пар. Груды LVPECL пар, заходящих на блок управления, подаются на 2 XCV50E-7PQ240, каждый Virtex-E занимался работой со своей половиной шины. Первый мультиплексировал поточные данные от плат расширения и заливал эти данные в PC (по однонаправленной шине). Второй обрабатывал запросы от PC (записать конфигурационную информацию/считать оную из плат расширения). При таком построении системы получалось 2 независимых шины, простое решение в ПЛИС (почти что одни мультиплексоры и коммутаторы). Особенностью аппарата является то, сбор данных необходимо производить с привязкой к пространственной координате, т.е. весьма шустро реагировать на изменения скорости подвижного объекта, в котором собран измерительный комплекс - в том числе и из-за этой особенности стандартные платы ввода данных в PC не использовались (может быть зря ?). Конструктивно блок управления может быть полноразмерной ISA (PCI) платой – с местом проблем нет – задняя планка ISA (KHPC) Bracket. Поток (по, как я это безобразие назвал, «Control Bus») данных управления в обе стороны не превышает 1 Мбит/с. Поток данных (по, как я это безобразие назвал, «Data Bus») от плат расширения к PC пока не превышает 16 Мбит/с, но хочется развивать (потихонечку) одну из модификаций плат расширения... и раздуть поток до 105 Мбит/с, а затем и до 210 Мбит/с (из-за возрастающих пожеланий заказчика). Думаю надо бы переделать передачу данных на Ethernet (а лучше бы с полной поддержкой TCP/IP). А вот тут и возникают вопросы как бы это получше сделать... Т.к. изделия не серийные, то можно использовать компоненты (в т.ч. ПЛИС) ценой в несколько тысяч рублей. 1. Может собрать почти как и было: поставить 2 Startan-3AN TQ144 (теоретически запаять BGA корпуса можно у соседей, но разводкой печатной платы под BGA пока не занимался, а чувствую, что это не делается с наскоку)... и приторочить к каждому Spartan’у по некоей фиговине (у которой с одной стороны какая-то шина, а с другой Ethernet (а лучше сразу TCP/IP) - знать бы еще как оные зовутся ?) ? 2. А может быть поставить одну ПЛИС и собрать там могучий мультиплексор, разгребающий данные к/от Ethernet ? 3. Может есть другие варианты - получше гигабитного Ethernet ??? P.S. работаю только с ПЛИС Xilinx. С EDK пока еще не работал...

Могу только предложить разово попробовать поглядеть на максимальные/минимальные задержки при максимальном питании и минимальной температуре, и наоборот при минимальном питании ядра и максимальной (т.е. не заданной) температуре. А вопрос что больше jitter от V4 DCM или изменение задержек в кристалле (IBUFG, время распространения clock. время срабатывания триггеров, OBUF) - на мой взгляд оооочень интересный.

Обращаю внимание на то, что в мною предложенном варианте происходит компенсация не только задержки обычных цепей и OBUF, но также и IBUFG. Недостатком компенсации задержек для IBUFG и OBUF является то, что оба IBUFG должны иметь один и тот же стандарт ввода/вывода... Тоже относиться и к OBUF'чикам. Кстати, эта схема компенсации успешно работает на железной дороге уже не менее 2.5 лет. А там условия эксплуатации немного "жестковаты" - зимой холодно, летом на солнышке как-то "жарковато". Присоединяюсь к настойчивости - т.к. только использование обратной связи может компенсировать динамические изменения задержки распространения Clock в системе. Через что Вы заведёте обратную связь - не принципиально (через Ваш Clock Manager или через DCM), но на Вами используемых частотах компенсацию динамических изменений задержки распространения Clock обязательно необходимо проводить. Касательно constraint TEMPERATURE - очень полезный constraint позволяющий ограничить максимальную температуру для которой будет производиться расчет задержек. Но есть одна тонкая деталь... он задаёт не внешнюю температуру воздуха или корпуса ПЛИС, а the operating junction temperature - как я понимаю - температуру транзисторов ПЛИС, вроде бы оную можно прикинуть при помощи Power Estimator. Для выяснения минимальной задержки Вы можете воспользоваться временным моделированием, но брать из SDF файла не MAX задержки (как настроенно по умолчанию), а MIN задержки. Не путайте Skew и jitter: Skew - конструктивен, и не очень сильно зависит от температуры и питания ядра - это простая рассогласованность доставки clock. Jitter - это дрожания clock от такта к такту. Просто так их складывать нельзя, они существуют в параллельных плоскостях. Кстати Skew кристалла Вас вообще не должен волновать - работает там внутри и хорошо. А волновать Вас должен только Clock Skew для использованных ножек ввода/вывода - если оные стоят кучно, то и SKEW получается маленький... Да и если вопрос упирается в пикосекунды, то тут уже надо учитывать и разводку печатной платы. Ну а jitter от Xilinx мне самому очень не нравиться... Особенно после работы над системами синхронизации для систем передачи данных (аля междугородняя АТС). И чего они заразы не ставят аналоговые ФАПЧ (ну или более дорогие - гибридные) - в них с jitter гораздо лучше.

Есть идейка, не совсем то, что Вам нужно, но может навести на полезные мысли: Насколько я видел эксплуатацию Virtex-4 (у соседей) оный достаточно хорошо выделяет тепло, а значит и задержки в такой ПЛИС будут плавать от изменения температуры (в т.ч. и время распространения CLK). Такое безобразие можно компенсировать только использую цепь опбратной связи (а как Вы её воспользуетесь - это Ваше дело: может помучаться в внешним Clock Manager, можете использовать и встроенный DCM). Как-то в стареньком проекте (на Virtex-E) мне понадобилось сделать почти тоже, что и Вам, с тем лишь отличием, что у меня частоты в 1.9 раза ниже, но и ПЛИС тоже заметно тормознее. Пришлось сделать следующею петельку для цепи CLK: Пара нижних триггеров используются для создания тактирующего сигнала с частотой равной частоте входного IN_CLK. OUT_CLK_BF схемно подается на IN_CLK_BF. Триггеры выдающие сигнал на OBUF располагаются в IOB. В итоге удалось полность скомпенсировать время задержек внутри ПЛИС... и соответственно смена выходного сигнала OUT_DATA была хорошо привязана (c jitter'ом от DLL конечно же) к положительному фронту IN_CLK. У Вас Virtex-4, насколько я помню у него есть выходные DDR каскады - если это так, то Вы можете не уродоваться с удвоенной частотой, а просто воспользоваться DDR режимом: на вход одного триггера подать '1' на вход другого '0' и тогда должен получиться симпатичный CLK (совпадающий по частоте с тактирующим триггеры – по крайне мере так обещал Xilinx в одном из appnote для Spartan-3A). Но такие шаманства можно использовать только если у CLK, тактирующего выходные триггеры, очень малый SKEW. Расположение окошка с переходным состоянием выходных сигналов можно задавать фазой CLK запушенного в цепь обратной связи.

Могу ошибаться, но мне кажется эта цифра достаточно странной для Virtex-4... Поэтому задам ряд наводящих вопросов: 1. Используете ли Вы выходные триггеры по линиям данных для DAC? 2. Используете ли Вы DCM для DAC_Tx_CLK_P ? 3. Какой путь проходит DAC_Tx_CLK_P ? К сожалению по OFFSET OUT подсказать не могу... т.к. в моих проектах особой пользы от этого constraint не было: частота выходных сигналов до 100МГц - т.е. можно без подстраховки, а время задержки получалось постоянным и определялось только параметрами ПЛИС; из-за того что CLK у меня проходили по следующему пути: IBUFG->(DLL) ->BUFG->C(OFF) - использовались только специально предназначенные для CLK линии связи, а данные с выхода OFF сразу (с 0 задержкой) попадают на OBUF. А мнения по правильному применению OFFSET OUT сам бы с удовольствием послушал...

К сожалению, мои телепатические способности зимой находяться в глубокой спячке, а т.к. автор этой темы не соизволил подробно изложить свою проблему, то я проигнорировал подаваемые телепатическими способностями сигналы сквозь глубокую дрёму: "...наверное, у него много асинхронных интерфейсов... и на всё про всё чего-то не хватает..." Это очень губительная позиция для проекта, как Вы теперь убедились - у всех микросхем есть свои ограничения и они должны быть учтены при проектировании системы. В ПЛИС эти ограничения менее очевидны, но часто весьма существенны. Собственно говоря, с этого и надо было начинать. 1. (и главное) - Вам понадобится выставить в ISE количество BUFG равное 0, и самому поставить эти BUFG именно туда, где они более всего нужны (Вы проектируете систему - не синтезатор, поэтому, именно Вам решать, где наиболее ответственное место, а где можно и пойти на сделку с совестью). 2. для разрешения подобных проблем имеются constraint'ы: TIMESPEC PERIOD, USELOWSEKWLINES (иногда приходиться назначать его не только CLK, но и для сигналов пересекающих с пол кристалла - так они быстрее доходят), MAXSKEW, MAXDELAY. 3. при PAR попробуйте использовать Reentrant route - может чуточку улучшить результаты. 4. если само будет отказываться ложиться, то прийдётся занять (полу)ручной раскладкой по кристаллу, constraint'ы: RLOC, AREAGRROUP, LOC. 5. есть еще небольшой мухлёж... если Вам известна температура (максимальная) при которой будет работать Ваше изделие, то можно посчитать значение температуры для constraint'а TEMPERATURE. Если оно меньше, чем предельное для кристалла, то задержки рассчитанные для Вашей температуры будут меньше обычных для предельного случая. Ну вот, если по быстрому, токак-то так.

Могу, конечно, и заблуждаться, но я считаю, что в ПЛИС должно быть минимум разных Clock’ов. Я использую различные Clock’и только когда у этих clock’ов различная природа; например: интерфейс PCI (около 33МГц), еще какой-нибудь дурацкий интерфейс (8.192 МГц) и собственная частота системы (200Мгц) - такие clock'и различны по природе, и соответственно требуют синхронизационных механизмов для передачи данных между Clock Domain. Бывали случаи работы с базовой частотой, умноженной (на 2) или деленной (на 16) одним DLL - в этом случае особых проблем синхронизации нет, надо только очень аккуратно схему составлять (описывать), т.к. эти clock'и - родственники: имеют синхронно дрожащие фронты, и, соответственно, особых проблем не доставляющих. Если же необходимо уйти на clock с низкой частотой (например базовая частота / на 1024), то для этой цели можно завести специальный сигнал (равный ‘1’ только в течении одного периода базовой частоты, а остальные 1023 периода остающийся ‘0’) подмешиваемый в цепи Clock Enable блока работающего на «низкой частоте». Кстати по поводу различных clock. Как-то недавно принес мне студент схему... естественно не работающую, из-за того, что товарищ (четко, как учили на курсах по азам цифровой схемотезнике на рассыпухе) воспользовался схемным вводом, и подал на CLK вход триггера сигнал = BASE_CLK and EVENT, а на CE вход - сигнал BASE_CE. Простое переписывание этого безобразия на VHDL привело к тому, что синтезатор подал на CE сигнал = EVENT and BASE_CE, а чистый BASE_CLK на CLK вход триггера.

Что-то подсказывает мне по вышеописанному поведению implementator'а, что это наконец-таки вытащенный в графический интерфейс constraint Compression (принадлежащий к constraint Area Group). Почитайте про Area Group. Думаю у Вас в проекте есть фрагменты, которые работают на небольших частотах,.. эти фрагменты проекта можно объединить в Area Group и задать им Compression = 1, тогда даже unrelated logic будет ложиться в один slice - так можно уменьшить бестолковое использование slice. Для некоторых высокоскоростных блоков Compression = 1 - заметно помогает, некоторым - вредит, посему подбирайте по фрагментно, что Вы хотите получить от системы... На тему "рекурсии", возможно имелся ввиду режим работы PAR Reentrant Route. В ISE 3.x, использование этого режима давало заметный положительный эффект (иногда очень большой, иногда мелкий, но польза была).

Делают они подобные железяки с ооочень давно... Насколько я знаю еще с серии XC4000, ну и дошли до V5. Естественно накоплена некоторая куча наработок, которые не хочется терять... а на сколько готовое железо американского дяди подходит под имеющиеся аппаратные наработки - еще очень большой вопрос - тем более, если предположить, что наша команда идёт путем отличным от супостата (а это я исключать не могу). Как это звучит ни странно (для подобного рода устройств), но "железяки" Таганрогской команды покупаются (плохо или хорошо - не мне судить) - значит, всё-таки кто-то с ними работает. К сожалению, необходимо отметить, что сайт mvs.tsure.ru - находиться в подвешенном состоянии, т.к. TSURE (Таганрогского Государственного Радиотехнического Университета) уже нет. Эго в принудительном порядке влили в ЮФУ (Южный Федеральный Университет) и соответственно переименовали в ТТИ ЮФУ (Таганрогский Технологический Институт ЮФУ). За всеми этими передрягами плохо видно, что группа Левина несколько удалились от ТТИ ЮФУ. Если есть баАальшое желание узнать информацию от самих разработчиков, то думаю лучше им позвонить по телефону.

Насколько я знаю, ISE сама учитывает DCM Jitter, входной же jitter, Вам необходимо указать в описании входного CLK. А для себя, ну чтобы прикинуть что к чему, можно воспользоваться следующей формулкой: Tmin = T - 2*tj, где Tmin = возможный минимальный период CLK, T - идеальный период CLK (1/частоту CLK). tj - jitter (Ваши: "скажем, плюс/минус 100 пс") Идеальный период CLK уменьшается на 2tj потому, что предыдущий фронт мог задержаться на tj, а следующий может опередить на tj фронт идеального CLK. Но обычно jitter задается не +/- чего-то, а как максимальное пиковое отклонение фронтов, тогда, как и написал CDG - это пиковое отклонение надо вычитать из периода идеального CLK. Совет прост: очень внимательно читает Datasheet.

Дам несколько советов по применению CoolRuner: 1. У XPLA3 только один Universal OE - т.е. только одна линия глобального OE синхронно поступающая на любые OBUFT в любых функциональных блоках. Если необходимо иметь 2 "широких" шины с независимыми OE, то одну из этих шин желательно расположить в одном функциональном блоке. Наиболее разбросанная по различным функциональным блокам шина с третьим состоянием быдет управляться через Universal OE, остальные через локальные Control Term. 2. Прочитайте XAPP310 - Power-Up Reset Characteristics of CoolRunner XPLA3 CPLDs. 3. Прочитайте XAPP342 - XPLA3 I/O Cell Characteristics. Как это ни странно, но в этом документе более полно освещена архитектура линий управления XPLA3. Обратите внимание, что одновременно только 2 GCLK могут заходить в один функциональный блок. 4. Входные ножки Вы можете располагать практически в любом месте кристала - на входную задержку это не оказывает никакого влияния (входной сигнал сразу попадает в ZIA, ну или фиксируется в Fast Input триггере и всё-равно пападает в ZIA). 5. Особыми ножками в XPLA3 являются только GCLK, только с этих ножек CLK может попасть в линии Global Clock. Если четырёх независимых CLK нет, то можно использовать эти ноги, как обычные входы. Но неиспользуемые GCLK ножки необходимо подтянуть к питанию. 6. XPLA3 имеет в ножках ввода/вывода неотключаемай Half Latch. Эта заморочка уже обсуждалась на форуме не более года назад. 7. Если есть возможность, то наверное лучше использовать CoolRunner II - он дешевле, жрёт (греется) меньше и работает быстрее, имеет больше PT и входов в каждом функциональном блоке, не имеет HalfLatch, может работать с несколькими стандартами ввода/вывода одновременно (например LVTTL и LVCMOS25); но не имеет 5V толерантности, требует 2 разных номинала питания (1.8В для ядра и питание выходных буферов) и имеет обычные для CPLD линии управления (т.е. более убогие чем XPLA3).

Поглядел свой старенький проект для PCI... И нашел аналогичное место: сигнал AD_nOE должен синхронно разрешать работу 32 выходных буферов. Естественно пришлось создать 32 IOB триггера для AD_nOE. Из constraint'ов я обнаружил только следующее: attribute IOB of AD_nOE: signal is "true";, но и IOBUF находился в модуле верхнего уровня. Также были выполнены все ограничения налагаемые используемым семейством ПЛИС (Spartan-2), т.е. CLK и RST един для всех IOB триггеров, CE - индивидуален; все сбросы одного типа (синхронные). Проверьте FPGA_Editor'ом, что можно разместить в IOB вашей ПЛИС, и то ли генерирует Synplify. В более поздних проектах (синтезируемых XST) в которых IOBUF находился вместе с описанием триггеров, к IOB дописывался и attribute NOREDUCE of nOE: signal is "true"; Почитайте про constraint KEEP, в его описании упоминается NOMERGE, очень похоже, что Вам нужен именно NOMERGE.

С Virtex-4 не работал, но в аналогичных ситуациях жестко прописывал IOBDELAY = NONE, вот например так: NET "ADC_D_p[0]" LOC = "xxx" | IOBDELAY = NONE; Но у меня особого выбора и небыло в Virtex-E - либо Delay есть, либо нет.

Как-то поручили мне протестировать DSL модем, разрабатываемый на фирме... на каких скоростях и при какой длине кабеля оно работает. Плановая длина около 1.5 км. Было два вида экспериментов, первая - на живом кабеле (благо в закромах нашлась катушечка... эдак метров с 600 10 парного кабелька). А вторая серия на различного вида самапальных эмуляторах... RC, RLC и т.п. Вторая серия показа, что нечего себе мозгу парить, и если есть возможность, то брать живой кабель (чистенький и со склада) и работать с ним. Лучше брать многопарный, и когда кажется, что всё работает хорошо, в соседнюю пару подавать сигналы с другого аналогичного макета.

Загляните в 3 раздел Datasheet'а и Вы увидите, что все I/O Timing задаются для LVTTL25, а для остальных стандартов есть поправочная таблица (Input Timing Adjustments by IOSTANDARD и Output Timing Adjustments for IOB)... Поэтому, естественно, задержки в симуляторе зависят от того, какой стандарт прописан в ucf.

Боюсь Вы опять немного недочитали... DLL у Spartan2 устойчиво работает только с 25МГц... (DS001.PDF - Spartan-II FPGA Family Data Sheet -> Switching Characteristics -> DLL Timing Parameters). Обратите особое внимание DLL - это полностью цифровой ФАПЧ, а значит, он вносит в систему существенный jitter. У Spartan2 этот параметр достаточно плохой, поэтому, если есть возможность, DLL лучше вообще не использовать. Не совсем так... DLL компенсирует задержку clock в BUFG и задержку распространения по ПЛИС по отношению к входному clock. При необходимости DLL может умножить входной clock на 2 (если использовать каскадно, то можно умножить и на 4, но jitter тогда тоже больше). Время распространения clock по специально выделенным для этого линиям - минимально, но главное на этой линии крайне малое SKEW (неодновременность прихода сигнала в различные участки ПЛИС). Обычно используют только выходную линию CLK0, или CLK2X. CLK180 может понадобиться только профессионалам в особых очень редких случаях. CLK90 (или CLK270) используются при необходимости выкроить дополнительный тактик между CLK0 и not(CLK0). Еще, CLK90 может использоваться в системах коррекции фазы входных данных, собранных на логике; но, как показала практика, даже для этого случаю лучше использовать CLK2X и not(CLK2X). DCM - это более новый блок для манипуляций с clock, он появляется со Spartan3. Для более детального исследования ПЛИС, Вы можете использовать FPGA Editor - всё, что он показывает - в ПЛИС есть. Также, Вы можете посмотресть этой полезной программой, как развёлся Ваш проет - иногда (особенно во время освоения нового кристала) видны большие ляпсусы.