pavlovconst

Приветствую! У меня сейчас нет под рукой доказательств 😁 Но я припоминаю, что для расчета параметров PLL альтера предоставляла простенький, на коленке слепленный калькулятор низкоуровневых параметров PLL в виде XLS файла. Проблема была в том, что редактирование формул там было запаролено. Но эта защита легко ломалась, и все формулы расчета становились доступны для исследования и подкручивания 🙂

Возможно Verible вам подойдет. По крайней мере, питонячьи обертки там есть

Посмотреть можно. Но, поскольку Ethernet MAC уже реализован до нас, этот вариант выглядит наименее трудоемко из всех вышеперечисленных

- Или всё же обратить внимание на IP-корку Езернета + свич на 8 портов и все дела 😁

Есть несколько вариантов реализации вашей системы - Системный (общий для всех устройств) клок. Передача данных и прием на этом клоке. Хорошо, если этот вариант заработает на 90MHz. - Source-synchronous тактирование, клок сопровождает данные. DDR буфера на передаче и на приеме. Думаю, максимум 90MHz внутренний клок, 180Mbps или около того на лейн. Реализовать такое относительно легко. - Source-synchronous тактирование, SERDES c кратностью от 4 до 10, передаем внутренний медленный клок. Потребуется умножать внутренний клок и на передатчике, и на приемнике, нужны PLL. Видимо, вы так не сможете сделать. - То же, что и предыдущий пункт, только с данными передаем быстрый клок. Приемник делит этот клок на логике, чтобы защелкивать данные с десериализатора. По даташиту обещают до 1200Mbps, по факту - будет трудоемко получить даже 400Mbps. Много подводных камней, связанных с пророческим названием выбранной ПЛИСки.

В моем случае, на скоростях более 600Mbps с приемника сыпется исключительно мусор. Никакие настройки не помогают, а попробовал я много всего, можете глянуть. Плата Tang Nano 25K, линия передачи в виде перемычки разъеме (плюс согласующие резисторы). Документация у них жиденькая, как таковых рекомендаций нет. Хотя, где-то я находил рекомендацию запитывать банк с LVDS линиями именно от 2.5V. В надежде на улучшение, я заколхозил плату, но ... ничего не изменилось 🤣 @iiv Ещё, обратите внимание на количество доступных PLL - их, вроде бы, две. А приемников у вас - 7 штук. Надо заранее подумать, на каком клоке вы будете принимать данные

На Xilinx это делается, и успешно работает. А вот на Gowin - будьте крайне осторожны. Обязательно смакетируйте передатчик, тракт передачи, и приемник. Я имел негативный опыт реализации LVDS SERDES на Gowin на высоких скоростях. Долго не мог понять, почему же лыжи не едут. В итоге, пришлось кратно снижать linerate, даже несмотря на динамическую подстройку фаз

Понадобится много спирта и ватные палочки 😆 Хотя, без ватных палочек можно обойтись 😆

По умолчанию добавленные файлы используются и для синтеза, и для симуляции. Можно дополнительно поиграть со свойствами set_property used_in_synthesis false [get_files path_to/my_file.sv]

Да, добавление исходников можно автоматизировать. Перечисляете свои исходники в TCL скрипте примерно так add_files -fileset sources_1 'file1.sv' add_files -fileset sources_1 'file2.svh' update_compile_order -fileset sources_1 Потом в TCL консоли Vivado запускаете этот скрипт pwd cd ./my_prj_dir/scripts source 'add_my_files.tcl'

Дело же не только в заполненности, но и в среднем Toggle rate вашего дизайна. Тепловыделение большинства проектов ПЛИС очень далеко от максимального, которое будет при TR 100%. Можно написать тестовый проект, который будет иметь требуемый объем, и TR 100%, но, скорее всего, перегрузит он систему питания на плате, а не корпус ПЛИС.

Используйте клок, которым защелкиваете триггеры CCLK* и D*. Пусть вас не смущает, что CCLK* - это тактовый сигнал для приемной стороны. Для прошивающей ПЛИС - это сигнал данных. Относительно клока определите set_output_delay для всех сигналов CCLK* и D*. Вот подсказка https://www.xilinx.com/video/hardware/setting-output-delay.html

Ну, у тебя топовое железо, результат предсказуемо хороший 🙂 Добавлю в статистику. Если в коде увеличить значения параметров WIDTH и LENGTH, то можно получить проект любого необходимого объёма. Только статистику придется набирать с нуля.

Всем привет! Я когда-то делал сравнение времени сборки одного и того же RTL проекта на разном оборудовании, код на гитхабе. Результаты экспериментов тут. Тестовый проект небольшой, чтобы была возможность консистентно протестировать мелкие ПЛИСки типа iCE40. Если интересно, присылайте результаты прогона на вашем железе 🙂

Не спорьте с компьютером 😆 В тайминг репорте красным по белому написано имя 50MHz-ового сигнала, который влияет на 160MHz сигнал

Расшифрую немного. Сейчас вы видите в отчете что-то, чего сами не задумывали в дизайне. Значит, IDE собирает какой-то другой проект, НЕ ВАШ. И собирает его неправильно. Вам нужно детально проанализировать каждую строчку репорта - посмотреть код, посмотреть схему, проверить тактирование всех участвующих сигналов. Если IDE говорит, что есть пересечение клоков - то так оно и есть. По крайней мере, в "её" проекте. Вопрос только "где?" и "как это исправить?". В одной и предыдущих ваших тем на форуме мы уже обсуждали этот момент. С помощью констрейнов можно легко заглушить все нарушения. Но вам-то, наверное, не отчеты нужны, а работающий дизайн. Поэтому, скорее всего, каждая красная строчка отчета потребует некоторых доработок по коду. Где-то нужно будет добавить синхронизаторы, а где-то - констрейны. Каждый случай потребуется разбирать отдельно, и на форуме это сделать сложно. Почитайте книжки, которые я прикрепил, это самая лучшая литература по теме.

Тут не пример нужен, а стремление разобраться в теме. Вот страничка с хорошими ссылками на литературу https://support.xilinx.com/s/question/0D52E00006hpUmcSAE/clock-crossing-guide?language=en_US "Лучше день потерять, потом за 5 минут долететь" 😊

Привет! Вручную расставлять логику на кристалле можно, но в вашем случае никак не решит проблему. Любая IDE (даже Gowin 😆) сделает это эффективнее и быстрее. Обратите внимание на первопричину, почему появляются красные отчеты? Потому что клоки From и To разные. Решайте ЭТУ задачу, она хрестоматийная!

Среда вам подсказывает, что в этих путях есть переход между тактовыми доменами. В тракт сигнала необходимо добавить синхронизаторы. Когда вы, как разработчик, будете уверены, что CDC сделаны корректно, можно будет написать констрейнт set_false_path. Если просто написать констрейнты, ничего не меняя в коде - вы только замаскируете проблему. Так лучше не делать )

Всем привет! У меня ПЛИС GW2AN-UV9XUG400C7/I6. Сделал проект с OSER10 + IDES10 + IODELAY. Используются дифференциальные буфера True LVDS с внешним согласованием. При скоростях 100Mbps (на линии) и ниже проект работает, а на 1000Mbps - гарантированно НЕ работает. Периодически с сердеса поступают последовательности в 10 и более нулей или единиц, что в принципе невозможно при использовании 8b10b кодирования, как у меня. Поделитесь пожста опытом, кто-то вообще запускал ПЛИС этой серии на скоростях под 1Gbps. Они в принципе могут в таком режиме работать? А если кто-то запускал - требовались ли для этого жесткие констрейны типа LOC-ов или прибитых гвоздями тактовых линий? От GOWIN конкретных рекомендаций я не видел, в логах тоже ничего страшного не вижу. Но по опыту реализации подобных проектов на Cyclone V я помню, что там требований было много (например использовать строго определенную PLL, ближайшую к IO банку, и специализированный тактовый буфер)

Привет! Я немного опоздал, но все же дополню 😃 В даташите на GW1N нашел такую запись Видимо, 25ps было задокументировано изначально, затем документация была поправлена, а модели - нет. Почему написали новые значения? Я предположу, потому что задержки IODELAY некалиброваннные (в отличие от Xilinx-а) и в разных PVT условиях могут отличаться. Возможно, перестраховались и вписали самый плохой случай...

Первый вариант - перед UART_TX поставить FIFO для того чтобы временно хранить отправляемые данные. А для записи в FIFO написать арбитр, который будет собирать с N модулей данные. Поскольку N модулей могут захотеть писать в UART одновременно - можно предложить второй вариант - в каждом из N модулей по небольшому FIFO, а затем самописный модуль-арбитр, который последовательно или по приоритету забирает данные из FIFOшек и скармливает блоку UART_TX Основная идея - UART_TX нужно переделать, чтобы он получал данные побайтно, потоком

Не выдумывайте велосипед. Всё уже сделано за вас, в стандартном IP-ядре от Xilinx. Называется IBERT Указываете необходимые лейны для проверки, генерируете example design, зашиваете. Прямо в интерфейсе Vivado будет показано количество ошибок, BER, и даже глазковая диаграмма (если нужно)

в продаже!

@1891ВМ12Я Может показаться, что все идеи на поверхности - читай мануал, настраивай трансиверы - и получи синхронную работу устройств. Но, в действительности, GTH-ы и телекоммуникационное оптическое оборудование никогда не создавалось для синхронизации времени. В типичной задаче нужно лишь достоверно передать поток данных, а с каким фазовым набегом он будет получен - неважно. Производители не гарантируют характеристики, на которые такая система будет опираться. Весь путь проб и ошибок придется пройти самому. Поэтому, отладка такой системы может легко стоить десяток-другой человеко-лет.