Beby

И вот что самое интересное, тот же самый ADS 2023.1 подобные конструкции в VHDL спокойно воспринимает: constant cnO_W: positive := Log2Roundup(A'Length); signal RAM_DO: std_logic_vector(RxC'Length+RxD'Length-1 downto 0); Log2Roundup - User Function (прямой аналог $clog2) 'Length - VHDL predefined attribute (прямой аналог $size) Отмечу, что вся поддержка VHDL - "Beta Feature for VHDL", равно как и поддержка Verilog $size - тоже Beta, но "Beta Feature for Vierilog". И обе эти Beta'ы необходимо включать соседними опциями в опциях Compile.

Обращаю внимание, что в обоих случаях Compile просто разваливается: В Messages нет ни Error ни Critical Warnings. А вот в конце Log выглядит как-то так: Start rtl-elaborate. I: Verilog-0003: [***.sv(line number: ***)] Elaborating module *** Development error at line *** in E:\wf\2023.2\output_files\ads\FAB_Develop\branches\pds_2023.2\source\sw\ads\***.cpp pds_shell crashes. call stack dump: 00000001405e00c4 00000001405e067f 00000001405e05ab 00000001404d8039 000000014036e7cc 00000001403196f2 000000014031bdda 00000001402f164d 00000001402efe74 0000000140309aee 00000001403012a3 00000001402c0d65 0000000141c6bc89 00000001407754dd 00000001407a3de0 00000001401766d3 000000014017c754 000000014017c379 00007ffa83ca93f4 00007ffa83ca7b53 00007ffa83c80207 00007ffa83c802c9 00007ffa83c81ffe 00007ffa83ccb420 00007ffa83c7c28b 00007ffa83c7f23b 000000014017f166 000000014197f524 00007ffaff1081f4 00007ffb01b4a251 000000014017f060 Action compile: Real time elapsed is 0h:0m:4s Action compile: CPU time elapsed is 0h:0m:1s Action compile: Process CPU time elapsed is 0h:0m:1s Action compile: Peak memory pool usage is 120 MB Current time: Wed Apr 24 11:46:27 2024 Названия конкретных файлов и номера строчек заменены на ***.

Забыл, есть ещё одна грабля при описании мультиплексора для ADS от PDS 2023.2-SP1: Вот так - можно: Mux <= A( cnMux_W*conv_integer(Sel) + cnMux_W-1 downto cnMux_W*conv_integer(Sel) ); А вот так - нельзя (Error: The left bound of range is not a constant expression): Mux <= A( cnMux_W*conv_integer(Sel+1)-1 downto cnMux_W*conv_integer(Sel) ); Но эта проблема была ещё в 2023.1 при синтезе Synplify, поэтому я не сразу вспомнил. Как-то в ISE на такие проблемы ни разу не наступал.

1. Главной проблемой была некорректная работа Hierarchy Updater’а: пока он не может корректно построить дерево проекта в тех местах, где в VHDL используются внешние модули (Verilog / IP-Core), но об этом я уже писал. 2. Для некоторых может быть непривычно и неочевидно, что (в строгом соответствии с VHDL’93) при использовании entity из библиотеки Work, необходимо указывать: library work; use work.all; 3. Несколько напрягает, что все справочные материалы на китайском. 4. Немного изменилась работа с атрибутами: для VHDL необходимо использовать Syn_* атрибуты (на 2023.1 достаточно было использовать PAP_* атрибуты – тогда было меньше warning/info о преобразовании Syn_* атрибутов в PAP_*). С другой стороны в ADS_Synthesis_User_Guide.pdf добавлено очень подробное описание правил применения Syn_* атрибутов с примерами на каждый случай. Но главной проблемой был п.1, т.к. приводил к падению Compile с «internal error» без объяснения причин падения. Отмечу, что Pango Micro старается сделать PDS/ADS лучше, с каждым шагом (2022.2-SP4->2023.1->2023.2-SP1) я отмечаю существенные сдвиги в лучшую сторону.

Поделюсь своими наблюдениями по PDS 2023.2 SP1 (относительно PDS 2023.1): 1. общее время компиляции проектов для Titan-2 уменьшилось где-то на 25% (чуть по разному для разных стадий, преимущественно за счёт резкого снижения Kernel-time). 2. чуть меньше стало потреблять ОЗУ при компиляции проекта. 3. "Beta" поддержка VHDL'1993 вполне рабочая* (напоминает ISE 14.7). 4. поддержка Verilog тоже заметно улучшилась. 5. Debugger - явно делался на основе исходников ISE Chip Scope (некоторые служебные следы, оставляемые в Windows, у обоих программ крайне похожи). Местами Debuger продвинулся дальше, но куда-то исчезла возможность не использовать всю выделенную память под сбор данных. * - есть ошибка при direct instantiation IP-Core (дочерние файлы IP-Core PDS не видит). Лечится ошибка добавлением в проект Verilog-файла в котором используется то же IP-Core. При этом Verilog-файл может не использоваться в самом проекте.

Вы оба: и правы, и нет - одновременно. 1. Если кто вспомнит стародавние времена (где-то 1996-1999), то может вспомнить, были золотые диски CD-R диски (у нас это был золотой Verbatim). Записи с этих дисков устойчиво читались и через 10 лет. 2. А потом им на смену пришли (уже не помню каких фирм, там было их минимум 5) сине-голубые,.. и были они в 2 раза дешевле золотых Verbatim (что после лета 1998 года было особенно актуально). Так вот, начиная с 3 лет хранения, начались проблемы и их чтением, а к 4 году всё становилось очень плохо. На 5-м году только специальные CD-ROM Drive'ы могли считать эти диски, перед их окончательной кончиной. 3. А вот через 2-3 года, от появления первых сине-голубых, появились сине-голубые заметно другого оттенка (много использовал TDK, но были у меня хорошие диски и ещё 2-х фирм) - вот на них информация опять хорошо держалась (по цене были на 10%-15% дороже поганых из п.2) - несколько лет назад читал такие диски: записям было более 15 лет ! Все диски из п.1 и п.2 хранились в толстых персональных пластиковых коробках (собраных по 10шт. в штатную картонную кубическую коробуську в которой и продавались). А эти кубики хранились в тёмном месте с температурой от 23С до 27С. Диски из п.3 первые года 3-4 хранились в персональных тонких пластиковых коробках. Потом были перенесены в большие банки на 20-40 дисков. Всё это хранилось в тёмном месте с температурой от 22С до 27С. Там же до кучи и DVD-R/RW хранились И естественно тут выборка не 1-2 диска была, а где-то 25-30 померших CD-R из п.2, где-то 20-25 из п.1 п.3 и более 70 DVD-R. Запись производилась разными CD-ROM Drive и CD/DVD Drive фирмы Teac (по мере износа и устаревания, из заменяли более современные). Отмечу, что лучше всех повреждённые CD-ROM диски читал самый древний Teac: SCSI (x2 Write, x4 - Read): переходил на x2 и просто читал без остановок то, что более современные никак не хотели читать. Проблема в том, что во время записи мы не знаем, что нам за болванка попадётся. А найти хороший CD-Drive/DVD-Drive в котором полноценно реализована восстановление данных - задача нетривиальная. P.S. Для длительных Backup предпочитаю качественные HDD (и ни при каких условиях не SeaGate).

1. Написано, в общем-то верно. Раз сказано, все - ну значит и пихать в "mipi_drv: process" надо все: в т.ч. и "CAM1_CLK_P_s", "CAM1_CLK_N_s". mipi_drv: process(SystemReadyFlag, CAM1_CLK_P_s, CAM1_CLK_N_s) 2. Но эту конструкцию я бы переписал в другом виде: CAM1_CLK_P <= CAM1_CLK_P_s when (SystemReadyFlag = '1') else '0'; CAM1_CLK_N <= CAM1_CLK_N_s when (SystemReadyFlag = '1') else '0'; Так меньше ошибок: - одно назначение, которое всегда выполняется, - никих элементов памяти (если есть else), - то, чему происходит назначение, указывается 1 раз, что уменьшает количество опечаток до минимума, - никаких списков чувствительности.

А теперь более тонкий вопрос: для какого процессора это удалось сделать ? Поясню суть вопроса: как-то нам потребовалось запустить ISE 14.7 на Win10 без виртуалок. С Intel Skylake (6xxx) проблем не было, но при попытке применить тот же путь лечения к Intel Coffe Lake (8700K) сразу вылезла куча новых заморочек. Естественно победили, но путь был намного длиннее и тернистее.

Да, direct instantiation. При отсутствие слова entity считается, что применён component, соответственно - требуется описание портов оного компонента. Если это библиотечный компонент - то всё естественно: подключаем библиотеку - там описание портов. Тело компонентов может отсутствовать на уровне синтеза (BlackBox). Для нами описанных модулей - entity (скомпилированных в библиотеку work) можно при direct instantiation указывать 'entity', тогда никаких дополнительных описаний не требуется: порты подключаемого entity мы уже описывали (когда это entity объявляли) - требуется только чтобы он был скомпилирован ранее, чем применяется. В своё время подсмотрел это в обучаловках в Aldec AHDL 5.x (и спецификации VHDL'93), лет с 20 назад. Обычно да. У сред от Xilinx, Altera всё в полном порядке. А вот ModelSim 5.x - 6.x может попить крови. Кстати тоже подсмотрел, но у Xilinx (где-то в ISE 7.1 c MXE - ModelSim Xilinx Edition)

Честно, не понимаю, что вы хотите (и судя по тишине - не один я такой). 1. Если необходимо signal'у XLXN_278 типа std_logic назначить значение '0', то так и пишем: XLXN_278 <= '0'; XLXN_279 <= '1'; 2. Если требуется что-то иное, то так и спрашивайте: "как лучше сделать то-то ?" (описывайте задачу целиком, а не задавайте вопрос вырванный из середины решения: если решение неверное - люди просто не поймут чего вы хотели и, соответственно, не помогут). 3. В конструкции port map настоятельно рекомендую указывать тип того, что вы хотите использовать component или entity: Xil_inst: component PULLUP port map ( O => qwerty ); My_Inst: entity My_XYI port map ( O => asdf ); Соответственно для component'а должно быть описание его портов (например в библиотеке), для PULLUP это будет библиотека UNISIM: Library UNISIM; use UNISIM.vcomponents.all; А используемая entity должна быть синтезирована до того, как вы её используете (т.е. правильно задать compilation order ваших исходников), и тогда можно сослаться на рабочую библиотеку: Library work; use work.all;

Ну почему же offtop: ECC RAM - это как раз немаловажная часть машины, и факт фиксации в нём ошибок корректируемых/некорректируемых тоже крайне интересный момент работы этой машины. В начале эксплуатации машины AMD Ryzen 5 5600X (на одном из первых BIOS) при включённом Memory Error Injection (1 раз в 24 часа), Win10 LTSB фиксировала ошибки: Windows Log, System, Source:WHEA. Но потом пришлось перейти на Win10 LTSС, да и в BIOS Memory Error Injection отключил, чтобы ошибки фиксировались только настоящие. За полгода эксплуатации в журнале ни одного сообщения от WHEA. Так с DDR4 UDIMM такой же геморрой на несерверных машинах, как и с DDR5 UDIMM. На серверах же стоит RDIMM/LRDIMM. Но 2666 - это для DDR4 небольшая частота. Мои 2 планки ECC DDR4 UDIMM работают на штатной 3200 - больше по JEST пока не предусмотрено (у gamer'ов вовсю обсуждается эксплуатация DDR4 3600-4800 non-ECC UDIMM). Если воткну 4 планки DDR4 ECC UDIMM, то частота может и просесть, а может и не просесть: тут много зависит от того, какими получились конкретные микросхемы RAM и CPU. Для DDR5 UDIMM в худшем случае практически гарантируется 3600 - что лучше, чем 3200 и тем более 2666.

Это да, без UPS - никуда, и не только на случай полного пропадания питания, но и для исправления всяких перекосов: AVR либо двойного преобразования (если шум не будет мешать). И, наверное, вы имели в виду Ram-Disk. @blackfin С Ryzen 9 вообще надо учитывать, что это фактически 2 весьма независимых процессора (CCD) под одной крышкой. Соответственно и кеш - не 64, а 32+32 (и насколько содержимое одного 32 является копией другого 32 - очень интересный вопрос !). А если брать Ryzen 9 с 3D кешем, то тут совсем всё непросто получается: "быстрый" CCD на 8 ядер, но 32 Мб L3; и "медленный" CCD на 8 ядер, но 96 Мб L3. У Ryzen 5/7 в этом вопросе всё честнее: сразу видно, что частоты единственного CCD заметно меньше, чем у аналогичного процессора без 3D кеша. С графиками зависимости частоти/количество потоков разных CCD в AMD Ryzen 9 7950X3D можно ознакомиться тут. Для нас тут возникает интересный вопрос: насколько этот 3D кеш поможет нашим задачам ? Помню, в своё время на этом форуме (только тему не помню) люди отмечали что на notebook'е проект компилировался былсрее, чем на Desktop'е. Процессоры Intel были где-то одного поколения, память - тоже... но в Netebook'чном CPU был L4 cache (с видиоядром IRIS шёл), толи 32 Мб, толи 64 Мб. Т.е. мобильный процессор имел явно более скромные возможности по питанию/охлаждению, однако работал быстрее. Поэтому было бы очень интересно было увидеть на наших задачах разницу результатов работы близких процессоров с 3D кешем и без оного. @yaghtn Да, в не Epyc/Xeon машинах 4 планки памяти заметно хуже работают, чем 2. Это ещё на DDR2-800 хорошо проявлялось. Если материнская плата была поуменее (видел на ASUS с Core2Duo и на Gigabyte Athlon64x2 65нм), то BIOS тихонечко докидывал 50мВ на питание ОЗУ и 25мВ на VTT. Т.е. питание становилось 1.85 вместо 1.80. А если потупее, то в большинстве случаев с 4 планками ОЗУ переодически глючила. Для DDR3 к мат.платам стали делать длинные перечи модулей памяти с указаним в каком режиме они смогут работать. Для DDR4 уже откровенно шли таблицы деградации скорости (на Gigabyte для ряда плат было хорошо разрисовано). Для DDR5 для Zen4 у Gigabyte написано следующее: * 2 DIMM: One pair of memory modules installed into the paired of slots will enable Dual-Channel memory configuration. Please install the memory modules into slot of DDR5_A2, DDR5_B2 for best compatibility and performance. * Speed dropping policy according to AMD processor specification (EXPO/XMP disabled): - Drops down to DDR5-3600 when 2 DIMMs of the same channel are installed e.g., DDR5_A1/A2. - Drops down to DDR5-3600 when 4 DIMMs are installed. * When running EXPO/XMP at DDR5-5200 or higher, the system's stability may vary by AMD processor and memory module's margin of capabilities. * When running EXPO/XMP at DDR5-6600 or higher, the memory performance gain may not be proportional due to AMD processor current architecture limitation. У Intel вроде не всё так печально, но тоже проседания есть: * 2 DIMM: Supports one pair of modules inserted into the paired slots to enable Dual-Channel memory configuration. Install the modules into DDR5_A2, DDR5_B2 for best compatibility and performance. * Speed dropping policy according to Intel processor specification (XMP disabled): - DDR5 4800 MHz speed drops down to 4400 MHz when 2 DIMMs of the same channel are populated e.g., DDR5_A1/A2. Please adjust your setup according to the recommendation above. - DDR5 4800 MHz speed drops down to 4000 MHz when 4 DIMMs are populated (1Rx8/ x16 modules). - DDR5 4800 MHz speed drops down to 3600 MHz when 4 DIMMs are populated (2Rx8/ x16 modules). * When running XMP at DDR5 5000 MHz or higher, the system’s stability depends on the CPU’s capabilities. Относительно "странных" 12, 24 и 48 Мб объёмов - где-то всколзь натыкался, что супостату удалось сделать MUX3->1 сравнимый по задержкам с MUX2->1, а вот MUX4->1 уже заметно медленнее. Там была структура какой-то системы (практически вся мат.плата), на зачем-то разрисованной структуре DDR5, внутри которой на выходе стояла параллельная батарея оных Mux3. А касательно топологии DDR - там просто персональный ад для топологов и «signal integrity team» - был опыт проектирования мат.платы лет 7 назад под свеженький мобильный Intel Core. Мы тогда от поддержки IRIS отказались - 3 чипа на одной подложке весьма проблематично охлаждать, тем более, что микросхема cache сильно отличалась по геометрии от CPU-U и PCH-LP, а мягкую компенсирующую (механическую кривизну и неоднородность) термопрокладку использовать было нельзя.

Благодарю @kskssk за ссылку на полезную тему – я её не смог google’ом зацепить, а в тот момент на форуме отсутствовал и даже не знал, что она была. Знал бы – в той теме и отписался бы. @Alex77 Если будем брать Intel, то наверное Core i9-14900K (Для него Intel таки выродил AI Assist - аналог Ryzen Master'а). CPU-Z Benchmark 19.01.64 beta - 1T: 301 Core i9-14900K 289 Core i9-13900K 259 Core i9-12900K 268 Ryzen 9 7950X 250 Ryzen 9 7950X3D 238 Ryzen 7 7800X3D 227* Ryzen 5 5600X* - это мой вариант - см.ниже. Сравнительные цифры взяты отсюда: Тестирование процессора Intel Core i9-14900K для платформы LGA1700 и соседних статей. Дополню таблицу результатов CPU-Z Benchmark 17.01.64 - 1T: 658 AMD Ryzen 5 5600X* А вот 12900KF брать точно не будем - у него нет поддержки ECC. 5600X* Ryzen Master: +200 МГц (Max: 4850 МГц), Curve Optimizer: All Core Values -1. ECC U-DIMM 3200 22-22-22-52-74-1T 1.2V (Kingston KSM32ED8/32ME, 9965745-020.A00G) DDR5 будем брать только ECC – так гораздо спокойнее. 128 - минимум, а там: сколько получится поставить - от CPU зависит. Swap не пользую (и не собираюсь) уже более 10 лет, и мне от этого – хорошо ! Даже иногда балую с Ram Drive (ImDisk) – для ряда действий хорошо идёт. Кстати вышел на него при помощи ASUS – где-то 10-12 лет назад ASUS предлагал RAM Drive в качестве варианта эдакого принудительного Write Cache (для gamer’ов) продляющего жизнь SSD – изменения которого записываются на SSD только при выключении компьютера или размонтировании образа: с оболочкой от ASUS записывались действительно только изменённые фрагменты. @_4afc_ Благодарю за замечания, тоже читал разные гадости про e-core и нюансы и (не)работы под Win10 / Win11. Поэтому планировал посмотреть, как будет работать машина (если мы таки возьмём Intel) при отключенных e-core. Ещё один аргумент "За Intel" (на W680 для поддержки ECC) - это IPMI удалённое управление: для удалённого сервера компиляция может оказаться весьма полезным. Когда появится - обязательно посмотрим. В качестве персонального рабочего места может оказаться интересным вариантом: только надо будет уточнить производительность и тепловыделение.

Благодарю ! Даже не предполагал, что опечатка на таком сайте может так долго существовать ! Не особо разглядывая скопировал нужную строку, а там вместо XCKU19P написано XCVU19P – меня-то цифры интересовали, а не буквы... В действительности сейчас максимум рассматривается XCKU19P: Typical: 16 GB, Peak: 24 GB. На машину будем ставить минимум 128 Гб ECC DDR5 (в если получится - больше). У W9-3475 маловата частота одно ядра только 2.2->4.6->4.8. Думаю даже AMD Zen 4 Ryzen 7 7700X с 4.5->5.4 ГГц его обгонит при P&R. И да, у большинства AMD Zen 4 Ryzen 5/7/9 есть поддержка ECC. Также и относительно свежие Intel Desktop 12, 13 и 14 поколений тоже стали поддерживать ECC. Сейчас сижу на AMD Zen 3 Ryzen 5 5600X (пару лет назад нужна была тихая машина) с 64Гб DDR4 ECC UDIMM. ECC под Win10 – работает. Обращу внимание, что когда я покупал 5600X, AMD утверждала, у них есть поддержка ECC, а теперь AMD говорит, что её – нет: возможно, нашли какую-то ошибку или теперь под 5600X идут более бракованные кристаллы, где ECC может не работать. В момент покупки 5600X ещё не было 5700X процессоров, может быть, исправное ECC переехало в эту (5700X) версию отбраковки: по частотам и заявленному TDP 5600X и 5700X - одинаковы, но у 5700X исправны все 8 ядер, а в 5600X только 6.

Подымем тему из небытия. Задача: собрать 2 варианта систем (умеренно тихий персональный компьютер и сервер) для компиляции самых толстых Xilinx KUS+ и PangoMicro Titan-2. Основные вопросы: 1. Кто что посоветует по ОЗУ (минимум – 32Gb DDR5) ? 2. Какие лучше CPU взять ? 3a. Есть ли у кого статистика по сравнениям AMD7700X, AMD 7800X3D, AMD7950, что-то ещё ? 3b. По другим процессорам сравнительные тесты тоже интересны: всё это в той или иной степени можно использовать для экстраполяции результатов. 4. Есть ли у кого статистика по AMD vs Intel ? 5. Есть ли какие замечания/наблюдения по Windows 10/11 / Linux ? 6. Есть ли какие замечания/наблюдения по деградации производительности от примениния виртуальных машин ? 7. Если есть предложения по системам с поддержкой ECC - совсем хорошо ! 8. Прочие, пока неучтёные, аспекты и замечания тоже приветствуются. По ОЗУ, Xilinx утверждает, что для XCVU19P потребуется: Typical: 16 Gb, Peak: 24 Gb, Поэтому - минимум 32 Gb, но ориентируюсь на 64/128 Gb. Пока видится, что необходимы машины с одним максимально быстрым ядром: - по PangoMicro PDS 2023.1 + Titan-2 точно могу сказать – в основном (около 85-90% реально времени) используется одно ядро на часовых компиляциях. - по Vivado и KUS+/VUS+ у меня информации нет: если кто чем поделится – внимательно выслушаю.