Хочу реализовать в FPGA master-taget PCI шины. Вроде бы все давно известно, решено и проблем нет. Однако, появились сомнения на предмет времени на конфигурацию FPGA. Успеет ли эта конфигурация завершится до того, как BIOS компьютера начнет процедуру Plag&Play и посылать обращения к уже сконфигурированной FPGA? Может, кто уже натыкался на случаи, когда конфигурация FPGA не успевала произойти раньше Plag&Play? С какими матрицами и компьютерам такое случалось?

Про PCI не в курсе. Но для PCIe четко задано время в течении которого оно должно начать отвечать. Решение это или батарейка или MAX2+Flash память. Для некоторых микросхем есть мегафункция в квартусе. Я прям сейчас думаю, писать самому или попробовать разобраться с тем что есть в квартусе.

Играть в рулетку, и подбирать материнку, не хочется.

Да, я тоже не хочу играться с материнками. Поэтому и продолжаю по старинке PCI-узел делать на EPM3256, не на FPGA. Но сейчас из меркантильных соображений хочется все упаковать в FPGA. Тем более, что кругом полно готовых корок PCI. Но непонятно, на какой тип матриц они рассчитаны и будет ли это работать на FPGA.

Зачем делать для PCI, если если PCIe 1x есть уже даже в циклоне, который успевает грузится с последовательной флешки?

Для PCI время документировано и составляет 1 секунду (точнее, сколько-то тактов PCICLK). Сейчас лень искать, но эта цифра приведена в спецификации. Так что если успеете за 1 секунду загрузить свою FPGA, то все будет в порядке.
Для PCIe это время составляет 0.1 секунды. Учитывая немалый объем конфигурационных данных, даже для минимальной GX15 требуется поток данных в 50 Мбит/с. Альтера кстати предупреждает, что это время можно выдержать только при Passive Serial загрузке.

Знаю, что ни разу не было проблем с "успеет конфигурация произойти раньше Plag&Play"
Чипы Сyclone, Stratix

А вот с реализацией контролера PCI на разных матплатах были приколы. В итоге устройство просто не определялось - приходилось править диаграмму конфигурации master/target в FPGA.

Припоминаю, что этим больше всего страдают дешевый матплаты со встроенным видео. 

Fast Passive Parallel только. FPP.

Хочу добавить, что использовать ресет с PCI надо очень осторожно. Его длительность 1 ms (PCI 2.3, Table 7.4, page 234)
Т.е. если уж очень нужно что-то сбрасывать в FPGA сбросом c PCI, то надо успеть сконфигурироваться за эту 1 ms, что достаточно суровое требование.

Что-то вы напутали.

Что именно? Доводы есть?

Нафиг при каждом ресете плис переконфигурировать?

Я встречал материнки, у которых Reset-а вообще не наблюдалось. Пришлось делать собственный по включению питания, это оказалось надежнее всего.


Которого не наблюдается у самых младших Циклонов-3. У них и POR составляет не менее 200mS от выхода питания на номинал. Пытаться раньше грузить конфигурацию - бессмысленно.


Стоит задача - встраиваться в дешевые пром.компьютеры китайского пр-ва. Там никаких PCIe не наблюдается.

1) А я такое и не предлагал.
2) При включении питания надо конфигурировать.

Спасибо за цифры. За 1сек грузить младшие Циклоны-3 даже при POR 200ms- вполне реально. Я проведу испытания на своем компе. - измерю, сколько проходит времени после вкл.питания до первого обращения к слоту PCI. Насколько эта цифра будет универсальной для разных материнок- не знаю, но проверить цифру 1 сек не мешает.

По специфиации от снятия резета до момента начала первого конфиг. цикла должно быть не менее 2^25 периодов PCI_CLK.
Для PCI-33 получится 1.006632960 сек.
Для PCI-66 вдвое меньше.
По поводу PCI-X точно не скажу, посмотрите сами если интересно.

Наверное за 1 сек. можно вгрузить все, что пожелаете:-)
Например, Spartan-3E\200 грузится примерно за 75 ms. с SPI FLASH

Вы писали? Конфигурироваться за 1мс не нужно.

А это смотря в каком случае :-)
Я не точно написал, но и Вы слишком категоричны.

-- Предствьте себе что Вы
1) Включили питание на системной плате.
2) Просходит сброс, через 1 ms сброс снимается
3) Кофигурация FPGA заканчивается допустим, через 100 ms.

Вопрос.... Как сбросом с PCI сбросить что-то в FPGA? При таком раскладе - никак.
Естественно, что если будет происходить сброс с включенным питанием (hot reset) и FPGA уже законфигурирована-
то сброс с PCI работать будет.

Получается, сброс PCI должен запускать конфигурацию FPGA в любом случае. Вот, только этого сброса случается, что не бывает он на разьеме китайской материнки.

А зачем Вам сброс на FPGA. Все регистры и так в ноль устанавливаются.

Нет, конфигурацию FPGA имеет смысл делать по включению питания.

А если надо, чтобы какие-то были не 0?

На входе разряда и на выходе одноименного разряда нужного регистра поставьте по инвертору.
(Или Вы думаете, что по щучьему велению регистры по включению питания в то или иноге состояние устанавливают. Именно на базе возможности установки триггера в ноль.)

Дело не в начальных значениях регистров. Нужно знать момент, с которого стартовать загрузку конфигурации FPGA.


Я знаю, что у большинства ПК питание на слотах PCI не исчезает по завершению работы Windows. Как же тогда узнаем, когда юзер нажмет кнопку "ON" компьютера и надо будет грузить FPGA?

Как питание нормальное стало, так и грузить.


Да и по завершению работы линуха, тоже не исчезает. Вообще там дежурные 3.3 вольта есть.

Давайте определимся - какой режим загрузки используется?
Если FPGA инициатор загрузки - то зачем знать "момент, с которого стартовать загрузку конфигурации FPGA." И кому надо это знать?

Вообщем совсем непонятно, для чего Вы хотите использовать PCI_RST для старта конфигурирования FPGA.
Включили питание - загрузилась FPGA. Не выключаете питание - конфигурация хранится в FPGA.

Давайте тогда конкретно. Вот, пришел юзер и нажимает кнопочку "ON" на компьютере При этом, совершенно неизвестно было ли отключено питание ПК, или не было. Ориентироваться на это - игра 50 на 50. Однако известно, что при нажатии "ON" у правильных материнок на PCI-слотах появится сигнал nRESET. Разве это не сигнал к загрузке конфигурации FPGA? Далее, более-менее надежным приемом от "зависаний" служит WatchDog. При его срабатывании тоже будет происходить reset-PCI, но питание - нет, останется постоянным. И как вы перезагрузите в этом случае зависшую FPGA?


Я использую FPGA в комплекте с простым ARM-ом, который и грузит конфигурацию из своего flash. Пассивная загрузка. Вот, ARMу и надо знать, когда грузить FPGA. Самое простое- завести сигнал PCI-reset на nReset ARMa и он всгда будет стартовать приложение с загрузки FPGA. Как такое сделать с активной загрузкой из последовательной flash- я плохо представляю.

Нажав кнопочку ресет.
Вам ведь надо, чтобы плата как Plug and Play определилась.
Чем быстрее стартанет, тем лучше.

Это как? Часто у Вас ФПГА виснут? оО

Речь шла о том, чтобы ориентироваться на пропадание-возникновение питания в PCI-слотах вместо Reset. Повторю- считаю это очень ненадежным решением потому, что питание в материнках не пропадает при "выключении" ПК.

Скажите, вы хоть немножко, хоть чуть чуть смотрели документацию на PCI?

Случается, например в старых, раздолбанных PCI-разьемах. Случайно покачаешь плату, тряханешь ПК, или юзер начнет подводящие кабели снаружи шевелить- вот вам и сбой алгоритма, или того хуже- слетает конфигурация FPGA. Hе только из-за разьемов возможны "зависания", но и от импульсных помех на внешних сигналах, например шарахнет рядом молния или включат электросварочный аппарат. В таких случаях бросок тока через клэмп-диоды вполне может сместить питание FPGA со всеми вытекающими. Думаю, много еще чего случается на практике, что приводит к "зависанию" FPGA. Я лично страхуюсь использованием WatchDog- программа на ПК, которая постоянно следит за активностью моего PCI-мастера. Как замолчал больше чем допустимо, - значит перегружаем FPGA. Но этот прием работает в старой конструкции, где PCI master/taget выполнен отдельно на матрице с жесткой прошивкой. Поэтому Plag&Play не требуется. А сейчас я хочу все узлы собрать в одной FPGA и просто ее перезагрузкой уже не обойдешься, надо чтобы она поучаствовала еще в Plag&Play. И тут два варианта -1. ресетить весь компьютер целиком, или -2 каким-то образом из виндов вызывать процедуру Plag&Play своей платы уже после загрузки FPGA. Последнее очень заманчиво, но как это делается- я не знаю.


"Хоть немножко" смотрел. Но больше смотрю на реальный ПК и вижу- питание +3.3V на PCI разьемах при "выключении" ПК не пропадает. Например, светодиоды сетевых плат продолжают гореть. Как вы это обьясните?

Магией. Не читайте доки, магия пропадет.

Простите, но это бред. Вы не там ищете проблему. если у Вас зависает фпга из за покачивания платы - ищите ошибки в формировании питания, в логике работы самой прошивки (я имею в виду различные автоматы). Но, лучше всего, обеспечьте нормальное крепление платы, чтоб не было "покачиваний". Если у Вас происходит сбой прошивки от молнии-сварочника - помимо питания обратите внимание на входные цепи прибора, на правильную разводку цепей (всех цепей устройства). В любом случае - вы боритесь не с причиной проблемы, а со следствием.

Короче, запомните: "зависать" фпга может только в результате ошибок при составлении ТЗ и/или проектировании устройства.
или у Вас такое ТЗ, "чтоб усе работало лучше всех"?

Бесплодный формализм.

Мы наверное говорим о разном. Иначе трудно обьяснить, что вы действительно не в курсе такой особенности десктопов- при "завершении работы" питание на разьемах USB и PCI не исчезает, а ПК переходит в режим power_down. Неужели и вправду не знаете, что настоящее выключение ПК делается специальным тумблером, который сзади, рядом с силовым вводом?

Что же касается темы данной ветки, то я уже понял следующее:
-1. Использовать FPGA напрямую на шине PCI можно только для 32-бит и 33 MHz. В этом случае есть достаточный запас времени 1 сек для произведения конфигурации FPGA до наступления Plag&Play.
-2. В качестве старта конфигурации использовать nRESET шины PCI
-3. Конфигурация пассивная, от МСU. В этом случае перезапуск будет происходить и от nReset шины, и от вкл.питания.
-4. В драйвере PCI предусмотреть команду принудительной конфигурации FPGA с восстановлением Config Area PCI.

Это Вы себе пытаетесь доказать или еще кому-то?
Откуда мантра -1.? ;-)

А не лучше ли бороться и с причиной, и со следствиями? В меру своих возможностей и способностей. То, что вы пишете, хорошо и правильно, но для чего тогда в каждом процессоре стоит сторожевой таймер, например? От всех внешних воздействий не спасешься. Поэтому и нужно предусматривать выход из самой невероятной ситуации. И тогда будет "лучше всех ".

А если ОДНОЙ причине соответсвует 10-100-1000 следствий? Которые проявляются случайным образом?
Однозначно надо с причиной бороться.
По поводу вачдога.... Сторожевой таймер - спасательный круг исключительно для спасения филейной части програмиста. И самому процесору, как материальной сущности (:-))
он совсем не нужен. Меня вообще очень умиляет использование внутреннего вачдога в процессоре, который этот вачдог еще и настраивает :-)

Это я приношу огромное спасибо всем тем, кто снабдил меня конкретными цифрами.
Вы сами не осилили, что ли? Это же очень просто. Вот исходные данные:
-1. Берем самый простенький Циклон-3, который без опции Fast Hot Socketing. Имеем сразу 200 мСек на время POR.
-2. Берем сжатый .ttf файл загрузки при использовании ресурсов на 50%. Это примерно 150Кбайт.
-3. Берем средненький ARM9 c частотой 100МГц, его SPI больше, чем 5..8 Mbit/sec не потянет.

Умножаем, делим.. и "мантра", как вы изволили выразиться, превращается в очевидность.



Hе бывает, чтобы одна причина порождала 1000 следствий. Hаоборот- сколько угодно: множество причин- одно следствие. А как вы хотите- нет, не бывает никогда.


Еще хочется спросить формалиста, зачем в зависших виндах предлагается перезапустить компьютер? Билл Гейтс плохо составил ТЗ? Hе предусмотрел всех возможностей?

Как Вы изволили выразиться:
"Использовать FPGA напрямую на шине PCI можно только для 32-бит и 33 MHz."

Открою Вам страшную тайну, что "Использовать FPGA на PCI возможно не только для режима 32 бита /33 MHz"
Не надо обобщать.
Если в Вашем конкретном случае не удается сделать - это не значит, что сделать невозможно в принципе.

Вы знаете другие примеры, когда удавалось? По-моему, я представил самый простой и быстродействующий вариант. Буду чрезвычайно признателен, если представите другие варианты, приводящие к успеху FPGA напрямую на шине PCI. А то, пока что с вашей стороны одни общие слова.

Пример хотите? Вот вам...
Проект у меня есть на Xilinx XC3S250EPQG208-4C "Адаптер PCI- 4xE1" (32 33/66 MHz master/slave)
Карта аналогична Digium TE410/405 - http://www.digium.com/en/products/digital/te412p.php
С момента подачи 5V до окончания конфигурирования проходит 76 ms.
Режим Master SPI (fast read)

P.S.
Это у Вас "самый простой и быстрый вариант"?! На MK?
Вы себя переоцениваете. Скромнее надо быть.

Извините, но вы забыли нолик справа, когда писали про 76ms. При последовательной побитной конфигурации, SPI как вы написали, ваша цифра выглядит нереальной. Там что, SPI работает на гигагерцах? Сам я про XC не в курсе, но вижу, как мои коллеги, что работают со Спартанами, тратят на конфигурацию из последовательной flash не менее 1 сек. А то и поболее. Не думаю, что они законченные дураки.

Размер SPI FLASH - 2 Mbit, частота 25 MHz.
Калькулятор имеете?

P.S.
Ваши коллеги наверное не подозревают, что частоту CCLK можно менять.
По умолчанию для S3E устанавливается 1 MHz, но может быть до 50 MHz.

Убедили. При активной загрузке действительно можно получить быструю готовность XC. Hо как такую загрузку сделать управляемой от ПК, чтобы грузить по команде? Или, например, как апдейтить прошивку в SPI флешке? Как защитить от сдира?
Знают они. И один даже использует 40Мгц для загрузки Virtex-4. Остальным просто некуда торопиться.