[Zversky 16]

Всем добра.
Есть мысль хранить в к.-л. регистре (лучше не придумал как назвать) "слепок" всего проекта, а не, например, дату и время формирования прошивки.
Для этого есть мысль на Python-е или, лучше, на TCL "прошерстить" все нужные файлы проекта (включая, конечно, сам RTL код и (например для Quartus) файлы *.qpf и *.qsf (чуть не забыл про *.sdc и иже с ними)), сформировать одну на всех контрольную сумму, которую и занести в упомянутый ранее регистр.

Вопрос: есть, что посмотреть уже готового по теме, дабы не изобретать самокат?

[RobFPGA 27]

13 minutes ago, Zversky said:

Для этого есть мысль на Python-е или, лучше, на TCL "прошерстить" все нужные файлы проекта (включая, конечно, сам RTL код и (например для Quartus) файлы *.qpf и *.qsf (чуть не забыл про *.sdc и иже с ними)), сформировать одну на всех контрольную сумму, которую и занести в упомянутый ранее регистр

Для того  нет смысла  изобретать свой велосипед, достаточно хранить хеш  ревизии  репозитория которая компилируется. 

[krux 8]

лучший вариант - пользоваться встроенныеми возможностями своей системы контроля версий.

Либо оборачивать ее до тех пор пока не устроит.

[Zversky 16]

Вот и Gowin что-то придумал

В 19.12.2022 в 14:54, RobFPGA сказал:

достаточно хранить хеш  ревизии  репозитория которая компилируется. 

Пока что не пользовал (здесь) контроль версий, но, если использовать, то локальный? А, если локальный, как он будет себя вести с переносом с одной машины на другую?

В 19.12.2022 в 16:54, krux сказал:

лучший вариант - пользоваться встроенныеми возможностями своей системы контроля версий.

Да, наверное без СКВ не обойтись

[StewartLittle 41]

В 20.12.2022 в 18:52, Zversky сказал:

Вот и Gowin что-то придумал

Да ничего он особенного не придумал!

Просто в настройках синтезатора нужно указать файл tcl-скрипта (который юзер должен сам написать!), который будет автоматически запускаться перед компиляцией и править исходник, вставляя туда новый таймстамп (задача предусмотреть такую возможность и соответствующий блок в исходнике также лежит на юзере).

[makc 192]

Почему просто не вписать серии метку времени в user id на этапе формирования битстрима? Для этого уже все давно есть.

[des00 25]

9 hours ago, makc said:

Почему просто не вписать серии метку времени в user id на этапе формирования битстрима? Для этого уже все давно есть.

а чем поможет метка времени сборки? Вот делал подобное на альтере, ну чисто только поиграться) Ну работаешь над проектом, сделал сборку зашил, потом  (без комита) проверяешь какую нить фичу или правишь багу. Собрал заново. Зашил. Ну да, можно определить что прошивки собраны в разное время, но ни чем они отличаются, ни их историю не отследить. В итоге побаловался и бросил. 

[makc 192]

13 минут назад, des00 сказал:

а чем поможет метка времени сборки?

В процессе отладки - всё зависит от частоты коммитов и порядка работы. Если работать по принципу закоммитил, собрал, прошил, то метка времени позволит определить коммит, из которого была собрана прошивка. То же самое касается версий прошивок, отправленных тестировщикам или на производство. А если же модификации, сборки и прошивки идут хаотично, то тогда и id коммита ничем не поможет, т.к. после коммита могло быть сделано неизвестно какое количество правок.

17 минут назад, des00 сказал:

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

Иногда из-за дефектов в процессе тестирования может прошиться не то (не оттуда) и изменившаяся метка времени это хороший признак изменения прошивки в плате. Мне это удобно.

[RobFPGA 27]

13 hours ago, Zversky said:

Пока что не пользовал (здесь) контроль версий, но, если использовать, то локальный? А, если локальный, как он будет себя вести с переносом с одной машины на другую?

Хэш  коммита в репе одинаков на любой  машине.  Во всяком случае  в Git. 

У меня  это делается  автоматом скриптом в начале билда.  Сначала проверяется есть ли изменения текущих файлов по сравнению с репом. Если есть то делается авто-коммит (или ругается и требует сделать коммит руками). 
Затем берется хеш коммита, дата и время начала компиляции, вычисляется минорная ревизия от последней метки в репе. И все это при синтезе засовывается в фикс. регистры. А заодно и создается текстовый файл с этой инфой который помогает утром вспомнить что за бинарник "вдруг" появился из ниоткуда ...  
И если затем когда ни будь нужно то по хешу в репе легко находится соотв. коммит со всеми исходниками и настройками проекта.   

[Zversky 16]

10 часов назад, StewartLittle сказал:

Просто в настройках синтезатора нужно указать файл tcl-скрипта

У Альтеры этому решению уже сто лет как, причём есть как пре, так и пост (и, не помню, вполне м.б., что для каждого из процессов отдельно): сам писал (немного модифицировал родной альтеровский скрипт) перед компиляцией генерацию модуля, хранящего дату и время, дабы уже основной RTL подцепил его в себя, а после всей компиляции копировал битстрим в нужное мне место.
Но вот вопрос: а есть ли ограничения на TCL для Gowin? Из того, что используется при сборке проекта в режиме CLI, разрешены на все операторы, как, например, я использую в Mentor-е.

И есть ли пример этого скрипта где (на githab-е?)

10 часов назад, makc сказал:

Почему просто не вписать серии метку времени в user id на этапе формирования битстрима? Для этого уже все давно есть.

Потому что датой и временем определяются только они сами по себе. Я не смогу сопоставить потом при реверсе какому проекту сопоставлена прошивка.  И да: я этим занимался лет 10 назад - не пошло.

53 минуты назад, des00 сказал:

В итоге побаловался и бросил. 

+1

37 минут назад, makc сказал:

Иногда из-за дефектов в процессе тестирования может прошиться не то (не оттуда) и изменившаяся метка времени это хороший признак изменения прошивки в плате. Мне это удобно.

Может, имеет смысл писать и то и то?

10 минут назад, RobFPGA сказал:

Хэш  коммита в репе одинаков на любой  машине.  Во всяком случае  в Git.

Склоняюсь к Git. Спасибо всем

[makc 192]

9 минут назад, Zversky сказал:

Может, имеет смысл писать и то и то?

У меня на самом деле так и есть: есть ROM со строкой версии, куда можно засунуть хоть текст, хоть SHA id. И есть USER CODE с меткой времени для оперативного контроля.

[des00 25]

1 hour ago, makc said:

В процессе отладки - всё зависит от частоты коммитов и порядка работы. Если работать по принципу закоммитил, собрал, прошил, то метка времени позволит определить коммит, из которого была собрана прошивка. То же самое касается версий прошивок, отправленных тестировщикам или на производство. А если же модификации, сборки и прошивки идут хаотично, то тогда и id коммита ничем не поможет, т.к. после коммита могло быть сделано неизвестно какое количество правок.

Иногда из-за дефектов в процессе тестирования может прошиться не то (не оттуда) и изменившаяся метка времени это хороший признак изменения прошивки в плате. Мне это удобно.

 для этого заводил программный регистр в котором хранил hardwareID/softwareID, первый - ID железа по технологической документации, назначаемый при открытии проекта, второй классический <номер версии>.<номер ревизии>.<номер багфикса>. 

[makc 192]

Только что, des00 сказал:

для этого заводил программный регистр в котором хранил hardwareID/softwareID, первый - ID железа по технологической документации, назначаемый при открытии проекта, второй классический <номер версии>.<номер ревизии>.<номер багфикса>. 

Как я уже написал выше у меня по сути как и есть: ROM со строкой идентификации прошивки + USER CODE с меткой времени сборки.