Перейти к содержанию

blackfin

Свой
  • Публикаций

    3 106
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о blackfin

  • Звание
    Гуру

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

5 859 просмотров профиля
  1. FMC122P - PCI Express v3.0 x16

    С чего это вдруг? PCIe отродясь является интерфейсом точка-точка, а потому bridge и Root Complex всегда могут читать и писать в config-space каждого устройства без всяких коллизий с остальными сорока устройствами. На уровне ОСи это делается через CAM/ECAM (См. Главу 7 PCIe 3.0 specs)
  2. FMC122P - PCI Express v3.0 x16

    Пишут в BAR 0xFFFFFFFF.. Потом читают из BAR'а.. Потом выясняют, сколько младших битов в BAR'e равны нулю.. ЕМНИП..
  3. FMC122P - PCI Express v3.0 x16

    Так и сам ИнСис могут точно так же "квотировать" и "посылать" просто не продавая им XCKU115. Тут ни вы, ни сам ИнСис от санкций никак не защищены. Сомневаюсь, что ИнСис преисполнен альтруизмом и готов продавать свои платы значительно дешевле западных аналогов. Скорее, наоборот. Та же BittWare покупая чипы напрямую у Xilinx'a и в больших количествах наверняка имеет хорошие скидки от Xilinx'а на сами чипы. А поскольку в стоимости этих FPGA'шных плат основной вес приходится именно на сами чипы, то скидка на чипы может существенно перекрывать стоимость изготовления самой печатной платы и стоимость монтажа м/схем "на коленке".. Короче, довольно мутный бизнес, ПМСМ..
  4. FMC122P - PCI Express v3.0 x16

    Ну да, конечно.. :biggrin:
  5. FMC122P - PCI Express v3.0 x16

    ..или четыре: BittWare XUPP3R. Этих плат уже легион.. Зачем делать ещё одну с такими же параметрами? В чем изюминка?
  6. А в чем смысл скрещивать ужа Altera и ежа Xilinx в одном проекте? Страсть к мазохизму?
  7. С четырьмя семплами и одним десериализатором не получится следить за направлением смещения фронта данных относительно точек семплирования. В этом случае алгоритм "Bit Skip" работать не будет. Иными словами FSM из рисунка 9 должен шагать строго по кругу - либо по часовой стрелке, либо против. Недопустимы переходы между состояниями "по диагонали"..
  8. Ну, я ориентируюсь на xapp523. Там каждый бит данных семплируется четыре раза. При таком семплировании наибольшая ошибка в определении положения максимума в линии данных не будет превышать 0.25*UI. Далее вы начинаете принимать пакет, но поскольку клок на приемной стороне имеет систематическую ошибку, со временем возникает сдвиг между центром бита и временем семплирования этого бита. Джиттер здесь влияния не оказывает, так как его величина мала по сравнению с длительностью одного бита на частоте 400 МГц и он не приводит к систематическому смещению фронта данных. А чем вызвано столь "жесткое требование"? Не соглашусь. Проще и компактнее то, как описано у Xilinx'а в xapp523. Один конечный автомат на четыре состояния, один триггер для граничных условий и немного логики для управления этим автоматом. Этот метод, кроме всего прочего, позволяет подстраивать момент выборки бита на интервале меньшем десяти бит (для кодировки 8/10) и не зависеть от длины пакета в принципе. Ваш же метод при большой длине пакета может привести к ситуации, когда во всех восьми блоках памяти будут лежать данные с неверными CRC.
  9. Если вы откалибровались по преамбуле и длина пакета не превышает 2500 бит, то "реклокинг" внутри пакета уже не нужен. Можно также поставить более дорогие TXCO с лучшей начальной точностью и стабильностью. Скажем, 10 ppm будет не сильно дороже, а расхождение клоков на обеих сторонах линка будет в пять раз меньше. Как следствие, допустимый размер пакета будет тоже в пять раз больше.
  10. Рекомендую проверить. DS892, page 10.
  11. Не будет там такой "разбежки".. У ТС клоки на обоих концах линка равны с точностью до 100 ppm. Из этого следует, что сдвиг на один бит случится после 10 тысяч бит. Меж тем, у ТС длина пакета 2048 бит. То есть, за время передачи пакета накопленная ошибка будет не больше 1/5 битового интервала. PS. Только сейчас заметил, что у ТС длина пакета указана в байтах. То есть, в битах это 16384. Так что ошибка в один бит вполне реальна. Тогда только кодировка 8/10 и подстраивать момент выборки бита на лету..
  12. Ну, понятно, что ручками что-то сделать всё же придется. :biggrin: Аппаратная фича состоит в том, что к каждому дифференциальному входу IBUFDS плисины можно одновременно(!) подключить две(!) линии задержки IDELAY и два(!) набора регистров IDDR тактируемых от сдвинутых на 90 градусов клоков, что дает четыре семпла данных на каждый бит входного потока. Остальное - дело техники и простенькой FSM.. Понятно, что про кодировку 8/10 эта схема ничего не знает и аппаратно не учитывает.
  13. А xapp1017 и xapp585 читали? Странный выбор.. Тогда уж лучше выбрать Spartan-7 + Artix-7 (или Kintex-7, или Kintex Ultra).. Кстати, ещё раз процитирую DS171: Если я правильно понимаю, Spartan таки умеет аппаратно восстанавливать клок из данных. То есть, достаточно одной пары LVDS..
  14. Во-первых, в Spartan 7 есть регулируемые линии задержки по входам: Во-вторых, 400 Mb/s это все-таки не 800 Mb/s на которых работает контроллер DDR3 Spartan'a: См. DS171, page 5,6