Raven
-
Постов
909 -
Зарегистрирован
-
Посещение
-
Победитель дней
4
Сообщения, опубликованные Raven
-
-
Тезрают меня смутные сомнения, что эксперимент Ваш некорректен. Так быть не должно. Скорее всего Вы квартус девятый подкрутили русским народным способом. А экспериментировать в данном случае нужно на честном квартусе.
Спасибо за ответ. Выходит, что по теории все должно быть так, как я и ожидал (за что уплатил, то и имеешь на протяжении бесконечного времени). Остается вопрос с экспериментом. Его ставил не я, но ставившего заподозрить в попытке смухлевать не могу. Совершенно точно могу сказать, что Quartus был честный. Тем не менее неплохо бы перепроверить, но с воссозданием условий эксперимента проблема - сейчас уже все лицензии свежие (и на Квартус, и на НИОС), а лицензионный сервер не в моей власти. Придется покумекать.
-
Хотелось бы получить окончательный ответ на такой вопрос.
Годовая лицензия на Quartus дает возможность пользоваться всеми обновлениями оного сотоварищи (SOPC Builder), выпущенных в течение этого года (и даже более ранними версиями, кажется, если это кому-то надо, но не уверен). Набор IP Cores также обновляется от версии к версии (по крайней мере, номинально), включая и NIOS-II core. Если имеешь лицензию на Quartus 2007 года, то воспользоваться ядрами из набора года 2009, само собой, не получится.
Вопрос: если имеется честная лицензия на NIOS-II, купленная, например, в 2005, то остается ли она в полной силе для, скажем, Quartus 9 выпуска 2009 года? Эксперимент говорит, что работает. Очевидно, дело в условиях лицензирования. Но все же хотелось бы получить окончательное авторитетное разъяснение (например, от Stewart Little). Кстати, с какими еще ядрами такая же история?
-
Дык я на другом компьютере пробовал.Правда свою лицензию ему подсунул,но вроде ж она к конкретному HOSTID привязана и на другом компе не должна сработать.
Ну, так можно ведь HOSTID поменять. А если при этом еще и вылеченный Квартус применить (у которого sys_cpt.dll вылечена), то все должно работать на ура.
-
Еще одна из возможных причин - данные цепи пересекают границу разных clk domains. Внимательно посмотрите, что это за пути распространения сигналов.
-
P.S. On-chip memory не использую.
Т.е., вы хотите сказать, что код программы у вас размещается во внешней, пока непроверенной памяти? Или я что-то не понимаю? Если это так, то возможно, в этом-то и причина.
-
Как говорится - случай классический - RTFM
Рад, если смог чем-то помочь. -
Вот вы говорите: "1) грузим в цепочку IR-ов единички в избыточном количестве". Описанная мной метода (на авторство, ессно, не претендую - уши растут из стандарта :-)), как раз и позволяет не гадать, не загружать единички в избыточном кол-ве (а кстати, сколько это - избыточное количество для конкретно взятой серьезной цепочки?), а точно определить кол-во TAP'ов в цепи. Прочитайте внимательнее.
В результате описанной процедуры мы имеем пока описание JTAG-chain'а в виде последовательности TAP'ов, каждый из которых представлен либо 1) BYPASS rg (в свою очередь, представлен одиночным "0" в выходной последовательности), либо 2) ID rg (представлен 32-битовым кодом, младшие 2 бита которого по стандарту д.б. "01"). Теперь для тех TAP'ов, для которых известен ID, можно определить производителя и модель чипа. Для тех же, которые ID не имеют - придется все же провести небольшой reverse engineering для сопоставления конкретного чипа (с конкретной маркировкой ;-)) конкретному TAP'у в цепочке. Но, сдается мне, что все более-менее современные чипы ID-регистр содержат, так что к последнему варианту вряд ли придется прибегать.
Ну, а коль скоро мы сопоставили каждому TAP'у производителя и модель чипа, можно доставать из Web'а соответствующие bsd-файлы, в которых описана масса другого интересного: и длина регистра команд, и коды команд (по крайней мере, public-команд), и полное описание всего boundary scan регистра, и многое другое. А дальше - все зависит от конечной цели...
-
Я буквально на днях закончил прочтение IEEE 1149.1, и не возьму в толк, отчего возник спор вокруг того, что достаточно ясно описано в стандарте. Чипы, поддерживающие JTAG, обязаны, как минимум, иметь на борту BYPASS register. Они также могут иметь опциональный ID регистр. При переходе в состояние Test-Logic-Reset (тем или иным способом) таковой чип обязан подключить между TDI и TDO либо BYPASS (если нету IDCODE), либо ID (если таковой есть, то именно его). BYPASS всегда инициализируется 0, а ID в 2-х младших битах обязан иметь pattern "01". Длина ID регистра известна (32 бита) и зафиксирована стандартом. Если добавить сюда еще необходимость начинать ВДВИГАЕМУЮ битовую последовательность зарезервированным fake-ID кодом ("xxxxx000011111111" <- lsb), то мы получаем все возможности для того, чтобы:
1) определять начало и конец "отклика" JTAG-цепочки;
2) отделять друг от друга последовательности, соответствующие BYPASS и ID регистрам;
3) соотвтественно, определять место в цепочке соответствующих чипов с BYPASS/ID и вести их учет.
Прошу извинить обчество, если вышеперечисленное было и так всем ясно.
-
Начиная где-то с PCI-ных 33 МГц, а может, и при гораздо меньших частотах, вопрос о том, ставить или нет согласующие резисторы даже не должен возникать - конечно ставить. Начиная с тактового сигнала - это в первую очередь. Его, к тому же, надо разводить по методу точка-точка от источника (это замечание важно, если у вас несколько потребителей). Затем по приоритету идут сигналы управления. А на частотах выше 66 МГц профессионально выполненный дизайн мог бы и на линиях данных-адреса согласующие сопротивления иметь. Поверьте: дешевле заложить это сейчас, чем потом страдать от плохого качества сигналов при попытках отловить нестабильно проявляющиеся "демонические" баги (это те, вначале были, потом, вроде, самоликвидировались, а перед завершением работ на ночном прогоне опять вдруг появились :-)).
Наука утверждает, что на таких частотах дорожки на печатной плате надо рассматривать как длинные линии. Так давайте же их и будем так рассматривать, а значит, проявлять к ним должное уважение. Ударим согласующим резистором по бездорожью, т.е., по плохому сигналу! :) ...
Напоследок приведу пару примеров из собственного опыта.
1. Резко отрицательный. Линия тактирования последовательного канала нескольких DSP от TI была разведена в виде развесистого дерева, согласующих резисторов нету вовсе, частота тактирования - всего 2 МГц!! (из-за этого, собственно, мы и пренебрегли всеми элементарными правилами. И как скоро оказалось - очень зря!). Вот уж была проблема, так проблема: время от времени, совершенно случайно и редко к тому же (просто беда для дебагирования), происходили сбои в передаче данных по последовательному каналу. Неделю или даже больше мы потратили на последовательное сужение круга подозреваемых, и в конце концов виновник был найден. Им оказался малюсенький такой горбик на фронте клока, наблюдавшийся в точке прихода клока к конкретному DSP (в дополнение ко всему, не все DSP еще и были подвержены этой проблеме с искажением данных!). А возникал этот горбик из-за отсутствия согласования и многочисленных отражений в нашей весьма неоднородной линии передачи тактового сигнала (развесистое дерево). Решить проблему удалось, подрезав кое-где дорожки и напаяв навесные провода, разводящие клоки от источника к каждому потребителю персонально, через согласующие резисторы (хорошо плата прототипная была, допускалась еще одна итерация в разработке, а не то...).
2. Положительный. Коммуникационный контроллер с SDRAM, работающей на частоте 50 или 66 МГц. Согласующие резисторы на линиях управления и клоков, клоки разведены по методу точка-точка. Все стабильно работало, несмотря на то, что шина данных и адреса представляла из себя довольно рискованную развесистую и несколько длинноватую конструкцию (по другому было чипы не расположить, получалось только еще хуже).
-
Как показывает практика, требуемую скорость передачи данных (40-50 МБ/с) вы получите без чересчур больших проблем. К примеру, одна из наших плат показывает пропускную способность по PCI в районе 45 МБ/с при работе в двух направлениях и заложенной длине пакетов не более 16. Увеличить эту длину при необходимости - не проблема. Конечно, необходимо будет предусмотреть буферизацию данных в устройстве, чтобы не вносить дополнительных вынужденных задержек.
Разница между операциями записи и чтения по эффективности для пакетных транзакций (а только о таких в данном случае и может идти речь) незначительна в сравнении с одиночными пересылками. Во-первых, дополнительные такты могут потребоваться только в самом начале пакетной операции - все последующие, кроме первой, фазы передачи данных в пределах пакета обычно проходят без дополнительных задержек (1 такт на слово). Во-вторых, при приличном потоке данных (а 40-50 МБ/с - это вполне приличный поток) с весьма высокой степенью вероятности пакетные транзакции данного устройства в течение длительных промежутков времени не будут перемежаться транзакциями других устройств на шине (из них нас здесь волнуют, в первую очередь, операции чтения из памяти), т.е., во второй и последующих пакетных транзакциях даже первая фаза передачи данных будет проходить без дополнительной задержки. Это возможно благодаря тому, что сколько-нибудь приличный современный Host Bridge обычно сконфигурирован на работу в режиме опережающего чтения, и дополнительное задержка видна устройствам на PCI только в тот момент, когда резко меняется адрес чтения.
-
Прошу меня извинить, что выпал из дискуссии на пару недель. Все-таки ничто так не загружает, как необходимость одновременно работать и оформлять кредит в банке. :)
Итак, если еще не поздно, попробую все-таки высказать свои соображения.
По всему похоже, что ваша команда впервые приступает к работе с подобными полосами частот и вытекающими из них требуемыми пропускными способностями тракта PCI card - PC memory. Значит, так или иначе, то, что вы будете пытаться делать по первому разу, должно содержать в себе какие-то черты evaluation board (в определенном смысле). Ведь вы же будете и обучаться в том числе работе в таких условиях, верно? А тут можно очень легко "найти" немало граблей, и чтобы не начинать все сначала где-нибудь в середине проекта, лучше подстраховаться и "накрыть" в схеме платы несколько возможных направлений дальнейшего развития событий. Мне кажется, что на поверку это выйдет не так уж страшно с любой точки зрения - и по цене, и по месту на плате, и по добавляемой сложности (учитывая, что вы уже собираетесь ставить на нее - Xilinx XC3S1500, быстрые ADC и т.п.).
Я бы на вашем месте поступил так.
PCI бы подключил с использованием PLX9054 (or PLX9056), и скорее всего, в режиме J. Тут, конечно, придется поработать с документацией на чип, чтобы разобраться, в каких режимах вам лучше его использовать, но там не бог весть сколько внешних сигналов - так что можно все сомнения решать в пользу "подключать к FPGA". Только тут не забывайте о возможной необходимости в pull-up or pull-down resistors. Кроме того, существуют refernce designs с открытой схемотехникой - изучайте и копируйте удачные решения при подключении узлов. Еще я бы особенно поинтересовался, как можно использовать режим запуска 2 внутренних DMA от неких аппаратных сигналов (встречалось вроде упоминание об этом) - такая штука вам может весьма пригодиться.
Далее. Все-таки я бы предусмотрел в схеме подключение SDRAM необходимого объема для буферизации. Всегда можно подыскать такую линейку чипов, которые будут pin compatible снизу вверх, и в то же время позволят вам варьировать объем устанавливаемой памяти. В конце концов, поначалу вы ее вообще можете не запаивать в надежде успеть прокачивать все приходящие данные в RAM, но предусмотреть место для нее и развести сигналы будет совсем не лишним. Я думаю, что скорее всего, она вам все-таки понадобится, вопрос только в объеме. И вот почему. Темп передачи по PCI, который вам потребуется в худшем случае (100 МБ в сек) - уж слишком велик для PCI 32/33. Наш опыт говорит, что даже при упоминавшихся мной где-то в начале дискуссии спецнастройках какая-то осмысленная "жизнь" на машине возможна только, если наша спецплата не будет пытаться передавать по шине более 70-75 МБ/с. Далее - жизнь замирает. Возможно, конечно, что суперсовременные P4 платы несколько улучшили эти показатели, но не думаю, чтобы настолько, чтобы комфортно чувствовать себя при 100 МБ/с. При этом надо еще сказать, что все это происходило на Linux машинах, где есть возможность гибко подстраивать конфигурацию под свои нужды. Windows-машина, скорее всего, перестанет подавать признаки жизни еще раньше. И еще не совсем понятно, можно ли там провести упоминавшиеся настройки, позволяющие осуществлять длинные и сверх-длинные пакетные транзакции по PCI.
Что еще? Пожалуй, я бы еще в схемотехнике предусмотрел некоторый минимум внешних компонентов и связей, необходимых для использования какого-нибудь soft-core CPU (RAM (лучше отдельное от вашей буферной памяти), место для Flash, JTAG, RS-232 (достаточно вывести его на 2х5 header, без DB-9)). Рано или поздно это вам пригодится - не в этом проекте, так уже в следующем. Я, правда, не знаком с Xilinx'овским soft-core CPU - мы пока больше с Alter'овским NIOS II работаем. Но думаю, черты у них во многом схожи, так что вещь может оказаться полезная несмотря на наверняка имеющиеся недостатки (например, для осуществления общего управления и интеграции потоков данных на вашей плате в будущем, когда будет более интеллектуальная обработка в FPGA). Советую присмотреться и примерить на себя, короче.
Думаю, для начала достаточно. Надеюсь, что в дальнейшем отвечать удастся быстрее (если, конечно, у вас еще будут вопросы :-)).
-
Все-таки пока недостаточно исходных данных, чтобы конкретно посоветовать. Вопросы такие.
1. Какой объем данных вы планируете захватывать? Это чтобы понять, реально ли обойтись буферизацией на самой плате, или все-таки нужно в реальном времени скачивать захватываемое в host's RAM.
2. С каким темпом предполагается вести этот захват (сколько таких захватываемых блоков в единицу времени будет)? И как быстро эти захваченные данные должны оказываться в памяти хоста для обработки? Собственно, я тут хотел уточнить - а действительно ли можно по сути решаемой задачи один раз захватить данные по-быстрому, а потом относительно медленно забирать их для обработки?
3. Наконец, сколько народу будет над этим работать, с какой квалификацией, и каковы временнЫе рамки проекта (приблизительно конечно)?
----------------------------------------------------------------------------------------------
С PLX9054 доводилось работать, очень хорошая машинка, довольно-таки добротная и универсальная. Реализация стыковки с локальной шиной PLX будет, по моему мнению, все-таки проще, чем с PCI-ядром непосредственно (это если говорить о Master'е, т.к. разница в Slave несущественна, на мой взгляд), плюс нахаляву достаются такие "вкусности" PLX, как хорошая буферизация, всякие doorbell регистры, 2 DMA (PCI-to-LocalBus!!), всякие features для обеспечения maximum throughput и т.п. (Для вашего случая 2 последних момента могут быть особенно привлекательными) _НО!_ Однозначно посоветовать вам этот вариант пока я не могу, т.к., во-первых, нет пока ответа на вышеупомянутые вопросы, а во-вторых, с этим чипом, действительно, еще надо научиться управляться и грамотно его подключить (а изучать там, как вы заметили, есть что :-)), а в-третьих, это все же еще один чип на плату, что не всегда может оказаться good (и цена у него вовсе не нулевая, и другие соображения м.б. в пользу чисто FPGA-го решения - хотя бы проблемы с местом на плате, например, или еще что).
-
Думаю, самое время узнать у Vincent Vega, а какая же все-таки скорость передачи требуется между его PCI устройством и памятью. Исходя из этого можно будет и дать более конкретный (а значит, и более полезный практически) совет по организации этого дела.
Vincent, так что за задача у тебя? Чуток подробнее, если можно, и с приведением треб. скорости и возможных особых требований к реализации (if any).
-
Максимальный размер burst'а на PCI зависит о целого ряда факторов, так как он определяется взаимодействием компонентов по всей длине прохождения данных (от PCI устройства до оперативной памяти). Попробую перечислить основные:
1) Возможности Host-bridge, а также всех PCI-to-PCI bridges (если таковые есть) по пути от Host bridge до локальной PCI bus, на которой и находится интересное устройство. Поток данных надо буферизировать внутри моста (а размер буферов никогда не бывает бесконечным :)), т.к. шина по другую сторону моста может оказаться занятой в отдельные моменты времени. Соответственно, вполне может оказаться, что не шибко большой объем буферной памяти в бридже будет ограничивать длину пакета. Правда, нужно сказать, что современные мосты вроде обладают вполне приличными характеристиками в этой области (по буферизации), но помнить об этом факторе не помешает.
2) Возможностями самого PCI device, будь то master или slave. Хотя идеология построения PC на сегодняшний день предполагает, что для достижения сколько-нибудь приличных скоростей передачи данных по PCI соответсвующее устройство должно быть PCI Master, т.е., само должно заботиться о перемещении данных в нужное место, и само должно стараться обеспечить нужную скорость (а значит, иметь, например, свой собственный DMA на борту). Т.е., весь этот разговор имеет смысл вести, имея в виду в первую очередь все-таки Master-устройства. А конкретное Master-устройство еще должно уметь работать с пакетами длиной в 2K, и не факт, что ваше на такое способно.
3) Но предположим все же, что первые два пункта позволяют передавать пакеты длиной в 2K. Тогда дело остается за "малым" :) (говорю с иронией, потому что это "малое" может оказаться совсем не таковым): обеспечить правильные настройки PCI обрудования (и мостов, и devices). Тут-то и надо вспомнить о Latency Timer'е, который задает гарантированное *минимальное* время занятия шины (реальная длительность пакета может быть и больше, если никто другой не пытается выйти на шину по истечении заданного в Latency Timer количества тактов). Размер Latency Timer'а - 8 бит, т.е., если ваше устройство не пренебрегает правилами PCI, гарантировать можно только длительность PCI транзакции в (255 + небольшой хвостик в пару-тройку) тактов. Другое дело, что если на этой же шине остальные устройства малоактивны и не будут часто лезть со своими запросами, то весьма приличная часть транзакций вашего устройства может иметь длину пакета и в 2K, и даже больше (если соответствующий bridge(s) позволит ему это). Настраивает Latency Timers во всех PCI устройствах соответствующий драйвер, и должен он это делать, вообще говоря, на основе информации, извлекаемой из MIN_GNT & MAX_LAT всех PCI устройств. Да только, похоже, пока штатные драйвера обходятся упрощенными алгоритмами обработки этой информации, и лепят значения Latency Timer, исходя из принадлежности устройства к тому или иному классу устройств попросту (т.е., если device скажем, просто Slave, и это какой-нить vendor-specific, то дадут ему 8 тактов (к примеру), а если это сетевой контроллер и мастер, то получит он, скажем 0x80). Вывод: придется делать еще и свой драйвер, который, кроме прочего, будет обеспечивать нужную настройку Latency Timer.
Вот такие вот пироги. Надеюсь, не сильно утомил? ;-)
-
А на Cypress Semiconductor вы не заглядвали? Там были неплохие (на первый взгляд, по крайней мере) чипы для USB.
Господа, помогите оживить JTAG-программирование
в Работаем с ПЛИС, области применения, выбор
Опубликовано · Пожаловаться
А что, по умолчанию эта галка не стоит разве? Что-то я не припоминаю подобных проблем при использовании Байт-бластера, равно как и необходимости выставлять что-то дополнительно в настройках загрузки...