serg_Fry

Я позже разобрался в проблеме прерываний: некорректно переводил буферы устройства со входа на выход(мастер-таргет) Сделал следующим образом: устройство переводит буферы в режим мастера только когда получает #GNT, таким образом исключается вероятность обращения к таргету во время работы мастера (те самые 1-и, которые возвращала ф-я чтения порта обработчика прерывания).

не совсем понял, как управлять переключением. Задача полностью имитировать внешний проводник, сигналы на обоих его концах двунаправленные, с третим состоянием (сигналы PCI)

на промежуточном этапе понадобилось внутри Spartan'a соединить 2 ноги, обе двунаправленные, тоесть имитировать обычный проводник на ПП Возможно ли это в принципе?

- ничего не нашел там по теме меня интересует обратаная сторона контроллера, PCI. Планируется сделать RAID с SATA Возможности работать с такими частотами у меня нету, поэтому нужно использовать готовый контроллер с параллельной шиной на др. стороне, единственное что удалось найти уже сейчас это Sil3112 теперь надо сделать что-то типа "моста" PCI (хотя это конечно не совсем мост), и посадить на него несколько таких контроллеров. Решение очень некрасивое и трудоемкое. Может есть контроллеры с более простой параллельной шиной на обратной стороне(всесто PCI)..?

тоже ищу доки на Sii3112 или любые другие контроллеры SATA.

Все вышеописаные советы пошли в дело, выходные задержки уложились, входные удалось свести к минимуму(макс. 8 с копейками нс.) каким образом это можно сделать в ISE?

Разве есть альтернатива tri-state буфферу? Мне кажется медлительность tri-state буффера должна быть включена в <Maximum output required time after clock>, поэтому это не должно играть роли.

я делаю на Spartan2E

что-то я совсем запутался: вот фрагмент отчета по синтезу: а вот из отчета P&R: что следует понимать под входной задержкой, и что под выходной? промоделировал все(все что смог) в ModelSIM'e(P&R-Simulation), там все как надо, запас есть, насчет входных задержек понять труднее, но судя по тому, что на все вх. сигналы схема реагирует вовремя, делаю вывод, что с ними тоже все в порядке. В жизни: Target-часть работает нормально, Master (мое устройство только пишет в комп, burst'ом) часто выдает Master-Abort , тоесть комп не отвечает на свой адрес, из чего получается, что выходы не поспевают. *** осциллограф у меня не тянет, поэтому нет возможности посмотреть что на самом деле происходит на шине, хотя я вообще не уверен, что это возможно: задержки накрутятся в щупах и все такое. Как же адекватно оценить задержки?

я недавно перешел с 7 на 8, ModelSim подключил, все работатет, единственное, что библиотеки для него пришлось перекомпилировать. Насчет памяти - аналогичная фигня: файл подкачки растет как на дрожжах.

2 v_mirgorodsky: - думаю с этим справлюсь, в крайнем случае оргонизую свой clk, запаздывающий по фазе на (<период> - <вх. задержка>) секунд или что то же самое "опережающий" реальный на время моей вх. задержки. обязательно ознакомлюсь, спасибо to 3.14: все именно так, пользуюсь DLL, просто я использовал отрицательный фронт клока, теперь понял что нужно делать по положительному, в этом и была моя ошибка, сижу исправляю.

2 makc: величина Th указана на диаграмме "Input Timing Measurement Conditions", тоесть она учитывает эту узадержку. Поразмыслив, я решил сделать по положительному фронту, но вопрос остался открытым. ---- to 3.14: в моем случае опаздывали именно мои выходные сигналы, тоесть сигнал, который я выставлял но отрицательному фронту clk'а реально устонавливался только через 11ns (по спецификации к маменту наступления положительного фронта сигнал должен быть стабилен >7ns, см. Tsu )

Делаю PCI 32 33 в Xilinx ISE, Для PCI определена валидность сигнала на восходящем фронте, я не долго думая сделал все по нисподающему(только входные сигналы захватывал по положительному), устройство заработало, но при тестировании на др. матерях стало зависать. Перечитав спецификацию обнаружил странную вещь: захватыать вх. сигналы, используя триггеры, тактируемые положительным фронтом небезопасно т.к Th(см. спецификацию) снизу ограничено 0 с., в то время, как любой триггер имеет некоторую задержку. Какими же тогда фронтами(или одним) тактировать свою схему? При всем при этом в моем проекте входные и выходные задержки (сигналов PCI относительно clk'а) составляют примерно 11 нс. Мне кажется, это слишком много, но если разработчики PCI изначально закладывали невозможность захвата сигнала по отриц. фронту, тоесть необходимость учитывать значительные задержки и с их учетом оперировать сигналами, тогда это вполне естественные величины. Возможно я чего-то не понимаю и мой проект необходимо круто оптимизировать, поэтому хотелось бы узнать: - величины задержек, которых добиватись другие (для сравнения) - по каким фронтам #clk'а надо работать.

аналогичная проблема, если не сложно выложите ссылку или на мыло [email protected] заранее спасибо

читая регистры конфигурационного пространства своего и прочих устройств я пришел к выводу, что моя материнка игнорирует все мои MIN_GNT и MAX_LAT и жестко всем выдает одинаковое значение layency timer=20 И это значение не меняется ни при изменении кол-ва мастеров на шине, ни при изменении нагрузки со стороны мастеров. Вероятно это все и объясняет: производители конроллеров PCI ограничиваются констанстой для layency timer'а (которую иногда позволяют менять в биосе)

еще такой вопрос: В новых материнских платах в биосе есть параметр Latency timer, какой в нем смысл, если каждое устройство само определяет для себя это значение(рекамендованое в MIN_GNT)? Вообще весь механизм не очень понятен: Latency timer записывается арбитром и может меняться взависимости от загруженности шины, так? По идее арбитр смотрит значение MIN_GNT и с учетом него по возможности выдает Latency timer.

Советую попробовать разобраться с работающим ядром. Наиболее понятное из тех что мне удалось найти: target_32_33 еще есть файлик с временными диаграммами сигналов в процессе загрузки:pci_top.scf. Насчет отладки я так ничего толком придумать не смог(имея в наличии только 2-канальный осциллограф).

Да, насчет арбитра - я невнимательно прочитал спецификацию, спасибо, что поправили.

2line: если честно, то я ничего конкретного об этом не нашел. Как не нашел и описание механизма работы связки windows - pci абонент на стороне компа(тот что на чипсете), но опыт показал, что несмотря на длительные транзакции, при штатной работе запись/чтение моего таргета всегда происходит, а вот обработчик прерывания вероятно из-за своего выского приоритета ограничен по времени и может не дождаться своей очереди. 2VslavX: примерно так я себе и представляю с той лишь разницей, что снятием #GNT арбитр не заставит меня закончить мою "долгую песню" :) , а всего навсего не даст начать еще одну. Как я понимаю арбитр управляет доступом только между транзакциями, но не может их останавливать или приостанавливать.

как раз это и непонятно: как регистр может быть всегда доступен?(где бы он ни находился: в пр-ве портов или в конфигурационном пространстве) Предположим ДМА передает burst'ом 100 фаз данных.В это время обработчик получил прерывание(не от нашего устройства) , он говорит драйверу, что нужно считать регистр состояния, драйвер в свою очередь вызывает ф-ю ReadPort , далее комп в роли мастера пытается инициировать транзакцию чтения, НО 1 он не получит доступа к шине пока текущая транзакция не закончится, а она может тянуться долго. +как выяснилось время отпущенное каждому драйверу на определение принадлежности ему прерывания ограничено. 2 как устройство поймет, что надо переводит буферы сигналов на прием?(например TRDY для мастера вх., для таргета - вых.) ---------------- я свою проблему решил следующим образом: Если мы выставили прерывание, тогда ДМА ждет пока драйвер не попросит его(прерывание) снять. Если прерывание выставлено не нами, тогда ф-я read_Port возвращает все '1' для значения регистра состояния.(~реально один бит у меня всегда '0') - как раз случай когда времени на опр. принадлежности прер-я не хватает. Таким образом для обработчика это значит, что прерывание адресовано не нам. ---------------- Но я все же не понимаю, как др. устройства-мастера решают эту проблему.

в процессе работы возник следубщий вопрос: есть master/target устройство. Мастер - для DMA , Target - для управления им. Есть 1 прерывание. Прерывание одно на несколько устройств(interrupt share). Когда любое из устройств, висящих на этом прерывании его вызывает, контроллер по очереди передает управление всем драйверам этих самых устройств. Те в свою очередь обращаютя к своим устройствам, проверяют им ли предназначено прерывание, если да, тогда они позволяют устройству снять запрос на прерывание. Собственно вопрос такой: другие устройства могут выставить прерывание в произвольный момент времени, если мое устройство в этот момент будет передавать по DMA(в режиме мастера), то оно не сможет ответить на запрос обработчика прерывания(в драйвере) о том ему адресовано прерывание или нет(так как это чтение из порта, а оно возможно только в target режиме). Как организовать постоянный доступ к портам таргета при DMA? Я полагаю чистых Мастеров не делают(или оч. редко) значит ситуация расхожая, но я нигде не нашел ничего об этом.