Beby

XST ошибался при оценке задержек в линиях в следующем случае: между элементами (особым образом подобранными) сигнал передаётся через Pin Wires (см. FPGA Editor), а XST для этой связи берёт задержку от Local Lines. Соответственно, ни про какую разрядность Pin Wires говорить невозможно, можно только говорить что: для конкретной FPGA можно сделать вот такое техническое ухищрение.

Это хорошо просматривается при помощи PhanAhead (окошко Process->User Constarints->Floorplan IO - Pre-Synthesis). И цветами разными банки помечены (меню View->Overlays) и разные разности можно увидеть рядом - где BRAM поближе, где TEMAC... для каких банков накидали BUFG, а для каких BUFR. Если чего, то для V-5 обычно банки с 1 по 4 - банки центральной колонки (в них в 2 раза меньше I/O ног, чем в обычных внешних банках). Кстати, если Вы использовали банк 1, то там же есть BUFG - чем он Вас не устраивает ?? (али уже все BUFG заперепользованы для других целей ?)

Гы-Гы. А когда припекало, то я заметно (более 10%) превышал частоту, указанную XST апосля синтеза, т.к. XST для оценки задержки берёт типовую задержку линии связи. А если самое тяжёлое место (с точки зрения XST) является хорошо оптимизированным RPM'ом (собственно говоря: для этого они и нужны), то задержки оказываются меньше типовых, а частота - выше.

В окне Process выбираем Implementation ->Place&Route->Generate Post-Place&Route Static Timing - тыкаем правой кнопкой и выбираем Properties.... Тут ставил галочку Perform Advanced Analysis - Потом смотрим временной отчёт (и при необходимости читаем в документации, что это за такой Advanced Timing Analysis). Но даже эта процедура не даст вам ответ о максимально возможной частоте, на которую возможно развести Ваш проект: Вы задали constraint - как только P&R его выполнил, то улучшения разводки оканчиваются. Весьма вероятно, что можно достичь и большей частоты, но если все требования уже выполнены, то "зачем же тогда тратить время на улучшение проекта ??". Поэтому остаётся только потихоньку ужесточать constraint и поглядывать - когда же время на разводку начинает резко увеличиваться...

Ну так, map же ДАЖЕ напишет Warning - а смотрите ли Вы на них,.. или не смотрите - это уже персонально Ваши проблемы. Важно, что Warning принципиально появится. Да, если Вы любите острые ощущения, то, пожалуй, OFFSET OUT - лишний constraint. Я же обычно добавляю OFFSET OUT на критичные ножки при любом раскладе: для цепей, где это не важно - развожу проект с пустым OFFSET OUT, смотрю получившиеся значения и вношу их в OFFSET OUT; и если что-то в проекте уносит - я это вижу. Но, опять-таки, некоторые любят острые ощущения... я же отношусь к перестрахуям - область применения обязывает.

Ну слабенькая матрица соединений у них, судя по картинкам,... я бы даже сказал убогая. Как-никак, а в FPGA interconnection matrix по гибче будет. Как я глядел, современные ускорители вычислений на ПЛИС имеют заметно более развитую (и оптимизированную под задачу) систему соединений,.. чем и берём пока, ну и конечно приятно, что вычислитель на FPGA, при необходимости при переконфигурации, может перераспределить разрядности вычислителей в их число, что невозможно для большинства процессорных элементов.

Ага, а чтобы такого не было, надо использовать constraint IOB, принуждающий среду укладывать нужные триггеры в IOB. Ну и еще необходимо использовать constraint'ы OFFSET IN/OUT, которые задают те самые временные ограничения. Т.е. если наблюдается описанный негативный эффект, то:

Да, есть такое дело. 1. Обычно плывут не за'constraint'ненные или неправильно за'constraint'ненные цепи. Более вероятны потаённые глюки в местах перехода данных с одного clock domain в другой. 2. Частенько, при добавление логических проб, они устанавливаются не только на выходы триггеров, но и на цепи, сформированные логикой - а это может изменить разбивку логики на LUT'ы в результате чего вылезают ранее не выявленные проблемы, описанные в предыдущем пункте. 3. Так бывает, что некоторая не очень новая версия ISE не правильно рассчитывает задержки для Hardware IP, например ISE 9.2 (без SP) неправильно проводила временной анализ Virtex-5 PCI-E Endpoint'а.

Я затруднюсь ответить, у нас на фирме используются 2 версии: 1. ISE 11.5 для новых проектов на V-6. 2. ISE 10.1SP3 для подавляющего большинства проектов - так исторически сложилось, а менять нет ни времени, ни желания. (у ISE 10.1 - огромные проблемы с Cleanup Project, если проект содержал coregen элементы и схемы - её лучше вообще не использовать). P.S. Если Вы будете писать на HDL, и не будете использовать CoreGen и schematic, то проблем при последующем переходе с 11.5 на 12.2 быть не должно.

Ну, тут тяжело сказать,.. ISE 12.1 - это фактически ISE 11.6 (кое-где в документации это проскакивает). Для установки ISE 12.1 на не английскую (или не японскую) винду нужен patch. Есть еще пачка patch'чей устраняющие те или иные промахи разработчиков... Для ISE 11.5 тоже могут понадобиться patch'и, чтобы исчез ряд ошибок отсутствующий в 11.4. А 11.4 имеет "не уточнённые" (т.е. завышенные) timing для Spatran/Virtex-6 и свои ошибки, поправленные в 11.5 или 11.6 (12.1). Ну вот как-то так... P.S. На моей фирме для работы с V-6 пока пользуются ISE 11.5 + some patches, на ISE 12.1 пока пересаживаться не хотят - говорят "ждём 12.2 Update".

Ну, если про XC9500 вспомнили... то уж тогда приятнее работать с XPLA3 (Cool Runner 1) Поглядел название Subj внимательнее: в нём говорится только про входы... для перехода с 5V->3.3V были разработаны 2 семейства логики LVC и LVT (по крайней мере, так утверждают на www.ti.com). Использования LVC для перехода 5V->3.3V – за 4 года эксплуатации устройств в индустриальных условиях проблем не выявлено.

Ну... с SSD еще не экспериментировал,.. зато баловался жестокой дефрагментацией (с ручным указанием, что и как сгруппировать и в куда положить на HDD) - результаты были вполне закономерными, на ISE от 1.5 до 10.1: резко уменьшалось время чтения с HDD (раз в 5-10 по сравнению с обычной дефрагментацией от WinXP)... Но вот незадача, после всех оптимизаций суммарное время чтения/записи файлов (при полной компиляции проекта) занимает где-то от 5 до 40 секунд (в зависимости от проекта). И для мелких проектов без включенных оптимизаций дает неплохой выигрыш, но при работе с крупными проектами выгода стремиться к нулю. Не думаю, что SSD даст ощутимое превосходство, по сравнению с хорошо продефрагментированным HDD, единственное, что можно сказать в пользу SSD - практически не надо заморачиваться с дефрагментацией и помнить про какие-то там настройки файлового кэша в системе. С общей идеей оценки - согласен, но надо бы глядеть не только сколько МБ пишется/читается, а и за какое время это происходит,.. а если еще руку на HDD положить, то станет хорошо понятно, когда же он и сколько конвульсирует головками...

Есть у Xilinx такой забавный документ CPLD I/O User Guide, и есть на 20 станице презабавнейшая формула, по которой супостат оценивает: сколько протянет ПЛИС при превышении допустимых напряжений... Конечно, у Вас не CoolRunner II, о котором там говорится, но сдаётся мне, что Вы сможете не хуже супостата прикинуть - на сколько же Вы у ПЛИС укоротили (для artem79) или укорачиваете (для yakub_EZ) дорожку на тот свет.

Наверное, Вы воспользовались Behavairal Simulation (функциональным моделированием) - быстрым, но без учета различных задержек. А вот есть еще PostFit Simulation - уже с учётом конкретного размещения по кристаллу - медленное и весьма поучительное (для освоения ПЛИС просто необходимо несколько раз её погонять... потом можно будет обходиться и Behavairal Simulation - так будет быстрее)

Т.к. телепаты уже успели свалить в отпуск, то давайте сразу определимся: 1. Вы - студент ? 2. Вам надо сделать реальное работающее устройство или сдать дипломный проект, курсовик и т.п./родить отписку, а не заниматься разработкой ? - уж простите, но как-то Вы странно выражаете свои мысли...

А Вы редактируйте HDL файлы в AHDL, намного удобнее и приятнее. Ну а ISE используйте только как implement'атор. А с синтезатором - по желанию: можно и встроенный пользовать, а можно и внешний...

Что-то не припомню, чтобы в IEEE802.3 был определён термин "Ethrnet Controller". Вы, это - того, определитесь, что же именно Вам надо. Есть куча разных микросхем (и микросборок) - и решают они заметно разные задачи,.. да и возможности имеют заметно разные - большую часть из них можно обозвать ethernet контроллер'ом. Ну вот, например, есть микросхемы - с одной стороны PCI, с другой - Ethernet - можно сказать практически готовая сетевуха. Есть и более хитрые сборки Ethernet (а на нём, заодно, и ряд протоколов TCP/IP) <-> высокоскоростной SPI. А есть просто Ethnernet Phy Layer Device (с одной стороны MII/GMII и т.п.), а с другой стороны Ethernet - это уже прицепляется к готовым MAC ядрам (реализованных в ПЛИС, али в еще какой бякости). Сформулируйте правильно (и грамотно) вопрос и наверняка получите содержательный ответ. Пока что Ваш вопрос выглядит, мягко говоря - несколько странным.

Virtex-6 - хранит прошивку в статической памяти (естественно при снятии Vccint эта память "забывает" свои данные), все способы загрузки "прошивки" (configaration bitstream) детально изложены в Virtex-6 FPGA Configuration User Guide. Собственно говоря "внешняя память" не нужна, нужен источник данных - Flash ROM (SPI, Parallel ну или Xilinx Platform Flash), MC (со встроенной Flash ROM) али чего еще, что сможет заливать прошивку в ПЛИС. Сам с EDK не работал, но, насколько слышал - это зависит от самой программы - если она небольшая, то была возможность встроить её (программу) в configuration bitstream. ну про Vccint я уже писал...

На сколько я помню, "несколько буферов от Xilinx" - это Xilinx Parallel Cable III, а в IV версии уже ПЛИС стоит. Сдаётся мне XC6SLX16-2CSG324CES стоит более 50$ (в Москве), т.е. некоторая покупательная способность у Вас всё-таки есть... Так что берите Platform Cable USB II - дешевле выйдет (если учесть материально-временные затраты на создание аналога или мучения с частичной совместимость не Xilinx шнурков - об этом недавно было несколько тем).

Спасибо за ответы. Сначала постараемся всё-таки задружиться с Marvall, ну а коли они начнут выёживаться - тогда попробуем Eth Phy от Micrell.

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

Хм... А в стандарте для выходных буферов вообще-то нормирован ток, а не напряжение на сенсорном резисторе приёмника. А ток обычно уровнями не называется... но это мелочи. По идеи с этой линии в куда-то должен течь ток, и это в куда-то должно быть немного повыше 3.3В/2. Ну, в принципе, Вы можете использовать и встроенный компаратор Smartan-3A (только не используйте встроенные резисторы - они кривые), но прийдётся собрать схемку, генерирующую опорное напряжение, на его комплиментарный вход компаратора, с которым будет сравниваться напряжение на основном входе.

Уточните, что это за зверь такой single-ended LVPECL. Какие и куда текут токи, какие напряжения и п.т. А еще расскажите откуда вы его взялит (с какого генераьтора или с какой микрухи) - возможно, тогда будет проще дать ответ.

Доброго времени суток. Так случилось, что фирма (в которой я сейчас работаю) несколько лет назад распробовала Marvell 88E1111 (удачно были запущены макетные платы, получены хороший результаты по стабильности передачи данных). Потом попробовали подписать NDA с Marvell - и нифига из этого не вышло. Вот и живём пока на сворованной документации, обрывках рекомендаций по разводке и на серых поставках этих микросхем - но хочется то по-человечески ! А вот недавно был куплен в IEEE OUI. И теперь становится вопрос о повторном запросе NDA. К сожалению, наши реальные потребности невелики: от 50 до 500 микросхем в год. А теперь вопросы: 1. Как "правильно" (чего можно обещать и потом обязательно нужно делать, чего можно обещать и потом не делать, а чего категорически нельзя обещать) подписать NDA с Marvell ? 2. Если Marvell окажется весьма кочеврёжестым вариант (т.е. опять откажет) - какую фирму производитель Ethernet Physics посоветуете ?

Эх, как же выродились аппаратчики... - до уровня средненьких программистов. Для принудительного использования линий в качестве GSR, GTS и т.п - есть 2 пути: 1. читаем cgd.pdf про constraint BUFG. 2. читаем cpld_all_scm.pdf (название дано для ISE10.1) про примитивы BUFG, BUFGSR и BUFGTS. В обоих случаях, для предотвращения недоразумений, на все входы и выходы растыкиваем IBUF/OBUF - по необходимости.