bogaev_roman

Да, но вот скорость обмена у них разная. SATA и PCIe 4.0 на порядок отличаются.

Насколько я помню, раньше узким горлом была скорость обмена с винтом, соответственно существенный прирост производительности давал размещение ПО и проекта на SSD, при закупке нового железа у нас в первую очередь смотрят на винт и материнку с максимальной скоростью обмена. Что-то поменялось?

А вы уверены что увеличивается только лишь общая задержка? При работе временного анализатора при рассчетах arrival/reqied time время распространения клока не фиксированная величина и дельта тем больше, чем больше расстояние (абстрактно конечно), а если брать еще и разные временные углы, то будут не очень приятные цифры. Data Arrival Time = Launch Edge + Longest tCLK + µtCO + Longest tD Data Arrival Time = Launch Edge + Shortest tCLK + min µtCO + Shortest tD Первая формула для анализа сетапа, вторая - холда. Для требуемого времени аналогично, лень формулы писать. Суть проста - чем больше время распространения, тем больше дельта, тем хуже времянка.

Вообще аккуратнее с этим чипом - классический временной анализатор дает задержки для флекса. Производитель утверждает, что они корректны и для их чипа. Только есть одно НО - различия в питании ядра (это для 5576хс4, для 1 по идее тоже самое)

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

А может просто в .qsf файле прописать в явном виде, зачем усложнять? set_instance_assignment -name GLOBAL_SIGNAL "GLOBAL CLOCK" -to CLK_EN Хотя квартус8 (9) и тупой, но он самостоятельно способен вытащить сигнал на глобальную тактовую дорожку не только при большом фанауте, но и при невыполнении временных ограничений (если они конечно заданы). И проверьте, что фиттер реально ваш сигнал поместил на глобальную линию - compilation report - fitter - resource section - global & other... Вот если не поместил, тогда надо внимательно читать отчеты...

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

Про фиксацию и закреплении региона Вам отписали, интересен другой момент - все DDC работают от общей тактовой частоты? Всю логику квартус прибил, судя по всему, к входным/выходным портам, разбросанным по всему периметру кристалла.

Дублирование логики в ртл-описании не всегда спасает - квартус при определенных настройках удалит дубликат, кроме этого, если фанаут большой, придется очень много копий создавать. Для подобных случаев все-таки ограничивают фанаут. Так все-таки - насколько далеко от проблемной логики расположен клокконтрол и какое время распространения тактовой частоты от него до входного триггера?

Доброго дня. 1. Вы используете сигнал чип енэйбл, какой фанаут у него и по какой линии его пустил фиттер? (compilation report - fitter - resource section - и либо global&other fast signals, либо non-global high fan-out signals). 2. Скриншоты из таймквеста с подробными путями для двух случаев - data path (arrival/required) 3. Слаки рассчитываются намного сложнее, чем вы думаете и даже таймквест подробно вам не распишет. Даже если брать одну угловую модель, то при рассчете слака для setup в arrival и requeired data path время распространения сигнала тактовой частоты (сlock network delay) будет разным (для данных берут максимальное, для частоты минимальное) и различие будет наибольшим, если клокконтрол и анализируемый триггер находятся на разных концах чипа, так вот required time меняется по этой причине - фиттер поставил плл в другое место банально. ЗЫ. Вангую - ваш чип енайбл имеет дикий фанаут (да еще и квартус пускает его по обычной сигнальной линии) и решит проблему ограничение на него для автоматического дублирования. А прибить гвоздями и ограничить все можно, только времязатраты будут слишком большими.

Error (169303): I/O standard LVDS on the clkO_1_2_l0 I/O pin cannot have Slew Rate logic option setting 2 Это если в .qsf принудительно прописать, в pin planner вообще неактивна установка эта - пишет бред - настройка возможна только для выходов и двунаправленных портов.

Добрый день, Уважаемые форумчане. Возник вопрос - какими настройками в квартусе можно поднять крутизну изменения выходного сигнала стандарта lvds (slew rate/current strength/termination)? Не нравится нестабильность выходного сигнала, хочется уменьшить, беглый осмотр документации результатов не дал. Для входа lvds помогло INPUT_TERMINATION DIFFERENTIAL.

Разобрался - требуется создать один reconfiguration controller на все линки, при этом указав в настройках соответсвующую группировку (в моем случае 4 1-lane трансивера, в каждом по два канала для реконфигурации, соответственно группировка 2,2,2,2). Ну и после разводки все как описано в документации - 4 трансивера на местах, одно место под TX_PLL , одно свободно (все в одном банке).

Что-то не могу понять, каким образом можно расшарить reconfiguration controller на несколько независимых custom phy? Создал 2 независимых custom phy (number of line - 1, PMA bonding mode - x1, enable lane bonding - off), при этом требуется два интерфейса реконфигурации - один на трансивер, второй на PLL. Далее создаю два идентиных регонфигуратора (number of reconfiguration interface -2, optional interface grouping - пусто). Все соединяю и на выходе получаю ошибку - каналы с разными реконфигураторами не могут находиться в одном триплете, но по идее сам квартус (согласно xcvr_user_guide, 17-59) должен был расшарить и реализовать только один реконфигуратор. Что не так делаю? Может кто-нибудь скинет ссылку на пример подобной реализации? Спасибо.

Добрый день, уважаемые форумчане. Поставли задачу - получить максимальную пропускную способность для трансивера. Условия - чип 5agxfb5k4, в банке 6 трансиверов, реально подключены 4 (остальные - 1 и 5 - не подклюены), логические каналы должны быть независимы (т.е. объединять их нельзя). На данный момент не могу определиться с конфигурацией (в режиме 2.5G ethernet phy все работает, 5G для данного кристалла подключить не получается, сейчас смотрю в сторону native phy - но там, по памяти, какие-то проблемы были с клоковыми деревьями). Если кто решал что-нибудь подобное - пните в нужную сторону. Спасибо!

Что за ПЛИС? Если пользуетесь квартусом, то можно с помощью timequest.

Можно попробовать сделать 4 параллельные семы приема на вс длину пакета. Каждая сема тактируется частотами 400МГ, сдвинутыx на 90 градусов. Потребуется 3 вещи: 1. Сxема решения - с какой именно забирать данные (подобные реализаии видел, потребутся служебные символы вначале/коне пакета). 2. орошего выравнивания по времени для водныx триггеров сем и частот (вручну точно придется прибивать). 3. Плавание частоты передащей части от приемной за интервал передачи пакета не более чем на четверть периода символа. Каким образом все ляжет на конкретно Ваш чип - ответить не могу - не работал с ним. ЗЫ.. Извинясь за написание - проблема с ПО - часть символов не печатается.

Альтера гарантирует работоспособность кристаллов, если в таймквесте все временные ограничения прописаны грамотно и выполняются. Что даст Вам дополнительно временное моделирование (функционал можно проверить на модели, полные задержки после трассировки можно посмотреть в таймквесте)?

Плохо разводилось (приходилось гвоздями прибивать клокконтрол), в документации советуют 90 градусов ставить. В трех проектах используется один и тот же контроллер, везде без сдвига. Работает стабильно, кстати, в режиме точка-точка при грамотном размере программного буфера UDP работает без пропусков, хотя все программисты утверждают о невозможности этого :biggrin:

В моем варианте по документации очень хитро все расписано относительно периода. У Вас проще. Я сейчас тупить могу, но как я понял: для выходных задержек все прописывается относительно фронта/среза GTX_CLK - максимальное время установки 2.2. нс, минимальное время удержания 1.65. Соответственно получается (тут еще потребуется добавить нестабильность разводки по плате): set_output_delay -clock { clk125_txclk } -rise -max 2.2 [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] -add_delay set_output_delay -clock { clk125_txclk } -fall -max 2.2 -add_delay [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] set_output_delay -clock { clk125_txclk } -rise -min -1.65 [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] -add_delay set_output_delay -clock { clk125_txclk } -fall -min -1.65 -add_delay [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] Ну и при таких ограничениях производитель гарантирует работоспособность. Я не знаю как у Вас pll настроена - при разных настройках временной анализ нулевой точки может отличаться. Для входных/выходных ограничений это нормально - нас же интересует анализ в том числе и относительно клока.

Можно ссылку на документацию, согласно которой ограничения задавались? У меня просто на марвелл ограничения другие стоят #************************************************************** # Set Output Delay #************************************************************** #88e1111-DS Register 20.1 = 1 Tsetup=-0.9ns/Thold=2.7ns GTX_CLK+0deg (page 218) set_output_delay -clock { clk125_txclk } -rise -max -0.9 [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] -add_delay set_output_delay -clock { clk125_txclk } -fall -max -0.9 -add_delay [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] set_output_delay -clock { clk125_txclk } -rise -min 2.7 [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] -add_delay set_output_delay -clock { clk125_txclk } -fall -min 2.7 -add_delay [get_ports {TX_CONTROL RGMII_OUT[0] RGMII_OUT[1] RGMII_OUT[2] RGMII_OUT[3]}] Просто 4 нс на нестабильность - многовато получается. PS. Можно еще сдвиг по фазе убрать, плюс на самих DDIO задержка огромная - т. е. там походу холд не вытягивается еще или запас очень маленький (он задержку подкрутил ненулевую).

Документация и поддержка со стороны Миландра по сравнению ВЗПП - высший уровень :biggrin: Касаемо FPGA - работал активно с 5576XC4T (аналог EPF10K200S), работает стабильно, согласно заданному алгоритму во всем диапазоне длительное время. Ложка дегтя при разработке осталась - технология отличается от альтеровской, временной анализ делается для альтера, при попытке связаться с разработчиками и выяснить данный момент - пишите официальные письма через голову и ждите ответа непонятно сколько (неофициально сказали, что работать будет, так как технология лучше, но риски Ваши и никто Вам этого официально не скажет). Если бы сейчас была возможность поменять - взял бы их последние поделки (для EPF10K200S из-за особенностей архитектуры невозможно для отладки использовать сигналтап, кроме этого - отсутствует возможность использовать timequest и нормальный chipplanner, что сильно задерживает процесс отладки и самой разработки). Что касается возможностей - попробуйте собрать для начала проект для циклона2 и посмотрите как все ляжет по ресурсам и временному анализу, потом возьмите аналог и найдите отличия в архитектуре, тогда все будет более-менее понятно.

При работе с трансиверами я именно так и делаю. Но Вы же хотели избавиться от фифо?

С точки зрения архитектуры этот новый клок должен пройти через клокконтрол (или как там его), и задержка у него будет приличная. Возможно придется после этого добавить в ограничениях мультицикл (условно для задержки на один такт сделать анализ по setup=2, а hold=1). Но вот вопрос - если у Вас несколько трансиверов будет, для каждого создавать новый клок? Я vhdl не знаю, но насколько понимаю, описание некорректно. gl_clk0 <= rx_clk0; Если это комбинаторика, то квартус по умолчанию новый клок выкинет за ненадобностью и ограничения поставить не получится, потребуется корку ставить (altclkctrl, раньше так называлась, могу ошибаться). Ну и по процессам написал выше - ограничения по умолчанию из-за большой задержки не будут выполняться.

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