Beby

Да я бы тоже использовал VHDL'2008... Но у Pango ADS 2023-2-SP1 заявлена только Beta поддержка VHDL'93 - в итоге частично пришлось переписывать код на VHDL'93. Кстати этот мультиплексор - тоже. В оригинальном описании (VHDL'2008) 'A' был 2-х мерным массивом, и мультиплексор был по одному измерению, а элементы - по второму. Но т.к. на VHDL'93 не получилось описать тип 2-х мерного массива (чтобы оба параметра варьировались, и в одном проекте этот мультиплексор применялся бы несколько раз с разными параметрами, да ещё и в качестве входных/выходных портов entity), то пришлось переходить на одномерный массив. Собственно об этом и тема: на языке можно много чего написать, только ADS это не будет воспринимать. Первоначально была в виде ответа на вопрос про "подводные камни на пути" применения VHDL в Pango ADS 2023-2-SP1.

Может быть,.. Если вопрос был в to_integer(unsigned(Sel)), то получаем такой результат: Проглатывает: Mux <= A( cnMux_W*(to_integer(unsigned(Sel))) + cnMux_W-1 downto cnMux_W*to_integer(unsigned(Sel)) ); Отрыгивает (Error: The left bound of range is not a constant expression) все 3 варианта: Mux <= A( cnMux_W*(to_integer(unsigned(Sel+1)))-1 downto cnMux_W*to_integer(unsigned(Sel)) ); Mux <= A( cnMux_W*(to_integer(unsigned(Sel)+1))-1 downto cnMux_W*to_integer(unsigned(Sel)) ); Mux <= A( cnMux_W*(to_integer(unsigned(Sel))+1)-1 downto cnMux_W*to_integer(unsigned(Sel)) ); Обязательно ещё раз гляну - с прошлого раза (лет 20 назад) запомнилось только, что оно не IEEE, теперь же гляну чьё именно. И Xilinx, и Pango функцию 'conv_integer' просто принужнает исользовать: см. эталонные описния RAM в xst.pdf и ADS_Synthesis_User_Guide.pdf. В итоге, я так и не понял, что подразумевалось под: Будет пример такого описания - я его попробую и о результатах расскажу. На взякий случай, постановка задачи такая: 1. из длинного A (std_logic_vector) выбирается кусок номер Sel (std_logic_vector) и выдаётся в Mux (std_logic_vector). 2. длины A, Mux и Sel - параметризированы так, что: A'Length = Mux'Length * (2**Sel'Length), Mux'Length = cnMux_W.

Но это же - статика... с заранее предопределённым количеством состояний. А мне нужна была полная динамика: A, Mux - параметризированы (Sel под них подстраивается). Кстати, саму конструкцию я посмотрел где-то во времена ISE 10.1/11.1 (для Virtex-5) в исходниках (или библиотеках) Xilinx или даже в xst.pdf того времени - уже не помню. При предопределённом варианте мультиплексора использую With-Select или When-When-Else (иногда Case, и если уж совсем припрёт if-elsif-else),.. и то, если не надо описывать много состояний или нет смысла конструкцию свернуть. Ключевым требованием в моём описании является минимизации возможностей посадить опечатку, вторичным - именование сигналов, которые переживут оптимизацию и будут доступны в FPGA Editor'е (куда как приятнее видеть подходящий к BRAM сигнал xx_LRAM_WE, чем net0078352). 1. conv_integer - IEEE.std_logic_unsigned, std_logic - живёт в соседнем IEEE.std_logic_1164. Соответственно теперь даже мыслей нет, что могло подразумеваться под: "написать в соответствии со стандартом языка". 2. и что-то не могу понять, где я использовал "умножения для типа std_logic_vector" ? - cnMux_W - generic positive, - conv_integer - даёт integer, - на всякий случай: signal Mux: std_logic_vector(cnMux_W-1 downto 0);

Да я бы и не против (а может и всячески 'за'), но что-то не могу сообразить, о чём идёт речь. Поэтому, если хотите получить ответ (или результат проведённого мною эксперимента), то: - либо приведите (ссылку/текст) фрагмента стандарта, который мною приведённая запись нарушает; - либо сам вариант записи конструкции (cnMux_W - generic positive, Sel - std_logic_vector).

И вот что самое интересное, тот же самый ADS 2023.2-SP1 подобные конструкции в 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.