RobFPGA

Еще раз - зачем? Для оценки скорости разводки на разных PC глубоко фиолетово что у вас в FPGA и на какой частоте оно работает важна лишь сложность достижения результата оптимизации при P&R. Уверяю вас если ваш проект собирается от ~1 часа и выше то любые изменения в архитектуре PC будут статистически достоверно заметны на времени сборки. У меня задачи ускорения по приоритету в другом порядке 1. Архитектура проекта 2. Констрейны таймингов 3. Констрейны размещения ... 10. архитектура ПК Среду разработки чаще всего выбирать нет возможности. А для P&R так уж точно. При этом кратность ускорения первыми тремя пунктами в разы (а иногда и в десятки раз) выше чем кратность от пункта 10.

Отлично - цель оценка скорости работы железа PC ... Упс ... А тут уже появляется требования к оценке работы инструментария (тулзов) для работой с различными примитивами FPGA. Каким боком наличие или отсутствие hard блоков могут влиять на особенности рабочего PC? Неужели при наличие hard PCie сборка полностью забитого Artix-7 на более медленной машине будет идти быстрее чем без оного на более быстрой? Привязка к BRAM, PCIe MGT ... равно как констрейны размещения лишь упрощают работу тулзов P&R. Но мы ведь не оцениваем их эффективность этого упрощения, мы оцениваем скорость работы железа PC, и наиболее интересен IMHO самый тяжелый случай для этого железа. Хотя опять же - при желании можно набросать в проект любого hard IP "мусора". Нам ведь не нужен рабочий проект, нужно лишь чтобы этот "мусор" не был оптимизирован при синтезе. Но IMHO это лишь трата времени Я не предлагал сравнивать скорость сборки для разных типов FPGА, я лишь указал что универсальный тест которым можно оценивать скорость сборки разных PC для разных типов FPGA (в разных тулза соответсвенно) не должен иметь специфические hard IP. Так кто мешает - оформляете элементарный блок расчета хеша как IP и или модуль ooc, а дальше дело за generate for ... Хотя по моему опыту и IMHO достоверность оценки "эффективности работы с памяти и кэшами" для тако типа тестов никакая, это все равно что измерять удава не в попугаях, а в слонах ...

Ну так цепочкой десяток-другой таких блоков пока в FPGA влазит (и будет хватать терпения ждать окончания P&R) ... Самое то для получения числа "попугаев". Ну и зачем вам в тестах на скорость сборки DSP и BRAM? Основная нагрузка и время P&R это именно P&R логики. И желательно логики с большим количеством беспорядочных связей. Так что вcякие хеши и крипта самое. А различные hard IP, DSP, PCie, ... будут только ограничивать применимость данного теста для разных типов FPGA. При сильном желании можно и BRAM задействовать включив опцию синтеза использовать BRAM для маппинга логики. Забив тот же Artix-7 хешами под завязку и поджав констрейном частоту повыше гарантирую "увлекательное" коротание вечеров в ожидании окончания P&R ...

Берете проект для "обогревателя" расчета хешей для крипты и вот вам готовый тест ...

А вы грамотный? Тогда сможете посчитать по формуле радиолокации на каком расстоянии этот неграмотный датчик, видящий человека на расстоянии до 5 метров, сможет увидеть коптер с эпр явно меньше чем эпр человека ...

Так SSD в еще худших условиях у меня трудятся, средняя температура внутри бука ~40С а сами SSD и до 60 нагреваются, и хоть бы хны ... А эти "... проверенные годами HDD" неженки ... то холодно им, то жарко, то слишком сильно по столу стучишь ...

Тогда я очень везучий - SATA: 2 x 256 GB, 1 x 1TB, NVME: 2 x 512GB, 3 x 1TB, 2 x 2TB, 2 x 4TB Все Samsung за исключением SK hynix 512-ок. SATA-шным уже 8-10 лет, NVME-шным ~3-5 лет (кроме 4TB, эти еще свеженькие) А НDD жили и умерли во внешней файлопомойке, и умерли как раз быстрой смертью ... Ну а для сохранности данных есть простое решение - грамотный, многоуровневый backup.

Так и есть. Повторюсь, IMHO брать для проф. работы в Vv, Qu ... стационарный "ноутбук" зря потраченные деньги и время ...

Шел второй десяток лет массового применения SSD, а страшилки все те же ... У меня все компы этот десяток лет работают только на SSD, и работают как раз с Vv и Qu и другой "тяжелой техникой". И ни один из SSD еще не умер. В отличии от обычных HDD которых, за аналогичный период, отправилось к праотцам магнитной записи аж 3 штуки ... И я не отключал своп, не переносил user на HDD или в RAM, ... и не делал кучу другой херни которую активно советуют "... для сохранения срока службы SSD ..."

Нет не без разницы - все же есть причина почему принято писать Acos(ωt + Ф) Как выше уже писали она лежит в представлении комплексного числа. А обычный гармонический сигнал есть частный случай комплексного с 0-вой мнимой частью ...

1. Длительностью с задержку переключения триггера 1а. Вполне успеет так как эта задержка обычно и определяет быстродействие логики. Но лучше все же увеличить эту длительность так как разброс дискретных эл. может быть велик. 2. RC это самый простой и вполне надежный способ. Но вашем случае можно растянуть длительность до половины периода тактовой на С входе, и для этого можно просто сделать на логике R = С OR ~Q; (Ну или эквивалентно на имеющихся лог элементах). Тогда длительность будет равна длительности положительного полупериода клока.

Да, в таком случае получите короткие импульсы если в момент фронта клока на D будет 1-ца. Длительность таких импульсов можно регулировать доп. задержкой от ~Q до ~R .

Я не против ноута, сам давно работаю в основном на буке, сейчас вот у меня бук процом i9-9980HK. Но зачем покупать для работы с FPGA стационар на ноутбучном проце? ...

А какой вообще смысл покупать комп на ноутбучном проце если это не собственно ноутбук? ...

Ну так легко! Мапинг виртуал -> физ. адрес делается ОС и при желании можно разносить например вирт. блоки память для разных ядер на разные физ. банки DDR. Но кажется мне что так особо не заморачиваются. Выигрыш от множества открытых банков в многоядерное/многопоточной системе будет получаться автоматически просто при правильном маппинге линейного физ. адреса на bank_grp|bank|row|col адрес DDR оптимально соответствующий усредненным паттернам доступа к памяти в таких системах.

DDR5 уже интересна даже при сравнимых с DDR4 частотах. За счет большего числа открытых банков, малому времени смены банков в разных группах, независимого рефреша в разных банках, большему бурсту, и двуканальной организации шины. Да и on-die ecc тоже плюс с учтём увеличения объема чипов.

Latency ячеек (внутрнние времена DDR) обычно не зависит от частоты. Это абсолютные времена в ns зависящие от техпроцесса чипа. Просто для удобства они выражаются в тактах актуальной частоты. А фактическое быстродействие это не только latency ячеек. Это и время пересылки данных, и накладные потери времени связанные с необходимостью открытия/закрытия банков и рефреша. Изменение структуры организации DDR5 по сравнению с DDR4 уменьшает в первую очередь эти накладные потери.

Фактическое быстродействие определяется не только latency ячеек, а и внутренней организацией памяти (число банков и груп банков), политикой refresh, числом каналов и скоростью шины. Замена DDR4 3200MHz на DDR5 даже при одинаковой скорости шины дает фактическое ускорение памяти ~1.2 раза, а при увеличении скорости шины до 4800-5600 MHz и до ~1.8-2.0 раз.

Для щупов кроме макс. напряжения RMS приводят также и зависимость макс. напряжения от частоты. Где четко прослеживается зависимость, выше частота - меньше макс напряжение. Например для щупа с BW 500 MHz x10 значение макс. 300V RMS идет до 20КНz со спадом по экспоненте до ~10V RMS на частоте >100MHz

Жуть какая ...

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

Что просили то и получили. Попросили бы не весь проект, а только снапшот нужной вам ветки, получили бы архив на любимой вами флешке, а не весь реп.

А ничего что для Vitis 2023.2 нужны Supported Operating Systems for Vitis HLS: ... Windows, 64-bit for Embedded Software and HLS Development: Windows 10: 21H2, 22H2 Windows 11: 21H2, 22H2 Windows Server 2022

Реф. клок используется как опора для восстановления клока RX, поэтому джиттер так же важен как и для TX.

А для этого есть бэкап, ежедневный, недельный, ...