Jump to content

    

Doka

СуперМодераторы
  • Content Count

    2243
  • Joined

  • Last visited

Community Reputation

0 Обычный

1 Follower

About Doka

  • Rank
    Electrical Engineer

Контакты

  • Сайт
    http://idoka.ru
  • ICQ
    0
  • Jabber
    https://t.me/fpgasic

Старые поля

  • Vkontakte
    https://github.com/iDoka
  • LinkedIn
    https://ru.linkedin.com/in/idoka
  • Twitter
    https://twitter.com/idoka_ru

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ничего удивительного. Стандартная практика внедорожник майнинг-оборудования. С той лишь оговоркой, что кол-во яиц убывает экспоненциально и курицу не сразу продают, а придерживают для съема сливок.
  2. Победил проблему!!! конфиг в UG580 рабочий, НО только для SYSMONE1, а для SYSMONE4 надо принимать во внимание следующее: в итоге всё заволось после минорной правки бита 0 в 0x57: .INIT_57(16'hAF7С), //OT lower alarm reset 70°C - Vref_int с другой стороны непонятно - как так получается, что я проинитил регистр значением, но по какой-то причине не хочу включать ОТ....
  3. это как-то странно... выяснил, что причиной послужила совокупность факторов: в tcl: set_property BITSTREAM.CONFIG.OVERTEMPSHUTDOWN ENABLE [current_design] а в параметрах SYSMONE4: .INIT_50(16'hAF7B), //ALM[0] upper alarm trigger 70°C - Vref_int .INIT_54(16'hAA5F), //ALM[0] lower alarm reset 60°C - Vref_int .INIT_53(16'hB723), //OT upper alarm limit 85°C - Vref_int .INIT_57(16'hAF7B), //OT lower alarm reset 70°C - Vref_int брал пример из верилог-референса UG580, там правда для US (SYSMONE1), а у меня SYSMONE4 и коэф. при формулах немного иные, но не настолько же! вот как было задано в UG580 для SYSMONE1: .INIT_50(16'hB723),// Temp upper alarm trigger 85°C - For On-Chip Reference .INIT_54(16'hAA5F),// Temp lower alarm reset 60°C - For On-Chip Reference .INIT_53(16'hCB93),// OT upper alarm limit 125°C - For On-Chip Reference .INIT_57(16'hAF7B),// OT lower alarm reset 70°C - For On-Chip Reference что интересно - не работает также и с дефолтными (из UG580 значениями регистров 0x50,0x54, 0x53,0x57)!!! UPD: изучаю дальше UG580 - пишут как раз про разницу поведения для регистров 0x54, 0x57 для SYSMONE4
  4. это мысль.... в скрипте стоит: set_property BITSTREAM.CONFIG.OVERTEMPSHUTDOWN enable [current_design] и как я понимаю, это строчка действует только, если в проект добавлен SysMon
  5. Описание прjблемы: при заливке битстрима в VU13P, она оканчивается неудачей с формулировкой ошибки: ERROR: [Labtools 27-3165] End of startup status: LOW На этапе сборки битстрима из RTL нет никаких критикал-варнингов, за которые можно было бы зацепиться, чтобы понять в чём дело, гугл выдавал советы: понизить частоту JTAG усилить питание по линии Vint из-за вероятных просадок во время конфига Методом последовательного исключения (от голого проекта с обёрткой с постепенным добавлением начинки) было установлено, что как только в проект добавляется SysMon, то это вызывает незаливаемость битстрима, притом на этапе сборки битстрима никаких подозрительных вещей не выводится в лог, встречался ли кто-то с таким и как это лечится, если лечится?*..
  6. по-вашему, это было единственной причиной в данном конкретном (единственном???) случае?.. админы никогда не косячат?.. ********** А смысл?... если упомянутые конторы знают, что у МИЭТа с EDA-лицензиями спасибо инициативе Европрактики итак всё хорошо (зачем дорого, когда можно с существенным дисконтом).
  7. это не причина кристаллам быть другими - уверен теже кристаллы, но другой менеджмент качества: помимо традиционной отбраковки, могут более тщательно отбирать кристаллы по отклонению процесса (FF/TT/SS)/сужать сигма в отбраковке в зависимости от серии плюс какие-либо испытания на вибро/удар согласно одному из MIL-STD вероятно спидфайл другой, поскольку больше корнеров участвует из-за другого диапазона температур, либо см.пп.1
  8. .....особенно если у Миландра куплены тулы только из указанных вендоров за git вангую ну, а что такое поддержка? доступ к пакетам в RHN - что-то слабо себе представляю, когда админ ставит RHEL и тут же сносит пакетный менеджер, чтобы заюзать yum c центосовскмими репо - тогда весь цимус пропадает затеи, ядра-то тоже не RHEL, а CentOS тащем-та в репо... но советы про RHEL больше походят на байки EDA-вендоров либо админа-любителя, который не слышал о файликах /etc/redhat-release /etc/centos-release /etc/issue после которых и саппорт EDA-вендоров носа не подточит
  9. до 60й страницы презентации с первого раза не долистал, каюсь) насколько трудоёмка эта фича: RTL code generator ?
  10. эх, сдали с потрохами бывшего работодателя.... ...видать зуб на них нешуточный.
  11. Преимуществ нет, согласен Но обычно есть ТЗ/минпромторговский тендер, из которых прозрачно вытекает техпроцесс...
  12. меня удивило почему до сих пор никто не задал вопрос о техпроцессе - а ведь от этого зависит и стоимость софта (который для FinFET даже для стартапов может стоить как космос), и требования к опыту инженеров и даже вероятностное кол-во шаттлов...
  13. да, это не удобно, но жить можно, притом Х как могли постарались облегчить жизнь благодаря Laguna'м (если мы говорим про частоту работы схемы) конкретно в VU13P ~20000 линков между кристаллами - разумеется наверняка есть приложения, которым это критично, но не думаю что таких приложений основная масса если конечно это не ЦОС - то просто бесполезный перевод кремния, эта унификация всех угробит, экономят на топологах и издержках на MPW, иначе бы предлагали опции: - максимум DSP48, минимум|средне LUT - максимум BRAM/URAM, средне LUT, отсутствуют DSP48 - максимум LUT, средне BRAM/URAM, отсутствуют DSP48 ++++++++++++++ а в итоге получается, что VU13P эт просто масштабированный "младший" и у него всего средне: LUT/RAM/DSP
  14. Приветствую! А есть какой-то roadmap/todo list чтобы понимать общий вектор развития тула и какие фичи ожидать в ближайшие полгода/год/два?
  15. да уж... у вивадо не нашёл требований выше 48ГБ в пике https://www.xilinx.com/products/design-tools/vivado/memory.html интересно как максимальный Stratix 10 бьётся по логической ёмкости с US+ ...по Фрейду?)