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

[Vivado] Оценка потребления проекта с учётом переключательной активности

Приветствую!..

По теме были изучены следующие материалы:

 

На основании которых создан tcl-скрипт из следующей последовательности:

  1. read_edif
  2. link_design
  3. read_saif
  4. set_operating_conditions ...
  5. report_power

На этом этапе выяснил, что саиф у меня неправильный и правильный саиф - это тот, который пишется по нетлисту (ок, как появится новый - перезапущу, ибо новый саиф по нетлисту с обеда пишется всё не запишется).

На что обратил внимание особенности работы report_power в старом SAIF: были аннотированы только клок, входы и выходы, дале он пытался сделать Activity Propagation, но по иерархическому репорту по потреблению, видно было что по какой-то причине этого не получилось, лишь финальный модуль конвейера (с которого собственно снимается выход) показал какое-то аномально-высокое потребление.

 

Ok, пока новый SAIF пишется решил поиграться с set_switching_activity, чтобы хоть какие-то начальные результаты были, т.е. вместо read_saif делаю магические последовательности из set_switching_activity.

Соответственно, report_power бодро рапортует о том, что честно делает Running Vector-less Activity Propagation...

Сначала я подошёл творчески, описал все входы максимально приближенно  к реальной картине мира, но затем заметил, что чтобы я не менял - получаю абсолютно одинаковую цифру потребления, в итоге это было протестировано двумя краевыми случаями (шина din[] - единственный вход 512бит,  ресета нету):

worst_case:

set_switching_activity -default_static_probability 0.5 -default_toggle_rate 0
set_switching_activity -static_probability 0.5 -toggle_rate  100 [get_ports din[*]]

best_case:

set_switching_activity -default_static_probability 0.5 -default_toggle_rate 0
set_switching_activity -static_probability 0.5 -toggle_rate  0 [get_ports din[*]]

 

Вопросы:

  1. Почему в случае с аннотированными входами-выходами report_power безобразно пропагирует активность? ЧЯДН?
  2. Почему цифры потребления неизменны для абсолютно разных set_switching_activity?  ЧЯДН?

 

Протестировано на Вивадо 2018.1 и 2018.3

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

UPD:  простенькая симуляция на post-synth нетлисте идёт вот уже почти сутки на i7-8700K

а если быть точнее, то симуляция встала на open_saif sim/out/dump.saif

может что-то не так делаю, запускаю

xsim ...... --tclbatch sim/bin/saif.tcl

 

 

saif.tcl

run 100ns
open_saif sim/out/dump.saif
log_saif [get_objects -r /tb/u0/*]
run 200ns
close_saif

quit

по прошествии почти суток размер dump.saif = 0

тот же saif.tcl используется при записи активности по RTL и симуляция отрабатывает нормально,

 

ощущение, что я определённо чего-то не учитываю на post-synth моделировании, но чего?

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

По существу вряд ли отвечу, но у меня saif на большом дизайне (~1M DFF) писался явно более суток и в процессе жрал под сотню ГБ памяти. Так что терпения...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

44 minutes ago, Doka said:

...

ощущение, что я определённо чего-то не учитываю на post-synth моделировании, но чего?

У меня ощущения  что xsim  еще тот тормоз очень сырой :wacko: Иногда даже при простенькой функциональной симуляции медленнее  modelsim в 10-100 раз. Особенно добивает ситуация когда  15-20 мин ждёшь запуска сима  чтобы потом на 1 ps симуляции получить неопределенную ошибку.  А уж про post-synth мне и подумать страшно.

Надо бы технологию симуляции отлаживать на простеньком проекте чтобы не было так мучительно больно ждать.

Удачи! Rob. 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 minutes ago, RobFPGA said:

Надо бы технологию симуляции отлаживать на простеньком проекте чтобы не было так мучительно больно ждать.

это даже не крупный проект, а один из блочков (~50000 LUT), притом RTL симуляция пробегает в xsim секунд за 30

42 minutes ago, alexadmin said:

но у меня saif на большом дизайне (~1M DFF) писался явно более суток и в процессе жрал под сотню ГБ памяти

~50000 LUT потребление памяти стабильное:

xsim 1.4GB

xsimk 1GB

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, Doka said:

это даже не крупный проект, а один из блочков (~50000 LUT), притом RTL симуляция пробегает в xsim секунд за 30

Тогда это еще печальнее :cray2::mega_shok:

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

промежуточные выводы:

 

1. xsim оказался в прнципе непригоден для записи SAIF на post-synth моделировании, так и не дождался окончания моделирования. пользуйтесь альтернативными решениями от ТОП-2

2. с новоиспеченным SAIF пока не удалось добиться успешной аннотации более чем одной цепи (clk), с предыдущим хотя бы входы-выходы сличались (SAIF от RTL vs EDIF). изучаю содержимое, экспериментирую....

3. попробовал вместо read_edif делать зачитывание нетлиста через read_verilog, потому как в новоиспеченный SAIF попадают "исковерканные" стандартом верилог на naming.convention имена сигналов типа din\[511\] - соответственно берёт он их такими из верилог-нетлиста, а в EDIF имена сигналов нековерканные. это тоже не дало результата.
 

вот как выписывает xsim по RTL:

(SAIFILE
   (SAIFVERSION "2.0")
   (DIRECTION "backward")
   (DESIGN )
   (DATE "Wed Mar 27 18:54:52 2019")
   (DIVIDER /)
   (TIMESCALE  0.01 ps)
   (DURATION  1502)
   (INSTANCE  tb
      (INSTANCE  u0
         (NET
            (clk (T0 748) (T1 754) (TX 0) (TZ 0) (TB 0) (TC 116))
            (rst (T0 1502) (T1 0) (TX 0) (TZ 0) (TB 0) (TC 0))
            (din\[0\] (T0 754) (T1 748) (TX 0) (TZ 0) (TB 0) (TC 58))
            (din\[1\] (T0 729) (T1 773) (TX 0) (TZ 0) (TB 0) (TC 29))

 

вот как делает SAIF альтернативный тул по нетлисту:

(SAIFILE
  (SAIFVERSION "2.0")
  (DIRECTION "backward")
  (DESIGN )
  (DATE "Mar 28 2019 17:38:24 UTC")
  (DIVIDER . )
  (TIMESCALE 1 fs )
  (DURATION  150200000)
  (INSTANCE top_name
     (PORT
        (clk
           (T0 74800000) (T1 75400000) (TX 0)
           (TZ 0) (TB 0) (TC 116)
        )
        (rst
           (T0 150200000) (T1 0) (TX 0)
           (TZ 0) (TB 0) (TC 0)
        )
        (din\[511\]
           (T0 150200000) (T1 0) (TX 0)
           (TZ 0) (TB 0) (TC 0)
        )

 

по факту разница лишь в DIVIDER иерархии.

перебирал зарные пути для read_saif -strip_path  но со вторым вариантом самое вменяемое решение: read_saif -no_strip

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, alexadmin said:

А почему post-synth? Я генерил SAIF по результатам P&R.

ну, мне хотя бы с этим разобраться....

в общем случае начинка SAIF будет идентична (если при роутинге не используются жёсткие оптимизации меняющие логическую схему, а значит и нетлист)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...