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 оптимально соответствующий усредненным паттернам доступа к памяти в таких системах.