Jump to content

    

fguy

Участник
  • Content Count

    223
  • Joined

  • Last visited

Community Reputation

0 Обычный

About fguy

  • Rank
    Местный

Recent Profile Visitors

1438 profile views
  1. Речь о HLS - изменив алгоритм работы ядра вам необходимо будет его пересинтезировать и соответственно пересобрать проект.
  2. А что не так с микроблэйзом - он конфигурируется под задачу и можно свести к достаточно компактному варианту. У "дефолтного" варианта правда есть проблема - он реально не работает на тех тактах что заявлены в бенче - например для ультракинтекс более менее работает на 125 МГц вместо 300. Если нужна замена автоматам на языке высокого уровня типа С/С++, то можно попробовать и HLS - конечно вещь в себе и не без проблем и фокусов на ровном месте. Соорудить автомат средней сложности с фиксированным числом тактов на цикл и работающий на 300 МГц для тех же ультракинтексов можно легко и быстро. Бонусом работа с axis, bram, slave axi lite и master axi. Из минусов то что любое изменение алгоритма потребует переразводки проекта.
  3. Я уже писал выше что определиться с оптимизациями и констрэйнами гораздо легче когда всем рулишь сам и проект написан от и до на VHDL/Verilog, а когда 80% это штатные ядра, для которых фэншуй оптимизаций нигде не описан совсем, остается действовать по методу перебора вариантов.
  4. Для проектов в процессе разработки эти минуса никак не мешают - при финальных сборках выкидываются илы и другие оказавшиеся ненужными ядра, уменьшается до необходимого уровня память для микроблэйза и т.п.
  5. Failed Point пишутся в виваде на странице Project Summary в блоке Timing для Setup и Hold. Их количество ненулевое при отрицательных WNS и WHS соответственно. Не знаю как для чистого VHDL, а на штатных ядрах и хлс проекты стабильно работают и при TNS в несколько сотен и фп в пару тысяч. Я для теста переразводил с ним рабочий проект в 2018.3, который давал с Performance_ExtraTimingOpt небольшие минуса и фп - проект развелся по этим параметрам лучше, но работать перестал.
  6. Тут кто то предлагал использовать стратегию Performance_ExploreWithRemap - она действительно относительно Performance_ExtraTimingOpt дала улучшение времянки и меньше failed point, но проект разведенный с ней просто не работал.
  7. Оптимизация разводки плис констрэйнами не имеет цели развести быстро - это в лучшем случае побочный эффект - её предназначение получить работоспособную разводку и это с ускорением процесса ни как не связано. В тех же стратегиях можно найти более "шуструю", которая даст и меньшее время разводки и лучшие времена, но полученный результат будет неработоспособен.
  8. По факту разница производительности одного ядра между и5 3й серии и 9900К составила всего раза 1.5 и то на даблах, а на сингл еще меньше. Это фактически соответствует разнице в тактовых цпу и ддр. Так что да - ждать какого то жуткого прироста на одном ядре от апгрейда не приходится. За счет числа ядер и озу можно получить хороший прирост только на поядерном синтезе в виваде и то один раз при первом запуске. Тут согласен, но при условии заполнения чипа по логике более 40-50% или работе на предельных частотах, а если проект без фанатизма, то чаще всего разводится и с ExtraTimingOpt. Попытка запихнуть больше обойдется в немалые временные затраты и тут уже нужно решать на уровне проекта - стоит ли оно того или проще поставить плис побольше (зачастую на то же место без переразводки платы). Ну и опять же если вы написали весь проект сами в VHDL/Verilog, то выбрать опции оптимизации и стратегии разводки будет гораздо легче, чем когда проект в бд на 80% из штатных ядер, которым никакие примочки не помогают.
  9. USB девайсы в винде ведут себя иногда странно, могут просто пропасть - подключаешь к одному пк и он его не видит, а другой видит. Я обычно очищаю стэк коннектов для usb программой usbdeview - чаще всего помогает и драйвера из системы удалять не нужно, но иногда требуется еще сделать перезагрузку винды. По поводу конфликтов Xilinx USB cable и STM JTAG есть подозрение что в обоих стоит FT-шка и проблемы от нее, т.к. и другие девайсы с чипом FT (USBtoUART) могут положить Xilinx JTAG.
  10. А вы случаем в линкер-скрипте прогу в ддр не грузите? Да и воткнуть разом 2 по 4 Гбайт в 32-х разрядный микроблэйз может быть проблематично - я такое тестил через свое ядро с дма, ну и на каждый банк отдельный миг-контролер ставил.
  11. Замедление все равно будет - сужу по опыты совместных вычислений и разводок на и9 9900 - проблема скорее всего в 2х-каналаьном ОЗУ - возможно пк с 4х-канальным озу дадут лучше результат, но они где то в 2е дороже и тактовые у тех процов ниже.
  12. Практически оно типа есть, а типа и нет. Я в процессе переноса того проекта сделал десяток разводок с одной стратегией имплемента - в основном исправления делались в ядрах хлс из за новых "фич" компилятора. Принципиальных улучшений так и не случилось - небольшая разница легко объясняется такими же небольшими изменениями в коде ядер. Проект конечно небольшой - всего 100к лютов - тут кто то писал что ИИ проявляет себя только на миллионниках - ну-ну.
  13. На порядок 2 ssd sata/nvme одного объема, поколения и цены не отличаются - максимум раз в 5 и то только на чтении, на записи больших объемов nvme может легко слить sata ssd. При выборе ssd m.2 nvme внимательно читайте тесты - могут быть неприятные неожиданности. SSD M.2 1 TB NVMe можно найти дешевле 10 кр, но они со своими причудами - нормальные стоят уже где то от 15 кр. Ну и обходите стороной QLC как можно дальше - это днище полное. Имплемент в виваде по умолчанию использует только 2 ядра - то что спрашивает вивада про процы в начале синтеза это только для поядерного варианта имеет смысл. Если хотите имплемент на 8 ядрах нужно в консоли TCL дать команду: set_param general.maxThreads 8 Ну и команда покажет вам сколько реально используется ядер для имплемента get_param general.maxThreads К сожалению принципиальной прибавки к скорости не будет, т.к. не все стадии имплемента используют несколько ядер.
  14. В современных реалиях виваду может ускорить только медный стакан с жидким азотом - проку от кучи ядер на имплементе мало, на синтезе только при поядерном режиме для бд. Я за проц с максимальной тактовой, а 8 ядер и 8/16 потоков за глаза, озу 64 Гб будет чаще всего хватать, на 32 Гб 2 даже средних проекта могут не собраться разом.
  15. Для задач дсп вполне себе подходящая конструкция - там чаще всего решение выливается в непрерывно работающий конвейер из последовательности ядер плис, часть из которых вполне эффективно смогут заменить эти процы. Но ценник пока еще конский как и на плис с HBM - может лет через 5 цены будут более адекватными, а пока будем выкручиваться на том что есть.