[one_eight_seven 6]

23 hours ago, OparinVD said:

Не стал отдельную тему заводить

Порекомендуйте, пожалуйста, какой симулятор взять  с фтп, чтоб был полноценный, был совместим с vivado 2022.2, желательно работал под убунтой, ну и самое важное - с рабочей таблеткой ))

В этой индустрии убунту не существует. Все поддерживают RedHat, кое-кто поддерживает Suse.
"Совместим с vivado" - это что? Никто их не делает совместимыми с вивадо или ещё чем. У каждого из низ свои команды компиляции, элаборации, симуляции. У каждого из них на кой-то чёрт есть фронтенд для вызова некоторого подмножества из ранее упомянутых отдельных команд. Фронтенды эти разной степени недоделанности и бесполезности. Если вивадо, то, наверное, знаком Modelsim? если так, то наиболее знакомой окажется Questa Sim от Siemens EDA, даже команды все те же. А вообще они все - Xcelium, VCS, Questa делают свою работу. На мой взгляд, лучший среди них - это VCS.

[one_eight_seven 6]

On 7/19/2023 at 11:46 AM, Raven said:

Это никто и не утверждал. Просто MR/PR хорошо укладывается в процедуру работы больших коллективов разработчиков.

Я полностью открыт для просветления. Поясните, пожалуйста, конкретнее, как по вашей методе предполагается противостоять тем проблемам, о которых выше поведал @dxp.

Я ранее просил, если вы во flow с CI помещаете конченных идиотов, то помещать таких же во flow с merge request'ами. Если есть утверждение, что идиоты не смогут создать рабочий мастер, то они точно так же не смогут создать и рабочую ветку (СЮРПРИЗ: мастер - это тоже просто ветка, никакого волшебства в ней нет). Только вместо одной версии, которую надо бы сделать, будет всё увеличивающееся количество других нерабочих веток.

В любом Flow при этом надо не коммитить запрещать, а идиотов исключать из процесса.

 

Далее, не пущать в мастер, если мерж реквест не прошёл CI. На первыый взгляд кажется разумным. Но только на первый взгляд. Это имеет смысл только если не смогли сделать хороший  набор тестов. Прекрасный пример - HP, они не смогли, и у них тестовый конвейер бежал 2 часа. Они смирились с тем, что тесты писать не умеют, и сказали, что мастер тестировать они не будут, зато будут тестировать отдельные ветки. И полную регрессию запускали на ветке, прежде, чем отприавить в мастсер. Но новая ветка у них всё-равно начиналась с мастера, и по прохождению тестов код тоже попадал из ветки в мастер.

 

Но вообще это требование звучит вот так:
- Нельзя сохранять файл, который не компилируется
- Но как его проверить, не сохраняя? Компилятор же будет компилировать только то, что сохранено
- Сохраняйте файл под другим именем, перепишите скрипты сборки, и когда соберётся, сохраняйте файл как надо, и обратно меняйте скрипты сборки. Звучит не как работа, а как ИБД.

 

Ведь  CI делает именно это. Он запускает скрипты сборки. И, чтобы он запускал их на другой ветке, её надо прописать в эти скрипты. А при удалении ветки - и это всё тоже удалить. Есть возможность автоматизированно сделать mult-branch pipeline но там будет fail если хоть одна ветка упадёт, поэтому, без ручной работы снова никак. А ради чего? Ведь если у человека это не мерджится на его рабочей станции, при полном контроле над файлами, при всех его удобных тулах, то с чего ровно этот же код ВДРУГ должен смержится сервером сборки?
В итоге, просто весь маршрут проще и надёжнее, если каждый коммитит в мастер. Кстати, это не означает, что он реально обязан коммитить в мастер. Это тоже непонимание инструментария. Это технически, значит, что он у себя начинает работу, ответвившись от мастера, после того, как сделал работу он проверяет обновления мастера, работоспособность мастера, и после этого мержит локально свои изменения  и мастер ,и снова проверяет работоспособность. Если всё хорошо, он коммитит уже этот смерженный рабочий код обратно в мастер.

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

Ну и ещё один аргумент. Что идёт в поставку? Где тот код, который должен пойти заказчику? В CI - это master. А в тысячеветочном мержреквестном? Если это тоже мастер, тогда всё просто - всё снова должно закончиться тем, что каждая ветка должна прийти в мастер, и закончиться на этом. Вопрос лишь в том, где это делать удобнее, и кто у вас умнее - скриптованный болван или разработчик : )

[andrew_b 15]

2 hours ago, one_eight_seven said:

В этой индустрии убунту не существует. Все поддерживают RedHat, кое-кто поддерживает Suse.

На других дистрах тоже замечательно работает.

2 hours ago, one_eight_seven said:

"Совместим с vivado" - это что? Никто их не делает совместимыми с вивадо или ещё чем.

А криптованные IP-ядра вы как симулировать будете, если в вашем симуляторе нет соответствующих ключей?

[one_eight_seven 6]

2 hours ago, andrew_b said:

На других дистрах тоже замечательно работает.

1. Не всё.
2. Не всегда.
3. И поддержка ответит в стиле: "работоспособность проверяется только на указанных в release notes операционных системах".

Лично видел неправильную работу симулятора. Проблема не воспроизводилась на легальной поддерживаемой системе. Чаще такое было с каким-нибудь непонятным segfault'ом. Но один раз видел прямо неправильную работу VIPов. То есть, симуляция шла неправлиьно.

 

Quote

А криптованные IP-ядра вы как симулировать будете, если в вашем симуляторе нет соответствующих ключей?

Так это криптованные ядра должны поддерживать симуляторы.

[andrew_b 15]

7 hours ago, one_eight_seven said:

1. Не всё.
2. Не всегда.

Согласен. Но в большинстве случаев работает.

7 hours ago, one_eight_seven said:

поддержка ответит

Мы все ещё про Росиию говорим?

7 hours ago, one_eight_seven said:

Так это криптованные ядра должны поддерживать симуляторы.

Не понял, кто на ком стоял? Генерируете IP в Виваде версии N, успешно симулируете в Квесте версии Q. Генерируете IP в Виваде версии M (M > N), Квеста версии Q прожевать это не может. Обновляете Квесту до версии P (P > Q), снова успешно симулируете.

[one_eight_seven 6]

17 hours ago, andrew_b said:

Мы все ещё про Росиию говорим?

Скорее про: "Знал бы прикуп - жил бы в Сочи". На мой взгляд, безудержная страсть к Ubuntu не стоит потенциальных проблем.
 

 

17 hours ago, andrew_b said:

Не понял, кто на ком стоял? Генерируете IP в Виваде версии N, успешно симулируете в Квесте версии Q. Генерируете IP в Виваде версии M (M > N), Квеста версии Q прожевать это не может. Обновляете Квесту до версии P (P > Q), снова успешно симулируете.

Ключи определяет тот, кто шифрует. Если корка зашифрована без ключей, скажем, для Xcelium, то в Xcelium оно не откроется. Поэтому, вопросы в данном случае к призводителю IP-корки.

Но в целом ваше замечание справедливо. Этот момент надо учитывать.

Изменено 24 июля, 2023 пользователем one_eight_seven

[OparinVD 0]

да, под совместимостью с vivado я имел в виду способность работать с ее криптованными корками... не знаю, меняют ли они ключи каждый раз, когда меняется номер версии, но таблица совместимости в доках есть... если не поедет под убунтой - это полбеды, что-нибудь придумаем

[dxp 53]

В Vivado есть требование к определённой версии симулятора. Например, 2018 требовала квесты (если квесты) 10.6с, и любая другая  версия порождала предупреждение. С квестой  10.4а не работало -- не могла квеста расшифровать  secureip библиотеку. Но вот 10.4е уже могла, и хотя предупреждение оставалось, всё работало. И даже если подсунуть квесту 10.7с. то всё равно  предупреждение (и тоже всё работает). Т.е. Vivado проверят на точное совпадение. Хотя ключи там меняются не так часто, и реально весьма широкий диапазон версий симуляторов работает с криптованными библиотеками.

И да, по убунтой Vivado и Questa прекрасно работают. А для Vivado убунта прямо указана в поддерживаемых ОС.