dxp

В случае с SSD там этим аппаратура занимается по большей части. Копировать файлы -- там никакого интеллекта не надо, бери больше, кидай дальше. А с сетевым трафиком уже не так просто -- там надо ведь принятое от сетёвки успевать пережёвывать, каждый пакетик -- skbuf создай, через netfilter пропусти и т.п., и это всё программно, там нагрузка на CPU возрастает кратно, особенно, если не "бытовой" трафик, а серверный (мне довелось немножко поработать с этим со стороны железа). Особенно вилы наступают, когда валится много мелких пакетов. В целом, тема понятна. Всё сводится к тому. подходит ли то или иное решение в конкретной ситуации или нет.

Вот том-то и дело. В среднем оно, вроде, гуд, потянет, но в каждом отдельном случае нет никакой гарантии, что не наступит задница. Кроме того, там в описании сказано, что во время теста активно копировались файлы, это не самая большая нагрузка. Интереснее было, если бы там видео лилось или трафик по сети на высокой скорости пёр. Подозреваю, что результат мог оказаться и похуже.

Бенчмарки можно где-нить увидеть? То, что патчи что-то улучшают, не сомневаюсь. Вопрос на сколько и за счёт чего. Как правило подобные патчи -- это костыли. Есть и более радикальный подход: https://xenomai.org, но это, имхо, уже не вполне линукс. 🙂

5 копеек. На толстых ОС типа венды или линуха добиться реалтаймовости в смысле гарантии времени реакции на события в общем случае, имхо, малореально. Там масса внешних факторов, которые влияют на это, а планировщик не позволяет их купировать. Поэтому, наверное, самым действенным способом как-то улучшить реалтаймовость -- это минимизировать влияние этих факторов. Основные меры: уменьшить количество процессов до минимума, использовать как можно более древние версии -- вплоть до XP (если, конечно, это возможно). Ну, и проц наоборот -- поновее. Если ещё руками как-то распределить процессы по ядрам, указав для реалтаймового отдельное, чтобы только он там выполнялся (и кэш не портили другие процессы), но насколько это реализуемо, не ведаю.

Речь не про DDR, а про просто наличие регистров в IOB, без которых с жёсткими таймингами бороться тяжело, если вообще возможно. У Cyclone iV E разве нет? Выходные DDR точно есть -- я через atlddio выходной клок формировал для SDRAM контроллера. Технически это FPGA. Как и MAX II. Не помню, чья архитектура внутри MAX V, а у MAX II внутри Cyclone I обрезанный -- без блоков памяти и регистров в IOB. Я имел в виду, что не все ПЛИС обладают необходимой аппаратурой внутри для реализации входных source-synchronous интерфейсов на 100+ МГц.

Как, например, насчёт MAX V (у которого нет регистров в IOB)? И речь идёт про RGMII, т.е. 125 МГц, по обоим фронтам, т.е. 4 нс смена данных. MII какой-нить о 25 МГц без всяких извратов заводится как угодно без привязки к особенностям конкретной ПЛИС, там тайминги позволяют.

Меня бесило это поначалу, а потом я понял, что это делалось специально -- чтобы после свопа в PCB и апдейта схемы, в ней были хорошо видны эти изменения -- для доп. контроля. Перевернуть их на фоне общей работы труда не составляло. Если в новых версиях убрали, то не факт, что это хорошо. Хорошо было бы, если эта фича была опцией, чтобы каждый мог выбрать себе подходящий ему вариант.

А тут, имхо, универсальных вариантов быть не может -- всё упирается в поддержку этой темы со стороны ПЛИС. Есть ПЛИС, где вообще не получится завести вот такой source-synchronous поток на таких частотах. Наиболее универсальный метод: использование PLL в режиме с компенсацией задержки прохождения клока, Xilinx его тоже поддерживает, но он дороже, поэтому в данном случае ни к чему, раз есть другая, более дешёвая, возможность.

Видимо, это зависит от задержки клока относительно данных от PHY. У моего нынешнего в доке указано 1.2 нс. Соответственно, задержку IDELAY подобрал: 15. Мой файл констрейнов: # Rx create_clock -name rgmii_rxclk -period 8 create_clock -add -name rgmii_rxc -period 8 [get_ports rgmii_rxc] set rxclk [get_clocks -include_generated_clocks -of [get_ports rgmii_rxc]] set_input_delay -clock [get_clocks rgmii_rxclk] -max -1.5 [get_ports {rgmii_rxd[*] rgmii_rxctl}] set_input_delay -clock [get_clocks rgmii_rxclk] -min -2.8 [get_ports {rgmii_rxd[*] rgmii_rxctl}] set_input_delay -clock [get_clocks rgmii_rxclk] -clock_fall -max -1.5 -add_delay [get_ports {rgmii_rxd[*] rgmii_rxctl}] set_input_delay -clock [get_clocks rgmii_rxclk] -clock_fall -min -2.8 -add_delay [get_ports {rgmii_rxd[*] rgmii_rxctl}] set_false_path -rise_from [get_clocks rgmii_rxclk] -fall_to ${rxclk} -setup set_false_path -fall_from [get_clocks rgmii_rxclk] -rise_to ${rxclk} -setup set_false_path -rise_from [get_clocks rgmii_rxclk] -rise_to ${rxclk} -hold set_false_path -fall_from [get_clocks rgmii_rxclk] -fall_to ${rxclk} -hold set_multicycle_path -from [get_clocks rgmii_rxclk] -to ${rxclk} -setup 0 set_multicycle_path -from [get_clocks rgmii_rxclk] -to ${rxclk} -hold -1 set_property IDELAY_VALUE "15" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxd*} ] set_property IDELAY_VALUE "15" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxctl*} ] set_property IODELAY_GROUP "gpr1" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxd*} ] set_property IODELAY_GROUP "gpr1" [get_cells -hier -filter {name =~ *rgmii/*idelay_rxctl*} ] set_property IODELAY_GROUP "gpr1" [get_cells -hier -filter {name =~ *rgmii/*idelayctrl*} ] # Tx create_generated_clock -add -name rgmii_txclk -divide_by 1 \ -source [get_pins -of [get_cells -hier -filter {name =~ *txc_oddr}] -filter {name =~ *C}] \ -master_clock [get_clocks -of_objects [get_nets gmii_clk90]] [get_ports rgmii_txc] set_output_delay 0.75 -max -clock [get_clocks rgmii_txclk] [get_ports {rgmii_txd[*] rgmii_txctl}] set_output_delay -0.7 -min -clock [get_clocks rgmii_txclk] [get_ports {rgmii_txd[*] rgmii_txctl}] set_output_delay 0.75 -max -clock [get_clocks rgmii_txclk] [get_ports {rgmii_txd[*] rgmii_txctl}] -clock_fall -add_delay set_output_delay -0.7 -min -clock [get_clocks rgmii_txclk] [get_ports {rgmii_txd[*] rgmii_txctl}] -clock_fall -add_delay set_property slew FAST [get_ports [list {rgmii_txd[3]} {rgmii_txd[2]} {rgmii_txd[1]} {rgmii_txd[0]} rgmii_txc rgmii_txctl]] set_false_path -to [get_ports rgmii_txc]

Это не мой подход, а компании Xilinx. Неправильно. Регистры находятся внутри специальных примитивов IDDR, способных воспринимать DDR поток. Эти примитивы находятся в iOB. А клок входной разводится через другие специальные примитивы -- клоковые буфера, для этого входящий клок должен быть заведён на специальный пин (Clock Capable Pin). Для тактирования IDDR используется BUFIO, а для регулярной логики -- BUFR. И вот тут, чтобы привести тайминги в норму и потребовалось вставить примитивы IDELAY, которые подключаются между пинами и IDDR. Для IDELAY нужно указать подходящее значение задержки (там они используются в режиме FIXED, т.е. со статической задержкой). Топология входных цепей этой ПЛИС такова, что позволяет получать стабильные тайминги, применяя такой подход (без PLL). Нет. Констрейнами контролируется правильность таймингов при приёме данных на этих входных элементах. Если тайминги неверные, получаем ошибки от STA. Разводчик и синтезатор, к сожалению, не настолько умные. Хотя ничего не мешает им самостоятельно воткнуть элементы задержки с нужными значениями. Но даже это они не могут.

Тем не менее, приём сложнее -- тоньше: нужно входной внешний клок так завести внутрь, чтобы фазовые соотношения клока и данных не "сломались". Распространённый способ -- через PLL в режиме компенсации. Но это не всегда используется. В частности, вот именно в этом примере у меня никаких PLL для этого не применяется, а всё разводится на специализированных примитивах: буферах и блоках задержки (ПЛИС позволяет. Так сделано из в корке Xilinx, так сделано и в обсуждаемой либе, только там не доделано). Это получается экономия ценного ресурса PLL и энергопотребления. А PLL используется для формирования выходных сигналов -- чтобы клок внешний был задержан на 2 нс (90°) относительно данных. По спеке RGMII v2.0 предлагается делать именно так. Этот вариант поддерживают все PHY. Нет зависимости от возможностей PHY. Тем не менее существует немало свободно выложенных библиотек, имеющих вполне коммерческую годность. Особенно в мире традиционного софта. Например: https://github.com/fmtlib/fmt. Или тот же boost.

Ну, вот я так сделал сначала, всё просинтезировалось, ошибок нет. А потом констрейны применил и увидел, что тайминги не сходятся. Т.е. дизайн не рабочий. Фиксить это, подбирая экспериментально задержку на внешней микросхеме (речь про приём данных по RGMII)? Вслепую? Или всё же, видя эту ошибку, поискать более правильное решение -- вставить элементы задержки и подобрать для них корректное значение, ориентируясь на отчёт STA (он сразу показывает слаки). Я предпочитаю второй вариант. Констрейны в ПЛИС (особенно input/output) чаще всего нужны не для управления синтезом, а для коррекции (если синтезатор умеет -- у Альтеры было слово специальное: timing-driven synthesis) и, главным образом, для контроля корректности таймингов.

А по этому вопросу может кто-нибудь объяснить? Зачем окно анализа сдвигают на такт назад?

С такой формулировкой полностью согласен. Будем считать референсом. 🙂

Тем не менее спека RGMII требует задержку клока на 2 нс. Это-то как-то нетрадиционно -- более классический (и, имхо, правильный вариант) будет указать tsu/th для PHY, и там уже разработчики сами сообразят, на сколько клок задерживать. Но авторы спеки видимо решили навести унификацию, чтобы любые RGMII PHY были взаимозаменяемыми.