Jump to content

    

dxp

Свой
  • Content Count

    4103
  • Joined

  • Last visited

Community Reputation

0 Обычный

4 Followers

About dxp

  • Rank
    Adept

Информация

  • Город
    Array

Recent Profile Visitors

10141 profile views
  1. Там есть мегаудобная фича: можно соединить элементы (прямоугольные в основном) так, что при их перемещении и изменении размеров линии-стрелки не "ломаются", а концы как бы скользят вдоль края блока. Со многими другими редакторами блочных схем это боль - что-то пододвинуть или изменить размер - стрелки из прямых превращаются в ломаные, т.к. их концы жёстко привязываются к точке на границе блока, и поскольку при перемещении/ресайзе эта точка перемещается, она тащит за собой и конец стрелки. Вся красота сразу портится.
  2. У нас сборки в CI (дженкинс) используются в основном для того, чтобы убедиться, что в реп лёг правильный целостный проект, что он собирается с нуля, там всего хватает. Потому как собираемость на локальной рабочей станции разработчика не означает, что в репозиторий попадает всё, что нужно - каких-нибудь библиотек может не хватает или настроек, которые есть в локальном контексте, но не попадают в реп проекта. И если в CI собрался без ошибок, то всё гуд. Но все вопросы с функциональной целостностью, таймингами и прочим - это всё добивается самим разработчиком в своём локальном окружении. Включая и тестирование в симуляторе и железе.
  3. Для таких схем лучше использовать что-нибудь иное, нежели САПР печатных плат. Более лёгкое и удобное для этого. Посмотрите draw.io. Там в комплекте и библиотеки соответствующие есть. Про реле не помню, но усилитель, фильтр, логические элементы и даже электронные символы имеются. А структурные схемы рисовать вообще намного удобнее, чем в AD.
  4. Не, там обычный двухюнитовый сервер с двумя Xeon'ами и рейдом на HDD.
  5. Температурное разрешение очень хорошее. Пространственное - весьма посредственное, но и ожидать от 250х190 чудес не стоит. Судя по обзору, дивайс не поделка. Но и цена тоже не игрушечная.
  6. На работе десктоп на Core i5 CoffieLake какой-то, 9-й серии, 6 ядер однопоточных, 3.6 ГГц штатная, буст до 4.2 ГГц, сборочная машина для CI на базе Xeon, не помню какой, там аж 18 ядер, 36 потоков, таких Xeon'ов в сервере два, память многоканальная у каждого (там он что-то порядка 5 килобаксов стоил каждый), памяти тоже в избытке, тактовая около 2 ГГц (2.1 или 2.2, не помню точно). Квесту не проверял, а синтез в Vivado на рабочей станции почти в два раза быстрее. Тактовая всё же рулит. Ну, и Xeon там тоже не самый свежий. Дома Ryzen 5 3600x, частотка такая же, как и у рабочего, но кэш L3 32МБ против 9МБ у интела, сборка проектов на 15% быстрее на рязани. Подозреваю, что с симулятором будет примерно так же. Многопоточность реально даёт прирост только на синтезе IP ядер в OOC - тут они создаются и синтезируется независимо. Если надо много корок часто пересобирать, то в многопоточке есть смысл. Но на практике это далеко не самый частый случай.
  7. Это я упоминал. На 2018.2 она у нас давала лучше результаты по таймингам, на других стратегиях они просто не сходились. Но тут подтянул 2021.1 и получил сюрприз: тайминги развалились. Поменял на Performance_ExplorePostRoutePhysOpt и всё получилось. По поводу неработоспособности Performance_ExploreWithRemap. Такого ни разу не было, если проект собрался с неотрицательными слаками, всё работало исправно.
  8. Прикольный вариант. Для разъёмов с небольшим количеством контактов будет вообще норм. Для больших нумеровать уже трудоёмоко. Если только скриптами как-то автоматизировать. Но этим кунг-фу в AD не владею.
  9. Дак у него ж УГО есть, на схеме вот его прям видно (я видел такую схему, весьма уродливо выглядит).
  10. Это одни и те же. Количеством отличаются, по сколько нарубили.
  11. Если контакт ставить на схему как элемент, то у него появляется позиционное. Это как-то совсем некузяво. В общем, видимо запись контактов (партномер и количество) в параметрах разъёма с последующей постообработкой ВОМ (который экспортировать в виде csv файла) скриптом с извлечением требуемой информации, представляется наиболее рациональным.
  12. Так вопрос-то не в этом. А в том, как автоматизировать процесс, чтобы из схемы контакты отправлять в спецификацию, хотя в перечень они не попадают.
  13. Вижу, меня совсем не понимают. :( Вот сам разъём (у них он называется housing): его партномер: 51021-1500 И в схеме (в перечне) обычно он и фигурирует как наименование разъёма - по сути это его тип, тут закодирована серия, шаг, размеры, количество контактов. Но самих контактов, которые обжимаются на провода и вставляются в эту пластмасску, с ними не поставляется. Контакты там такие: Партномер контакта: 50058-8000. Они покупаются отдельно. И в схеме они никак не фигурируют. И в перечне элементов, соответственно, тоже. Но в ВОМ попасть должны. И надо бы как-то автоматизировать процесс. На мелких сериях мы не парились, купили один раз здоровенную катушку, на приличный срок хватило. Но на больших сериях, да ещё и когда производство не своё, а контрактное, этот способ не годится.
  14. При чём тут длина проводов и цвет корпусов разъёмов? Есть тип разъёма, к нему идёт строго определённый тип контакта. Нужно только, чтобы контакт тоже в BOM попадал автоматом.