Jump to content

    

[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

 

 

Share this post


Link to post
Share on other sites

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 моделировании, но чего?

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

44 minutes ago, Doka said:

...

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

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

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

Удачи! Rob. 

 

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
2 minutes ago, Doka said:

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

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

Удачи! Rob.

Share this post


Link to post
Share on other sites

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

 

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

 

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
1 hour ago, alexadmin said:

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

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now