Кому разрабатывать схему, а кому разводить ПП, как лучше организовать процесс Опции

[alex_elect]

Хотелось бы обсудить следующий вопрос.
Как-то так исторически сложилось, что у нас на фирме разработкой схемы и разработкой печатной платы занимались разные люди. Т.е. процесс выглядел следующим образом:
- разработчик схемы передавал схему (+ файл списка цепей) и техническое задание на разработку разработчику печатной платы. В ТЗ он указывал желаемую компоновку, характеристики основных цепей и т.д.
- разработчик печатной платы выполнял разводку схемы, рисовал сборочный чертеж платы и готовил файлы для передачи в производство.
Однако в настоящее время, когда появились пакеты проектирования, позволяющие выполнять моделирование схемы с учетом топологии печатной платы, возникла необходимость в наличии топологии на этапе разработки схемы.
И вот как тут быть? Первое, что приходит в голову:
- А в чем проблема? Берешь и разводишь сам.
Но возникает следующий вопрос.
В каком виде передавать результат такой работы?
В виде рисунка топологии? Но очевидно, что разработчик плат с 10-летним опытом сделает это лучше новичка. А навязывать кому-то свой вариант разводки, или еще хуже, сидеть рядом и пальцем показывать куда вести цепь, явно бесперспективное дело.
Может правильный путь заложить результаты моделирования в схему в виде атрибутов цепей. Но можно ли передать таким способом всю необходимую информацию?
Кто-либо может поделиться своим опытом либо своими соображениями по данному вопросу?

[yornik]

Приходилось работать и "станочником-универсалом" (схема-разводка платы-корпус-софт контроллера-софт персоналки), и "пришивателем пуговиц" (свой модуль внутри большой FPGA или принципиальная схема одной платы в 19"-стойке). Все от проекта зависит, и от того, какие средства разработки имеются. По моим наблюдениям, однако, все чисто конструкторские заморочки (не связанные с электроникой или программированием) значительно сложнее остальных при внешней "ерундовости" (вроде того, как плату оптического датчика в корпусе закрепить, чтобы ни от вибрации не выпала, ни от конденсации не сдохла, и чтобы юстировать было удобно). И книжек таких, универсально-конструкторского толка, как-то не попадалось. Так что предпочитаю во всех сколь-нибудь нетривиальных случаях работой (и ответственностью за результат!) делиться.

По поводу "когда появились пакеты проектирования, позволяющие выполнять моделирование схемы с учетом топологии печатной платы, возникла необходимость в наличии топологии на этапе разработки схемы". Телега впереди лошади получается - т.е. не было пакетов - не было необходимости, так что ли? Имхо, случаев, когда топология тотально необходима (какие-нибудь полосковые СВЧ-фильтры) не так уж и много, и в этом случае схемотехника и разработка рисунка платы - одно и то же и выполняются в соответствующем САПРе. А в более типичных случаях, когда есть куча, скажем, около/загигагерцовых цифровых линий передачи, имхо, достаточно один раз совместно с конструктором пройти полный цикл <IBIS|SPICE>- моделирование - разводка - повторное моделирование - проверка в реальных условиях, а потом на основе полученных шаблонов этому конструктору во всех остальных проектах от вас будут нужны только списки цепей с типами сигналов и требованиям к временам задержек; про "мелочь" вроде того, что согласующий резистор ставится куда-то там ближе, он вас сам переспросит, если забудете написать в задании. Да и схемотехник по памяти набросает проверенную конфигурацию слоев и ширин дорожек - ведь даже в книжках для самых упертых "толькосхемотехников" уже не захочешь, на эти цифры наткнешься.
Так что нет проблемы - передать всю необходимую информацию конструктору, и наоборот тоже. Было бы желание. А "ура, добыли еще десяток крутых конструкторских САПРов, давайте, схемотехники, их изучим" - неверно, имхо. Только для простых проектов прокатывает в одиночку все сделать. А те конструктора, которые навсегда "заточили свои способности на минимальную длину проводников, VIA и прочей топологии, и понятия не имеет согласовании и наводках" нас покидают, естественным путем - как и схемотехники, знавшие толк только в релейной или тиристорной логике.
P.S. Хотя порой кажется - вот дали бы мне нормальный всесторонний САПР, да компьютер с мысленным интерфейсом-меелофоном, да станок а-ля "универсальный материализатор", да сказали бы четко, чего им надо - вот уж осчастливил бы всех и каждого. Ан нет в мире совершенства - пойди да вытряси, а чего ж заказчик-то хочет, на глюкастом САПРе с Ннадцатым сервис-паком схему нарисуй, конструктору задачу разъясни, ошибки монтажа найди, софт отладь, и "все должно было быть сделано еще вчера"