dxp

Xilinx. BMTI выпускает полные аналоги, правда, достижения пока дальше 7-й серии не ушли, но и это немало. Fudan делает частично совместимые ПЛИС (есть отличия в трансиверах и ещё каких-то аппаратных блоках), требует постобработки после сборки в Vivado. Вроде так. Поскольку, требований не озвучено, выбор широк. Для совместимости с китайцами ориентироваться на 7-ю серию. Например, Xilinx AC701. Но она достаточно набитая и поэтому не такая уж дешёвая. Это из оригинальных. Из китайских, например, такое: https://www.en.alinx.com/Product/FPGA-Development-Boards/Artix-7/AX7A035B.html. Тут существенно дешевле, т.к. и ПЛИСка сама потоньше, и плата попроще. Ну, а вообще есть там выбор: попроще: https://www.en.alinx.com/Product/FPGA-Development-Boards/Artix-7.html пожирнее: https://www.en.alinx.com/Product/FPGA-Development-Boards/Kintex-7.html Без конкретизации задачи сложно советовать что-то адекватное.

Эта модель имитирует работу микросхемы SDRAM. Она представляет собой модуль языка Veriog с портами, соответствующими пинам микросхемы. Далее вы ставите (инстанцируете) её себе в тестбенч и подаёте сигналы со своего DUT, в котором у вас должен быть контроллер SDRAM. Собственно, модель эта нужна для: отладки функционирования контроллера SDRAM; проведения симуляционных тестов своего RTL описания (DUT) совместно с моделью памяти, которая достаточно достоверно имитирует поведение настоящей памяти (тайминги, задержки, всякие precharge, autorefresh и пр.).

По ходу, пора этих бездельников банить. Ладно бы, если бы был вопрос, де, вот задача, вот так решал(а), вот тут не сходится, не догоняю, где ошибка. А тут даже попытки нет -- дайте на блюдечке с голубой каемочкой.

Дебильная задача. Зачем вообще такое давать? Неужели нельзя учить студентов на реальных схемах -- да хоть на того же ХиХ опираясь в методике. Тут же вообще о чём речь? Это научит разбираться в транзисторных схемах? Нет. Тут задача вообще на закон Ома: найти токи эмиттера и коллектора, из них, зная падения напряжения на резисторах, найти их значения. Такие задачи могут только отбить остатки интереса у обучающегося, если таковой вообще был.

Эффект Эрли -- изменение тока коллектора из-за модуляции ширины базы при изменении напряжения на коллекторе. Численно влияние изменения Uк примерно как при изменении Uбэ = Uк/1000. Т.е. при изменении Uк на 1 В, ток коллектора поменяется так, как будто Uбэ изменилось на 1 мВ. Нивелировать можно разными способами, например, применением каскодной схемы.

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

В случае с 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]