evsh

Спасибо, всё получилось. Не первый раз проходил и в ISE, и в Виваде. Но давно, вылетело из головы. Сохраняю здесь как получить доступ к Engineering Samples (ES1) кристаллам в Vivado на примере Versal. 1. Найти файл /Xilinx/Vivado/20xx.x/data/parts/xilinx/versal/public/ibis/FileMap.txt Там будет список файлов с PN всех кристаллов для данной версии. Список ключей должен быть вида (корпус, времянка не учитываются) вида: XCVH1522-ES1 XCVH1522-ES1_bitgen 2. В файл .Xilinx/Vivado_init.tcl добавить строку: enable_beta_device xcvh* или enable_beta_device * - включить все Если этого файла нет, нужно создать.

Подскажите, как включить поддержку Versal ES кристаллов в Vivado? Видны только Production. Хотя бы название ключа.

"Переходи на тёмную сторону, у нас есть печеньки!" (с) У нас SATA отлично работает в Kintex7. Большая часть проблем - собственные ляпы и особенности работы отдельных моделей винчестеров. Но это уже уровень транспортника, к кристаллу не имеет отношения. С физикой вопросов не было.

signal led_counter : std_logic_vector(24 downto 0); begin LED_CNTR : process (RESET, CLK) begin if RESET = '1' then led_counter <= (others => '0'); elsif rising_edge(CLK) then led_counter <= led_counter + '1'; end if; end process; LED_OREG : process (RESET, CLK) begin if RESET = '1' then USER_LED <= '0'; elsif rising_edge(CLK) then USER_LED <= led_counter(24); end if; end process;

Не вижу решительно никакого смысла в Evaluation на начальном этапе без, даже минимальной, цели. Нужно изучить схемотехнику ПЛИС, понять какие возможности ПЛИСы предоставляют. Изучить HDL, понять связь между конструкциями языка и реализацией в ПЛИС. Разобраться с пакетами ПО: построением проекта, моделированием, синтезом, созданием constrain'ов, связь с Матлабом. Вот когда будут идеи, что захочется реализовать, хотя бы из какой области: DSP, видео, звук, интерфейсы и т.д. - вот тогда и стоит обратить внимание на платы. Уже будет понятно, сколько хотя бы примерно ресурсов требуется, какие аппаратные ядра нужны, какая периферия: LCD экран, DVI, SATA, PCIe, сколько и какой внешней памяти, ЦАП, АЦП (или возможность поставить модуль в формате FMC), гигабитные трансиверы (и какого типа порты), USB, многое другое. Иначе, с большой вероятностью, выкинутые деньги. Я бы их отложил на оригинальный JTAG кабель - пользы в будущем больше. :)

http://www.xilinx.com/support/documentatio...uides/ug380.pdf Вроде всё понятно расписано.

Не совсем так. Если раньше было доступно два асинхронных входа одновременно: Preset и Clear, то в V6 остался только один на выбор. Поэтому, если в старом коде используются два асинхронных сигнала (и сброс и установка), это порождает комбинаторную петлю, с не всегда предсказуемым результатом. Как в плане корректности ковременных констрэйнов, так и в логике работы реальной схемы. Маппер и синтезатор об этом предупреждают. От себя могу сказать, как действовал бы сам: 0. Внимательно прочитал все сообщения синтеза, трансляции и рутера для старого проекта. Вспомнил где были проблемы, если подставляли костыли, то где и какие. 1. Прочитал свежие: Constraints Guide, XST User Guide for Virtex-6, Spartan-6, and 7 Series Devices, Synthesis and Simulation Design Guide, Virtex-6 Libraries Guide for HDL Designs. 2. Внимательно прочитал все сообщения синтеза, трансляции и рутера для нового проекта. 3. Если для синтеза используется Synplify, проверил, не остались ли включены по умолчанию опции "Autoconstraint" и "Write Vendor Constraint File". 4. Обратил внимание на IP и примитивы, используемые в схеме, особенно: память, тактовые буферы и генераторы (DCM, PLL), регистры (на предмет вышеуказанных особенностей), IODELAY, заменил на подходящие именно для V6. 5. Просмотрел временные констрэйны: всё ли задано, включая multipass, не перегружены ли sdc/ucf дублирующими констрэйнами и всякими натяжками (старыми костылями) - это может здорово замедлять и ухудшать трассировку. Для рутеров современных кристаллов сейчас достаточно указывать лишь входную частоту с пина, все последующие частоты на буферах и выходах PLL они определяют и вычисляют сами. 6. Открыл имеющуюся ucf через "Create Timing Constraints", удивился куче сообщений о некорректных назначениях, исправил их. 7. Как уже отметил Boris_TS, очень внимательно посмотрел на RLOC'и, если они есть - действительно ли они необходимы, грохнул всё необязательное. 8. Снова внимательно просмотрел репортажи, особенно рутера: все ли констрэйны прошли, всё ли правильно задано, ничего не забыто. 9. Дальше уже можно открывать Timing Analyzer и разбираться с временными ошибками. Как-то так.

RTL Vewer есть практически во всех современных средствах синтеза. Самый же удобный просмотр схемы, RTL и технологической для FPGA, что видел, реализован в Synplify.

В Q11 SP1 при генерации контроллеров памяти QDR/DDR для Stratix 4/5 происходит ошибка и не генерируется example design. Это я у квартуса не все приступы жадности вылечил или проблема общая?

Это вопрос реализации обмена процессора с системными устройствами. Тут уж Intel/Microsoft как хотят, так и поступают. Можно лишь оценивать эффективность решения. Вот ограничения чипсета на длину пакета (128/256 байт), когда устройсто в режиме DMA при всём желании не может передавать больши блоки данных - это, действительно, не полная поддержка стандарта PCI-E.

Обычно используем DMA и скорость записи/чтения в режиме completer не замеряли. Но недавно полез с чипскопом в pci-ный модуль и заметил следующее. Раньше, на старых материнских платах, начиная с P4 до Core2Duo под Win2k/2003Server, обмен процессора с девайсом производился всегда строго по одному слову (4 байта). Правда, программную часть толком не копали. На современных же системах: Core i7/Win7 обмен идёт уже блоками по 16 слов (64 байта). Встречаются транзакции и меньшей длины, но основной поток всё же 16DW. И ещё один момент. Есть такое мнение, существенный вклад тут и чипсета. В системе на i7 ещё под Win2003 наблюдались пересылки по 2-3-4DW. Вероятно, хост-контроллер сам уже умеет склеивать последовательные транзакции.

Для sys_cpt 11.0 SP1 x64 адрес: 0xA30C0. Для x32 адрес остался прежний: 0xE3370.

Spartan-6 поддерживает только PCI-E x1.

Ну да. Разводка простенькой системы на PCI-E под 5-й Stratix отжирает в пике до 4.7Гб.

Я с Microblaze не работаю. Но коллеги уже месяца два отлаживают проект с ним, о проблемах с CS не говорили ни разу. Используют его постоянно. Были какие-то другие глюки с EDK, после установки апдейта для 13.1 они все ушли.

Для современных проектов нужно много памяти. 3Гб уже мало для нормальной работы. То есть, 64бит однозначно. Под W7-64 то, что нужно, работает нормально. Nios, DSP Builder пока что не используются, ими можно пожертвовать.

Честно сказать, не понимаю, какие проблемы могут быть с Чипскопом. Когда он только появился, почитал доки, попробовал всякие варианты, за полдня разобрался полностью. Были у него свои глюки и тромоза анализатора при отображении больших массивов данных. Но в целом всё просто и понятно. Такие сложности бывают как раз когда приноровился работать с другим софтом и с наскоку пытаюсь делать в новом софте ровно также как привык в старом. Ну или тупь нападает. Эт нормально.) Я вот тоже в Чиппланёре искал, как залочить GXB на нужное место. Или долго думал, почему он не показывает номера пинов трансиверов - это ведь так естественно: смотришь, и сразу видишь внутреннюю структуру кристалла, как расположены трансиверы, на какие ноги подключены, где PCI-E - то, что PCB дизайнеры первым делом спрашивают. В ISE это видно в любом редакторе. Вряд ли. В Квартусе он через Tools запускается. А в ISE, чтобы корген в текущем проекте открылся запускать нужно было через New Source. Недоработка эргономическая вообще-то, в 13.1 исправили.

Коллеги, с какой ОС сейчас работаете? Есть ли какие-то проблемы с рабочим софтом? Замерял ли кто разницу в скорости? На работе Xilinx в основном. ISE13 полностью поддерживает W7, глюков не замечено, всё устраивает. С Quartus, Modelsim, Synplify тоже проблем нет. Но домашний компютер - другое дело. Есть ряд пожилой, но вполне себе бодрой периферии. Принтер, сканер. На которые в семёрке уже драйверов или нет, или сделано через этсамое. Не считая особенностей нового интерфейса вообще. Поэтому возникло желание дома поставить XP64 и забыть обо всех этих лишних проблемах. Наступит ли счастье? Производители софта консервативны (Altera DSP Builder до сих пор официально не держат W7) и полностью отказываться от старой винды не спешат. Подозреваю, что парк машин с XP ещё приличный. Но есть ли какая-то разница в производительности, поддержке как раз новых фич, современных многоядерных процессоров, больших объёмов памяти?

Порой сам компонент (если 1-2 или задаются через generic) вставить быстрей и проще, чем в гуях конфигурировать память, а потом почти точно так же вставлять этот компонент.) Опять же, иногда это удобно, когда проект тяжёлый и разводить долго. Несколько лет назад пользовался (а лет 10 назад регулярно). Сейчас да, давно так не делал. В 12-м чипскопом нало пользовался, но имхо в обоих всё ещё нужно было отдельно подгружать .cdc файл. В 13 версии эта опция включается галочкой при загрузке проекта. Недавно начал осваивать Квартус. Матов на него поначалу сложил - не счесть. То не так, это не эдак, всё не на месте. Плюс другая структура кристалла, другая форма документации. В условиях, когда проект нужно сделать быстро, многие вроде бы элементарные действия отнимают просто уйму времени и это может раздражать. Плюс ещё спросить не у кого. Ну не будешь же при каждом затыке на форум писать.) Потом освоился, ничего, жить можно. Так что читать про все эти "первые впечатления от ISE" забавно на самом деле.) Это вопрос опыта, привычек и желания учиться. Когда 10 лет работаешь в одной среде, с кристаллами одной фирмы, "пригрелся", всё уже знакомое и понятное, многое делается просто на автомате. И переход на другую платформу может быть тягостным и неприятным. Ну как же - тут у меня всё отлично получалось, всё было логично и понятно! 5сек и всё готово. А тут засунули не пойми-разбери куда, это же заново учиться надо. В обоих средах есть как удобные, удачные решения, так и не очень. Есть свои глюки и приятные фенечки. В какой на сколько грамм больше - дело 10-е, считаю. В более-менее сложном проекте процесс изучения документации, проработки структуры, алгоритмов, интерфейсов, построение симуляционных моделей, сама функциональная симуляция, поиск ошибок, почёсывание маковки над полуработающей платой - занимают куда больше времени, чем ввод текста на HDL, задание констрэйнов и жамканье кнопок интерфейса. P.S. У нас сотрудники молодые недавно пришли, до этого как раз с Альтеры. Поначалу тоже ворчали на ISE. Но освоились довольно быстро и сейчас хорошо спокойно работают. И на вопрос "где удобней работать?" уже задумываются.)

Спасибо. Нашли ошибку: строб спецсимвола выскакивал когда этого не надо. Всё сразу зажило-закрутилось без проблем во всех каналах. Собственно, 8-канальный RAID уже практически готов. )

Так, с зависаниями шины разобрались - своя глупость. Но по какой причине высокий уровень ошибок CRC, не понятно.

Отлаживаем SATA контроллер в кристалле Virtex5. Режим работы - SATA2.0 (3Гбита). При коротких пересылках по 1-2 сектора всё работает хорошо. А вот при передачи больших объёмов данных, при блоках больше 4 секторов возникают проблемы: 1. Высокий уровень ошибок CRC на шине. На приёме от дисковода - ~2 ошибки на 15Гб, на передаче те же 2, но на 100Мб. 2. Зависания шины. Причём на двух разных дисководах это проявляется по разному. Один в какой-то момент не подтверждает приём данных и далее не реагирует ни на какие команды. Второй подтверждает приём, но далее также ни на что не реагирует. Выяснили, что всегда (по крайней мере в большинстве случаев) зависанию предшествует передача символа Align во время фазы данных. В спецификации нет никаких запретов на выдачу Align'а. Хотя опытным путём выяснили, что если выравнивание происходит во время старта кадра - шина также виснет. Хорошо, эту ситуацию зарубили. Но что делать с выравниванием во время прохождения обычного тела кадра? Возможно, проблема в линии - вероятно, сбой происходит именно в момент выравнивания и это вешает шину. Подключение по стандартной схеме: на всех линиях стоят конденсаторы 10nF. Все питания в норме. Во всех каналах ситуация одна и та же. Регулировка амплитуды сигнала не даёт толком ничего. PCI-E в этом же кристалле работает без проблем.

Можно и на лету перезагружать часть кристалла с PCI через ICAP порт. Создать блок, включающий в себя: контроллер PCI-E, контроллер конфигурации, ICAP модуль. Они будут работать всегда. Остальные блоки загружаются/перезагружаются по мере надобности. Подробно в UG702 - Partial Reconfiguration User Guide

У нас PCB дизайнеры каждый раз просят такую информацию. Особенно если плата стартует одновременно с проектом ПЛИС. Интресуются куда что подключать, лучше понимать как повернуть кристалл на плате, что куда тяготеет. Решающего значения для проекта PCB такая схема, конечно, не имеет. Но с подобной картинкой в руках объяснять и рисовать было бы несколько удобней, наглядней.

Есть кристалл StratixIV. В нём есть GXB Transceiver. У трансивера есть порт rx_clkout - восстановленная частота параллельных данных с приёмной CDR. Подаю её на вход FIFO и обычную PLL чтобы поделить. Квартус ругается: Error: Clock input port inclk[0] of PLL "pll_dec:DECODER_PLL|altpll:altpll_component|pll_dec_altpll:auto_generated|p ll1" must be driven by a non-inverted input pin or another PLL, optionally through a Clock Control block Info: Input port INCLK[0] of node "pll_dec:DECODER_PLL|altpll:altpll_component|pll_dec_altpll:auto_generated|p ll1" is driven by gtx_10g_alt4gxb:GTX_10G|rx_coreclk_in[0] which is CLKOUT output port of GXB Receiver channel PCS type node gtx_10g_alt4gxb:GTX_10G|receive_pcs0 В StratixIV Handbook, в Table 2–14. FPGA Fabric-Transceiver Interface Clocks сказано: rx_clkout - Phase compensation FIFO clock - Global clock, Regional clock, Periphery clock Что я делаю не так? Как правильно подать приёмную частоту на PLL?