[v_mirgorodsky 0]

Доброго времени суток :)

 

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

 

В процессе проектирования ядра выяснилась необходимость работы с нерегистровыми сигналами шины PCI. При этом необходимость диктуется не столько эффективностью работы контроллера, как самой логикой формирования выходных сигналов по реакции на входные воздействия. Весь опыт предыдущей разработки говорит о ошибочности такого подхода, но похоже, для решения синхронизации передачи данных по шине другой альтернативы нет. Камнем преткновения стали сигналы FRAME и IRDY. Реально входная Target машина просто не успевает управлять логикой пользуясь регистровыми версиями этих сигналов :maniac:

 

Существующий контроллер от PLDA, который мы исследовали для ознакомления не имел входных регистров на эти сигналы, однако имел множество примитивов типа LCELL на различных стадиях работы с этими сигналами. Как мы думаем, они использовались для устранения гонок на сигналах :ohmy:

 

В первом приближении для использования нерегистровых версий сигналов для машин, логики и всего остального необходимо ограничить время распространения сигнала от пина до входа триггера через остальную логику. Выглядит так, что по стандарту PCI на сигналы накладываются жесткие ограничения на Setup. Таким образом, если время распространения сигнала плюс Setup триггера меньше времени Setup шины, то все должно быть шорошо :cranky:

 

Есть ли у кого опыт написания собственных PCI ядер и кто как решал выше описанные проблемы? Какие есть мысли по данному поводу?

 

Хелп ас, плииииз, а то :smile3046:

[-Al- 0]

PCI шина - синхронная, таким образом ничто не мешает разбить весь процесс на такты.. на самом деле за 30нс (длительность одного такта на PCI при 33МГц) можно сделать все что угодно... вообще непонятно... в чем именно загвоздка? нрмально спроектированный PCI-автомат работает довольно шустро... мне свой Target удалось запустить на FLEX10K10 (в симуляторе граничная частота была ), а в конечном варианте на ACEX1K30-1 максимальная тактовая частота в симуляторе на PCI CLK составила 90МГц... может и не самый лучший вариант, но работает весьма стабильно даже на разогнанных системах где, например, PCI CLK ~ 42МГц (83МГц/2)

[VslavX 0]

Реально делался тагет на EPM7160xxx-10 - на 33МГц вообще не было никаких проблем в 10 нс спокойно все проходило в рамках спецификации PCI (кажись, там tsu 10 нс) Причем регистры были не на "чистые" IRDY, FRAME, TRDY а на их комбинаторную функцию - обычный автомат состояний как и во многих готовых ядрах.

 

Недавно делал PCI 66 МГц на EP1K30xxx-2, вот там с IRDY и FRAME пришлось сильно помучиться - сделать их через dedicated input (с порезом уже изготовленныйх плат). Но в tsu 3 нс мне на данной FPGA влезть не удалось, удовлетворился tsu<4.5нс, благо шина короткая и целиком на плате, и второй агент имеет tval существенно лучший чем стандартные 6 нс. Могу также сказать, что очень много времени провел в FloorPlan с временнОй оптимизацией - time-driven compilation в Квартусе - ацтой полный. Для плотных и быстрых проектов :( все равно много критических цепей приходится "прибивать" руками через assignments.

 

Если у Вас мастер (то есть надо рулить FRAME и IRDY), то вход можно сделать dedicated как и в тагете, а выход подавать с отдельной ножки обычного I/O.

[v_mirgorodsky 0]

PCI шина - синхронная, таким образом ничто не мешает разбить весь процесс на такты.. на самом деле за 30нс (длительность одного такта на PCI при 33МГц) можно сделать все что угодно... вообще непонятно... в чем именно загвоздка? нрмально спроектированный PCI-автомат работает довольно шустро... мне свой Target удалось запустить на FLEX10K10 (в симуляторе граничная частота была ), а в конечном варианте на ACEX1K30-1 максимальная тактовая частота в симуляторе на PCI CLK составила 90МГц... может и не самый лучший вариант, но работает весьма стабильно даже на разогнанных системах где, например, PCI CLK ~ 42МГц (83МГц/2)

 

Если не использовать нерегистрированные FRAME и IRDY сигналы, то Target забирает у пользователя "лишние" данные. Фактически регистрированные данные необходимо выставить на внутреннюю шину за такт до того как они попадут на шину PCI, а регистрированная реакция мастера на эту фазу данных - IRDY будет готова для анализа еще на такт позже. Это было бы ничего, если ограничить количество фаз данных по PCI до одной и после каждой давать дисконнект, но в данном случае это приведет к резкому падению производительности. Дело скорее даже не в скорости, а в самом факте необходимости использования нерегистрированных версий сигналов, что раньше никогда не практиковалось.

[Hilter 0]

Использование нерегистрированных сигналов в этом случае рано или

поздно приведёт к перекраиванию вручную проекта во floorplan'е

привнесении любого изменения. Гараздо надёжнее будет переделать

автомат на задержанные на 1 или даже 2 такта операции. При реализации

мастера с барстами это не сильно повлияет на конечную производительность

а времени сбережет много.