Бугурта от электроники тред

Знайте что я тут подумал? Профессиональное радиоблядство для быдла.

Современная электроника сильно усложнилась. Микросхемы имеют по 1000 шаров, причем часть из них однотипные, как например адресные шины, шины данных etc. И как же производители кадов предлагают мне иметь с этим дело? А никак. Они предлагают ебашить отдельно каждую ногу, делать по ней двойной клик и заполнять свойства этой ноги. А после создания библиотеки и установки модели на схему, предлагается подключать вручную каждый ебучий проводник. Ну не охуели ли вы, господа? Я вам что, скот, который может целый день выполнять однотипные операции?

А ведь все могло быть по другому... Можно было бы разработать языки описания аппаратуры. Как СистемВерилог, но с учетом особенностей обычной схемотехники. Тогда бы и шины в микросхемах описывались намного проще:

interface DDR3
{
AddressBus[15];
DataBus[64];
...
}

package BGA96(A0:M10)
{
// Описание закона, ставящего в соответствие каждой ножке ее координаты на корпусе
}

ic Ddr3InBga96(DDR3, BGA96)
{
// Задаем соответствие между пинами корпуса и проводами интерфейса
AddressBus = {M1, N2, P1, H1, M3, ...};
DataBus = {K1, B2, H3, ...};
...
}

А знаете почему все не так? А потому, что производители кадов ориентируются на быдлоинженеров, которые не могут в код и которым подавай окошечки, менюшечки, визардики. И на индусов с китайцами, которые могут работать сутками напролет за миску риса и выполнять любую работу, которую скажет выполнять начальник. Тьфу, блять! Смотреть на вас всех тошно!

>>189197 (OP)
Ты там совсем уже ёбнулась, неполовозрелая цифровая макака?

>>189205
А что не так?

>>189197 (OP)
ПОДКЛЮЧИЛ АРДУИНУ
@
СКЕТЧ НЕ ЗАЛИВАЕТСЯ

>>189210
Я тебе про применение принципов программирования в разработке электроники, а ты мне про ардуино. Вообще охуеть.

Сажа, скрыл.

>>189214
Аргументируй. Или жопный пожар не дает тебе сосредоточиться?

>>189210
Кстати, ардуинопидары в массе своей кодить как следует не умеют.

>>189197 (OP)
Что за софтина на оппике справа?

>>189230
MS Paint

>>189197 (OP)
>Я вам что, скот, который может целый день выполнять однотипные операции?
Ты будешь смеяться, но во всех более-менее крупных конторах есть человек, в чьи обязанности входит только менеджмент библиотекой компонентов, да ещё и есть ставка для какой-нибудь девочки-студентки, которая руками хреначит компоненты для библиотеки.

>>189230
>Что за софтина на оппике справа?

Очевидный P-CAD 2004 очевиден.
Altium Designer это

>Они предлагают ебашить отдельно каждую ногу, делать по ней двойной клик и заполнять свойства этой ноги.
То то на сайте производителей лежат их библиотеки компонентов для кадов.

>Можно было бы разработать языки описания аппаратуры
VHDL ?

Сеганул умника.

ОП хуй.

>>189197 (OP)
>КО-КО-КО
Дали ему хороший инструмент - нет, не хочу его функции изучать, хочу говно жрать!
http://techdocs.altium.com/display/ADOH/Editing+Multiple+Objects
>USING A QUERY TO FIND AND EDIT MULTIPLE OBJECTS

>>189254
http://techdocs.altium.com/display/ADRR/Sch_Pnl-SCHList((SCH+List))_AD

>>189197 (OP)
Ага. И роботизированное автоматическое производство. А потом каждый сраный телефон будет вглядеть как пикрелейтид из-за нагромождения legacy-кода, творчества индийских аутсорсеров, дллок на 5 мегабайт, подключенных единственной функции ради и прочего кодового мусора.

Ох ты, сколько вас тут собралось. Начнем по порядку.

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

>>189245
>То то на сайте производителей лежат их библиотеки компонентов для кадов.
Охуительные истории, бро.

>>189245
>VHDL ?
Нахуй забирай свое говно. И Verilog прихвати. Единственный более менее годный язык это SystemVerilog с его божественными интерфейсами, структурами и юнионами, но и тот не лишен недостатков. Но самая соль в том, что его мало какой софт адекватно поддерживает. Особенно сильный пожар в моей жопе случился, когда я юзал Vivado от Xilinx. Это пиздец, господа. Таскать из файла в файл списки проводов для шины AXI - это вам не хуй собачий. А ведь могли бы няшные системверилоговские интерфейсы запилить. Индусы одним словом. В любом случае, для обыкновенной схемотехники понадобился бы свой язык, с учетом ее особенностей.

>>189245
>Сеганул умника.
>Кококо, ты чо самый умный что-ли сука?
>Кукареку, тебе больше всех надо что-ли?

>>189254
>Дали ему хороший инструмент - нет, не хочу его функции изучать, хочу говно жрать
>Altium
>Хороший инсрумент
Ясно. Понятно.

>>189254
>USING A QUERY TO FIND AND EDIT MULTIPLE OBJECTS
>QUERY
Костыль. Костыльность заключается в отсутствии исходников кода, как элемента конечного дизайна. Т. е. разработчик по прежнему генерирует данные в виде библиотек, соединений элементов etc. А когда разработчика настигает нужда, он пишет этот твой запрос, которым меняет, скажем, номинал резисторов в R-2R ЦАПе. Причем исходник запроса после этого теряется. Максимум что можно сделать - это схоронить его в текстовом файле на рабочем столе.

Вместо этого, по моему мнению, разработчик должен описывать законы, по которым эти данные может сгенерировать компьютер. Касательно примера с R-2R ЦАПом, это позволит достичь параметризации, благодаря которой, станет возможно изменением одного значения в исходнике, менять номинал резисторов в ЦАПе или даже его разрядность. Т. е. наш R-2R ЦАП становится универсальными модулем, и будучи однажды написанным, может в дальнейшем использоваться разными разработчиками для разных целей. Но к сожалению, быдло и так хавает кады, каждый раз заново изобретая один и тот же велосипед с разным числом колес.

>>189275
>охуительные истории от РАЗРАБОТЧИКА в радаче со стартапом
>альтиум не хороший инструмент
>в запросы не умею
>о логе вносимых изменений по запросу не знаю
Ну тут всё понятно.

>>189296
>альтиум не хороший инструмент
Пожалуй лучший из имеющихся. Но это не отменяет его хуевости в плане предлагаемой им стратегии разработки.

>>189296
>в запросы не умею
>о логе вносимых изменений по запросу не знаю
По недостаткам запросов, как концепции, есть что сказать?

>>189274
>нагромождения legacy-кода
>дллок на 5 мегабайт
О статической линковке и оптимизации мсье, я так понимаю, не слышал?

Bump

>>189275
Ну-ка, рассказывай, как параметризировать settling time, DNL, INL у R-2R цапа.

>>189393
>settling time
Я пока только о схемотехнике говорил. До автоматизированной разводки платы мы еще не добрались.

>DNL/INL
Выбор допуска резисторов по заданным максимальным DNL/INL тебя чем не устраивает?

Веб-кодерок хоббист в треде. Перепробовал альтиумы менторы диптрейсы и остановился на менторе. Все это запредельное говноедство да.

Вместо трейсов ошибок они предлагают открывать файлики логов. Вместо описывания кодом связей компонентов предлагают тянуть дороги в схематике. Уже третий год делая прототипчик своей платки мне хочется сделать наконец нормальный кад но это пиздец проёб времени я староват уже для подобных трюков. С другой стороны можно всётаки наверное вкатиться в эту нишу.

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

>>189438
>тянуть дороги в схематике
Сосачую тебя. Разработчик вынужден решать задачи, которые по сути не влияют на конечный результат. Представим, например, оче плотную схему, в которую нужно добавить пару деталек. Что нам придется делать? Нам придется раздвигать ворох проводов и компонентов, чтобы освободить место для новой детальки. Это при том, что по сути требуется лишь добавить новые связи между элементами и ничего более. Графические редакторы - зло.

>>189438
>это очень коммерциализировано
И снова сосачую. Все платное дохуя. И отсутствуют какие-либо общие стандарты. Каждая фирма клепает свои либы компонентов для своего када и никто нихуя не делится.

Блять, веб погромисты в треде. У меня пердак летит на луну.
>Представим, например, оче плотную схему, в которую нужно добавить пару деталек. Что нам придется делать? Нам придется раздвигать ворох проводов и компонентов, чтобы освободить место для новой детальки. Это при том, что по сути требуется лишь добавить новые связи между элементами и ничего более.

А что, эта новая деталька в воздухе должна будет повиснуть? Я просто не могу с вас, такая злоба невыносимая.
Дороги им, блять, таскать не хочется. Охуеть.

>>189442
>эта новая деталька в воздухе должна будет повиснуть?
Это ты с чего взял? Объяснись.

>>189442
>Дороги им, блять, таскать не хочется. Охуеть.
Объяснили же тебе, чем плохо дороги таскать. Алсо в FPGA разработке таскание дорог считается зашкваром. Но в классической схемотехнике такой от этого уходить почему-то не спешат.

>>189442
>Блять, веб погромисты в треде.
Я вовсе и не веб-программист, например.

>>189444
>Это ты с чего взял? Объяснись.

>Это при том, что по сути требуется лишь добавить новые связи между элементами и ничего более
???
Алсо, если такие хитрожопые - пишите нетлисты в блокноте, хуле там. Там очень быстро связи можно сделать и дороги таскать не надо.

>Я вовсе и не веб-программист, например.
Я тоже.

>Объяснили же тебе, чем плохо дороги таскать
Не объяснили.

>>189446
>пишите нетлисты в блокноте
Это все-равно что кодить на асме - в больших проектах нинужно. Нетлист должен генерироваться. Есть два пути: генерирование из схемы и генерирование с помощью языка проектирования. Второй способ гораздо универсальней.

>>189446
>Не объяснили.
Давай еще раз объясню чем плох графический способ проектирования:
1. Приходится решать задачу компоновки компонентов в схеме, не смотря на то, что она никак не влияет на конечный результат, а влияет лишь на изображение схемы.
2. Отсутствует возможность алгоритмизации и параметризации. Я уже приводил пример с R-2R цапом. Вместо рисования десятка резисторов, можно описать закон построения одного элемента и способ его подключения к следующему элементу (алгоритмизация) и задать число повторений для получения нужной разрядности ЦАПа (параметризация).
3. В современных редакторах отсутствует понятие интерфейса. В альтиуме конечно сделали harness'ы, но это говно без задач. Нормальный интерфейс должен быть параметризируемым (чтобы менять разрядность его шин, например) и должен описываться один раз а не копироваться из схемы в схему, как в альтиуме.
4. В схемных редакторах все проводники представляют собой простые связи (сигнализируют лишь о соединения сетей). Такой функциональности не всегда достаточно. Например, провода между памятью DDR3 и процессором было бы здорово соединить специальным примитивом "длинная линия" с заданными параметрами "временная задержка" и "импеданс", а не выкручиваться net tie'ами как сейчас. Подобных примеров можно выдумать большое множество и для каждого потребуется свой примитив. Наличие большого количества различных примитивов затруднит реализацию такой концепции в схемном редакторе, т. к. для каждого примитива придется выдумывать графическое обозначение, что несомненно запутает читающего схему инженера.

>>189450
>Приходится решать задачу компоновки компонентов в схеме
Зачем? Ставьте компоненты в принципиальной, там никакой компоновки не надо.
>Отсутствует возможность алгоритмизации и параметризации
Ну для параметризации есть всякие матлбабы, например.
Всё равно не вижу применений этому в сквозном проектировании.
В том же альтиуме после установки компонента сразу вылезает окно с выбором нового. Ну и копипастить 3 секунды свои резисторы для нищенского ЦАПа тоже никто не запрещает.
>В современных редакторах отсутствует понятие интерфейса.
Зачем знать о разрядности шин при компоновке платы?
>"длинная линия" с заданными параметрами "временная задержка" и "импеданс"
Тебе надо, чтобы каждый проводник на схеме, в зависимости от импеданса и задержки, окрашивался своим цветом\выглядел иначе? Мде. Ну и то, что альтиум умеет в расчет импедансов и задержку, я говорить не буду.

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

>>189458
Ты совершенно не понимаешь моих мыслей. Давай по порядку.

>>189458
>Зачем? Ставьте компоненты в принципиальной, там никакой компоновки не надо.
Я как раз и говорю о компоновке в принципиальной схеме. Покажу на примере, что я имею в виду. Обрати внимание на пикрилейтед #1. Видишь C156, C157? Допустим, что испытания прототипа показали нехватку блокировочных конденсаторов и тебе необходимо добавить к этим кондерам еще пару-тройку. Каковы твои действия? Ты начнешь двигать резисторы, чтобы вместить туда новые элементы. И хорошо, если их будет куда двигать, ибо в сложном случае тебе придется и вовсе переделывать пол-листа. Но самое обидное, что эта перекомпоновка совершенно не влияет на конечный результат - это издержки выбранного способа проектирования. Компоновка же в печатной плате, напротив, важна - от нее зависит результат: размер платы, влияние компонентов друг на друга и т. д.

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

>В том же альтиуме после установки компонента сразу вылезает окно с выбором нового
Если ты знаком с программированием, то представь, что перед тобой стоит задача инициализировать массив числами 0, 1, 2, 3 ... Я тебе говорю, что надо делать так: for(int i = 0; i < a.length; i++) a = i;, т.к. это универсальный и компактный способ, а ты говоришь, что всегда делал так: a[0] = 0; a[1] = 1; a[2] = 2;... потому, что среда предлагает тебе следующую строчку после ввода точки с запятой. Также и с резисторами в R-2R ЦАПе. Вместо разработки универсального модуля с настраиваемой разрядностью ты предлагаешь ебашить цап каждый раз заново.

>>189458
>Зачем знать о разрядности шин при компоновке платы?
Не понял твоего вопроса. Темы разводки платы мы еще не поднимали. Интерфейсы нужны для реализации принципа повторного использования при проектировании схемы.

>>189458
> окрашивался своим цветом\выглядел иначе?
Нет. Цвета, граф. обозначения, толщины - все это для визуально ориентированного схемобыдла. Я хочу иметь возможность задать параметры проводника еще на этапе проектирования схемы, а не во время разводки. Сейчас приходится выкручиваться подписями, как на пикрилейтед #2. Это плохо, т.к. подписи доступны только человеку. Параметры же проводника может считать PCB кад, с определенной степенью автоматизировать разработку или хотя бы просигнализировать, что проведенный разработчиком проводник не соответствует ограничениям, указанным в схеме. Предвижу кукареку про констрейнты в альтиумовском псб редакторе.

Я так нихуя и не понял, чего хочет ОП. Звучит так, будто он хочет софт с одной кнопкой - "MAKE PIZDATO".

>>189462
>Видишь C156, C157? Допустим, что испытания прототипа показали нехватку блокировочных конденсаторов и тебе необходимо добавить к этим кондерам еще пару-тройку. Каковы твои действия?
На листе куча пустого места. Туда и добавялешь.

>>189462
Чтобы сделать так, как ты хочешь, нужен роутер/автоплейсер, который адекватно всё сам сделает. МНе пока такие не попадались

>>189467
>На листе куча пустого места. Туда и добавялешь.
Сам потом будешь объяснять ПСБ дизайнеру, что вон тот кондер в левом нижнем углу листа нужно ставить как можно ближе к вот этой микросхеме в в правой верхней части.

>>189464
ОП хочет описывать электронные схемы языком программирования

>>189468
>нужен роутер/автоплейсер
Да что ж вы все сразу к роутингу перескакиваете? Я вам пока что только про схемный редактор рассказываю.

>>189470
>Сам потом будешь объяснять ПСБ дизайнеру,
Для этого есть комментарии на схеме.

>>189471
>языком программирования
Почти так, да. Но язык должен быть специфическим.

>>189474
>Но язык должен быть специфическим.
Ну так придумай такой язык, хули ты. Сделай под него софт и стриги купоны.

>>189472
>Да что ж вы все сразу к роутингу перескакиваете?

А сам-то?

>>189470
>Сам потом будешь объяснять ПСБ дизайнеру

>>189473
Существует возможность пропустить или неправильно интерпретировать такой комментарий из-за отсутствия контроля со стороны када. Впрочем, комментарии я уже обоссал тут >>189462

>>189462
Ну наконец-то.
>Обрати внимание на пикрилейтед #1.
Шунты удобно делают через порт. А где-то отдельно вдали уже рисуй хоть 10 кондеров в ряд.
Но двигать и правда не всегда приятно, но альтернативы не вижу, предлагай. (кроме кнопки "make peezdato")

>Также и с резисторами в R-2R ЦАПе.
Опять ты со своим ЦАПом. Кроме этого есть какие-то настраиваемые модули, нужные тебе?
R-2R сборка это вообще пушка конечно. Микроконтроллеры или ЦАПы из коробки не нравятся?

>как на пикрилейтед #2
Кукарекe насчет констрейтов для каждого NET'a вполне обоснованы и логичны.
А подписи, что конденсаторы надо бы поближе к ногам делать, а дорожку с 5А надо бы пожирнее - ну вообще охуеть. Если только ты не занимаешься лишь принципиалкой, а какой-то студент тебе за чай делает печатку.

>>189477
Я не перескакивал. Я лишь указал, какие недостатки схемных редакторов негативно влияют на следующий шаг проектирования. Наличие же автороутера никак не влияет на способ проектирования схемы классический или с использованием языка описания аппаратуры, поэтому мне непонятны причины из-за которых ты о нем заговорил.

>>189480
Ок, расскажи, как ты видишь процесс поиска багов в схеме, если описывать ее при помощи языка? Что будет, если ты вдруг перепутаешь буквы и соединишь не те ноги?
Алсо, как предлагаешь согласовывать такие "схемы"? Понесешь начальству простыню кода типа на - читайте, подписывайте?

>>189481
Тихо, тут рождается россеянский SAP.
Топор уже изобрели с самым лучшим автотрассировщиком, так почему бы и кад не забубенить?

>>189479
>Шунты удобно делают через порт
This >>189470

>>189479
>Опять ты со своим ЦАПом
Это просто хороший пример схемы, которую можно параметризировать. Если хочешь, то я могу посидеть и подумать над другим примером.

>>189479
>Кукарекe насчет констрейтов для каждого NET'a вполне обоснованы и логичны.
Не логичны. Принципиалку и плату могут делать а так и будут делать в крупной фирме разные люди. Нужен надежный способ передачи информации о дизайне между ними. Комментарии это не выход - я уже писал почему. Констрейнты указываются на этапе проектирования платы, следовательно не подходят, т. к. разработчик схемы по сути не должен иметь к ним доступа. Ну и еще раз обращаю твое внимание на net-tie для разделения сетей при выравнивании длин трасс - это охуенный костылище.

>>189479
>А подписи, что конденсаторы надо бы поближе к ногам делать, а дорожку с 5А надо бы пожирнее - ну вообще охуеть
Ты это инженерам из Nvidia скажи. На пике схема их борды.

>>189476
>Сделай под него софт и стриги купоны
Так и сделаю. Просто мне нужно подискутировать с аноном, чтобы выяснить не ебанулся-ли я, ибо некоторые психические болезни могут протекать скрытно от поциента.

>>189484
>мне нужно подискутировать с аноном, чтобы выяснить не ебанулся-ли я
Полтреда тебе говорят, что ты ебанутый. А ты все сопротивляешься.

>>189484
>не ебанулся-ли я
>А знаете почему все не так? А потому, что производители кадов ориентируются на быдлоинженеров, которые не могут в код и которым подавай окошечки, менюшечки, визардики. И на индусов с китайцами, которые могут работать сутками напролет за миску риса и выполнять любую работу, которую скажет выполнять начальник. Тьфу, блять! Смотреть на вас всех тошно!
>Все мудаки, один я Д'Артаньян.
Вообще ни разу не ебанулся.

>>189482
>рождается россеянский SAP.
Не российский надеюсь. Я потенциальный пётр.

>>189481
>как ты видишь процесс поиска багов в схеме
ВНЕЗАПНО, можно сгенерировать схему по ее описанию, как например это делается в Quartus или Vivado. Ее-то ты и можешь отнести начальству. Но такой способ поиска багов не очень надежен, поэтому неплохо было бы разработать что-то вроде юнит-тестирования. Например, в виде частичного моделирования схемы. Наш дизайн теперь состоит из отдельных модулей, поэтому мы можем абстрагироваться от прочих участков схемы. Ну и в конце концов, ошибки в буквах не часто случаются в программировании, т. к. компилятор обычно ругается на обращение к несуществующим объектам. Чего не скажешь о том же альтиуме. Если если ошибиться в названии метки, то элемент вместо подключения к нужной сети, просто останется висеть в воздухе. Причем кад об этом стыдливо умолчит.

>>189486
Гемфри Поттер с тобою не согласен. http://clubbrain.ru/referatu-avtomatika/avtomatiziroval-malchik/

>>189485
>А ты все сопротивляешься.
Смысл именно в том, чтобы не дать себя обоссать.

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

ОП, говноедам чтото обьяснять бесполезно.

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

Я разделяю твоё стремление но прозреваю что язык будет путаный очень. Ну тоесть я прикинул как бы я делал на DSL на python и как то слишком много аспектов. Ну т.е. окей допустим мы форсим модульность(что везде неплохо). при том в нетах нам нужна звезда. а ис из разных модулей мы вообще группируем на плате...

отдельный вопрос какой пиздец был бы в УЗМЧ где ехала ОС через ОС. Однако если приучить петушков писать модульно то и тайна эта пропадет.

Делись контактами может нафантазируем чтото вместе

та-же-веб-макака

>>189462
>Сейчас приходится выкручиваться подписями, как на пикрилейтед #2.
Лучше все дополнительные требования к схеме писать в отдельном текстовом блоке, а в том месте схемы, к которому это требование предъявляется ставить ссылку на номер этого требования, например, "*1".
Тогда и схему эти требования по отдельности не засоряют.

1. Расположить конденсатор С228 вблизи вывода J15 микросхемы DDx.
2. ...
3. ...

>>189492
>все дополнительные требования к схеме писать в отдельном текстовом блоке
Поздравляю, ты только что ГОСТ.

>>189494
Я про него и говорил.

>>189489
Твои замечания вполне уместны. Попробую оправдаться.

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

>>189489
>Вообще непонятно, чеж до сих пор не разработали.
Для HDL языков же придумали. Тут правда точно такой же механизм не прокатит, т. к. у нас не будет функциональных моделей микросхем. Поэтому придется обойтись чем-то вроде подачи питания на схему и выводом напряжений/токов на/через ножках/ножки микросхемы. Также понадобится обратное действие - подача сигналов с микросхемы на ее окружение. Детализация такого тестирования - вещь определяемая для каждого отдельного случая. Впрочем, над тестирование я еще особо не думал, поэтому могу ошибаться.

>>189492
>>189495
>>189494
Это конечно лучше, чем комменты в рандомном месте но описанной выше проблемы не решает. Алсо, как будешь контролировать десигнейторы? Что если в спешке С228 228, лол заменишь на что-то другое и присвоишь ему другой десигнейтор, а список требований поменять забудешь?

>>189491
Пиши на [email protected] если что

>>189497
Давай подытожим все, что ты предлагаешь. То, что ты предлагаешь:
- хуй формализуешь;
- будет содержать миллион поводных камней;
- не разработано;
- потребует больших вычислительных мощностей (юнит тесты для моделирования схем, ага)

Исходя из этого, экономически гораздо выгоднее посадить пару макак на рисование схем и трассировку.

юнит тесты нинужны
оп и предлагает попытаться формализовать
оп и предлагает разработать
подводные камни везде есть

>>189503
>оп и предлагает попытаться формализовать
>оп и предлагает разработать
У нас в универе каждый год был минимум один диплом на тему YOBA када для автоматизации разработки принципиальных схем. Все они работали только если схема состояла из трех резисторов и одной микросхемы с тремя ногами.

>>189504
Погромисты. Погромисты невер ченджс.

>>189501
>- хуй формализуешь;
Что именно по твоему мнению сложноформализуемо? Части предлагаемого када например построитель схем по описанию или же какие-либо задачи, с которыми столкнется конечный юзер при проектировании схем?

>>189501
>- будет содержать миллион поводных камней;
Подводные камни встречаются где угодно.

>>189501
>не разработано
Да ето так. Но все когда-то случается в первый раз.

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

>>189501
>Исходя из этого, экономически гораздо выгоднее посадить пару макак на рисование схем и трассировку.
>Паровые машины нинужны! Рабочие сделают эту работу дешевле!

>>189506
>Что именно по твоему мнению сложноформализуемо?
Все многообразие электронных компонентов от всех производителей.

Кстати. Вот что еще было бы не плохо. Частичный расчет компонентов схемы. Нет нет, я не предлагаю вам считать всю схему по нажатию кнопки ZDELOT' ZAEBIS'. Я предлагаю автоматически подбирать резисторы в делитель напряжения по заданному коэффициенту деления, подбирать гасящее сопротивление для светодиодов, по характеристикам диодов и напряжению питания и прочие чуть более сложные вещи. Просто иногда очень заебно пересчитывать компоненты и вносить изменения в схему, когда меняются требования к дизайну.

>>189508
Я и не предлагаю тебе иметь модели всего на свете. Микросхемы ведь будут всего-лишь черными ящиками без функциональной составляющей.

>>189512
>Микросхемы ведь будут всего-лишь черными ящиками без функциональной составляющей.
А их выводы будут всего-лишь черными палками без функциональной составляющей? И можно будет соединять что-угодно с чем-угодно?

>>189512
Проиграно
>>189514
Он тебе сейчас расскажешь про параметризацию, черный ноги в одном углу для данных, черные ноги внизу для питания и прочее.

>>189514
Вполне допустимо указывать такие свойства пина, как направленность, цифровость/аналоговость, допустимые напряжения и пр. Это в общем-то уже присутствует в том же альтиуме. По функциональной составляющей имелось в виду поведение микросхемы. Этого нам не надо.

>>189515
>Он тебе сейчас расскажешь про параметризацию, черный ноги в одном углу для данных, черные ноги внизу для питания и прочее.
Чего? Мне кажется, ты не совсем понимаешь, что я имею в виду под параметризацией.

>>189517
Ну так расскажи скорей, что ты там у 16выводных диповских корпусов параметризовывать собрался.

>>189518
Я бы лучше послушал про параметризацию микрух с 500+ выводов. И про простоту и изящество кода, описывающего каждое из 500 соединений этой микросхемы с другими компонентами.

>>189498
Да, в этом плане они не допилили. Хотя у каждого компонента есть свой Unique ID и в тексте можно отображать значения некоторых переменных через =Param, но возможность отображения значения параметра компонента по Unique ID, например, =ComponentParam(UID, Designator) в текстовой строке/блоке не допилили.
Так что пока только вручную.

>>189521
Хотя в альтиуме у каждого параметра есть свой UID, так что можно было бы просто сделать =ComponentParameterValue(ComponentParameterUID).

>>189518
>что ты там у 16выводных диповских корпусов параметризовывать собрался
Ничего не собрался. Это ты без меня придумал. Параметризация нужна, когда мы имеем повторяющуюся структуру и заменяем эту структуру на некий шаблон, по которому она может быть построена.

Если хочешь пример с микросхемами - пожалуйста. Вот есть у нас мультиплексор с 4 входами. А нам нужно N входов. Вот мы и пишем модуль, в качестве параметра которому передаем нужное число входов N, а модуль выбирает минимальное число исходных микросхем - M и правильно их соединят, чтобы соответствовать N-входовости. Задача разработчика сводится к разработке алгоритма расчета M по N и соединения M-ной микросхемы с M-1-й, вместо тупого нахуячивания вороха из дохуя микросхем и поочередного их соединения.

>>189520
>Я бы лучше послушал про параметризацию микрух с 500+ выводов
Вот тут как раз все просто. Зачастую такие микросхемы имеют различные шины, которые можно обрабатывать подобно массивам. Я приводил пример возможного описания таких микросхем в ОП-посте. Более того, зачастую такие шины просто напрямую подключаются к другим микросхемам, т. е. соединение 50 проводов вручную можно заменить на что-то вроде: CPU.DataBus = DDR3.DataBus; Концепция интерфейсов их можно сравнить со структурами в языках программирования позволила бы обращаться таким образом не только с шинами, но и с произвольными наборами проводников, связанными логически.

>>189526
>Зачастую такие микросхемы имеют различные шины, которые можно обрабатывать подобно массивам.
А зачастую - не имеют. Или подключаются не напрямую шина-в-шину, а, например, через буфер. Или еще какие нюансы. В общем случае придется прописывать 500+ выводов.

>>189527
>А зачастую - не имеют
Тогда да, ничего не поделать и придется обрабатывать каждый провод отдельно. Но что-то я не припомню микросхем с 500 ногами, у которых нельзя было бы заметить какого либо шаблона соединения со внешним миром. По крайней мере 50 ног питания и земли точно можно будет подключить "автоматически": YobaIC.VCC[0:50] = Power.DigitalVcc;

>>189526
>через буфер
Тоже мне проблема. Делаем interconnect модуль с размноженным внутри буфером и соединяем шины через него.

>>189529
>Но что-то я не припомню микросхем с 500 ногами, у которых нельзя было бы заметить какого либо шаблона соединения со внешним миром.
Ну, например, любая ПЛИС.

>>189530
Так и знал, что ты скажешь про плис. И что же ты собрался такое делать с ПЛИС, что задействуешь каждый из 500 выводов для уникальной задачи?

>>189531
А это уже мое дело, как я их задействую.

>>189532
Я просто попросил пример, чтобы убедится в том, что описываемая тобою задача действительно может встретится на практике.

>>189533
>Я просто попросил пример, чтобы убедится в том, что описываемая тобою задача действительно может встретится на практике.
Так понимаю, проблема компоновки мультиплексоров стоит в индустрии особенно остро?

>>189534
Просто один из примеров. Можем с тобой придумать кучу других, если этот тебя не устраивает. Ты конечно будешь прав, сказав, что для мультивибратора на МП39 такой софт нахуй не нужен, и там можно обойтись спланом и лейаутом. Но в таких задачах, как, например, соединение DDR3 с контроллером, подобный функционал был бы очень кстати.

>>189533
>описываемая тобою задача действительно может встретится на практике
То есть ты собираешься пилить КАД, который будет заточен только под определенные задачи, которые, по-твоему мнению, встречаются на практике?
Я тебе сказал, что в общем случае тебе придется описать 500+ соединений. И это только для одной микросхемы.

>>189538
> в общем случае тебе придется описать 500+ соединений
Да, ето так. Мой способ проектирования для общего случая был бы ничуть не лучше классического. Но исходя из малой вероятности встречи с такой задачей, можно говорить о потенциальной успешности моего способа проектирования.

>>189539
Т.е. сидят такие в nvidia ребята, генерируют, параметризируют, не могут нарадоваться. Как вдруг появляется нестандартная задача, весь отдел вопит, что им нужно сменить способ проектирования OP-HUY на ALTIUMGOVNO, сменить всю документацию, купить лицензию на софт, и прочее?

>>189539
>можно говорить о потенциальной успешности моего способа проектирования
Ну и когда можно ожидать первую альфа версию?

>>189540
>Как вдруг появляется нестандартная задача, весь отдел вопит, что им нужно сменить способ проектирования
Я же не говорил, что мой способ будет хуже. Просто не будет заметного выигрыша. Зачем же тогда менять софт?

>>189541
>Ну и когда можно ожидать первую альфа версию?
Рано еще про такое справшивать. Давай лучше обсудим потенциальные недостатки описанного подхода.

>>189542
Т.е. в ствоём способе проектирования, когда кому-то что-то не нравится, это норм, чтобы покостылять без особого выигрыша.
Но стоит проприетарному говну опростоволоситься с параметризацией цапа r-2r, как стоит менять концепцию проектирования?

>>189543
Предложенная тобой общая задача является абстрактной, ибо ты не предложил конкретного примера, который теоретически может встретиться на практике. Я же привел тебе задачи с R-2R ЦАПом и Мультиплексором, которые хоть и не встречаются каждый день, но вполне могут появиться среди рутины любого инженера. Более того, я привел тебе достаточно общий пример с шинами, которые встречаются в каждом более менее сложном цифровом проекте, ибо любая видеокарта или материнская плата содержит большое число повторяющихся объектов, включение которых в схему может быть автоматизированно. Собственно после всего этого, я не понимаю в чем заключается твое недовольство?

>>189437
>Я пока только о схемотехнике говорил.
А цап у нас тупо набор резисторов, да? Если да, копипаст, и всего делов.
Если же ты сколь-либо его себе представляешь, то расскажи, как параметризировать время установки выходного буфера, или, если это нормальный цап, I/V- преобразователя.
>Выбор допуска резисторов по заданным максимальным DNL/INL тебя чем не устраивает?
Окей, САПРнейм резисторы в 1ппм? А ничего, что для даже 12 бит уже потребуется йоба-напыления со всячкого хрома или лазерная подгонка? А ничего, что конечный КОСС буферного усилителя может захерить линейность хуже, чем неточные резисторы? А сопротивление коммутирующих резисторы ключей? А смещение нуля, а кодозависимые выбросы, а шумовые параметры? А нагрузочная способность, температурный дрейф?
Ебать, параметризирует он тут. Аналоговая электроника так не работает.

>>189241
Сдаётся мне, что ты пиздишь!

>>189549
>А цап у нас тупо набор резисторов, да? Если да, копипаст, и всего делов.
Да ты бы и пса закопипастил. От ручного копипаста я и предлагаю избавляться. Такой подход плох тем, что при малейшем изменении в повторяющейся структуре, ее приходится удалять, рисовать элемент структуры заново и снова размножать. Не жалко ли тебе своего времени на подобную индусскую работу?

>А ничего, что для даже 12 бит уже потребуется йоба-напыления со всячкого хрома или лазерная подгонка?
Ты совсем пизданулся? Какое отношение это имеет к КАДам?

>>189549
>А сопротивление коммутирующих резисторы ключей? А смещение нуля, а кодозависимые выбросы, а шумовые параметры? А нагрузочная способность, температурный дрейф?
Минуточку, ты предлагаешь мне как-то влиять на параметры ЦАПа, которые зависят от модели выходного буфера и устройства с которого поступает цифровой сигнал?

>>189499
написал

>>189580
Замечательно.

>>189587
>>189580
ну и ебите теперь друг друга в жопы. уебни пиздоголовые.

>>189574
> Не жалко ли тебе своего времени на подобную индусскую работу?
Ты, похоже, серьезно не понимаешь схемотехники и особенностей микроэлектроники, если считаешь что трудозатраты на копипаст тупого набора резисторов значительны в сравнении, скажем, с выбором самого номинала R.
>Ты совсем пизданулся? Какое отношение это имеет к КАДам?
Какое отношение КАДы имеют к разработке схемотехники, что первично?
>Минуточку, ты предлагаешь мне как-то влиять на параметры ЦАПа, которые зависят от модели выходного буфера и устройства с которого поступает цифровой сигнал?
Разумеется, блядь, потому что все влияет на все. Тем более, что по цапом, будь то кусок периферии микроконтроллера, или отдельная микросхема, понимается даже в самом минималистичном варианте связка из ключей и резистивной матрицы.

Резистор в R-2R-матрице выбирается из множества факторов. Мощность, выделяемая матрицей в мидскейле равна квадрату опорного напряжения, делить на 4R, то есть, меньше сопротивление - экономичнее цап, меньше саморазогрев - меньше плывет сопротивление (а оно не идеально пропорционально меняется), меньше дрейфуют параметры источника опорного напряжения и всего остального.
Кмоп-вентиль "выходной мощности", отдающий 24 миллиампера на порт микроконтроллера или плис, имеет выходное сопротивление порядка 5 ом, но оно гуляет в два-три раза у обычных вентилей, да еще и р-канал имеет сопротивление выше канала. Надо, во-первых, брать специальные, во-вторых, брать резисторы в матрице побольше, дабы ошибка ключей не сказывалась.
Взяв слишком большое сопротивление, паразитные емкости на нагрузке и распределенные по чипу будут затягивать время установления.
Большое сопротивление повышает чувствительность к пролезанию сигналов с цифры на выход (особенно хорошо наводится клок в цапах c spi). Большое сопротивление вносит больше теплового шума, повышает вклад шума от токовой составляющей последующего усилителя, а так же смещает ему нуль входным током.
Малое сопротивление потребует более жирного блокировочного конденсатора на референс, чтобы при резком переключении и смене потребляемого тока, на время реакции буфера референса напряжение на матрице не просело больше чем на lsb, а лучше его малые доли.

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

>Профессиональное радиоблядство
>Микроэлектроника
>коденг коденг коденг
>ОЙ МНЕ ЛЕХЧИ НА МК НАПИСАТЬ
>Паять для быдла
>Миллиамперы
>Мощность
>Еще немного кода
Чому сейчас так много цифропетухов развелось? Настоящие инженеры от силовой, импульсной еще остались?

>>189697
>Настоящие инженеры от силовой, импульсной еще остались?
Остались. Но они в петушиных боях не участвуют.

>>189698

боятся что их заклюют ардуиной?

>>189697
имплаинг инженер от силовой не мечтает крутить ФАПЧи и дедтаймы на МК

>>189438
>>189440
Ну пиздец... Вы же Mentor не открывали, да? Табличное задание соединений между компонентами не видели, да?

>>189442
Очевидно же, что очень плотную схему они видели лишь в своих влажных мечтах, и о такой процедуре, как проверка, они не подозревают, и о том, что схемы нужны для наглядности. Кстати, как и описание программного кода (которое, о божечки, тоже делается вручную).

Кстати, текстовое описание схемы кто будет делать? один хуй вручную же.

И да, для работы с шиной вполне себе инструменты имеются.

Ну что, сучечки, вот я и вернулся.

>>189659
Внимательно прочитал твой пост. Ты заблуждаешься, считая, что я предлагаю панацею, которая будет делать всю работу за разработчика. Мы с тобой оба понимаем, что это невозможно. Все что я предлагаю - это упрощение рутинных операций, таких как рисование повторяющихся структур на схеме, и расчет номиналов элементов там, где это возможно сделать. Ловля блох по прежнему остается на разработчике. Особенно это будет полезно, для цифровой электроники, где такое встречается на каждом шагу и громоздкость схем порой зашкаливает. Но и в аналоговой электронике применение такого подхода не исключено, где тоже порой можно заметить некоторые шаблоны.

>Ты, похоже, серьезно не понимаешь схемотехники и особенностей микроэлектроники, если считаешь что трудозатраты на копипаст тупого набора резисторов значительны в сравнении, скажем, с выбором самого номинала R
Судя по твоим словам, дай тебе волю, ты бы и на листочке схемы нормально ебашил. А че? Трудозатраты на выбор компонентов выше! Наймем индусов, пускай на листочке чертят! Выдумали тут, понимаешь, кады за дохуя далларов! Деды чертили и мы будем! Алсо, вполне вероятно, твое мнение основано на том, что ты редко сталкиваешься с громоздкими схемами, в которых реально много времени уходит на рисование повторяющихся вещей.

>Надо, во-первых, брать специальные, во-вторых, брать резисторы в матрице побольше, дабы ошибка ключей не сказывалась.
Вот ты сам пример и привел с сопротивлением ключей. Сменились ключи? Придется судорожно менять сопротивления в матрице резисторов. А мог бы просто одну строчку на входе модуля матрицы заменить...

>>189697
>>189698
>>189699
>>189700
По недостаткам предлагаемой концепции есть что пояснить или вы только способны кукарекать про ардуинщиков?

>>189728
>табличное задание соединений между компонентами не видели, да?
Не видели. Расскажи нам. А лучше покажи.

>>189729
>И да, для работы с шиной вполне себе инструменты имеются.
Расскажи же нам про шины скорее. По мне дак вообще разницы нет, к шине 50 проводов по очереди тянуть или напрямую целевой микросхеме. Про шины в Алтиуме я вообще молчу. Там шина - это самый бесполезный объект, который можно придумать.

>>189738
>Не видели. Расскажи нам. А лучше покажи.
https://www.mentor.com/pcb/xpedition/engineer/
Даже на скрине есть.

>Расскажи же нам про шины скорее
Ок, даже в ущербном альтиуме:
С помощью Paste Array легко одним кликом на выводы микросхемы. При этом, если шина находится в нескольких разных рядах, на схеме их легко просто расположить один под другим. Дальше с помощью порта и шины хоть всю шину, хоть отдельный её диапазон тащишь на любой другой лист схемы. Не по-одному.
все переходы во время верификации легко отслеживаются с помощью навигатора, внутри листа - маркером. И всё это наглядно, что, кстати говоря, очень важно, когда работаешь с энергиями, которые могут убить.
Сколько мне за мою жизнь попадалось первёрнутых МОП-транзисторов, которые ещё на этапе проверки схемы удавалось перевернуть только по той причине, что их ВИДНО. А с текстовыми описаниями это в принципе невозможно. И да, чтобы из текстового описания "сгенерить" схему - нужно точно так же делать все символы, привязывать к описанию. В общем, всё бы вам попердолиться...
Так что, если тебе кажется, что схемы, и ECAD'ы делают люди сильно-сильно глупые, то может быть это заблуждение вследствие твоего долбоебизма, а не все вокруг - дебилы?

Хули вы тут устроили?

>>189197 (OP)
Да ты охуел, в альтиуме научись уже пользоваться PCB \ SCHList.
в них инфа вставляется как и в табличный процессор, и копируется также.
автозаменами/регэкспами форматирование подбил, и прямо с даташита вставил.

>>190543
Охуеть. Вместо того что-бы договорится о стандарте текстового документа, описывающего список пинов и скачивать этот список с сайта производителя, эти говноеды предлагают дрочить мне пасту с шита регекспами. Радиоиндусы never change.

>>190764
Ну хуй знает чувак, я привык.
На прошлой работе когда проектировщиком в области энергетики работал, так там перечни приоритетов сигналов телеуправления/сигнализации на подстанции были и по 5000+ строк. Тогда регэкспы и освоил, похуярив эти перечни несколько дней.
Вообще отчасти ты прав, в области инженерии довольно мало автоматизировано. И приходится либо макросы изобретать либо хуярить что-то не по прямой специфике деятельности, да ещё и с левым софтом в анусе пронесённом на рабочий комп.

>>190764
>что-бы
Зна-чение зна-ешь?

>>190807
Про-иг-рал.

>>190764
>Вместо того что-бы договорится о стандарте текстового документа, описывающего список пинов и скачивать этот список с сайта производителя
Да ты совсем охуел. Нахуй ты тогда нужен, инженер драный.

>>190812
Это ведь был сарказм, правда?

>>190910

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

>>190914
А. Дак значит они только из-за говнософта и ошибок в шитах не штампуют? А я-то думал...

>>190764
Ну ты уже хоть один раз САПР открой. Или ты открывал, но просто постичь даже столь простых вещей не способен?

Всё уже совсем близко к тому, что скоро согласуют единый формат.
http://www.youtube.com/watch?v=0n6k6GYu_V0
http://www.altium.com/files/pdfs/smartgridtools.pdf

Очень похожим образом делается и в САПР от Cadence, например.

>>190944
>
http://www.microsemi.com/document-portal/doc_view/132761-creating-schematic-symbols-using-cadence-orcad-capture-cis-for-smartfusion2-and-igloo2-designs
https://www.cadence.com/rl/Resources/datasheets/allegro_pcb_lib_xl_ds.pdf

>>190944
>Short Method to create Schematic in Altium Designer
>13 минут, чтобы создать схемный компонент со сраными 24-мя ногами
>Short Method
Схемоиндус, плиз.

Я бы посмотрел как ты делаешь такую хуйню для проца с 500 пинами половина из которых имеет вид DATA_BUSx.

Алсо сколько индусочасов убивается каждый на создание одних и тех же компонентов для одних и тех же кадов но разными компаниями? А могли бы просто нажать Download all our components in *.PizdatiyOtkritiyTekstoviyFormat на сайте производителя. Говноеды в общем вы.

>>190947
>>Short Method
>для проца с 500 пинами
Взаимоисключающие пункты.

>Говноеды в общем вы.
Ну дак хули ты не сделаешь свой охуенный кад, или охуенный текстовый формат, который будут понимать многие промышленные кад? Чего мешает то? Либы для альтиума, например у ST есть.

>>190947
В общем ты хочешь аналог *.SCR файлов игла, но применяемый ко всем кадам?
В видео калич крайне медленно ворочает, за 13 минут можно и 500-ногий проц заебашить.
Да и возмущения столько, будто ты каждый день приходя на работу начинаешь хуярить новый проц. Сколько раз в твоих проектах обновляется номенклатура за год? Да её все подряд стараются уменьшить по многим очевидным причинам.

>>190947
>хуйню для проца с 500 пинами
Я тут важный момент упустил. Тебе дороги надо выровнять и разложить. Конфигурацию процессора правильно прикинуть. Проверить signal integrity.

>>190956
Какие дороги? Когда делается библиотечный элемент раскладываются только пады, да рисунок на сборке/шелкографии, плюс 3D для души. Может быть группы цепей в схематике поудобней расставить, это да.

>>190955
>все подряд стараются уменьшить по многим очевидным причинам.
>>190957
>Когда делается библиотечный элемент раскладываются только пады, да рисунок на сборке/шелкографии, плюс 3D для души.
Он тебе уже ответил. Ты разводишь батхёрт за такую малую долю задач, которая в производстве не играет роли. Твоя работа по созданию библы мала, по сравнению с общей задачей, потому на неё всем похуй.

>>190959
>Ты разводишь батхёрт за такую малую долю задач, которая в производстве не играет роли.
Во-первых не он, а я тут батхерт развожу, а во вторых зачем тебе вообще кады тогда? Ебашь все на листочке. Это ведь в производстве роли не играет.

>>190960
>Ебашь все на листочке. Это ведь в производстве роли не играет.
Дурачок ты. Производство уже кругом ЧПУ. Давай, перекладывай листочки. Есть у нас такие уебаны.

>>190954
Ну например при грамотной организации описания этого процессора можно свести 500 оъектов (пинов) к 50 объектам, учитывая повторяющиеся провода в шинах и повторяющиеся группы проводов в интерфейсах.

>>190962>>190962
>Давай, перекладывай листочки.
Вообще-то я написал это не потому, что предпочитаю такой подход, а чтобы проиллюстрировать глупость ваших кукареков типа "а нам и вручную пины ебашить норм. мы привикли так. ди нахуй". Вижу, что ты аналогию с рисованием на листочке прочуял, раз так воспламенился.

>>190963
>при грамотной организации описания этого процессора можно свести 500 оъектов (пинов) к 50 объектам
Похуй. Это менее 10% от рабочего времени. Тратить на это деньги. Нахуя? Думаешь в альтиуме идиоты работают?
>>190964
>раз так воспламенился
Мне глубоко похуй. Я инженеру пишу пины, которые мне нужно для периферии, и говорю где их хочу видеть. Остальное он разводит сам. Но мы с ним хорошо знакомы, и я понимаю, что разводка схематика у него занимает неебически мало времени, по сравнению с общей задачей. Нахуя на это тратить деньги?

>>190965
>что разводка схематика у него занимает неебически мало времени, по сравнению с общей задачей.
Вы там мультивибраторы на МП39 что-ли рисуете? Посмотрел бы я, сколько твой индусоинженер потратит на разводку какой-нибудь плисины или проца с парой интерфейсов ДДР3.

>>190965
>Думаешь в альтиуме идиоты работают?
Нет. Просто они ориентированы на индусов, которые могут ебашить все, что скажет начальник.

>>190947
> А могли бы просто нажать Download all our components in *.PizdatiyOtkritiyTekstoviyFormat на сайте производителя.
Зачем пиздатый-открытый, когда процам-плисинам(как раз твои случаи с йоба-500 пинами) в подавляющем большинстве случаев, если не дается сразу на сайте, то по запросу предоставляются компоненты под любой нормальный кад?

>>190969
Врети. На новые компоненты хуй чего найдешь.

Ой, бля... уёбок, которых хочет стандартизировать IO на ПЛИС, да ещё и с учётом временных задержек, кому-то что-то говорит про мультивибратор.

Очевидно же, что этот уёбок даже до мультивибратора не добирался, влажные фантазии про ПЛИС у него.

>>191011
Он только ддр3 схемачит, не видно? r-2r цап да ddr3, ничего более.

>>191011
> хочет стандартизировать IO на ПЛИС
Чего? Кто тебе такое сказал? Что ты имеешь ввиду под словом "стандартизировать"?

>>191017
>Он только ддр3 схемачит, не видно? r-2r цап да ddr3, ничего более.
Какие-либо маня-оправдания низкого уровня автоматизации в сфере EDA у тебя еще будут или с тобой диалог можно прекращать?

>>191018
Я с тобой диалог закончил уже давно, когда вы нашли друг друга по мейлу начали ябать друг друга в жёппы. Удивлен, что кто-то поднимает этот тред до сих пор.

>>189738
>на листочке схемы
Вот не поверишь же, но все ответственные узлы я сперва набрасываю на бумаге, делаю 9000 комментариев вида "этого стабилизатора садить на радиатор, эту цепь делать предельно короткой, сюда влепить дорожки эквипотенциальной защиты, эти два транзистора разместить в тепловом контакте..."
Причем все эти извращения сопровождаются, ВНЕЗАПНО, тоже расчетами на бумаге. В цифру перевожу только показавшие себя состоятельными наброски.
Поиск, чтение даташитов, анализ цен и доступности элементов на рынке, оценка их адекватности задаче, детальные рассчеты и симуляция отдельных узлов - да даже забивание элементов в Ментор занимает малую долю времени.

>>191019
Ну ладно тебе. Чего ты злой-то такой? Ну хочешь я тебе про плис охуительных историй расскажу? Как могло бы все быть, если бы EDAшники не делали упор окошечки и визардики? Хочешь?

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

1. Находим у производителя файлик с задержками пинов для нашего камня.
2. Выбираем нужные нам пины и вставляем задержки для этих пинов в эксель.
3. Рассчитываем длины дорог с учетом задержек и расположения элементов на плате.
4. Полученные длины копипастим по очереди для каждой сети (охуенно это делать, когда у тебя 64-битная шина данных и тебе надо указывать желаемую длину для каждой дорожке в шине)
5. Рисуем собсно дороги согласно созданным правилам.

Теперь смотри. Удлиненные дороги не влезают на плату? Делаешь все заново начиная с п. 3. Надо перенести шину данных на другие пины плисины? Переделываешь все начиная с п. 2. Выясняется, что не хватает ресурсов камня? Меняешь чип и делаешь все заново, начиная с п. 1. Нравится? Мне нет.

А сейчас представим, что у нас есть годный EDA продукт, где схемы и модели компонентов можно описывать на специальном языке. Это значит, что в модели мы можем задать для каждой ножки свойство - "задержка" и заполнить его данными от производителя. Или даже скачать готовый компонент с заполненными полями с сайта производителя. А дальше мы пишем прогу или берем готовый модуль, который по задержке пина рассчитывает длину каждой дороги между плисиной и целевой микросхемей. Остается только развести эти дороги в соответствии с автоматически созданными правилами. Смена пинов или чипа приведет только к необходимости перекомпиляции проекта и переразводке дорог.

>>191027
1. Нужны пины добавляем в отдельную группу.
2. Рассчитываем длину дороги.
3. Рисуем.
4. Equalize Net Lengths в группе.
5. ???
6. Профит.

>>191028
>Нужны пины добавляем в отдельную группу.
>Рассчитываем длину дороги.
Ололо, ты забыл, что у каждого пина своя задержка, поэтому каждому пину нужна своя длина дороги.

>>191027
>А сейчас представим, что у нас есть годный EDA продукт, где есть кнопка ZdelotPIZDATOUUU.

>>191034
>ZdelotPIZDATOUUU
Не кнопка ZdelotPIZDATOUUU должна быть, а программный интерфейс должен присутствовать, используя который, можно написать СВОЙ код и ZDELAT' PIZDATO

>>191035
Autoplace/autoroute до сих пор не может MAKE PEEZDATO. Ждём твоего божественного кода хуй знает для чего.

>>191036
>Autoplace/autoroute до сих пор не может MAKE PEEZDATO
Я тебе про автороутер и не говорил ничего. Речь шла про авторасчет правил длинных линий при разработке схем.

>>191037
>авторасчет правил длинных линий при разработке схем.
Какие исходные данные для расчета?

>>191038
Задержка каждой ножки чипа, параметры текстолита, желаемый импеданс, желаемая задержка.

>>191039
Ну отлично. Сначала ты автоматизируешь повторяющиеся цапы в схематике с параметризацией. Теперь ты в том же схематике уже руководствуешься параметрами платы и считаешь необходимую длину дорожек. Охуительно.
Еще ты сначала ставишь плис, потом рисуешь от неё дороги, а потом уже к этим дорогам присоединяешь другую хуиту, которую нужно было соединить с плис?

>>191041
>в том же схематике уже руководствуешься параметрами платы
Параметры длинной линии такие как импеданс и задержка, на мой взгляд, относятся к схеме, т. к. от их правильного выбора зависит работоспособность дизайна. А вот конкретное расположение и форма этой линии, а также толщина дорожек в ней - это все параметры определяемы на этапе проектирования платы.

>>191027
Ты дурак?
В ПЛИС заранее не известно, на каком пине какая функция будет вообще. То есть. ВООБЩЕ.

Более того, неизвестно, что на данной ПЛИС сделает разработчик. Тоже от слова ВООБЩЕ.

о каких данных от производителя ты бредишь?

>>191030
>Ололо, ты забыл, что у каждого пина своя задержка, поэтому каждому пину нужна своя длина дороги.

Но ведь вот как раз эти моменты и есть описанные в текстовых файлах. То есть, то о чём ты заявляешь "ЭТОГО НЕТ", на самом деле есть.

>>191047
P.S. только это есть не для ПЛИС, а для процессоров, микросхем памяти, PCI-E свитчей и т.д.

>>191046
>Ты дурак?
Нет ты.

>>191046
>В ПЛИС заранее не известно, на каком пине какая функция будет вообще
Производителю ПЛИС нет, разработчику дизайна на ПЛИС известно. Ему-то и нужно знать задержки на ногах, к которым он собирается подключать высокоскоростные линии. Эти задержки определяются строением корпуса микросхемы.

>>191046
>о каких данных от производителя ты бредишь?
Об этих: http://rghost.ru/82BFhGrDf. Генерится в Vivado для каждой модели камня.

Кажется кое-кто спалился, что умеет лишь светодиодами на плис мигать :3

>>191048
>>191047
>на самом деле есть
Есть, кто спорит то. Но вот рассчитывать длины дорог приходится в экселе. А потом еще вручную создавать кучу сетей и задавать для каждой ограничения на длину с помощью копипаста КАЖДОГО значения для каждой сети. Тут не исключена и человеческая ошибка. А ведь это все можно сделать частью дизайна, если не рисовать схемы, а описывать соединения на спец. языке. Рассчитал длины дорог и прошелся циклом по массиву соединений плисины и памяти (или к чему мы там ее подключаем), задавая им рассчитанные длины. Поменялся чип? Перекомпиляция и вуаля, у нас все заново рассчиталось по ЕДИНОЖДЫ написанному НАМИ алгоритму.

>>191050
Ну если тебе нравится в экселе, почему бы и нет. Но можно и в модель элемента в библиотеке внести. MG и Cadence этого не запрещают. Проблема в чём?

>>191049
>разработчику дизайна на ПЛИС известно.
Так и вноси с модель элемента, понятно, что говно, типа Альтиума, а тем более Иглы и диптрейсы это не сожрут, но не они одни на рынке САПР.

>Поменялся чип? Перекомпиляция и вуаля, у нас все заново рассчиталось по ЕДИНОЖДЫ написанному НАМИ алгоритму.
Ну так новую модель подцепляешь, и вуаля.

Тут одно из двух. Либо у тебя нет доступа к САПРам, которые это могут (пусть и не по одному шаблону, но если ты купишь САПР, который стоит несколько миллионов за одно рабочее место, тебе совместимость с другими будет не нужна - ты уже будешь пользоваться им одним), и ты негодуешь, что этих прелестей нет даже в зачаточном виде в бесплатных САПРах, либо ты просто не используешь этот функционал, потому что...

>>191060
Возможно я действительно плохо знаком с фукционалом САПР. Давай я более четко поставлю задачу, а ты мне ответишь, возможно ли такое в знакомых тебе пакетах.

Итак, есть чип с задержками на пинах. Пусть эти задержки (разные для каждого из пинов) находятся в модели нашего чипа, тем более, что по твоим словам такое уже практикуется в нынешних сапрах. Далее, нам нужно подключить 50 пинов этого чипа к целевой микросхеме таким образом, чтобы величина задержка_пина+задержка_линии_до_целевой_микросхемы была одинаковой для всех 50-ти связей и минимально возможной. Чтобы этого добиться, нам нужно рассчитать длину каждой из линии по тривиальной формуле и задать ее в качестве правила для данной линии. Таким образом, на этапе разводки дорог, можно будет проверять, соответствует ли данная линия заданным характеристикам. Также необходима возможность автоматического пересчета правил при смене пинов чипа или его модели (при условии, что новая модель также содержит данные о задержках пинов).

Возможно ли это в современных САПРах? Возможно ли описание произвольного закона расчета длин, в случае появления новых исходных данных?

>>191064
в MG Expedition описываешь шину (формат - скобки, разделитель задаётся в настройках), например DATA[0:49].
Лупишь эту шину на схему, правый клик - RIP Nets
подтаскиваешь к схемному символу.

второй вариант создания соединений - через таблицу соединений в том же xDxDesigner.

Дальше можешь задать для всей шины сразу ограничения на время пролёта и ограничения на разницу времян отдельных цепей. Если это не просто линии, а диффпары, то согласование времени пролёта можно отдельно задать между парами и внутри одной пары.

Время пролёта внутри микрухи CES (система задания ограничений), xPCB (трассировка) HyperLynx (моделирование, в т.ч. Signal Integrity) подтягивают из модели.

Естественно, для рассчёта времени пролёта необходимо указывать параметры диэлектрика, стек слоёв и т.п.

Можно задавать ограничения по длинам, а не по времени пролёта.

Но вот Альтиум, например, такого не умеет, Eagle - тем более.

>>191076
P.S. Забыл сказать важную штуку. Если время пролёта между отдельными линиями или диффпарами можно согласовывать достаточно точно, используя ограничения по длине, то время пролёта от одной микросхемы - до другой - тут уже вообще ничего невозможно.

Ибо разброс параметров (в т.ч. и диэлектрической проницаемости диэлектрика) при производстве никто не отменял.

>>191076
>Дальше можешь задать для всей шины сразу ограничения на время пролёта и ограничения на разницу времян отдельных цепей.
Дак я так и не понял. Время для каждой цепи надо самому посчитать и задать, или же оно считается само исходя из времени пролета внутри микрухи?

>>191079
>то время пролёта от одной микросхемы - до другой - тут уже вообще ничего невозможно.
Почему же невозможно? Берешь данные производителя и учитываешь. Да, возможен некоторый разброс между разными партиями, но лучше учесть среднее время пролета для данной модели, чем вообще не учесть.

>>191081
Да.

Поясню. Считаешь, что тебе надо (требуемое время пролёта, погрешность) ты сам. Задать можешь как хочешь - для шины в целом, для отдельных цепей, между конкретными парами/тройками/n цепями внутри шины.

Считает, что, в итоге, получилось - сама программа. Эти данные при трассировке и/или выравнивании она тоже считает сама.
Для рассчёта ей нужны: длины в модели(ях), длина трасс, которые программа сама проложила, или проложил инженер-трассировщик, стек слоёв, для учёта переходных отверстий, изменений диэлектрических свойств материала, при разных ламинатах/препрегах.

>>191148
Ок, ок, убедил. А что с возможностью расширения функциональности при появлении новых исходных данных? Скажем, мне нужно в разрыв шины поставить блок буферов. Может кад вычислять длину дорог, учитывая разные задержки еще и в каналах буфера (при условии, что они прописаны в модели буфера)?

>>191169
Нет, разумеется. Это уже другая цепь вообще-то.

Давайте посмотрим, что у нас тут сегодня:
- О боже, на разъеме не хватает контактов! Жавайте выберем другую модель!
- Давайте, чего делать-то.

Что нужно сделать по факту, чтобы заменить разъем? А вот что:
1. Скопипастить схемный компонент старого разъема на новый, перегруппировать старые пины и добавить новые.
2. Заменить все (их 4) компоненты разъема на новые.
3. Перетаскивать метки со старых пинов на новые, для каждого из четырех разъемов.
4. Заново задать пин свопинг для каждого разъема.

Как могло быть:
Заменить module HueviRaziom {wire pins[40];} на module PizdatiRaziem{wire pins[60];}

Оправдывайтесь, схемобляди.

INB4: Кококо, схема все-равно нагляднее, кукареку, твоя замена занимает незначительную часть времени

>>191264
Ну хотя бы перенастроить как-то можно, чтобы кад стал ориентироваться при расчете длин на общую задержку цепей?

>>191271
>Заменить module HueviRaziom {wire pins[40];} на module PizdatiRaziem{wire pins[60];
На это даже отвечать смешно, наконец скрою тред.

>>191273
>На это даже отвечать смешно, наконец скрою тред.
А ты ответь.

>>191271
иди на хуй.

Ибо только пункт 1 из твоего перечисления уже полностью перекрывает текст.

потому что для пункта 2 ты текст не прислал. для пункта 3 тем более. а о четвёртом и говорить нечего.

Заменить все 4 на новые вообще не проблема, если они одинаковые меняешь по парт намберу.

Если делать будет схемный символ не полный уёбок, и уж, тем более, не ты - то он легко сделает их совместимыми. не говоря уж о том, что ошибку в 50% совершить - это надо быть сказочным долбоёбом. Да ещё и метки... метки... блядь. таскать... Эта хуита (метки) из известных мне САПРов есть только в альтиуме. В Альтиуме нет ничего, совсем ничего для работы с высокоскоростной цифрой, для работы с компонентами с большим количеством выводов. Ты бы ещё жаловался, что в пейнте тяжело послойный чертёж делать.

А если уж ты сначала делаешь свопинг, а потом узнаёшь, что тебе не хватает 50% выводов... То боюсь даже представить, какие ошибки ты наделаешь в тексте.

>>191283
>иди на хуй.
Негоже анону демонстрировать взрыв своей жопы в людном месте.

> для работы с компонентами с большим количеством выводов
А что, есть кады в которых с этим норм? Расскажи о них, будь няшей.

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

2. Заменить HueviRaziom connectors[4]; на PizdatiRaziem connectors[4]; - это я забыл указать, каюсь.
3. Зачем что-то менять, если интерфейс разъема не поменялся? Да, новые пины добавились, но старые вида pin[0], pin[1] etc остались на месте.
4. Пин свопинг мог бы выглядеть так: connector[0].pins[?] = {huita1, huita2, ....}; - т. е. мы связываем список сетей справа с группой пинов разъема. Связывание конкретных пинов разъема с сетями huitaX произойдет уже на следующем этапе. Как видишь, тут при смене разъема ничего делать не пришлось.

Где твой бог теперь?

>А если уж ты сначала делаешь свопинг, а потом узнаёшь, что тебе не хватает 50% выводов...
Щито поделать, если выяснилось, что нужны новые интерфейсы?

>>191295
>connector[0].pins[?]
connectors[0].pins[?]

>>191295

>>191316
>
Вот и поговорили.

>>189230
Вы все ебу дали? это ж Altium Designer, блядь!

>>191345
Это Eagle, кран.

>>191373
Псих что ли совсем?

>>191272
Какая-то математика там есть, и можно кратность частей одной линии выстраивать, и что-то в этом роде. Не пользовался, но в рекламе, когда показывали преимущества продукта - видел. Но там была физически одна линия, один общий кусок меди, просто распределённый с помощью формул.

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

>>191430
>Какая-то математика там есть
Это уже хорошо. Вот только полноценного ЯП не заменит.

>>191430
>не искал такую возможность
Я на самом деле тоже не уверен, нужна-ли такая возможность, но мне показалось, надобность выровнять задержки для линии с буфером может встретиться на практике.

>>191600
>Это уже хорошо. Вот только полноценного ЯП не заменит.

Язык программирования не способен решить эти проблемы. Как и верилог-коды или VHDL-коды не способны решить проблемы проектирования микросхем.

Логику работы аппаратной части они описать могут, но не более того. Кристалл на них не спроектировать.

Язык программирования точно так же может работать в жёсткой заранее созданной инженерами-разработчиками аппаратной части системы.

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

>>191644
>Язык программирования не способен решить эти проблемы.
Ну охуеть вообще. Ты способен, кад написанный с использованием ЯП способен, а ЯП не способен. Любая формализуемая задача может быть решена применением ЯП. А описанный мной пример с выравниванием задержек цепей состоящих из двух частей и вовсе является тривиальным с точки зрения математики.

>Как и верилог-коды или VHDL-коды не способны решить проблемы проектирования микросхем
Сейчас прибегут ASICогоспода и обоссут тебя.

>>191644
> программирование само по себе существует именно как абстракция от железа
Программирование - это прежде всего математика, которую за тебя будет вычислять комп. А кад - это набор написанных программистом утилит для решения конечного числа задач без возможности расширения его функциональности пользователе. Я же предлагаю вместо КАДа использовать ЯП с синтаксисом и библиотеками позволяющими по сравнению с ЯП общего назначения, а не по сравнению с кадом упростить рисоваие "схемы", но при этом, по сравнению с КАДами иметь возможность программного доступа к "схеме" и возможностью, при надобности, дописывать функциональность (например, рассчитать какие-то элементы в "схеме").

>>189197 (OP)
> языки описания аппаратуры
А лучше бинарный формат, который хранил бы информацию о входах выходах, математическую модель, потребление\рассеивание мощности, физические характеристики, datasheet, картинку, 3d модель + пару библиотек, под популярные ЯП для работы с ним.

>>191669
изобретатель архива в base64

>>191649
>Сейчас прибегут ASICогоспода и обоссут тебя.
Ну asicогоспода - вряд ли. А те, кто считает себя таковыми - обоссутся. Ибо Asic - не есть создание микросхемы. Это такое же создание микросхемы, как заливка скетча в ардуино - разработка.

>Программирование - это прежде всего математика
А математика - не абстрактная наука уже?

>по сравнению с КАДами иметь возможность программного доступа к "схеме" и возможностью, при надобности, дописывать функциональность (например, рассчитать какие-то элементы в "схеме")

Так это есть в ADS, microwave office, да даже в LTSpice, да и в других Spice'ах. Но такое потом в производство не запустишь - производству нужны конкретные PartNumber'ы, а не 343,12548 мкГн и 1,2341204 пФ.

>>191689
>Asic - не есть создание микросхемы
Ебать дебил.

>>191690
Ссу тебе в рот, уёбище

>>191690
Читай внимательнее, выше написано, что в создании микросхем verilog или VHDL не является ничем большим, чем описанием функционала. На что было возражение, мол ASIC же.

Тот ASIC, который полностью описывается verilog'ом или VHDL'ем - это уже готовая заготовка ПЛИСоподобная, в которую жестко зашивается функционал. То есть, микросхема разработана сильно заранее и не тем, кто считает себя разработчиком микросхемы. Там же, где разрабатывается силиконий, роль языков описания железа - гораздо меньше, чем пытаются тут преподнести. Потому и абсолютно одинаковые, с точки зрения верилога, кортексы так по-разному работают у разных производителей.

>>191779
>с точки зрения верилога
>кортексы так по-разному работают у разных производителей
Что за хуйню я читаю? Пожалуйста, съеби отсюда и не неси ахинею.
Кортексы разных производителей у енго по разному работают. Ты - дебил?
Одна архитектура - ARM, разная начинка и обёртка. Суть работы переферии не может сильно отличаться даже между разными архитектурами.

Сажа, скрыл.

>>189197 (OP)
Если ты не можешь в задрачивание контактов - ебись в свое программирование и не отсвечивай.
У вас там накосорезил - "а, потом исправлю, в версии 28.4 betа". Хуй с ним, обновятся кому надо.
В железе такое не проходит. Проебал 1 контактик - 10000 плат в помойку или в доработку, сравнимую по стоимости со сборкой.
Алзо взрослые пакеты (а не игл твой любительский) могут и в шины и в подбор длины. Только ты слишком туп, чтоб это освоить.

>>189462
Блять, он еще и в алиасы не знает.
Обзываешь неты именами -то самое 1.8V_VDDIO и ставишь свой компонент где хочешь, подключенным к кусочкам с алиасами.
(Правда в результате, схема превращается в ебучий нетлист и что там с чем соединено нихуя не видно - нужно искать "точки входа с одинаковыми алиасами", но сраные программисты такой стиль любят: я сделал, а на других мне похуй).
>>189525
Мда. Я вижу, ты просто боишься настоящего железа и хочешь спихнуть работу с ним на программу. При том что работа эта дичайше сложна и разнообразна, чтоб ее формализовать. Пока ты будешь писать модуль синтеза твоего мультиплексора, нормальный инженер уже найдет готовое решение (у себя в башке или справочнике производителя) и воткнет его в схему. А в источниках питания есть расчеты по теплу, ширине дорожек, а в линиях связи - по задержкам. При этом дорожки линий не надо считать на тепло, но надо на импеданс. И т.д. и т.п. Это нужно ЗНАТЬ инженеру. А твой монстр-кад откуда это будет знать? В итоге для каждого чиха будут какие-то дикие необозримые списки параметров, в которых уже сам черт тогу сломит, а на выходе будет франкенштейн, которого никой гальванизацией не оживишь.
Ручками все хорошее делается, ручками и головой.
>>189544
Задачи, встречающиеся "среди рутины любого инженера" оным инженером рутинно же решаются.
Надо поименовать 500 выводов - сядет и поименует за час, а не будет писать два дня модуль автоматического наименования.
Терпение - часть инженерного навыка. Кнопка "Make peezdato" - мечта лентяя, причем абсолютно иллюзорная.
>>190963
Да, и для этого обычно хватает тупого ctrl-C ctrl-V.

>>191779
>Тот ASIC, который полностью описывается verilog'ом или VHDL'ем - это уже готовая заготовка ПЛИСоподобная, в которую жестко зашивается функционал
Поясни, как выглядит нежестко зашитый функционал?

>>191939
Как в FPGA. Он хранится в оперативке, где он может быть изменён. В оперативку же закачивается через внешние интерфейсы, например (чаще всего) из конфигурационной FLASH-памяти, где он, собственно, тоже может быть изменён.

>>191825
Во-первых, дебил - ты. И работают они таки по-разному. С разными Errata'ми, с разным потреблением, и т.д.

У них только функционал одинаковый.
Периферия - отдельный разговор. К тому, что она разная - никаких вопросов.

>>191966
А ты про это. Хорошо. Возвращаясь к микросхемам. Если ASIC не микросхема, то что в твоем понимании микросхема и как они проектируются в настоящее время?

>>191893
>Проебал 1 контактик - 10000 плат в помойку или в доработку, сравнимую по стоимости со сборкой
Ты также можешь проебать один контактик рисуя схемку в КАДе. Причем даже с большей вероятностью. Взгляни на этот пик >>191271. Видишь множество контактов с почти одинаковыми метками, отличающимися только индексами? Дак вот, ручной копипаст может привести к ошибке, т. к. ты можешь тупо пропустить один из контактов и нихуя не заметить из-за их огромного числа. Таково свойство человеческой психики. В то же время подключение разъема с помощью грамотного языка описания намного мене громоздко:
YobaRaziem connector;
connector.pins[0:10] = huita1.yobaInterface[0:9];
connector.pins[10:19] = huita2.yobaInterface[0:10];
Как видишь, случайная опечатка сюда вряд ли закрадется.

>>191689
>производству нужны конкретные PartNumber'ы, а не 343,12548 мкГн и 1,2341204 пФ
Кажется я понимаю, анончик, в чем состоят наши разногласия. Ты вероятно считаешь, что я предлагаю делать поведенческое описание схемы, как в HDL языках. Но нет. Я хочу как и раньше собирать схему из отдельных частей (транзисторов, резисторов, микросхем) с конкретными партнамберами. Но:
1. В отличии от классического рисования использовать описание соединений с помощью ЯП. Это позволит упростить соединения элементов с большим числом контактов, но не даст выигрыша, по сравнению со схемой, в случае разработки схем где отсутствует шаблонность соединения.
2. Сделать упор на модульность. Причем модуль может быть сделан достаточно универсальным. Для этого внутри него нужно соединять только абстрактные элементы (компоненты без номинала и модели), а при установке этого модуля в проект, задавать ему в качестве параметров модели неизвестных компонентов. Таким образом, описав один раз полумост на полевиках, можно использовать такой модуль в подавляющем большинстве силовых схем, просто указывая модулю модели транзисторов, номиналы затворных резисторов и прочих компонентов. При этом, часть номиналов компонентов может быть рассчитана (например ограничивающие резисторы для светодиодов) и по полученным значениям может быть произведен поиск реального компонента в БД, но этот расчет и поиск должен быть явно реализован разработчиком модуля.

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

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

>>191897
>При том что работа эта дичайше сложна и разнообразна, чтоб ее формализовать.
Я не предлагаю формализовывать выбор компонентов. Их по прежнему будет выбирать инженер. Я говорю немного о другом. Скажем у тебя есть шина из ста пинов, а тебе нужно подключится к каждому второму. Что будет делать схемоблядь? Рисовать 50 линий вручную. Что сделает программистобог? Напишет одну строчку кода for(int i = 0; i < ic1.bus.length; i += 2) ic1.bus = ic2.bus;

>>191897
>Надо поименовать 500 выводов - сядет и поименует за час, а не будет писать два дня модуль автоматического наименования
Ты думаешь для программного описания схем сгодятся подходы быдлоКАДов? А вот нихуя. Зачем мне писать модуль переименования пинов если их имена задаются одной строчкой? Например:
module Pamyat
{
DataBus[1000];
AddrBus[100];
}
И если понадобится заменить DataBus на PizdatoBus, то я сделаю это в течении трех секунд. В то время как ты будешь жвачаса дрочить пины, думая что другого подхода не существует.

>>191982
Язык высокого уровня не дает понимания о том, как и с чем он работает, что там за железо.
Как дело доходит до конкретики, таймеры там и сякая перферия - начинаются костыли или ассемблерные вставки. А тут чистое железо.
То, что ты называешь "громоздкой работой" - сущая ХУЙНЯ по времени. Да к тому же твои хотелки во многих КАДах есть, просто надо мануал чуть дальше корки прочитать. Пины нумеровать он устал, смех. Как будто вся работа только из этого и состоит.
А for i=1 то 100 - а если надо не по порядку? И оно так и есть в 99% случаев. Все равно в итоге джва часа дрочить.

>>191984
> таймеры там и сякая перферия - начинаются костыли или ассемблерные вставки
Охуительные истории.
Мимо-дрочу-таймеры-и-остальную-периферию-чисто-на-си

>Язык высокого уровня не дает понимания о том, как и с чем он работает
Давай различать языки высокого уровня для чисто программных целей и то что предлагаю я для "сборки схемы". Два главных момента моей идеи описаны тут >>191981 (смотри пунктики там). Как видишь, с одной стороны происходит абстракция от конкретных компонентов внутри модулей, но с другой, эти компоненты в дальнейшем все-равно должны быть определены, как конкретные.

>А for i=1 то 100 - а если надо не по порядку?
Приведи пример.

>>191988
>Приведи пример.
Подключаешь ты, например, АЦП к ПЛИС. 24 диф. пары.
По умолчанию ты захерачил 48 выводов с одной стороны к 48 выводам с другой стороны при помощи ололо цикла.
На этапе трассировки оказалось, что для упрощения разводки надо поменять p и n одной дифференциальной пары местами.
Будешь писать цикл (for i = 1 to 24 ){ if (i = 12){}}
?

>>191989
Дак это же пинсвопинг. О нем я уже писал. Не смотря на то, что в кадах такая фича есть, она мне кажется не очень удобной, ибо там нужно заполнять йоба-таблицы. В ЯП предлагаю делать примерно так:

// Это все должно быть описано в либах
module YobaADC
{
  ...
  output diffpair data[24];
  ...
}

module YobaFPGA
{
  ...
  inout diffpair bank0[50];
  ...
}

// А это мы пишем сами для конкретного дизайна
YobaFPGA fpga;
YobaADC adc;

// Значок ? в качестве индекса массива означает, что мы подсоединяем дифф пары из adc.data не к конкретным парам fpga.bank0, а логически связываем их с bank0 целиком. Связывание конкретных пар произойдет уже на этапе проектирования ПП.
fpga.bank0[?] = adc.data[0:23];

>>191991
>В ЯП предлагаю делать примерно так:
>все должно быть описано в либах
>логически связываем их с bank0 целиком

>Что сделает программистобог? Напишет одну строчку кода for(int i = 0; i < ic1.bus.length; i += 2) ic1.bus = ic2.bus;

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

>>191993
>>все должно быть описано в либах
Не всё, а только компоненты. Ты можешь делать свои либы, а можешь брать их у производителя, если они есть. Все как обычно. Код который связывает пины, находится вне либы. Я специально указал это в комментариях.

>Ты уже определись, как ты собираешься все это реализовывать.
Я определился. Способ for(int a = 0; a < ic1.bus.length; a += 2) ic1.bus[a] = ic2.bus[a]; макаба съела индексы в верхнем сообщении, тут я их заменю, на а, чтобы она не ела инженер использует, если ему нужно жестко связать каждый второй пин шины ic1.bus с каждыми вторым пином шины ic2.bus. А пинсвопинг вида fpga.bank0[?] = adc.data[0:23] используется в случае, если для правильной работы схемы не имеет значение конкретная связь между микросхемами.

>>191996
Ну так когда инбифо никогда от тебя уже бетку ждать?

>>192001
Единомышленников бы побольше. Общаемся тут с анончиком из треда. Но мне кажется, двоих человек мало для бетки.

>>191996
Пиши уже все через random.
Какая разница, все равно это или работать не будет, или пользоваться этой ересью будет невозможно.

>>192028
Конкретные замечания по описанному подходу имеются или ничего кроме абстрактного кукареканья от тебя можно больше не ждать?

>>191980
Опять не надо вырывать из контекста.
Verilog и VHDL - лишь описание функционала. Очень крутая вещь, вообще-то, но оно далеко не решает вопросы проектирования силикония.

ASIC вполне себе микросхема. Но тот ASIC, для проектирования которого достаточно лишь Verilog'а и VHDL - это уже огромная куча разработанной схемотехники, функционально (и с учётом ограничений) располагаемая в соответствии с данным функциональным описанием.
И эти ASICи делаются на основе тех же ПЛИС.

Далее, что в моём понимании проектирование микросхем.
Это не только функционал. Но ещё и такие вещи, как токи потребления, температурная стабильность, стойкость к проникающей радиации, паразитные ёмкости, площади коллекторов, эмиттеров, стоков, истоков, ширины каналов, соотношение площадей эмиттеров, согласованность vbe, одинаковость коллекторов многоколлекторных транзисторов и прочая-прочая.
Проще говоря, не только собирание целого из кирпичиков (VHDL, Verilog и прочие IP Core), но и создание этих самых кирпичиков, их расположение, учитывание ограничений техпроцесса, и прочие ништяки.

>>191981
>Таким образом, описав один раз полумост на полевиках, можно использовать такой модуль в подавляющем большинстве силовых схем, просто указывая модулю модели транзисторов, номиналы затворных резисторов и прочих компонентов.

Ну это даже в альтиуме есть, не говоря о более сурьёзных CADах. Design Reuse называется. Кстати, в шаблон для повторного использования вполне себе можно скопировать и расположение элементов, и кусок трассировки.

>>192040
> Design Reuse называется
Такая функциональность действительно присутствует. В Альтиуме такой схемный блок называется snippet. Вот только он не дает нужного уровня абстракции. Т. е. ты можешь собрать снипет-полумост на IRF740, но когда тебе понадобится полумост на IRF640, ты будешь делать новый снипет и как следствие соснешь с таким подходом к reuse.

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

>>192039
>Проще говоря, не только собирание целого из кирпичиков (VHDL, Verilog и прочие IP Core), но и создание этих самых кирпичиков
Очевидно же, что это задача другого уровня проектирования. Ты же свои махарайки тоже из готовых компонентов собираешь, а не дизайнишь каждый транзистор.

>>192042
>Такая функциональность действительно присутствует. В Альтиуме такой схемный блок называется snippet. Вот только он не дает нужного уровня абстракции. Т. е. ты можешь собрать снипет-полумост на IRF740, но когда тебе понадобится полумост на IRF640, ты будешь делать новый снипет и как следствие соснешь с таким подходом к reuse.

Если они Pin-to-Pin совместимы, то не сосну.
Если они не Pin-to-Pin совместимы, но совместимы функционально (что можно к обоим применить одинаковый схемный символ) - то опять же не сосну, ибо Design Variants, да и схемный Snippet, вроде как редактируется (тут честно скажу - не помню, так как больше пользовался design sheet - те не редактируются). Только трассировку переделать, разумеется, придётся (но тут и текстовое описание не поможет).

>>192044
>Если они Pin-to-Pin совместимы, то не сосну.
Нет соснешь. Только с полумостом ты на полшишечки соснешь, ибо в Design Variants хоть и возможно заменить компоненты, но делать это надо для каждого компонента. Т. е. в мосте тебе пришлось бы менять четыре транзистора, четыре затворных резистора и т. д. Но тут конечно затраты времени не намного больше программного подхода.

А вот где ты действительно соснешь, дак это в схеме с намного большим числом компонентов. Скажем в N-сегментном светодиодном дисплее. Внезапно решили заменить красный дисплей на зеленый? Пиздуешь пересчитывать номинал резистора и заменять все %количество_сегментов% резисторов в Design Variants. В то время как при программном подходе, можно просто передать на вход модулю другую модель pin-to-pin совместимого дисплея, а грамотно написанный модуль пересчитает номинал резистора на основе программно-доступных параметров дисплея и установит в "схему" нужные компоненты.

>>192039
Ебалай сгреб в кучу все и говорит, что VHDL не используют при проектировании микросхем. Ну что за ебалай.

>Не надо лезть туда, где ваши подходы ведут к обосракции.
И тут перед глазами всплывает менторовский редактор топологии дорог и покерфейс.

>У вас там накосорезил - "а, потом исправлю, в версии 28.4 betа". Хуй с ним, обновятся кому надо.
>В железе такое не проходит. Проебал 1 контактик - 10000 плат в помойку или в доработку, сравнимую по стоимости со сборкой.
Как же это смешно. Первое означает только сложность уровня хелло ворлд. По второму - видел кучу косяков на платах. Вон небезизвестное юзб порт упирающийся в кондёр.

>Обзываешь неты именами -то самое 1.8V_VDDIO и ставишь свой компонент где хочешь, подключенным к кусочкам с алиасами.
(Правда в результате, схема превращается в ебучий нетлист и что там с чем соединено нихуя не видно - нужно искать "точки входа с одинаковыми алиасами", но сраные программисты такой стиль любят: я сделал, а на других мне похуй).
Сам предложил сам и обосрал. Вот в коде должно быть так, но не так. Сети должны называться не одинаково а импортироваться из модуля в модуль и линковаться кодом.

>Мда. Я вижу, ты просто боишься настоящего железа и хочешь спихнуть работу с ним на программу. При том что работа эта дичайше сложна и разнообразна, чтоб ее формализовать. Пока ты будешь писать модуль синтеза твоего мультиплексора, нормальный инженер уже найдет готовое решение (у себя в башке или справочнике производителя) и воткнет его в схему. А в источниках питания есть расчеты по теплу, ширине дорожек, а в линиях связи - по задержкам. При этом дорожки линий не надо считать на тепло, но надо на импеданс. И т.д. и т.п. Это нужно ЗНАТЬ инженеру. А твой монстр-кад откуда это будет знать? В итоге для каждого чиха будут какие-то дикие необозримые списки параметров, в которых уже сам черт тогу сломит, а на выходе будет франкенштейн, которого никой гальванизацией не оживишь.
Да хоть миллион параметров. Это же не окошечки и менюшечки. Что надо то и юзаешь.

Вообще анончики вы очень правы. Нормальные схемки описаные кодом будут ОЧЕ убоги. Я даже думаю следовало бы создать ПРОСТО кад без легасца и фич запиленых очень сбоку.

Всему виной то чо электроблядок не кодерок. И делиться знаниями он не желает никак. Может быть придет таки нормальное поколение электроблядков и будет ок всё а может и нет. ВСЕ описаные проблемы это вообще не проблемы. Был бы просто текстовый дамп схем который можно было копипастить и кидать в любой кад был бы мир и любовь. Был бы у када АПИ который мог шуршать все обьекты - было бы збс, была бы библиотека компонентов открываема програмно и имела бы описание в жсоне - всё бы просто копипастили компоненты а не рисовали бы каждый как даун для себя.

Но в том треде мы общаемся о радикализме. о полной замене схемок кодом.

второй полуёбок

>>192060
>Всему виной то чо электроблядок не кодерок. И делиться знаниями он не желает никак. Может быть придет таки нормальное поколение электроблядков и будет ок всё а может и нет.
Кодерок в треде.

Я вижу это все дело так.
Создается описание элемента в котором выводы группируются, и описываются правила деления этих групп на подгруппы.
Кодом эти выводы соединяются. Одиночно, группами, подгруппами.
В визуальном редакторе все это отображается заебись.
Можно так же двигать контактики мышкой и код будет изменятся.

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


Ну вот как-то так. Ну и простой и понятный формат описания компонентов, их размеров, групп выводов, и даже правил для трассировки.


Вот. Ну симуляция - это очень сложно, это можно потом добавить к этому всему в качество расширения формата.

В общем, я хуйню полную говорю, или я уловил чего надо народу?
А то я сам небольшой спец.

>>192060
>Всему виной то чо электроблядок не кодерок. И делиться знаниями он не желает никак. Может быть придет таки нормальное поколение электроблядков и будет ок всё а может и нет.
Кодерок в треде.

Я вижу это все дело так.
Создается описание элемента в котором выводы группируются, и описываются правила деления этих групп на подгруппы.
Кодом эти выводы соединяются. Одиночно, группами, подгруппами.
В визуальном редакторе все это отображается заебись.
Можно так же двигать контактики мышкой и код будет изменятся.

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


Ну вот как-то так. Ну и простой и понятный формат описания компонентов, их размеров, групп выводов, и даже правил для трассировки.


Вот. Ну симуляция - это очень сложно, это можно потом добавить к этому всему в качество расширения формата.

В общем, я хуйню полную говорю, или я уловил чего надо народу?
А то я сам небольшой спец.

>>192062
Да. как то так.

>>192062
Ну Я сам не большой спец потому что веб-макака. Но как видишь бугурта СПЕЦОВ полон тред.

>В общем, я хуйню полную говорю, или я уловил чего надо народу?
Не народу а кодеркам, лол. Я сам кодерок, ОП кодерок, походу.

>>192064
>Не народу а кодеркам, лол.
Причем тут это?
Какую-то ерунду говоришь.

Для инженера уметь программировать это как для маркетолога уметь говорить и писать.
Я так понял, что просто нет кадов реализующих элементарную описанную мною концепцию.

Описание схемы открытым простым языком дает огромные преимущества. Можно по всякому ее модифицировать, анализировать, использовать для генерации всяких других вещей, например трассировки.
По схеме, и схемам, можно легко ИСКАТЬ.
короче куча возможностей.
Вплоть до разработки схемы при помощи ИИ.

>>192063
>Да. как то так.
Ну и само собой из готовых схем можно делать "модули" и описывать их как кустомные компоненты.

>>192065
"Описание схемы открытым простым языком" - это рисунок схемы. То что уже 100 с лихуем лет есть как данность и мало меняется. Язык этот универсальный и читается кем угодно.
Ты же хочешь из схемы сделать нетлист, который человеку уже не воспринять.
Изучи Allegro - там есть практически все что надо. И блоки, и шины, и черт с горы. Правда продуктов у них куча, нужно брать под свои задачи конь-плект. И интерфейс злой, но как обычно - "привыкнешь полюбишь".

>>192065
>Вплоть до разработки схемы при помощи ИИ.
Ну все, понеслась. Может проще написать ИИ, который напишет КАД, в котором будет все что ты понаписал?

>>192048
уёбище, съеби нахуй

>>192076
Нет, ты.

>>192047
Это ты соснёшь, а я не сосну.

Мне ничего не мешает сделать шаблон, в котором, резисторы затвора будут иметь LibraryID = {GateResistor}, где транзисторы будут иметь LibraryID = {HighSideMOS}, {LowSideMOS}, и дальше я просто задам нужные мне переменные через параметры проекта.

И нужное мне подтянется через БД библиотеки

Вопрос в правильной постановке задачи.

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

Не кодерки обычно очень хуёвые кодерки

>>192066
>"Описание схемы открытым простым языком" - это рисунок схемы. То что уже 100 с лихуем лет есть как данность и мало меняется. Язык этот универсальный и читается кем угодно.

Как его машине прочитать?

>Ты же хочешь из схемы сделать нетлист, который человеку уже не воспринять.
Ох, ну сириусли.
Человек просто какой-то даун у тебя, который только рисуночки рассматривать умеет.
А письменность, математика, вот это все - это для инопланетян просто блядь.

>>192075
>Ну все, понеслась. Может проще написать ИИ, который напишет КАД, в котором будет все что ты понаписал?
Ну в этом направлен сейчас например разработки то-же идут.

>>192083
>Не кодерки обычно очень хуёвые кодерки
Хуйня это все.
Может "некодерки" еще и считать не умеют? Элементарная математика внезапно такой же формальный язык как и любой ЯП.

>>192085
Ты максималист какой то. или школьник.
ИИшечка это бред.

>Как его машине прочитать?
тебе же говорят парс+нетлист. этого достаточно машине. но этого нигде нет

>Может "некодерки" еще и считать не умеют? Элементарная математика внезапно такой же формальный язык как и любой ЯП.
Я вот паяю и кодерирую но с математикой НЕ ОЧЕ дружу. Дело не в сичтать не считать дело в том что не у кодерка просто нет чувства такта. он возмёт и высрет функцию на тыщу строк, хуёво назовёт переменные, не разглядит что вместо сотни строк можно хуйнуть полторы функции. Ниасиляторство реляционных баз и колупание заместо этого в списках списков.

второй омич веб-кодерок

>>192086
>Ты максималист какой то. или школьник.
Специалист в области ИИ.

>ИИшечка это бред.
Ясно.

>но этого нигде нет
Это есть везде, но в закрытых недоступных для редактирования форматах, не оптимизированных для чтения и правки человеком.

>он возмёт и высрет функцию на тыщу строк, хуёво назовёт переменные, не разглядит что вместо сотни строк можно хуйнуть полторы функции. Ниасиляторство реляционных баз и колупание заместо этого в списках списков.
В таком случае систему проектируют таким образом, чтобы вынуждать пользователя к "бест практис".

>>192088
>>Ты максималист какой то. или школьник.
>Специалист в области ИИ.

уроки сделал, специалист ?

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

Если по теме треда - электроблядки это мерзкая раковая опухоль. Разбирал сегодня ЭПРА для МЛГ ламп. Вместо нормального IR контроллера поставили контроллер от OSRAM. ради полторых центов не впадлу было реверсить же, клепать свой. ёбаные мрази. называется он если что osram 46624-1. Транзисторы тоже дикий ноунейм, причем два а не как у ir полный мост, хотя при таких мощностях можно наверное через кондёры.

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

Вы о каком то реюзе компонентов, блядь, открытых либах. Нутро электромрази такое что она обязательно слижет схемку из даташита, наберёт её сука заново вручную и ей не впадлу будет еще прокликивать десяток минут для каждой ис чтобы создавать НОЖКИ, проглотит это всё дерьмо и попросит еще.

>>192130
Баттхерт неосилятора.

>>192079
Похоже, что в этом вопросе ты победил. Это почти то, что нужно. Не весь функционал, который должен выполнять модуль, но уже кое-что. Однако, я все-таки проверю то, что ты описал в альтиуме на предмет удобства использования. Отпишу, если почувствую бугурт.

Что вы тут, блять, без меня устроили? Вы молодцы на самом деле :3
Мимо-ОП

>>192129
>омич веб-кодерок
>т
>в
>электроблядки
>Электромразь
>уроки сделал, специалист ?
Ясно.
Не пиши мне больше пожалуйста.

>>192138
Ну мне до сих пор смешно. Запомни школьник - специалист в области ИИ не позорился бы называть себя так. А уж тем более говорить что ИИшечка запилит схемку

>>192143
>специалист в области ИИ не позорился бы называть себя так
У тебя комплексы.

>А уж тем более говорить что ИИшечка запилит схемку
В чем проблема?

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

>>192144
Ой ну ладно. Говоря ИИ что ты конкретно имеешь ввиду ?

>>192145
>Говоря ИИ что ты конкретно имеешь ввиду ?
Который схемы разрабатывать будет, или вообще?

Интеллект - способность решать нетривиальные задачи.
Нетривиальные задачи - задачи нелинейной оптимизации.
ИИ - некая интеллектуальная(решающая задачи нелинейной оптимизации) система(компьютерная в данном контексте)

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

Там много всего должно быть. Тебя подробности интересуют?

Одна из проблем, это составление достаточно формализованного ТЗ. Понимание естественного языка задача сложная и нерешенная.
Но можно ее обойти путем введения достаточно жесткой описательной терминологии и упрощенной схемы построения предложений. Ну и плюс чисто формализованные указания, вроде уровня энергопотребления например.

Строится ТЗ.
Затем, происходит оче сложная нелинейная оптимизация в процессе которой строится собственно электрическая схема удовлетворяющая ТЗ.

Все это счастье обеспечивается базой знаний, содержащей знания о принципах работы электрических цепей, компонентов, примеры схем, итд итп.
И вспомогательной базой с общими принципами и знаниями, которая помогает строить и интерпретировать ТЗ.
Обычной базой данных с перечнем и описанием доступных компонентов и типовых решений. (Это нужно для возможности легко добавлять/удалять соответствующие данные.)

Система логического вывода для работы с базами знаний.
Разные алгоритмы оптимизации, кластеризации, классификации.

И собственно сложный нелинейный оптимизатор(думалка), утилизирующий все это.

Такие системы сейчас активно разрабатываются.
Как только они начнут работать, оче многие программисты потеряют свою работу.

Хуйней страдаете. Начали бы с трассировки печаток, а то даже, казалось бы, такую простую задачу (в сравнении с разработкой схемы) до сих пор могут автоматизировать только при задании критериев чуть ли не каждого ебаного соединения. А в итоге все равно - говно.

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

>>192154
>только при задании критериев чуть ли не каждого ебаного соединения
Эти критерии логично отнести к схеме. Следовательно при разработке годного схемного построителя, будет проще формализовать и автоматизировать разводку ПП.

>>192154
>Или перейдут в моделлеры-составители тз, которые будут пилить модели, по которым алгоритмы будут хуярить код.

Так тут об этом уже не раз написано, что сделать быстрее, чем описать. Причём, несравнимо быстрее.

Зойчем вы мне тред искусственным интеллектом своим зашкварили?

>>192154
>Или перейдут в моделлеры-составители тз, которые будут пилить модели, по которым алгоритмы будут хуярить код.
Ну, 1/10000 перейдет.
Всякие прочие с зп выше 3к $ и минимум 2мя ВО.

>>192160
Двачую.

>>192166
>Так тут об этом уже не раз написано, что сделать быстрее, чем описать. Причём, несравнимо быстрее.
Я зделяль.жпг
Чтобы сделать ОК, нужно нормально описать, себе самому чисто. А над крупными проектами вообще не один человек работает, внезапно, а команда.

>>192168
Потому что мы можем.

>>192169
>Чтобы сделать ОК, нужно нормально описать, себе самому чисто. А над крупными проектами вообще не один человек работает, внезапно, а команда.

О, тут кто-то думает, что если взять 9 женщин, то ребёнка можно сделать за месяц? Некоторые работы не параллелятся.

>>192160
Отнеси к схеме дорожки эквипотенциальной защиты, спаи для выравнивания термо-ЭДС, тепловые якоря, пропилы для снижения передачи деформаций на критические узлы, обход разводкой крепежных отверстий, удобоваримую для монтажников очередность сборки...
Кодерки совсем ебанулись, видимо.

>>192186
>пропилы для снижения передачи деформаций на критические узлы, обход разводкой крепежных отверстий, удобоваримую для монтажников очередность сборки...
Это все механические характеристики схемы, которые не влияют на ее работоспособность. Очевидно, что они не должны присутствовать в схеме принципиальной.

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

>>192186
>дорожки эквипотенциальной защиты, спаи для выравнивания термо-ЭДС
Честно скажу, не встречался с этим. Но если ты мне скинешь ссылки на матчасть, то я попробую описать мысли по поводу того, что с этим делать в рамках предлагаемой концепции.

>>192184
>О, тут кто-то думает, что если взять 9 женщин, то ребёнка можно сделать за месяц? Некоторые работы не параллелятся.
Зато если оплодотворять их со сдвигом в месяц, можно получать ребенка каждый месяц. Только выхода первого ребенка нужно ждать 9 месяцев, а потом пойдут один за другим.

Посоны, а какой КАД подойдет для моделирования/визуализации размещения элементов/плат в корпусе? Хочется делать красивые махарайки, а я имел дело только с 2д и то довольно давно.

>>192197
А это надо?

Тут суть-то основная в том, что кто правда с этим работал, понимают, что не надо.

>>192191
ЮЭто все механические характеристики схемы, которые не влияют на ее работоспособность.
О, я узрел великого специалиста по аналоговой электронике. Стабильность опорного напряжения, стабильность опорной частоты - ну вообще никак не влияют на работоспособность.

>>192191
>Честно скажу, не встречался с этим. Но если ты мне скинешь ссылки на матчасть, то я попробую описать мысли по поводу того, что с этим делать в рамках предлагаемой концепции.

В общем-то это измерения на постоянном токе с точностью 16 бит и выше.

>>192198
Из доступных пиратских и простых к освоению - Altium Designer. В бесплатностях не рылся.
STEP (в который умеет AD) воспринимают практически все MCADы. Мне ближе всего SolidWorks (исторически сложилось). Хотя, люди знающие говорят, что он уже не торт, по сравнению с Solid Edge. Но то такое - для красивости махараек преимущества Edge перед Works будут незамечены и неиспользованы.

>>192206
Альтиум не умеет в несколько плат жи. Если только из них делать отдельные степ-модели, но нахуй тогда альтиум нужен.

Ну что, господа, кадопетушки? Давайте двигаться дальше. На этот раз немного затронем PCB дизайн. Такой вопрос вам. Можно ли вашими кадами параметризировать компоненты/футпринты? Скажем у меня имеется некое семейство разъемов с разным числом пинов. Могу я нарисовать/написать/задать компонент/фунпринт таким образом, чтобы при его использовании, возможно было указать нужное число контактов и получить требуемую модель? Или же вы для каждого разъема ебашите свою модель? Жду ваших оправданий.

>>192213
>Жду ваших оправданий.
Ну, понимаете, это... большинство разъемов имеют стандартное количество пинов, и такого чтобы не подошло из библиотек Eagle cad я еще не встречал. Было 1 раз, что девайса не было ни в библиотеках ни в инете, но в datasheet нарисованы полностью размеры, и я сделал свою либу тогда. когда я ставлю ножки пины с шагом 2.54 я просто ставлю подбором, хоть по одному пину ставишь на схему хоть по 10 пин. там много разных. Есть либы с большим количеством семейств разъемов.

>>192227
>большинство разъемов имеют стандартное количество пинов
Ограничить параметр, указывающий число пинов, чтобы случайно не поставить несуществующий разъем, никто не мешает.\

>и такого чтобы не подошло из библиотек Eagle cad я еще не встречал
Ты кроме хидеров ничем не пользуешься что-ли?

>>192236
>Ты кроме хидеров ничем не пользуешься что-ли?
ну я игл знаю не в совершенстве и что-то могу делать не так, конечно же, а что ты там можешь посоветовать?

>>192243
Ты меня не понял. Я так съязвил в ответ на то, что ты всегда находишь нужные разъемы в либах. Мол самыми распространенными пользуешься и редкоты не искал.

>>192210
Так несколько плат собираются в MCAD'е

>>192213
Значит так, давай-ка ты расскажешь, как ты будешь параметризовать что-то действительно сложное- например, QDR с шириной шины данных 64 бита (помнишь, что там всё диффпарами?) на разъём четырёхрядный. Так, чтобы пары не поехали. А как напишешь, тогда вопросы задавай.

>>192258
Курсы DFM проспасли, видимо?

>>192278
Проспали*, конечно же.

>>192272
Так мкад это приблуда солидворковская, альтиум здесь постольку поскольку.

>>192280
Это не приблуда, это Mechanical CAD.
Altium здесь только потому что он может красивые модельки сначала сожрать в модели компонентов, а потом их переправить в MCAD. Это может, разумеется, не только альтиум. Возможно, сегодня уже все ECAD'ы что-то подобное могут.

>>192213
>Или же вы для каждого разъема ебашите свою модель?
This. Это занимает ровно 2 минуты.

>>192274
>QDR с шириной шины данных 64 бита (помнишь, что там всё диффпарами?) на разъём четырёхрядный
Еще раз скажи более внятно, чего ты хочешь. Корпус в котором QDR память сидит тебе надо или разъем?

>>192283
Я конкретно об этом, если что.
http://www.altium.com/products/extensions/platform-extensions/mcad-co-designer-solidworks/features

>>192205
Это хорошо, что ты назвал область применения. Мне бы ссылку на описание описанных тобою улучшаторов, а то я что-то ничего нагуглить не могу.

>>192310
Странно, а гуглил thermal relief, stress relief?

>>192321
>thermal relief, stress relief?
Это я знаю. Это чисто механические фичи, не влияющие а работу схемы. Ты мне про
>дорожки эквипотенциальной защиты, спаи для выравнивания термо-ЭДС
расскажи лучше.

>>189440
>Нам придется раздвигать ворох проводов и компонентов, чтобы освободить место для новой детальки.
Наркотики - зло индид

EAGLE masterrace!
получаю 7к грязными

>>192340
Как там на работе дела, мань? Много мультивибраторов развели?

>>192341
>7к грязными
Зеленых, надеюсь 7к?

В орле новая деталька создается с полпинка
1. Нарисовать symbol (5min)
2. Footprint (5min)
3. Соединить 1 и 2 (10мин)

для трололо, кому 5мин долго: детальку только нагуглил, покурил шит и вперед

>>192348
Мы тут считаем мои деньги? Извольте.
в зелёных больше

>>192355
Попробовал бы ты это сделать с ПЛИСиной на 1000 ног.

>>192356
>в зелёных больше
Врешь!

>>192357
> EAGLE
> script execution
> ULP
> OP is a faggot
ещё вопросы?

>>192360
Он не врёт! Брат умер

>>192362
Нука покажи нам как ты будешь плисину скриптами дрочить.

>>192363
>покажи нам
http://web.mit.edu/xavid/arch/i386_rhel4/help/36.htm

>>192366
>Скрипты
>Команда CONNECT
>Надо перечислять все пины и пады
>Нельзя сделать ic.dataBus[10:13] = pads[3:6]
Охуенные скрипты, мань.

>>192375
Ты нихуя не понял, для чего CONNECT нужон.
Эх, маня, сидел бы ты в своём мирке.

>>192376
Расскажи мне скорее, в таком случае.

>>192378
Неа, живи безметежно.
Завтра не в школу?

>>192379
>безметежно
И после этого ты отправляешь меня в школу?

Нет, ну серьезно говорю, расскажи. Вдруг в твоем ОРЛЕ и вправду есть все то, об отсутствии чего я развожу бугурт в этом треде.

>>192381
Слезь с Росинанта и вдумчиво перечитай тхреад. Тебе тут накидали кучу аргументов, что ты хуйнёй занят и все твои идеи никому не упали. Есть workflow в орле, есть он и в KiCad. Ты же начинаешь с упортсвом студента-отличника доказывать дядям, что они всё не так делают. отцы и дети 2015, блеат

Сам-то какой кад вкурил?

>>192382
>дядям
Знаю я таких дядей. На кульмане до сих пор чертежи делают. Вот и ты тоже, я смотрю, того же сорта дядя, только другого поколения.

>>192382
>Сам-то какой кад вкурил?
Альтиум пока только. Знаю, что не лучший кад, но то о чем я говорю, судя по вашим ответам, в других кадах тоже не встречается.

Алсо, за CONNECT свой поясни, раз говоришь, я его неправильно понимаю. Интересно мне.

>>192213
Нахер иметь модели чего-то несуществующего?
Разумеется нужны модели конкретных выпускающихся изделий. Отдельные, со своими особенностями и ограничениями.
Эх, кодерок, кодерок. Все уже упростил в своей головушке до i++, а в жизни то оно гораздо сложнее.

>>192324
>Это я знаю. Это чисто механические фичи, не влияющие а работу схемы.

Говорят же тебе, что не знаешь. НЕ ЗНАЕШЬ. И это сразу видно по:
>Это чисто механические фичи, не влияющие а работу схемы.

>дорожки эквипотенциальной защиты, спаи для выравнивания термо-ЭДС
Guard Ring и Thermocouple effect луркай.

>>192295
>Еще раз скажи более внятно, чего ты хочешь.
Зачем? Электроблядку (TM) достаточно такого описания, и он всё понимает. Это кодерки заявили, что электроблядки нихуя не понимают, и можно гораздо удобнее и быстрее. Вперёд, оправдайся.

>>192383
>Альтиум пока только.
Когда освоишь Ментор - приходи.

>>192383
>Знаю я таких дядей. На кульмане до сих пор чертежи делают.
Вот-вот. Узнаю юнца-зазнайку с нулевой наработкой чего-либо.
Всем пох кульман у тебя или йоба за 10к. Уважение тебе не за отметки в дипломе и даже не за познания, а за твою полезность в коллективе, собравшемся вместе заработать немного денег.

>CONNECT
По ссылке всё написано. И пример дан. А у студента-отличника всё ещё вопросы.

Ну, задавай.

>>192398
Когда я затеваю что-то очень новое, делаю отдельную либу с новыми деталями или продолжаю из старого проекта. Так и называется main.lib. Мои кубики так сказать.

>>192398
>Нахер иметь модели чего-то несуществующего?
Почему несуществующего? У тебя есть серия в которую входят разъемы например с 4,5,...30 пинами. Ты ебашишь либу для каждого из 27 разъемов, а я говорю что рациональнее сделать универсальную либу для серии, которая генерит разъем с нужным числом контактов. Чтобы случайно не получить несуществующий разъем, входной параметр нужно ограничить в пределах от 4 до 30.

>>192399
>Guard Ring
Спасибо, залуркаю.

>>192399
>Thermocouple effect
Ну охуеть ты кэп. На PCB то это как реализуется и зачем?

>>192399
>Зачем?
Потому что ты описал хуево. Напиши четко: "У меня есть X и Y. Хочу чтобы было Z"

>>192399
>И это сразу видно по:
>>Это чисто механические фичи, не влияющие а работу схемы.
А что влияют. Ну расскажи, как схема не плата реализованная по схеме, а именно схема не будет без них работать.

>>192401
>Когда освоишь Ментор - приходи.
И много там есть из того, что я описываю?

>>192408
>По ссылке всё написано.
Написано:
>This command is used in the device editing mode in order to define the relationship between the pins of a symbol and the pads
Назначение предельно ясно. Вот только как такой "скриптинг" помогает автоматизировать процесс накатывания футпринта на компонент мне не понятно, ибо приходится перечислять все пины, вместо указания, например, диапазона, если это возможно. Типа такого:
>CONNECT ic.dataBus[10:13] pads[3:6]

Ох вас и понесло. Речь была тлько про схемный редактор. трассировщик понятное дело всёравно будет ручной

>>192425
>трассировщик понятное дело всёравно будет ручной
Схемный редактор тоже. Ибо ОП дальше пиздежа никуда не продвинется.

>>192426
Юзайте свой sPlan и не выёбывайтесь.

>>192425
Ручной, да. Но вопросы о том, какие параметры нужно задавать в схеме, чтобы получить правила для PCB, тоже стоит рассмотреть.

>>192417
>вместо указания, например, диапазона, если это возможно.
Ударение на если возможно.
Например, ОЗУ. Ну, накатил ты обе шины и тебе полегчало.

А питание, а WR, NE, OE и прочие?

Если тебе заспиновка дана таблицей, она вставляема в exel и обмазываема CONNECT. Потом просто исполняешь скрипт и сверяешься по даташиту, не наврал ли с именами.
Этот метод для 100 пинов и больше. И для соединения футпринта с символом. На симболе изволь сам пины расставить и подписать. Тебе с ними работать.

>>192433
>А питание, а WR, NE, OE и прочие?
Ебашишь каждый по отдельности, потирая ручки от того, что сэкономил кучу времени на шинах. Более того, объединение группы разнородных пинов в интерфейс позволит потом в некоторых случаях соединять микросхемы одним махом.

>Если тебе заспиновка дана таблицей, она вставляема в exel и обмазываема CONNECT.
Вот нахуя так делоть, если можно договорится о текстовом формате описания микрухи?

>>192435
>объединение группы разнородных пинов в интерфейс
да, охуенно! И где же все эти стандарты? Я знаю, что ты ответишь. Но это всё хуйня и в каждом даташите к памяти временные диаграммы и таблицы истинности. Индивидуально, панимаш?

>соединять микросхемы одним махом
сколько тебе нужно времени, чтобы соединить ручками? 5мин, полчаса, 3 дня?

>если можно договорится
мой юный друг! Ты видешь проблему, где её нет. Может уговоришь microchip, atmel, latticesemi, xilix, altera, TI, ST писать даташиты по какому-то одному стандарту?
Начни с малого. И переведи даташиты на эсперанто.

>>192435
>о текстовом формате описания микрухи
Hardware Description Language?

картинкой лучше

>>192438
>Hardware Description Language?
Я имел ввиду ее внешний интерфейс, а не внутреннюю структуру.

>>192437
>Индивидуально, панимаш?
Как же интересно контроллеры памяти в процессорах умудряются работать с памятью разных от производителей в таком случае? Искусственный интеллект в них вживляют, не иначе.

>сколько тебе нужно времени, чтобы соединить ручками? 5мин, полчаса, 3 дня
Достаточно, чтобы заебаться однообразной работой.

>>192437
>Может уговоришь
Договорились же о схемных символах более менее единых. О формате ПДФ для шитов договорились. О содержании на английском языке. Очевидно, что необходима популярность некого стандарта среди инженеров, чтобы производители стали его использовать. Но процесс этот дико сложный, признаю.

>>192440
>Договорились же
вот и флаг тебе в руки

>Как же контроллеры умудряются
И как же? Ну, давай же! Расскажи!

>внешний интерфейс
HDL не описывает внешний интерфейс? Как же туда входит и выходит?

>>192441
>HDL не описывает внешний интерфейс? Как же туда входит и выходит?
Описывает. Вот только в большинстве HDL интерфейсы только цифровые.

>>192441
>И как же? Ну, давай же! Расскажи!
Берут и работают)))

>>192440
>>192442
>Вот только в большинстве HDL интерфейсы только цифровые.
То, что ты и хотел!
>ic.dataBus[10:13] pads[3:6]

>>192444
Почти. Но там есть не все что нужно для проектирования классической схемы. Большинство HDL созданы для проектирования на FPGA и ASIC. Очевидно, что в языке который я описываю, должна быть учтена специфика обычных "схем".

>>192445
>>192445
>в языке который я описываю
Я что-то упустил. Переработался, устал, прочитал не весь тхреад.

Где ты его описал?

>>192446
Забыл совсем. Это же мы с аноном по почте набросками языка обменивались. В треде нет, сорян. Только отрывки показывающие, как можно было бы решать определенную задачу.

>>192417
>Ну охуеть ты кэп. На PCB то это как реализуется и зачем?
Ты что, дебил? Это на PCB реализуется как термопара. Потому что ВНЕЗАПНО, не всё в электронике сделано лишь из меди. Там ещё никелей до ёбаной страсти, а ещё ковар есть, а ещё олово, а ещё свинец, да и соединение с кремнием тоже даёт такой эффект. А уж что делает окисел меди, у...

И всё это порядков от сотен нановольт до единиц милливольт на градус цельсия.

И это, блядь, надо компенсировать. А ты понять не можешь, как QDR к разъёму подсоединить - да это детский сад вообще.

>>192450
>И всё это порядков от сотен нановольт до единиц милливольт на градус цельсия
Это я все понимаю, анон. Ты мне ссылку на меры по компенсации данного эффекта на PCB дай.

>А ты понять не можешь, как QDR к разъёму подсоединить - да это детский сад вообще
Конечно не могу понять. Ты же хочешь память на разъем посадить. Откуда мне знать с какой целью ты это делаешь и какие требования предъявляешь. Дай ссылку на дизайн какой-нибудь или опиши вкратце.

>>192448
>наброски языка
В викиликс уже вскрыли вашу почту:
make_peezdato_button;
connect a.[0-i] to b.[0-j].

>>192456
>Ко-ко-ко
>Кукареку
Что, простите?

>>192462
prove me wrong

>>192463
О чем именно ты хотел бы узнать?

>>192563
Наброски языка, которые не похожи на
>make_peezdato_button;
>connect a.[0-i] to b.[0-j].

Или читать, анализировать и строить логические цепочки нынешние погромисты не могут?

>>192399
>Guard Ring
Посмотрел что это и зачем. По поводу интеграции данного решения в мою концепцию могу сказать следующее. По моему мнению, в схему не должно включаться конкретное решение проблемы. Вместо этого, должен быть обозначен факт недопустимости появления данной проблемы. Эквипотенциальная защита нужна для устранения тока текущего от/к чувствительного контакта. Таким образом к "схеме" нужно подключить виртуальный источник тока, ток от которого будет течь на рассматриваемый контакт. Причем, это будет не источник тока в классическом понимании, а скорее ограничитель тока, указывающий, что на данный контакт не должно затекать тока больше определенного значения. Таким образом, зная максимальный ток, потенциалы рядом идущих контактов часть из них можно указать вручную, часть вычислить по каким-то другим данным, а также характеристики текстолита, возможно автоматически создать правила для PCB редактора. В таком случае софт сможет сам вынести решение о необходимости защиты. Если защита оказалась необходима, разработчик может выбрать тип защиты, т. к. нашу проблему можно решить не только с помощью эквипотенциальной защиты, но и выполнением фрезеровки. После чего, вручную рискну предположить, что и автоматически такое можно реализовать, производится реализация защиты с последующей автоматической проверкой ее достаточности. Как-то так.

>>192564
Может дашь какое-нибудь задание? Небольшую схемку, например. Можно стандартную схему включения чего-нибудь из дейтшита.

>>192417
>Почему несуществующего?
Потому что разъемы сложнее простой гребенки не получаются тупым циклом i++. У них есть монтажные элементы/отверстия с немасштабируемым паттерном, промежуточные заземляющие элементы и прочее.
Да и не нужны разработчику ВСЕ разъемы. Я как-то посмотрел нашу библиотеку накопленную за 5 лет (при том что у нас там и FPGA используются и силовуха и всякое такое) - оказалась на удивление скромной.
Если прямо хочется программировать, аж жопа горит - можешь, конечно нахуячить скриптом символов разъемов от 1 до 40 пин про запас, но фактически-то потом будут из них 1-2-3 реально использованы. Нахуй мне за такой мартышкин труд тебе платить, если у меня разводчик этот символ рисует за 5 минут между делом, попивая чай и поглядывая в даташит? Используя простенький визард, встроенный в аллегро.

Мне не нужен интеллект, гибкость, универсальность, портируемость и вся та тупая левая хуйня, которой так радуются кодерки. Мне нужно работоспособное устройство за минимум итераций в железе, а не система по его созданию. Если система существенно упрощает работу - да, она нужна. И можешь быть уверен - она уже существует в том или ином виде.

>>192607
>Потому что разъемы сложнее простой гребенки не получаются тупым циклом i++. У них есть монтажные элементы/отверстия с немасштабируемым паттерном, промежуточные заземляющие элементы и прочее.
Просто ты не шаришь. Можно же делать так: константное начало + N повторяющийся элемент + константный конец*.

>>192607
>Нахуй мне за такой мартышкин труд тебе платить
Во-первых, мартышкин труд делает твой разработчик, срисовывая чертежи из дейтшита в кад. Во-вторых, параметризируемый разъем позволит запилить автовыбор разъема для соединения кастомных плат. Т.е. ты подключаешь контакты к абстрактному универсальному разъему, а система по числу контактов, сама ставит конкретный разъем. Внезапно изменились требования во время проектирования? Просто добавляешь/убираешь контакты с абстрактного разъема, перекомилируешь проект, и вот у тебя уже стоит новый разъем с большим/меньшим числом контактов.

>>192607
>Мне не нужен интеллект, гибкость
Очевидно, что вы никому ненужные махарайки клепаете. Ибо для нормального девайса, гибкость, реализуемая за счет параметризации позволила бы без особых затруднений выпускать модификации основного девайса.

>>192640
В схеме на начальном этапе ее создания мой разъем предельно абстрактен - это прямоугольник с нужным мне количеством выводов, их в библиотеке навалом, с любым количеством выводов, да и самому нарисовать минутное дело.
Конкретика начинается, когда требуется железный разъем на плату. Подбирается разъем, для него делается футпринт, футпринт присваивается моему прямоугольнику (их выводы встают в соответствие), пересовываются подключения к разъему как мне удобно для разводки или по логике работы.
>>192643
Ты пока что своими скриптами можешь клепать исключительно сферические махарайки в вакууме. Причем воображаемые, состоящие из одних шин и цапов R-2R. Которые не можешь при этом даже изобразить в виде схемы на бумаге. Зато гиииибкие, дальше некуда. Но только из шин и только по порядку.

>>192643
>Очевидно, что вы никому ненужные махарайки клепаете.
Может расскажешь, в каких КАДах клепают топовые материнки и прочие серваки?

>>192651
Откуда мне знать? Алсо, даже если их клепают в том же в чем и ты клепаешь свои девайсы, то это не показатель. Когда-то и посложнее электронику на листочке рисовали и было норм. Вот только ебаться с листочками приходилось больше.

>>192656
>это не показатель
А тот факт, что за десятилетия не реализовали иного подхода к разработке принципиальных схем, тоже не показатель? Языки программирования когда изобрели? Verilog и прочее? Но почему-то принципиальные схемы все равно пилятся в Менторах и прочих Альтиумах.
Или все просто тебя ждали с твоей мега идеей?

>>192657
>А тот факт, что за десятилетия не реализовали иного подхода к разработке принципиальных схем, тоже не показатель?
Не показатель. Наукобляди в СНГ пишут научные статьи в вордике, надрачивая формулки и нумеруя рисуночки вручную, в то время как задолго до вордика появился божественный Латех. Потратив на его изучение немного времени, можно в последствии сосредоточится на содержании и не думать о форматировании. Но быдло продолжает жрать говно, потому что оно привыкло. Также и с электроникой. Ее разрабатывают люди, имеющее скудное представление о программировании, поэтому они и не задумываются об автоматизации рутинных задач, рассматривая их как данность.

>>192657
>Verilog
Это язык поведенческого описания схем. Не уверен, что такое прокатит с аналоговой электроникой. Хотя попытки были. См. Verilog-AMS.

>>192660
>в СНГ
При чем тут СНГ? Весь остальной мир тоже то программирования не дошел?

>Ее разрабатывают люди, имеющее скудное представление о программировании
Ты так толстишь? Или ты реально даун? Микроконтроллеры, процы, ARM, FPGA - это не программирование?

>>192661
>При чем тут СНГ?
Это как пример. В других местах просто люди приучились. А у нас нет. Может потому, что они были знакомы с разработчиком языка. Вот и распространилось оно среди них. А в электронике, видимо, не сложилось пока просто. Появление новых концепций - событие случайное. Даже если кто-то и привносит казалось бы полезную новизну, она может не взлететь по различным причинам. А потом раз и взлетает похожая новизна, но через время. Просто так получилось.

>>192661
>Микроконтроллеры, процы, ARM, FPGA - это не программирование?
Не каждый из перечисленных тобою программистов может в грамотный код. Видал я поделия вашего брата. То они светодиодами мигают с помощью трех страниц с if'ами, то нахуячат 300 строк копипасты для FPGA, которую можно переписать десятью строками. Причем последнее я видел в коде уважаемого инженера, который судя по его линкедину, поработал в известных европейских конторах. Решение задачи в лоб и построение грамотной архитектуры проекта, который можно поддерживать и масштабировать, немного разные скилы.

>>192664
>Появление новых концепций - событие случайное.
Ну тебе из погреба виднее, понятно дело. Разработчики КАДов, понятное дело, дебилы. Один ты, понятное дело, молодец - программист архитектор от бога.

Про 300 строк кода м.б. пруфанешь? Или все исходники удалил уже?

>>192665
>Разработчики КАДов, понятное дело
Не дебилы они. Просто следуют проверенным концепциям, к которым привыкли разработчики. Вполне себе рациональное поведение с их стороны.

>>192665
>Про 300 строк кода м.б. пруфанешь? Или все исходники удалил уже?
Ты не поверишь, удолил. Хотя нет, нашел: http://pastebin.com/Zz38bzY5. Это про мигание светодиодами. FPGA код я не уверен, что буду показывать, ибо могу спалить контору. Но я посмотрю, что можно сделать.

>>192668
>Просто следуют проверенным концепциям, к которым привыкли разработчики.
И никто не додумался допилить в свой продукт мега фичу, которая, по твоим словам, облегчила бы жизнь этим самым разработчикам. Ну ну.

>Хотя нет, нашел
Удаленную страницу. Молодец.

>>192669
>Удаленную страницу.
Сорян, точка в ссылку попала. Держи нормальную http://pastebin.com/Zz38bzY5

>>192669
>И никто не додумался допилить в свой продукт мега фичу
Это не фича будет. Это смена концепции. Вчера ты рисовал схемки, а сегодня тебя заставляют писать код. Любой бы охуел от такого расклада. Но такова цена потенциального повышения эффективности. Вспомни баттхерт совковых инженероблядей, когда их с кульмана на кады переводили.

>>192670
>Это смена концепции.
С хуяли смена? По-твоему, Ментор не может запилить дополнительный модуль рисования схемы при помощи кода?

>>192671
>По-твоему, Ментор не может запилить дополнительный модуль рисования схемы при помощи кода
Не знаю я, что ментор может, а что нет. Но тут просто модуля мало. Надо же еще разработать иерархию компонентов и как-то вписать в нее существующие вещи. Формат нетлиста должен быть расширенный, для некоторых фич. Не знаю, могут ли они позволить ли себе заниматься встраиванием всего этого в готовый продукт.

>>192672
>могут ли они позволить ли себе заниматься встраиванием всего этого в готовый продукт
Могут, если в этом есть смысл. Но, видимо, товарищи из Ментора смысла в этом не видят.

>>192673
>Могут, если в этом есть смысл
Я смотрю ты знаток в разработке софта. Вот тебе контрпример. Масштабирование в винде. Дохуя актуальная тема в связи с ростом плотности пикселей на современных мониторах. Но при этом билли и его команда до сих пор не запилили нормального решения для всех приложений. При этом на некоторых других ОСях такая проблема уже решена.

>>192674
Ну и? То есть ты видишь, что если есть какая-то крутая фича, то в условиях конкуренции кто-то рано или поздно к ней придет. Однако же твою мега фичу пока что ни Ментор, ни Каденс, ни Альтиум внедрять не спешат.

>>192676
Дак нет такой фичи не фичи, а концепции ни у кого. Вот и не спешат реализовывать, а когда появится, то зашевелятся. Так обычно и бывает. Компании выпускают вещи годами даже и не думая что-то в них менять радикально, потому что бабло итак течет. А новыми охуительными идеями обычно выступают новички на рынке. Иногда успешно, иногда нет.

>>192677
>Так обычно и бывает.
Ну тебе виднее, как оно бывает. У тебя-то небось в загашнике уже штук пять команий - лидеров в своих отраслях?

>не думая что-то в них менять радикально, потому что бабло итак течет
Ну да, за рынок ведь никому бороться не надо. Прям не капитализм, а рай какой-то.

>>192678
>У тебя-то небось в загашнике уже штук пять команий
Нет, просто существует множество подтверждений моим словам. Вытеснение ламп, полупроводниками, например. Первые транзисторы начала производить Bell Labs, в то время как лампами занимались другие конторы.

>>192678
>Ну да, за рынок ведь никому бороться не надо.
Борются они. Но в рамках существующей концепции. Ее смена приводит к конкуренции немного в другой области, которая со временем может вытеснить старую или вовсе не взлететь. Поэтому что-то радикально менять - опасно.

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

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

Сейчас же ничто не мешает конторам натянуть тот же Verilog на микросхемы. Просто сделать библиотеку компонентов и дальше работать так же, как сейчас это делается при разработке FPGA. Но почему-то никто так не делает.

>>192683
>Сейчас же ничто не мешает конторам
Мешает необходимость обеспечить обратную совместимость с имеющейся системой. См. пример с масштабированием в винде.

>>192686
Ты же говорил про генератор схемы из кода? Код -> схема, а дальше уже все как обычно.

>>192688
>Ты же говорил про генератор схемы из кода?
Судя по всему ты не до конца представляешь себе, что должен делать генератор. Начнем хотя бы с иерархии компонентов. Все, например, резисторы должны наследовать базовый абстрактный резистор, чтобы можно было передавать тип желаемого резистора на вход модуля (схемы с параметрами и торчащим наружу интерфейсом, если угодно) и быть уверенным, что туда случайно не попадет, скажем, кондер. В кадах, насколько мне известно, такой иерархии нет и все элементы сами по себе. О наследовании там тоже ничего не слышали, поэтому одни резисторы имеют какие-то параметры, другие нет. Наследование же от базового резистора предполагает заполнение таких свойств, как сопротивление, допуск и прочие, всеми дочерними резисторами, которые могут понадобится для расчета. Т. е. тамошние библиотеки будут несовместимы с требованиями ЯП.

Оп - охуенный теоретик, который мне всё-таки чем-то симпатичен. Охотно бы с них попиздел за чашечкой чего-нидудь. Жаль только, что живём мы в разных мирах: я клепаю свои махарайки в европпах на тупейшем орле, а он фантазирует за революцию в разработке электроники в СНГ.

язык для описания и аналогово, и цифрового мира изобрели, когда ОП еще был не запланирован. Писпайс, блеат. Вот и напиши под него охуительный компилятор, испражняющий железо

ОП, нахуя нужны молотки, зубила, напильники, пилы, дрели и прочая хуета, когда есть божественные CNC или еще? знаешь? Любую йобу ищ програмки! а 3д принтера сделают и CNC обсолет

>>192681
Вытеснение ламп полупроводниками, тащемта, до конца не произведено, многие устройства свч, а так же, ВНЕЗАПНО, производства самих полупроводников базируются на ламповых технологиях.
То же справедливо и для радиоблядства, ты глянь, например, в силовую электронику, причем не в собственно силу, почитай, сколько десятков, если не сотен алгоритмов управления реализуется в шим-контроллерах. Софт с кнопкой "сделать пиздато" сумели сделать только для редких специально вылизанных примеров, и то, я почему-то почти не видел применения "параметризируемых" TOPxxx в блоках питания, тупые китайские пердолики предпочитают uc3845, или, о ужас, всякие резонансники.

>>192640
> и вот у тебя уже стоит новый разъем с большим/меньшим числом контактов.

Этот функционал - ненужное говно. Ибо надо переделывать плату. Платы с вариантами так не делают. Разъём как раз всегда один и тот же - стандартный.

>>192670
>Сорян, точка в ссылку попала. Держи нормальную http://pastebin.com/Zz38bzY5

Ну радиогубители никогда не были жалованы в среде профессионалов. Ты ещё схемотехнику от ардуинщика привёл в качестве примера неспособности схемотехников делать схемы.

>>192677
Нет такой фичи? Да ты чего?
По-твоему, у Cadence есть только Allegro, А у MentorGraphics - только PADS и Expedition? А то, что они же выпускают софт для проектирования микросхем? Что, например, тот же modelSim - это Mentor'овский продукт - ни на какие мысли не наталкивает?

Эта вся параметризация подходит только для отработанных решений. Для отработанных решений есть Design Reuse в области схемотехники и проектирования ПП. Нормальный профи, видя перед собой схемный символ операционного усилителя и PartNumber Opa124 уже прекрасно представляет не только функционал, который начерчен на схеме, но и его характеристики. А ты предлагаешь ему пялиться в 20 страниц кода, чтобы в конце ему система сама предложила подходящий операционник? А если это будет AD822, который фирмой не закупается, вместо того же OPA124, покупаемого по 5к в год? Ты предлагаешь специалисту заниматься тем, чтобы нахер выпиливать "такую-то нужную штуку", или как? рисовать на бумажке, потом давать трём обезьянам, которые наделают ошибок в параметризации, а потом ещё месяц выискивать, где они были сделаны?

>>192677
Нашел цитату интересную, про ОПа:

"Важные решения о будущем развитии атомной энергетики часто приходится принимать людям, которые вовсе не обязательно близко знакомы с техническими аспектами реакторов. Тем не менее, этим людям интересно, что этот реактор даст им, во сколько он обойдётся, сколько времени займёт его постройка, и насколько долго и хорошо он будет работать. Когда они пытаются узнать всё это, они узнают и о путанице, существующей в реакторном бизнесе. Представляется, что нерешённые проблемы имеются практически в каждой области.

Я уверен, что эта путаница происходит из неумения различать академическое и практическое. Эти очевидные противоречия обычно можно объяснить только при разделении всех разнообразных аспектов проблемы на их академическую и практическую составляющие. Общее определение этих характеристик, позволяющих отличать одно от другого, может оказаться полезным для подобного разделения.

"Академические" реакторы или станции почти всегда имеют следующие основные характеристики:

их конструкция проста;
их размеры невелики;
они дешевы;
они имеют небольшую массу;
их можно построить очень быстро;
их легко приспособить для различных целей (многоцелевой реактор);
они практически не требуют НИОКР и используют в основном уже имеющиеся "на складе" компоненты;
они находятся на стадии исследований;
сейчас они не строятся.

С другой стороны, "реальные" реакторы можно отличить по следующим характеристикам:

они строятся сейчас;
их строительство отстаёт от графика;
они требуют огромного объёма НИОКР в областях, казалось бы, тривиальных - в частности, одной из проблем здесь является коррозия;
они очень дороги;
их постройка занимает очень много времени из-за инженерных проблем;
они имеют большие размеры;
они тяжелы;
их конструкция сложна.

Инструменты конструктора академического реактора - лист бумаги, карандаш и ластик. Если допущена ошибка, её всегда можно стереть и исправить. Если ошибается конструктор реального реактора, его ошибка висит камнем у него на шее, и её не сотрёшь. Она видна всем.

Конструктор академического реактора - это любитель. Ему никогда не приходилось нести никакой реальной ответственности за свои проекты. Он может наслаждаться элегантными идеями, любые практические недостатки которых можно отнести в категории "мелких технических деталей". Конструктор же реального реактора должен жить с этими "техническими деталями". Хотя эти проблемы трудно и неудобно решаются, решить их необходимо, причём не откладывая на завтра. И это требует значительных усилий, времени и денег."
Хайман Риковер, адмирал "отец атомного флота" США.

>>192697
Ох ох. а раскажи про TOPы и чем они отличаются от uc3845. вроде шим как шим. А чего резонансники ужас ?

>>192695
Ну красиво мечтать не запретишь. ты еще не видел /c/ нульча образца 2010 года. Дизайнеры языков теоретиками лямбда исчисления погоняли. До сих пор хаскиблядков по рунету гоняют ссаными мётлами.

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

>>192670
>Это смена концепции. Вчера ты рисовал схемки, а сегодня тебя заставляют писать код.
Спешите видеть. Погромист хочет переделать кад, делающий из читаемой схемы код (читай нетлист) в кад, которым ты пишешь код ради нихуя.

>>192736
>Ох ох. а раскажи про TOPы и чем они отличаются от uc3845. вроде шим как шим.
Ничем не отличаются, тот же шим с обратной связью по току. Только к первому PI выпустила нужную софтину, со вторым придется немного поразмыслить, хотя трансформатор можно передрать из первого случая.
Энивей, моточные элементы и разводка силовых бп параметризируются не очень, особенно если мотать самому.
> А чего резонансники ужас ?
Да хотя бы тем же трансформатором с нормируемой индуктивностью рассеяния. Нет, конечно может быть, что кто-то не поленится и нарисует его в ансисе или фемм-е, но полагаю, даже в серьезных фирмах ебутся с макетированием и замером отдельных параметров.
Ну и еще резонансники плохо держат большие колебания входного напряжения, а переменная частота временами зло похуже хард свитчинга для чувствительной измериловки, но это к делу не относится.

Электроникобугурт?
ПРОЕКТИРОВЩИК ДЕЛАЕТ ПЛАТУ НА КОРТЕКСЕ М3
@
НА ПЛАТЕ ДВА ДИСПЛЕЯ И МАТРИЧНАЯ КЛАВИАТУРА
@
ПРОЕКТИРОВЩИК ВЕШАЕТ НА ЕБАНЫЕ ПИО СУКА ОТДЕЛЬНО ДИСПЛЕИ С ПАРАЛЛЕЛЬНЫМИ ШД/ША
@
ПРО ПОНЯТИЕ EBI НЕ СЛЫШАЛ
@
МОЯ ПРОГРАММА ПЕРЕКЛЮЧАЕТ ПИНЫ ДЛЯ ЗАПИСИ В РЕГИСТРЫ МК
@
ОДИН ДИСПЕЙ НЕ РАБОТАЕТ ПО СХЕМОТЕ
@
РАЗРАБ ПЛАТЫ КОНСУЛЬТИРУЕТСЯ СО МНОЙ
@
ОН ПОЛУЧАЕТ ЗАРПЛАТУ

>>193124
Артемка, сука, тебе же Михалыч при мне дал пизды, пиши как хочешь, но чтоб работало и неебет, железо уже в производстве. Забыл как чуть не расплакался, пидор?

>>193124
Ну типа если ты с раздельными и независимыми шинами обосрался интерфейсы к дисплем написать - то с расшаренными и подавно обосрешься.

>>193162
Ты не видишь разницу между аппаратной шиной и гпио?

>>193192
Вот ты сейчас обосрался так обосрался. Этож одно и тоже лолка.

Вы меня потеряли наверно? Я тут если что. В декабре мы с вами продолжим. Анон с почты, я не пропал. Занят немного просто. Если ты не против, продолжим обсуждение в декабре.

>>195805
Нахуй надо с тобой общаться? Вот предоставишь бетку своего ЙОБА САПРа - приходи, обсудим.

>>195852
>Нахуй надо с тобой общаться?
Слышь, тебе в падлу что-ли?

Эй, сучечки, а ну ответе мне, почему я должен тратить время на поиски места на схеме под конденсаторы, думать над тем, как их покомпактнее расставить, а затем кликать мышкой, расставляя N-штук? Нахуй делоть такие кады, м?

>>198272
Правила Кирхгофа осиль и токи проводимости и смещения.

>>198382
Это тут причем, наркоман?

>>198272
Я не понял. Ты хочешь, чтоб искусственный интеллект за тебя обвязку расставлял?

>>198424
Нет, я хочу делать все сам, но избегая повторяющихся действий:

// Это микросхема. Она описана в либе производителя
YobaIC
{
...
// А это пары, которые должны быть подключены
// через последовательные кондеры
diffpair TD[4];
...
}

// Тут я ставлю эту микруху
YobaIC myIC;

// Объявляю пары, к которым будут подключены вторые контакты кондеров
diffpair tdAfterCaps[myIC.TD.length];

// Тут я нахожу подходящий тип кондера
// Если мне понадобится изменить емкость, то я просто
// поменяю цифру в одном месте, а не буду передра-
// чивать 8 кондюков
Capacitor* MyCapType = findCap(33n, CapType.X5R);

// Тут я ставлю 8 кондеров
MyCapType caps[2][tdAfterCaps.length];

// Сажаю кондеры на ноги
myIC.TD = caps = tdAfterCaps;

// Использую tdAfterCaps для дальнейшего подключения линий
...

>>198424
>Ты хочешь, чтоб искусственный интеллект за тебя обвязку расставлял?
Кстати, я тут был на семинаре по продуктам Cadence. Дак вот, у них там что-то типа того и сделано. Можно проанализировать топологию+обвязочные кондеры и построить АЧХ этой системы. Таким образом можно увидеть, куда нужно доставить кондюков по питанию. Но это не искусственный интеллект, а вполне себе формальный алгоритм.

>>198441
Ты работаешь где-нибудь по специальности?

>>198445
Ну вроде того. Не просто же так я тут бугурт на 300 постов развожу.

>>198449
>Ну вроде того.
Вроде того - это как?

>>198450
>Вроде того - это как?
Просто я работаю не на постоянке, а попроектно. Т. е. не всегда моя работа связана непосредственно с разработкой схемы девайса.

>>198451
Контора серьезная или так, махарайки пилит?

>>198461
Насчет серьезности судить не могу, но пилим с другом для них не махарайки.

>>198421
>Это тут причем, наркоман?

Да вот при этом
>Кстати, я тут был на семинаре по продуктам Cadence. Дак вот, у них там что-то типа того и сделано. Можно проанализировать топологию+обвязочные кондеры и построить АЧХ этой системы.

Охуенно они тут для АЧХ...

>>198493
>Охуенно они тут для АЧХ...
По их словам, частотный анализ топологии плейнов позволяет выявить препятствия для обратных токов высокоскоростных линий. А блокировочные кондеры между плейнами помогают избавится от резонансов на рабочих частотах. Эти кондеры какбы приклеивают АЧХ в точке где они расположены к нулевой частоте. Частотный анализ для signal integrity дохуя крутая штука, т. к. позволяет обойтись без IBIS моделей. В качестве исходных данных нужна только топология.

>>198505
Охуенное понимание вопроса.

Там разделительные конденсаторы стоят для того, чтобы постоянку отрезать.

Что ты мне за дичь загоняешь про плейны? Вы уже со своими симуляторами ДИФФПАРУ от ПЛЕЙНА не отличаете, а РАЗДЕЛИТЕЛЬНЫЕ КОНДЕНСАТОРЫ от БЛОКИРОВОЧНЫХ.

Неудивительно, что хотите, чтобы САПР был умнее вас. Хотя секрет прост - собственным образованием надо заниматься.

>>198597
>Там разделительные конденсаторы стоят для того, чтобы постоянку отрезать
Разделительные - да. Но когда я писал в своем посте >>198443 про анализ обвязки+топологии, я имел ввиду именно блокировочные кондеры между плейнами, а не разделительные вдоль сигнальных трасс. Сожалею, что резкая смена темы сбила тебя с толку.

>>198597
>Вы уже со своими симуляторами ДИФФПАРУ от ПЛЕЙНА не отличаете
Тащемта речь идет именно о плейнах. На пике выше показана амплитуда ЧХ плейна питания в разных его точках относительно земляного полигона на частоте 600 МГц. Очень жаль, что ты не знаешь о том, что не только характеристики сигнальных трасс, но и опорных слоев влияют на целостность сигналов.

>>198597
>Неудивительно, что хотите, чтобы САПР был умнее вас
Нет, я этого ни в коем случае не хочу. Тред в общем-то изначально был о проектировании схемы, а не топологии. И главный мой посыл состоит в том, что меня заебало аки индусу делать повторяющиеся действия, которые могли бы быть изящно описаны кодом, вместо схем. В качестве примера, я привел возможную альтернативу ручной расстановке одинаковых компонентов >>198441. Эта альтернатива по сути состоит всего их 5 строк кода и обладает большей гибкостью в плане замены элементов, нежели классический схемный подход. Заметь, куда и какие кондеры ставить, по прежнему выбираю я, а не кад.

>>198607
Мне как-то довелось лечить резонанс дороги на большой плате с широкополосными усилителями до 2 Ггц. Звенела длинная питающая дорога, на концах у нее были блокировки, а вдоль - нет. Она пересекала некоторые сигнальные трассы, получился слабосвязанный резонатор. Обвешал ее вдоль конденсаторами на общий - перестало звенеть. Так что да - таковой анализ может иметь смысл в некоторых случаях.
Ну либо разводчик таких высокочастотных вещей должен понимать, что дорожка = резонатор, и если она висит голая - надо ее глушить, попроси схемотехника досыпать блокировочных конденсаторов куда надо.

>>198441
Эту ебантацию в сто раз дольше писать, чем эти несчастные 16 конденсаторов копипастом натыкать.

>>198607
>меня заебало аки индусу делать повторяющиеся действия
Типа копипастить код - это не повторяющееся действие?

>>198616
>Эту ебантацию в сто раз дольше писать
Я бы поспорил. Взгляни на пик. Допустим ты соединил GOVNO и MOCHA, но внезапно понял, что тебе нужно соединять их через разделительные кондюки. Просто расставить их на линии у тебя не выйдет, т. к. кондер оче большой. Придется делать выкутасы из проводов. Также вероятно тебе придется раздвинуть GOVNO и MOCHA, ибо тебе не хватит места чтобы уместить там все кондюки и изгибы проводов. Но ведь GOVNO и MOCHA с других сторон тоже с чем-то контачат, поэтому тебе придется перелапачивать и эти связи тоже. Удачной дрочки, мой друг.

К тому же у кода есть некоторые преимущества:
1. Число строк не изменится ни для 10, ни для 100 ни для over 9000 конденсаторов.
2. Замена номинала всех конденсаторов происходит сменой одной цифры.
3. Номинал кондера можно рассчитать прямо в коде по каким-то исходным данным. Может для данного случая и проблематично придумать расчет, но в каком-то другом это может пригодиться.

>>198621
>копипастить код
Кто тебя заставляет это делать? Пиши код не копипастя. Учитывая, что в ЯП, в отличии от схемного подхода, существует разнообразие способов реюзинга, с этим не должно возникнуть проблем.

>>198615
>Так что да - таковой анализ может иметь смысл в некоторых случаях.
Более того, мне кажется, что такой анализ возможно использовать, как критерий для автороутера. Т. е. зная от пользователя необходимую пропускную способность трасс, он может оценивать качество своей работы и итеративно вносить изменения. Расстановку блокировочных конденсаторов после такого анализа тоже возможно возложить на автороутер. Тем более что у Cadence уже сделан советчик установки кондеров.

>>198645
>Допустим ты соединил GOVNO и MOCHA, но внезапно понял, что тебе нужно соединять их через разделительные кондюки.
1) Всегда можно просто обозвать нужную цепь, а потом нарисовать кондеры в любом другом месте схемы, просто посадив их на цепь с таким же именем.
2) Если, как ты говоришь, тебя заебало копипастить схемы, то как так может получиться, что тебе в скопипащенную схему надо еще что-то добавлять?

>>198650
>1
Просто напомню, что для N линий тебе придется создать 22N меток. При этом, если GOVNO и MOCHA будут расположены достаточно близко, то тебе все-равно придется их раздвигать, чтобы между ними влезло по две метки.

>2
a) Копипаст требуется не только при слизывании дизайна целиком, но и при разработке своего, т. к. в нем могут встречаться повторяющиеся элементы, как например эти разделительные конденсаторы.
b) Даже при слизывании референсного дизайна целиком, иногда приходится вносить изменения, чтобы соответствовать ТЗ.

>>198651
>22N
>2 х 2 х N
Сраная макаба.

>>198646
Обосрался. Что за тул?

>>198651
Ты реально доебал своими сраными кондерами. Не покажешь микруху, у которой к каждой из N ног надо цеплять по десять кондеров?

>>198651
Поставь себе уже на жопу разделительный кондер и разрабатывай схемы как все нормальные люди.

Кто, что может сказать за KiCad? На первый взгляд непонятный интерфейс.
>>198653
САПР DipTrace http://diptrace.com/rus/
Начертить схему, создать компонент для библиотеки, провести трассировку и даже посмотреть 3D визуализацию компонентов на плате. В бесплатной версии 300 соединений и 2 слоя, погуглив можно найти ключи на 1000 соединений и 4 слоя.

>>198655
>Не покажешь микруху, у которой к каждой из N ног надо цеплять по десять кондеров?
>к каждой из N ног
Я не говорил про 10 кондеров на каждую ногу. Я лишь сказал, что на каждую линию тебе придется прилепить по 4 метки, если ты будешь использовать меточный способ соединения кондера.

Если тебе нужна микруха с большим N, то пожалуйста. Возьмем 4 портовый свитч: https://www.broadcom.com/collateral/pb/5388-PB02-R.pdf Каждый из его портов содержит 8 линий. Итого 32 линии. Про встроенную терминацию там ничего не сказано. Поэтому, вероятно, придется собирать ебулу, как на пикрилейтед. Итого, 32 резистора и 16 конденсаторов. И все это ты будешь лепить поэлементно.

>>198656
>разрабатывай схемы как все нормальные люди
На кульмане чертить их?

>>198645
>1. Число строк не изменится ни для 10, ни для 100 ни для over 9000 конденсаторов.
Их один хуй в практических шинах никогда не бывает больше 32, которые ручками копипастятся за минуту, по 2 секунды на штуку. Нахер мне твои сферические в вакууме 9000?
>2. Замена номинала всех конденсаторов происходит сменой одной цифры.
Берешь один меняешь. Остальные удаляешь и закопипащиваешь этот один на старые места. Ровно та же одна минута. Нахуй мне твое сферическое в вакууме "ускорение" одноминутной процедуры?
>3. Номинал кондера можно рассчитать прямо в коде по каким-то исходным данным. Может для данного случая и проблематично придумать расчет, но в каком-то другом это может пригодиться.
Реальный банк элементов весьма невелик, и твое автоматическое выдрачивание ничего не ускорит. Все равно решение что ставить, у кого покупать - будет приниматься не роботом а человеком.

>>198658
Если используются однообразные модули - этот модуль можно создать отдельным блоком и подсоединять его. Orcad, который я знаю такое позволяет. Либо тупо копипастить кусок, никто не обидится.

Использовать для забивания 100 гвоздей в самые разнообразные заборы лучше рабочего с молотком, а не программиста, которому понадобится автоматический CNC-молоток, для которго он, так и быть - напишет цикл от 0 до 99. Но каждый раз этот цикл нужно будет патчить для нового забора, и гораздо дольше, чем рабочий просто и бесхитростно заколотит эти гвозди.

>>198660
>в практических шинах никогда не бывает больше 32
128 битная шина данных для видеопамяти и 16 портовый 1000base-t свитч сикают тебе на лицо.

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

>>198660
>автоматическое выдрачивание ничего не ускорит
Ускорит. Изменяя один параметр, ты меняешь сразу все элементы. Не нужно пересчитывать компонент ручками на калькуляторе, следовательно можно избежать потенциальной человеческой ошибки.

>>198660
>решение что ставить, у кого покупать - будет приниматься не роботом а человеком
Поэтому рассчитанный элемент не должен быть единственным. Функция поиска элемента должна возвращать целый набор компонентов удовлетворяющих условиям поиска. Выбор конкретного элемента будет осуществлен человеком, но уже на следующем этапе после разработки схемы. Причем выбирать он будет среди ограниченного списка компонентов, что упростит задачу.

>>198661
>Использовать для забивания 100 гвоздей в самые разнообразные заборы лучше рабочего с молотком, а не программиста, которому понадобится автоматический CNC-молоток, для которго он, так и быть - напишет цикл от 0 до 99. Но каждый раз этот цикл нужно будет патчить для нового забора, и гораздо дольше, чем рабочий просто и бесхитростно заколотит эти гвозди.
Приведи живой пример из электроники с ~100 компонентами, который по твоему легче заиндусить, чем алгоритмизировать. Я в свою очередь попробую опровергнуть его, приведя пример кода для изящного решения задачи.

>>198661
>этот модуль можно создать отдельным блоком и подсоединять его
Ты про разбивание микросхемы на одинаковые части? Копипаста это все-равно избежать не позволяет.

РАСПЕЧАТАЛ ДЛЯ ЛУТА ШАБЛОН
@
ЗАБЫЛ ОТЗЕРКАЛИТЬ
@
ОТЗЕРКАЛИЛ
@
ЗАБЫЛ УБРАТЬ СЛОЙ МАРКИРОВКИ
@
РАСПЕЧАТАЛ И ПЕРЕНЁС
@
РЕТУШИРУЕШЬ МАРКЕРОМ И СКАЛЬПЕЛЕМ ОТПЕЧАТОК

>>198665
Разработка любого электронного устройства из 100 элементов - и есть такой пример.

>>198664
>В условиях, когда их надо доставить туда, где под них не запасено место, ты будешь дрочить их час и больше
Твоя "ебала i++" тоже не расставит их так, чтоб было приятно глазу. Скорей раскидает по всей странице и подключит километровыми линиями.
Удобно для глаза расставляет только сам человек.
>Изменяя один параметр, ты меняешь сразу все элементы.
В твоем сферическом мирке в вакууме. В реальном же это нужно чуть реже чем никогда.
>Функция поиска элемента должна возвращать целый набор компонентов удовлетворяющих условиям поиска.
Вот если бы ты такой продукт написал, способный в поиск по всем маузерам-диджикеям-производителям, то тебе миллион разработчиков спасибо сказали бы. Но ты же все опять постараешься свести, что элементы должны быть сферические и у них должно быть три параметра - диаметр, цвет и цена, потому что тебе так удобней, ибо ты программист, и реальный мир - это слишком сложно, там конденсаторы надо ручками расставлять.
Блять - да во всей электронике, который ты пользуешься, конденсаторы расставлены ручками. Хуже от этого она не стала, и сейчас и без твоих i++ улучшайзеров обновляется гораздо чаще, чем нормальному человеку хотелось бы.

>>198666
Я про функциональные модули.
Копипаст - самый удобный инструмент. Чем искать в списках элемент (резистор, например) - его гораздо быстрее скопипастить с соседнего, подправив номинал и футпринт, если надо.

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

Так что ещё раз, занимайтесь собственным образованием.

>>198646
И? радуйся, что CAD умнее тебя. Вообще-то хорошее правило проектирования - не соединять более 3 линий в одной точке. А если уж очень надо - то под разными углами, чтобы не было похоже не пересечение при беглом взгляде.

>>198726
>Ребята, вот бы было здорово переложить повторяющиеся операции на плечи компьютера.
>РЯ-ЯЯЯ-ААА! НИНУЖНО!!! ТЫ ВСЕ-РАВНО СОСНЕШЬ, ЕСЛИ У ТЕБЯ В СХЕМЕ НЕ БУДЕТ ПОВТОРЯЮЩИХСЯ ЭЛЕМЕНТОВ!!!
Вы тут все в /ra/ такие отбитые? Да, в общем случае, выигрыша от цикличной обработки не будет как впрочем и проигрыша. Но ты открой для начала любой мало-мальски сложный цифровой дизайн и сам убедись, что он чуть менее чем полностью состоит из шин с одинаковой обвязкой на каждом проводе, дублирующихся интерфейсов и одинаковых кондеров на каждой ноге питания. Все это можно было бы неслабо упростить, имея надлежащий инструмент.

>>198728
>Скорей раскидает по всей странице и подключит километровыми линиями
Если ты до сих пор не понял, то я вовсе хочу отказаться от схемы. Т. е. вообще. Чтобы схемобляди соснули у кодобогов. Хотя в реале придется под вас все-равно подстраиваться и делать схемогенератор. Дак вот, если его правильно сделать, он расположит кондеры массивом. Т. е. это будет элемент нарисованный жирной линией, означающей вектор компонентов. А рядом будет стоять цифра, указывающая количество элементов в векторе.

>>198728
>В реальном же это нужно чуть реже чем никогда
>Иван, ты неправильно посчитал резисторы для светодиодной линейки. Пересчитай и замени все 50 штук
>Иван, вот эти 50 конденсаторов от УралВагонЗавода на питании ПЛИС оказались плохого качества. Замени их все на Мурату.
>Иваааан, мы тут провели измерения и выяснили, что 50-омные трассы для нас не подходят. Замени-ка терминирующие резисторы на всех шинах на 40-омные.

>>198728
>во всей электронике, который ты пользуешься, конденсаторы расставлены ручками
Потому что депелоперские конторы дохуя богатые и могу позволить себе покупать ЙобаКады с окошечками и визардиками и нанимать штат индусов. Но не все конторы такие богатые, и не все разработчики хотят быть индусами.

>>198728
>реальный мир - это слишком сложно, там конденсаторы надо ручками расставлять
Только в вашем схемоблядском мирке их ручками ставят. Не вижу смысла делать вручную то, что может сделать компьютер.

>>198728
> раскидает по всей странице
Выкинь этот термин из головы. Не будет никаких страниц. Будут модули, разбиение на которые будет происходить по функциональности, а не из соображений удобства печати на принтере.

>>198729
>Чем искать в списках элемент (резистор, например) - его гораздо быстрее скопипастить с соседнего
Но первый-то резистор ты все-равно будешь искать в либе и только потом будешь копировать его. Дак вот, если ты обратишься к моему последнему куску кода, то увидишь, что там происходит то же самое. Элемент один раз находится, а дальше расставляется везде где надо. Причем, если изменить условия поиска и перекомпилировать дизайн, то элемент будет заменен во всех местах, где он был использован. Тебе же придется заново находить элемент и вручную его раскопировать.

>>198754
>Я всегда сначала рассчитываю
>Иваааан, тут один студент разделительные кондеры не поставил. Мы его уже пидорнули из-за кризиса, так что подтирать за ним тебе

>>198778
>Если ты до сих пор не понял, то я вовсе хочу отказаться от схемы
Наркоман.

>Чтобы схемобляди соснули у кодобогов.
Идиотизм.

>>198821
>Идиотизм.
Скорее я просто погорячился. Но максимум что должно присутствовать - это схемовьювер скомпилированного дизайна.

>>198821
>Наркоман.
Не правда. Я привел массу недостатков схемы. При этом ее единственное достоинство - наглядность, тоже может быть подвергнуто сомнению.

>>198836
>При этом ее единственное достоинство - наглядность, тоже может быть подвергнуто сомнению.
Не может.

Ты перегибаешь палку.

>>198776
>Все это можно было бы неслабо упростить, имея надлежащий инструмент.
Тогда поясни, почему до сих пор этого инструмента нет?

>>198850
>почему до сих пор этого инструмента нет?
Среднестатистический разработчик избалован визардиками и не может в код.

>>198645
гражданка вы обязонны страдать
ибо вам стоит только рассуждать
то чего вы не щнаеите в купе о ваших мечтах

>>198840
>Ко-ко-ко, схема - верх наглядности
>Пок-пок-пок, только человек знает, как наглядно расставить компоненты

>>198853
>то чего вы не щнаеите в купе о ваших мечтах
Человеческим языком пожалуйста.

>>198854
Кривляешься как клоун. Некрасиво.

>>198857
Я же не просто кривляюсь, а привожу пример, после которого как-бы иронизирую. Ты как первый раз тут.

>>198852
>Среднестатистический разработчик избалован визардиками и не может в код.
А ты, видимо, не можешь в визардики?

>>198859
>а привожу пример, после которого как-бы иронизирую
Типа если то же самое оформить кодом, то будет красиво? Типа люди говнокодить не умеют?

>>198875
>Типа если то же самое оформить кодом, то будет красиво? Типа люди говнокодить не умеют?
Кажется ты говорил, что схема понятнее кода, а теперь скатился к утверждению о том, что все зависит от человека. Но раз сам инструмент не влияет на наглядность, то почему не использовать более мощный из них? И да, я считаю, что кодом эту схему можно было бы описать понятнее.

>>198875
>А ты, видимо, не можешь в визардики?
Могу. В них и ребенок сможет. Просто они обладают недостатками.

>>198859
>Я же не просто кривляюсь
>Ты как первый раз тут
Просто или непросто. Дела не меняет. Ты или готов к добросовестному диалогу, или юродивый клоун.

>как-бы иронизирую
Ирония как-бы неуместна.
Отрицание важности и необходимости визуального представления информации нелепо, и даже безумно.
Зачем рисовать графики когда можно писать формулы?
Зачем рисовать картины, когда можно описывать изображенную на них сцену словами?
Зачем дурацкий графический интерфейс пользователя в ОС, когда все в консоли можно командами делать?
Зачем графические игры когда все то-же самое можно в виде текстового квеста делать?
>Ололо ниосиляторы немогут в кодинг тупые художники и прочие визуалыговнолары поккудахпокпок1111111
Сходи к врачу.

>>198936
>Зачем рисовать графики когда можно писать формулы?
Ты же не станешь рисовать график гамма-функции руками на листочке, правильно? Скорее всего ты дашь на вход матлабу выражение и получишь результат, чтобы его проанализировать. Почему не делать то же самое со сложной схемой?

>>198936
>Зачем дурацкий графический интерфейс пользователя в ОС, когда все в консоли можно командами делать?
Смотря что делать. В некоторых случаях командный интерфейс дает пососать графическому. К примеру, тебе нужно переименовать пак с MP3 файлами в соответствии с ID3 тегами. Скриптогосподин потратит на код полчаса, а потом за три минуты переименует сто гигов музыки. При этом, окошкоблядь не справиться с задачей и за неделю.

>>198936
>Зачем рисовать картины, когда можно описывать изображенную на них сцену словами?
У меня для тебя плохие новости https://en.wikipedia.org/wiki/Algorithmic_art

>>198936
>Ты или готов к добросовестному диалогу
Конечно готов. Я дал тебе выше пример говносхемы от Nvidia. Ты утверждаешь, что схема - это хороший способ визуализации. Прокомментируй, в таком случае, приведенный пример.

>>198947
Я утверждаю, что схема это способ визуального представления. Ваш К.О.

И что визуальное представление является важнейшим способом представления информации.
И что оно незаменимо.
Эти мои утверждения есть отражение объективной реальности, обусловленной особенностями устройства человеческого мозга и органов чувств.
И я утверждаю, что ставить под сомнение, и открыто отрицать, эти очевидные факты, есть проявление крайней степени невежества, и даже психического расстройства. Троллинг и клоунада.

Нет. Ты неготов к добросовестному диалогу.

>>198966
>Опровергаешь примеры оппонента с помощью конкретных контрпримеров
>Надеешься услышать ответные контрпримеры, либо же согласие со своей точкой зрения
>В ответ слышишь абстрактные речи и обвинения в невежестве с переходом на личности
Дискуссия уровня /ra/.

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

>>198970
1) Я не твой оппонент. Я с тобой ни о чем не спорю.
2) Никаких "абстрактных речей". Я говорю о вещах очень конкретных очень конкретные вещи.
3) Речи не шло о недостатках. Ты писал:
>Но максимум что должно присутствовать - это схемовьювер скомпилированного дизайна.
>При этом ее единственное достоинство - наглядность, тоже может быть подвергнуто сомнению.
Я указал тебе на абсурдной этих заявлений.
После чего ты изошелся на кривлянья юродство и троллинг.
Я развернуто объяснил в чем именно заключается абсурдность и показал, что ты "споришь" со здравым смыслом.
В ответ ты начал втирать мне какую-то дичь - "примеры оппонента конкретные примеры согласие, абстрактные речи, обвинения".
В духе - "Че ты такой ученый давай на пальцах показывай, че ты не хочешь на мой троллинг отвечать, я тебе нахимил ты давай мне в ответ хами, а то где твои контрпримеры?".


>и все-таки вернемся конкретно к электрическим схемам и недостаткам проектирования графическим способом в случае их громоздкости
Возвращайся. Я к твоим отклонениям от темы не причем.
Раз уж о том зашла речь:
1) Недостатки имеет не "графический способ редактирования" вообще, а конкретные его реализации, не позволяющие автоматизировать однотипные действия.
2) В реальном мире вещей без недостатков не существует вообще. Все имеет какие-то побочные эффекты.

>>198976
>Недостатки имеет не "графический способ редактирования" вообще, а конкретные его реализации
Отсутствие удачных с точки зрения возможности ухода от рутины реализаций графических способов проектирования наталкивает меня на мысль, что ущербностью обладает непосредственно сам способ, а не его реализации. И действительно, как по твоему в редактор электрических схем можно заложить возможность написания алгоритмов?

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

>>198976
>Я развернуто объяснил в чем именно заключается абсурдность
Ты лишь указал, что по твоему визуальный способ проектирования более удобен. Однако, большинство математиков, программистов и FPGA разработчиков скорее всего с тобой не согласятся.

>>198976
>В ответ ты начал втирать мне какую-то дичь
Не правда. Я лишь указал на твое игнорирование моих примеров с ОС, построением графиков и рисованием картин, которые показывают, что в некоторых случаях описательный подход дает пососать графическому.

>>198905
>почему не использовать более мощный из них?
Потому что его нету. Где бета версия?

>>198980
>программистов
Тех самых, которые UML диаграммы придумали?

>>198981
>Потому что его нету.
Значит надо делать.

>>198982
>Тех самых, которые UML диаграммы придумали?
Их самых. UML, да будет тебе известно, нужен лишь для визуализации на высоком уровне. Это аналог структурной схемы из электроники. Тут действительно, визуальный метод может пригодится. Стоит отметить, что избыточности в виде повторяющихся элементов в отличии от принципиальной схемы в электронике в UML не бывает.

>>198979
>Отсутствие удачных с точки зрения возможности ухода от рутины реализаций графических способов проектирования наталкивает меня на мысль, что ущербностью обладает непосредственно сам способ, а не его реализации.
У отсутствия более удобных реализаций есть свои очень конкретные причины. Которые рассматривались где-то выше в этом треде.
Твои же выводы об "ущербности самого способа", абсурдны, что показано немного выше.

>И действительно, как по твоему в редактор электрических схем можно заложить возможность написания алгоритмов?
Алгоритмов для чего? И чего?
В чем проблема заложить такую возможность?
Мне кажется, или выше в обсуждении приводили пример наличия такой возможности в некоторых кадах?

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

>полностью компенсируется дальнейшим уходом от рутинной работы
Чтобы уйти от рутинной работы, нужно не в текстовый вид кад переводить, а устранить очень конкретные объективные причины, которые являются следствием множества разных противоречий в индустрии.

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

>по твоему
Я выражаю свою точку зрения. К.О.

>Однако, большинство математиков, программистов и FPGA разработчиков скорее всего с тобой не согласятся.
Плохо для них тогда.

>>198980
>Не правда.
Правда.

>Я лишь указал что описательный подход дает пососать
Мысль дурака дискретна.
http://asterrot.livejournal.com/296040.html
Чтение или слушание для совшизофреника сводится к разбивке сказанного на "чёрное" и "белое":
- это за наших;
- это против наших;
- за наших;
- против наших;
- за наших;
- против наших.
И всё. "За" и "против", весь анализ. И, если "против" - "дать гневную отповедь наймиту".

>>198986
>Их самых. UML, да будет тебе известно, нужен лишь для визуализации на высоком уровне.
>Лишь
Ох.
>Это аналог структурной схемы из электроники.
Нет. Не аналог.
Ты сравниваешь хуй с пальцем.

>избыточности в виде повторяющихся элементов в отличии от принципиальной схемы в электронике в UML не бывает.
Ты абсолютно не понимаешь сути программирования и всяких UML.
Не знаю что у тебя за бекграунд, но познания ты демонстрируешь дилетантские.
Сколь нибудь крупному программированию предшествует процесс создания огромного количества диаграмм схем и графиков.

>Значит надо делать.
С таким подходом ничего нельзя толкового сделать.

>>198994
>Алгоритмов для чего? И чего?
Алгоритмов установки элементов в "схему" и расчета их номиналов по некоторым исходным данным, например. Причем я говорю не о закладывании туда каких-то заранее определенных алгоритмов, а о возможности самому их писать на нормальном ЯП.

>>198994
>В чем проблема заложить такую возможность?
Как ты себе это представляешь?

>>198994
>Это не главный недостаток.
В таком случае, озвучь тот, который ты считаешь главным.

>>198994
> устранить очень конкретные объективные причины
Укажи их, если они тебе известны.

>>198994
>Я лишь указал что описательный подход дает пососать
>Мысль дурака дискретна
Воу воу, полегче с выдергиванием слов из контекста, паринь. Я же специально написал:
>в некоторых случаях описательный подход дает пососать графическому

>>>Лишь
>Ох.
Лол, как ты на UML сортировку пузырьком, например, досконально описывать будешь, прогромизд?

>Ты абсолютно не понимаешь сути программирования и всяких UML
Расскажи мне скорее, а я покажу твои замечательные истории анонам из /pr/ на потеху.

>>198998
>Лол, как ты на UML сортировку пузырьком, например, досконально описывать будешь
Для этого есть блок схемы.

>прогромизд
>Расскажи мне скорее, а я покажу твои замечательные истории анонам из /pr/ на потеху
Кривляться перед своими родителями будешь.
Разговор окончен.

>>198947
Как раз визуально я график гамма-функции вспомню первым, связь с факториалом - вторым, а уж саму формулу без гугла никак не вспомню.
мимо учил матан 5 лет назад

Я одного не могу понять, чего опу не хватает? Он не знает о верилоге для описания плисов и процессорных ядер? Или знает, и со своим вериложным уставом лезет в аналог?
Если второе, то да будет тебе известно, что электрические схемы и сосредоточенные детальки - это охуеть какое упрощение само по себе, что за тебя уравнения Максвелла с хитровыебанными начальными и краевыми условиями уже упростили, разжевали, и свели к законам Ома.
И проблемы в реальных аналоговых, силовых и смешанносигнальных задачах, да даже в якобы тупых блокировочных конденсаторах, они не в копипасте и нужности параметризации, а как раз наоборот. Желаю опу-наркоману раз поебаться с кондерами с другим esr, или феррит бедами на 100 ом, но с не указанными и разными резонансными частотами, и всю эту кодерскую дурь как рукой снимет. Вангуя встречный вопрос, отвечу: параметры деталей тебе придется замерять реальные в любом случае, ибо мудак-производитель забудет, мудак-начальник заставит купить на замену китайчатину с Али, или еще какая хуйня вмешается, и пустит все красивые расчеты по пизде.

>>199002
>визуально я график гамма-функции вспомню первым
Дак я ж не против, няша. Мякота в том, что визуализацию эту строили не ручками, а с использованием коплюктера по известному выражению.

>>199008
>Он не знает о верилоге для описания плисов и процессорных ядер?
Знает. И умеет. И считает верилог говном ибо есть, но плохо поддерживается кадами, околобожественный СистемВерилог.

>>199008
>Или знает, и со своим вериложным уставом лезет в аналог?
Почти. Суть в том, что в верилоге есть фича в виде так называемого поведенческого описания. Суть его в том, что прогромизд описывает функциональность, а компилятор сам решает, как ее реализовать. Дак вот, я прекрасно понимаю, что в аналоге такую фичу замутить крайне проблематично. Поэтому хочу я всего лишь программировать сборку схемы из готовых компонентов. Главная предпосылка - громоздкость современных схем из-за наличия огромного числа повторяющихся элементов.

>>199008
>еще какая хуйня вмешается, и пустит все красивые расчеты по пизде
Ни кто и не заставляет тебя писать расчет для всех компонентов дизайна. Считай то, что гарантировано будет работать. Тот же делитель для ОС стабилизатора под заданное напряжение можно подсчитать. Понадобился такой же источник на другое напряжение? Просто ставишь тот же схемный узел, но с другим параметром, задающим напряжение. Такое упрощение освободит тебе время для действительно важных и не алгоритмизируемых моментов дизайна.

>>199009
>Поэтому хочу я всего лишь программировать сборку схемы из готовых компонентов. Главная предпосылка - громоздкость современных схем из-за наличия огромного числа повторяющихся элементов.
Может тебе еще к архитекторам наведаться? Типа нахер они чертежи рисуют, когда можно здания описывать кодом.

>>199028
>Может тебе еще к архитекторам наведаться? Типа нахер они чертежи рисуют, когда можно здания описывать кодом.
Ти непонимаешь. Зрение нинужно!11111 Картинки для тупоги бидла и ниосиляторов11111

>>199028
В архитектуре важен именно внешний вид. В электрической схеме важны только соединения. Размещение деталей на схеме и внешний вид линий соединения - вещи второстепенные, на которые не стоит тратить время.

>>199097
>В архитектуре важен именно внешний вид.
Ну схемы трубопроводов-то точно не нужны?

>>199104
>схемы трубопроводов-то
Это тоже "внешний вид" в том смысле, что их пространственная конфигурация имеет значение. В отличии от пространственной конфигурации проводов и элементов в эл. схеме.

>>199117
Да не пизди. Вместо пикрелейтед лучше кода накидали бы.

>>199117
>В отличии от пространственной конфигурации проводов и элементов в эл. схеме.
Заврался ты окончательно и бесповоротно.
Нельзя же так. Нужно знать когда остановится.

>>199121
>>В отличии от пространственной конфигурации проводов и элементов в эл. схеме.
>Заврался ты окончательно и бесповоротно.
В чем, по твоему, ошибка в этом утверждении? Заметь, речь идет только о пространственной конфигурации элементов и проводников на принципиальной схеме, но не о конфигурации самих соединений и не о расположении проводников и элементов на печатной плате.

>>199125
>речь идет только о пространственной конфигурации элементов и проводников на принципиальной схеме, но не о конфигурации самих соединений и не о расположении проводников и элементов на печатной плате
Так хули. Пусть архитекторы запилят компелятор, который будет трубопроводы по дому раскидывать. Тогда точно схемы не нужны.

>>199127
Зачем ты мне говоришь про трубы, когда речь идет про электрическую принципиальную схему? Это такой новый способ троллинга?

>>199130
>когда речь идет про
Речь идет про то, что нахуй графическое представление - надо ебашить код. При этом все аспекты, связанные со схемным проектированием ты умножаешь на ноль, мол они нахуй не нужны.

>>199132
Не прояснишь, какие важные для конечного результата аспекты программный способ умножает на ноль?

>>199137
Способ восприятия и представления информации человеком.
Всего-то навсего.
Схема для человека удобный способ. Чрезвычайно.
А вот текст - неочень.

Для компьютера наоборот.

Харош уже со здравым смыслом спорить, тебе лет сколько?

>>199137
>Не прояснишь, какие важные для конечного результата аспекты программный способ умножает на ноль?
И вообще ты несвязный бред городишь.
>важные для конечного результата
Что за результат такой. Наркоман.
Конечный результат када для рисования схем это блядь нарисованная схема.
Хватит уже галюцинировать. И выдумывать всякую ерунду находу.

>>199175
>Конечный результат када для рисования схем это блядь нарисованная схема.
Ты не прав. Конечный результат для схемного када - это нетлист, который потом будет использован для разработки PCB дизайна. Схема же - лишь небольшой бонус, внешний вид которого никак не влияет на характеристики разработанного в итоге устройства.

>>199174
>Схема для человека удобный способ.
>А вот текст - неочень.
Приведу контрпример. Рассмотрим два случая:
1. Схема на пикрилейтед.
2. Схема описанная текстом: "шесть параллельно соединенных резисторов по 36 Ом каждый".
Для какого варианта ты быстрее найдешь общее сопротивление?

>>199186
>Конечный результат для схемного када - это нетлист
Тебе из погреба виднее. Про ЕСКД ты, видимо, не слышал.

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

>>199186
>Ты не прав. Конечный результат для схемного када - это нетлист, который потом будет использован для разработки PCB дизайна. Схема же - лишь небольшой бонус, внешний вид которого никак не влияет на характеристики разработанного в итоге устройства.
Если схему разрабатывает, разводит, настраивает, и паяет, компьютер, то да.
Если где-то участвует человек, графическая схема необходима.


>Для какого варианта ты быстрее найдешь общее сопротивление?
Разработка электрической схемы не сводится к поиску общего сопротивления в приведенном тобою нелепом примере.

И да, ты тупой баран. Прозреваю тебе 20 лет, и тебе кажется, что ты уже все на свете знаешь и понимаешь.
Досвидания.

>>199194
>Про ЕСКД ты, видимо, не слышал.
Слышал конечно. Вот только я не видел, чтобы какие-либо заморские компании его соблюдали. Я тебе больше скажу, они вообще никакие внешние по отношению к организации стандарты не соблюдают - в каждой новой пдфке новые охуительные обозначения и размазня из элементов наезжающих на соединительные линии. Причем такое встречается у даже у крупных контор типа Nvidia. Это конечно плохо, но еcли от тебя требуют соблюдать ЕСКД просто чтобы соответствовать, то это ничуть не лучше. Это я к тому, что нет схемы - нет проблем с соблюдением стандартов.

>>199194
>Может ты словами опишешь схему, которая у тебя на пике?
Конечно: "шесть параллельно соединенных резисторов по 12 Ом каждый". Надеюсь мой посыл достаточно очевиден :3.