Перейти к содержанию
    

Beby

Свой
  • Постов

    645
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Beby

  • Звание
    Злополезный
    Знающий
  • День рождения 03.12.1979

Контакты

  • AIM
    Array
  • MSN
    Array
  • Сайт
    Array
  • ICQ
    Array
  • Yahoo
    Array

Информация

  • Город
    Array

Retained

  • Звание
    Array

Посетители профиля

3 274 просмотра профиля
  1. 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 раз, что уменьшает количество опечаток до минимума, - никаких списков чувствительности.
  2. А теперь более тонкий вопрос: для какого процессора это удалось сделать ? Поясню суть вопроса: как-то нам потребовалось запустить ISE 14.7 на Win10 без виртуалок. С Intel Skylake (6xxx) проблем не было, но при попытке применить тот же путь лечения к Intel Coffe Lake (8700K) сразу вылезла куча новых заморочек. Естественно победили, но путь был намного длиннее и тернистее.
  3. Да, 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)
  4. Честно, не понимаю, что вы хотите (и судя по тишине - не один я такой). 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;
  5. Ну почему же 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.
  6. Это да, без 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, а мягкую компенсирующую (механическую кривизну и неоднородность) термопрокладку использовать было нельзя.
  7. Благодарю @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 удалённое управление: для удалённого сервера компиляция может оказаться весьма полезным. Когда появится - обязательно посмотрим. В качестве персонального рабочего места может оказаться интересным вариантом: только надо будет уточнить производительность и тепловыделение.
  8. Благодарю ! Даже не предполагал, что опечатка на таком сайте может так долго существовать ! Не особо разглядывая скопировал нужную строку, а там вместо 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.
  9. Подымем тему из небытия. Задача: собрать 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+ у меня информации нет: если кто чем поделится – внимательно выслушаю.
  10. Терминология PangoMicro отличается от Xilinx: GTP - Generic Technology Primitive. Об этом написано в разделе Glossary следующих документов: UG050001_Titan2 Series FPGA Configurable Logic Module (CLM) User Guide V1.0_innek.pdf UG050002_Titan2 Series FPGA Dedicated RAM Module (DRM) User Guide V1.0_innek.pdf UG050007_Titan2 Series FPGA GTP User Guide V1.0 en_Zig.pdf
  11. @des00, @makc - Благодарю за представленные документы - они были весьма интересны. Я бегло проглядел эти... изыскания. Есть здравые зёрна, а есть и маразм. Вот последний заключается в том, что для существенно нелинейной системы частоту отказов решили аппроксимировать функцией 1-го порядка: e^(Td/Tay). Отмечу такой момент: 100-200 пс (Tay), о которых говорилось: это - НЕ "время необходимое для успокоения метастабильности в триггере"; это - величина "постоянной времени" аппроксимирующей функции или время, которое дают CDC системе на успокоение, но так, чтобы сбои шли достаточно часто для их уверенной фиксации, но и гарантированно не накладывались друг на друга. Да, Тау имеет размерность времени, но смысл совсем иной. Т.е. Если мы возьмём интервал N Тау, то получим следующие вероятности возникновения ошибки работы CDC из 2 DFF: 1 Тау - 37%, 2 Тау - 14%, 3 Тау - 5.0%, 5 Тау - 0.7 %, 10 Тау - 4.5 *10^-5 раз, 100 Тау - 3.7 *10^-44 раз, 150 Тау - 7.2 *10^-66 раз. Но это если верить линейной аппроксимации нелинейного процесса. В итоге получается, что рекомендации от технического специалиста Xilinx (про не более 250 МГц и 300 МГц) - вполне здравые (если, конечно, нам необходимо обеспечить надёжную работу).
  12. 1. Вот, всё тоже самое, но в более красивом виде: XAPP094: Metastable Recovery in Virtex-II Pro FPGAs (v3.0, 10 February 2005, Author: Peter Alfke) Собственно именно на этот документ и попробовал съехать в 2011 году специалист Xilinx - и тут же получил отлуп. На тот момент Xilinx не выпустил ни одного документа по Metastable Recovery для ПЛИС новее Virtex-2Pro и, исходя из беседы, не планировал опубликовывать получаемые по Metastable Recovery данные в ближайшие несколько лет. 2. Я правильно понимаю, первоначальны вы имели в виду другой документ, и можно продолжать надеяться на его успешный поиск ?
  13. Если не сложно, найдите, пожалуйста, этот документ, было бы крайне интересно с ним ознакомится. В 2011 году на МАКС-2011 у меня был разговор с техническим специалистом Xilinx, как раз по поводу подобных цифр. После нескольки минут юления, специалист запросил разрешение от своего начальника (возможно Йенса Смита - я тогда с ним ещё не общался и в лицо не знал) на разглашение этой информации, после чего выдал: Для надёжного подавления метастабильности в Virtex/Kintex-7 со SpeedGrade -1 во всём диапазоне температур достаточно: 1. 2 CLB триггеров для частоты до 250 МГц; 2. 3 CLB триггеров для частоты до 300 МГц; 3. более 300 МГц могут быть глюки. CLB треггера обязательно находятся в одном Slice (т.е. с одинаковым RLOC'ом). У того разговора был с 10 свидетелей/слушателей, потому NDA в явном виде на него не располагалось. Если этого недостаточно, то предложил: "написать запрос в Xilinx для получения дополнительной информации (благо NDA есть),.. а ещё лучше написать запрос на трудоустройство: у нас весьма большой отдел по применению наших ПЛИС - обычно специалисты, которые интересуются подобными вопросами, потом у нас и работают... и с получением подробнейшей информации о наших ПЛИС у них более проблем не возникает." 250 МГц, т.е. 4 нс (даже с учётом, Routing, Setup и чего-то ещё) явно больше, чем указанные вами 100-200 пс. Поэтому мне так интересен источник информации о 100-200 пс. И да, на предложение померить самим, как описано у них в AppNote (ещё для Virtex-2) я привёл контраргумент, что я не в курсе какая у меня партия ПЛИС: удачная или на гране допустимого - а цифры то для них будут сильно разниться; Xilinx же прекрасно знает для какого кристалла они проводят измерение - вот на этом отмазки/юления и закончились.
  14. Тема выделена из темы https://electronix.ru/forum/topic/173971-ne-vsegda-srabatyvaet-uslovie/ Будьте добры, уточните, пожалуйста, откуда вы добыли информацию о "100-200пс" для выхода триггера из метастабильного состояния в Xilinx 7-Series ?
×
×
  • Создать...