Мысль об инструментах разработки электрических схем

Задали мне сегодня неожиданный вопрос — почему электрические схемы до сих пор рисуют в графическом виде? Хотя, казалось бы, схемы всяких микрух давно уже пишут текстом — это ведь гораздо эффективнее. Я сперва начал задвигать про то, что графика привычнее и понятнее типичному разработчику и ещё что-то такое, а потом задумался — а действительно, почему не текст? Привычка — дело наживное, понятность — вопрос спорный. Зато текст удобнее редактировать, он гибче, его легко класть под контроль версий.

По сути, для чего вообще нужна электрическая схема устройства (ну если не брать в расчёт страшные слова типа «ЕСКД» и «нормоконтроль»)?
  1. Выдача перечная компонентов и нетлиста трассировщику
  2. Выдача перечная компонентов, нетлиста и контрольных точек/внешних воздействий симулятору
  3. Облегчение понимания за что отвечает конкретный элемент на плате
Первые две задачи вообще не требуют графики, текст тут сам собой напрашивается (ну нафига для этого задавать расположение компонентов и пути прокладывания связей?). С третьей чуть сложнее, но в целом, если язык описания разработан правильно и принять хороший кодинг-стиль с добавлением комментариев где надо, то оно может быть ещё и понятнее, чем схема. Опять-таки, диффать удобнее. А если ещё и прикрутить что-то типа Doxygen, то вообще блеск будет!
А графику, собственно, комп и сам может сгенерить из описания — раскидать кучку прямоугольников на холсте и линии между ними задача давно решённая (например графвиз на вход принимает простой список узлов и рёбер графа и сам рисует красивую картинку). Ещё один один сопутствующий бонус — такой рендерер можно прикрутить к чему угодно. Например, сейчас на работе продвигаю использование redmine в качестве трекера и базы знаний. К редмайну у меня прикручен тот самый графвиз, так что я могу прямо в wiki-странице набросать любой граф и сразу показать коллегам для обсуждения, а вот набросать схему проблема, так что рендерер схем пришёлся бы очень кстати =).

Так вот, к чему это я? Может кто в курсе, есть ли более-менее серьёзные ECAD (уровня, хотя бы, KiCAD), практикующие описание схемы в HDL? (вариант править руками исходник схемы того-же кикада не предлагать, интересна именно штатная возможность)
  • -4
  • 06 февраля 2013, 23:00
  • Alatar

Комментарии (198)

RSS свернуть / развернуть
Интересно было бы еще посмотреть как с такой текстовой схемы будет делаться разводка печатки «текстовая»…
0
  • avatar
  • kalik
  • 06 февраля 2013, 23:07
Хм… А почему она должна чем-то отличаться от обычно разводки? Разводка печатной платы — это, по сути, чертёж. Я пока не предлагаю выполнять чертежи в текстовом виде, так как там критичны кучи цифирок (координаты, размеры и тд.). Я говорю лишь про создание схемы, где всякие эти координаты — эта побочная информация, совершенно не нужная для достижения требуемого результата. Впрочем, в студенчестве делал и фрагменты чертежей на автолиспе и мне это вполне нравилось…
0
Я пока не предлагаю выполнять чертежи в текстовом виде, так как там критичны кучи цифирок (координаты, размеры и тд.). Я говорю лишь про создание схемы, где всякие эти координаты — эта побочная информация, совершенно не нужная для достижения требуемого результата.
Сразу видно человека, далекого от серьезной электроники (сложнее, чем 1-2 микросхемы, разведенные сразу в Спринте без принципиальной схемы)…

Попробуйте интереса ради описать словами хотя бы Центральный Контроллер или Контроллер Башни моего робота (есть на форуме).

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

Так что ваша тема носит характер пустой болтовни среди пацанов. Типа, «А вот если бы у вашей бабушки вдруг вырос член, стали бы вы звать ее дедушкой?»

Хотя, некоторые из особо ленивых, уже не рисуют схемы полностью, а просто показывают на рисунке отдельные детали, проставляя индексы на выводах, что с хем соединять. И потом ползай кругами по всей схеме, отыскивая одноименные связи. Пока проследил одно соединение, предыдущее — уже забыл…

Когда полностью нарисованную схему легко окинуть одним взглядом, и сразу все видно, куда что идет.
Вместо того, чтобы читать ваш роман с описаниями.
+7
Так что ваша тема носит характер пустой болтовни среди пацанов. Типа, «А вот если бы у вашей бабушки вдруг вырос член, стали бы вы звать ее дедушкой?»
эх, не было-бы такой категоричности…
Хотя, некоторые из особо ленивых, уже не рисуют схемы полностью, а просто показывают на рисунке отдельные детали, проставляя индексы на выводах, что с хем соединять. И потом ползай кругами по всей схеме, отыскивая одноименные связи. Пока проследил одно соединение, предыдущее — уже забыл…
правильные кады умеют подсвечивать одноименные цепи. но вам, конечно, оно просто не нужно.
-1
SWG говорит о зрительной памяти. проставление индексов (NetName) действительно следует использовать, когда нет другой возможности. Представлять в понятном с первого взгляда виде схемы своего рода искусство.
+1
угу. как смотришь на это хитросплетение линий — хочется застрелиться.
-2
Я же сказал «искусство» — не все им обладают. И, уж, совсем им не обладают те, кто подсел на рваные цепи.
+2
я там чуть ниже про это высказался.
вкратце: что удобно для восприятия не удобно в работе.
0
правильные кады умеют подсвечивать одноименные цепи. но вам, конечно, оно просто не нужно.
Что, даже на PNG'шке в статье?
+1
угу. и даже в чб на картинке в пятой копии из журнала рыгдио.
-3
Хотя, некоторые из особо ленивых, уже не рисуют схемы полностью, а просто показывают на рисунке отдельные детали, проставляя индексы на выводах, что с хем соединять. И потом ползай кругами по всей схеме, отыскивая одноименные связи. Пока проследил одно соединение, предыдущее — уже забыл…
О да. И добро бы схема уровня схемы PS2 — там на одном листе не особо уместишься, да и то индексы только для межлистовых соединений, так ведь бывает — вся схема на А4 умещается, а поименованных стрелочек больше чем нормальных соединений.
+2
а впротивном случае эти самые линии займут больше места.
0
Их, по крайней мере, отследить проще. Плюс есть шины. Тоже не сахар, но лучше. А с этими метками — пока всю схему сантиметр за сантиметром не просмотришь нельзя быть уверенным, что все связи для данной линии отследил.
0
шины === метки цепи. только не любая может приходить, а одна из 100500. от этого не легче.
а линии отследить ничуть не проще чем метки.
имхо, SWGшные схемы смотрятся ничуть не легче чем с метками. а в нагромождении линий еще проще затеряться.
имхо, как описавший некоторое количество вот таких портянок «в полосочку и сеточку» на верилоге.
0
Не совсем равно. Метка может валяться где угодно, шину же по крайней мере можно отследить. Хотя бывают клинические случаи, когда все детальки подключены всеми выводами к одной и той же шине.
+1
Хотя бывают клинические случаи, когда все детальки подключены всеми выводами к одной и той же шине.
Стоит заметить, несмотря на то, что в схеме была только пара небольших микросхем и с десяток пассивных деталек, автора убить хотелось. Очень хотелось. Да и схему я до конца так и не дочитал.
+1
ну, совсем клинику мы ведь не рассматриваем, правда?
0
ну, совсем клинику мы ведь не рассматриваем, правда?
Ну, собственно, это аргумент в мою пользу ;)
Нет, поименованные цепи тоже полезны, но применять их надо очень аккуратно. Еще аккуратней, чем шины.
+1
ну, собственно, это аргумент в обе стороны. и пару корпусов с горстью россыпи можно так художественно обвести, что захочется что-то очень тяжелое уронить аффтару на голову.
0
И все же. Схему Вы создаете не только для себя любимого и не факт, что у всех коллег по цеху редакторы с подсветкой. И те, кто будет «читать» схему в печатном виде тоже лишается подсветки. Загромождение решается введением шин, которые дадут рыскать по всему листу в поисках одинаковых имен у рваных цепей.
+2
* которые не дадут
0
"коллеги по цеху" как правило пользуются тем-же инструментом. соответственно все фичи есть.
И те, кто будет «читать» схему в печатном виде
ОЙ! А такие еще остались??! =0
-1
ОЙ! А такие еще остались??! =0
Ну, если ты пишешь статью… Впрочем, о чем это я)
+2
не надо о статьях. лениввоооо… ;)
впрочем, к статье всегда можно и приложить схему. кому надо — скачают, поставят, и посмотрят. понятно, если оно чуть сложнее пары корпусов.
-2
впрочем, к статье всегда можно и приложить схему. кому надо — скачают, поставят, и посмотрят
Это тоже издевательство)
+2
сказать кому это высказать? ;)
-1
Ну скажи)
0
всем выкладывающим в орле/диптрейсе/спринте а не любимом мной альтиуме.
:)))
-2
особенно учитывая, что у них нет экспорта-импорта.
-2
Не совсем равно. Метка может валяться где угодно, шину же по крайней мере можно отследить.
угу. а если шин несколько? просто еще один уровень организации, не решающий проблемы.
-2
«Несколько шин» — это и есть то самое, что делает их лучше. Если что-то ушло в шину — значит оно выйдет из этой же шины, а не в любой точке схемы.
+3
ой, не надо.
возьми (почти) любой совеццкий спек выше пенька128, скажем. порой в таких местах находишь сигнал, что хочется что-нить взять и уронить на голову разрабу.
и я еще не говорю о «нормальной» практике где-нить среди картинки указать типа 14:DD156…
-2
и я еще не говорю о «нормальной» практике где-нить среди картинки указать типа 14:DD156…
Типичная метка, за которые ты ратуешь. Искать даже проще — знаешь хотя бы, что оно выйдет на 14-й ножке DD156 и больше нигде, остается только найти DD156.
возьми (почти) любой совеццкий спек выше пенька128, скажем. порой в таких местах находишь сигнал, что хочется что-нить взять и уронить на голову разрабу.
Не видел. Но запутать можно что угодно.
+1
Типичная метка, за которые ты ратуешь. Искать даже проще — знаешь хотя бы, что оно выйдет на 14-й ножке DD156 и больше нигде, остается только найти DD156.
угу. осталось только найти этот DD156… при условии, что это какая-нить ЛН2 (напомню: 6 инверторов), и она раскидана по всем полутора десятков листов…
и это все среди линий, шин, осмысленных обозначений, а на том выводе еще не обратная ссылка, а какое-нить имя. хочется просто застрелиться.
-2
угу. осталось только найти этот DD156… при условии, что это какая-нить ЛН2 (напомню: 6 инверторов), и она раскидана по всем полутора десятков листов…
Ну, к метке все это точно так же относится.
+1
конечно относится. вот только пока изучаешь, привыкаешь к определенному стилю. а тут НА ТЕБЕ такой сюрприз.
-1
имхо, SWGшные схемы смотрятся ничуть не легче чем с метками. а в нагромождении линий еще проще затеряться.
Когда разбираешься по картинке, линию хоть отследить можно. Меток же в таком случае будет столько… И для отслеживания любой линии их все нужно прочитать.
+1
что линию отследить, что метку найти — монопенисуально.
еще смотря что проще.
схему МОЖНО только одними линиями и читабельную нарисовать. вот только В РАБОТЕ оно будет ой как не удобно. особенно если туда-сюда перекидываешь сигналы в зависимости от удобства разводки.
-2
что линию отследить, что метку найти — монопенисуально.
Нет. Вдоль линии можно провести взглядом. Метку же приходится искать на листе, причем методом линейного поиска. Причем найдя — поиск придется продолжить. Ведь требуемая метка может быть и не одна.
Ну и для разводки оно возможно вообще лучше схему нетлистом загнать. Но для документирования, когда схему будут читать — надо позаботиться о читаемости. А метки ее в большинстве случаев ухудшают.
+1
Не убедите — не тратьте время. В конце концов, каждый вправе решать и выбирать для себя вариант на свое усмотрение, если ему неважно мнение тех, кто юзает его схему.
0
Ну, это же не Lifelover. Да и тащемта, если взглянуть с его стороны — в работе такое действительно удобней, когда схему не нужно читать. Просто остальные обсуждают с точки зрения читабельности схем, а treasure — с точки зрения работы с ней.
0
Согласен, потому как об этом же и говорю. Более того, с его позиции схемы нашей концепции видятся так же как его нам :)
0
прошу заметить, что я не ратую за однозначное именование _всех_ цепей и связи по ссылкам.
0
Не убедите — не тратьте время
смысл разговора не в убеждении кого-либо, а в рассмотрении сильных и слабых сторон подходов.
если ему неважно мнение тех, кто юзает его схему.
не поверите. но мои схемы как правило в рапечатанном виде не изучают. я или отдаю схему в смысле «хотели — получайте», или отдаю в оригинальном формате, где все удобства идут вместе с форматом и пакетом, в котором оно смотрится. смотрелки как правило фришные, да и для просмотра особых навыков владения не нужно.
-2
Значит я был прав.
0
я вроде и не говорил, что все и всегда должно быть по меткам. или о чем другом?
0
Нет. Вдоль линии можно провести взглядом. Метку же приходится искать на листе, причем методом линейного поиска. Причем найдя — поиск придется продолжить. Ведь требуемая метка может быть и не одна.
с линией аналогично. она ведь где-нить по дороге может обозваться, а потом куда-нить приехать. или вообще может быть ссылка не на имя а на ногу корпуса.
А метки ее в большинстве случаев ухудшают.
а нагромождение линий ухудшает читабельность еще больше.
-1
с линией аналогично. она ведь где-нить по дороге может обозваться, а потом куда-нить приехать. или вообще может быть ссылка не на имя а на ногу корпуса.
Ерунду спороли
+2
да ну? вы таких не видели? я за вас искренне рад. а я однажды полтора месяца убил на эту гадость.
-1
Хотите сказать, что как правило это так?
0
не правило. но довольно часто встречается.
-1
Ну дык, криворучек немало… Да и тех, кто делает схемы только для разработки платы и потом их в таком виде и публикует для изучения — тоже.
+1
ну вот второй случай — как раз вполне нормальный, имхо.
исключение — оплаченные публикации.
-1
Ну, публиковать для чтения все же следует причесанную схему.
+1
ну, кому надо — и причешут, и разберутся. кому непонятно — значит просто не надо.
понятно, что тут я не о клинике.
-1
ну, кому надо — и причешут, и разберутся
… и словом недобрым помянут…
+2
ну помянут. ну и что. знал-бы ты, сколько народа хоть даже отсюда я поминал незлым тихим словом… ;)
хотя поминал только в процессе. как правило, в процессе и решения новые посещают, и под свои компоненты попилишь, и пару деталек в базу новых закинешь. в общем, по итогу только профит.
-1
она ведь где-нить по дороге может обозваться, а потом куда-нить приехать. или вообще может быть ссылка не на имя а на ногу корпуса.
Это уже не линия, а какая-то херня)
+2
Замечаю, что treasure больше о каких-то исключениях толкует. Я уже говорил, что создание читабельной схемы — это своего рода искусство. Кстати, где возможно, надо стараться, чтобы и имена цепей были понятны как в программировании имена переменных.
+2
Замечаю, что treasure больше о каких-то исключениях толкует
правил без исключений не бывает.
Я уже говорил, что создание читабельной схемы — это своего рода искусство.
с этим никто и не спорит.
Кстати, где возможно, надо стараться, чтобы и имена цепей были понятны как в программировании имена переменных.
ну правильно. я разве говорил, что цепи должны именоваться типа «skhfoujoifjr1568»?
0
Кстати, где возможно...
— это я так, в общем.
0
то есть — Verilog-а нет? :) Вы в курсе, что начинку крупных микрух (посложнее башни робота будут) уже давно не рисуют визуально в процессе разработки? Так, выводят иногда по-необходимости…
0
графика и правда привычнее. и с этим ничего не поделаешь. более того, она — наглядна.
текстовое описание все-таки требует определенной перестройки мозгов. как пример — два подхода в описании плисов.
ну и как завершающий в голову. одно дело, когда мы (ну, не совсем мы) синтезируем схему из элементарных И-ИЛИ-НЕ, и совсем другое, когда нам доступны счетчики-дешифраторы, многовходовая логика и прочее. ведь в случае текстового описания придется распознавать некие типовые блоки (те самые счетчики, сдвиговые регистры с последовательной/параллельной загрузкой, и т.д. и т.п.).
в общем, почитайте типичную ветку про плис. только не на этом форуме, не на радиокоте, и не на казусе. а, например, на электрониксе и в ЖЖешечке… ой, забыл автора, надо искать…
0
УПД: вот представьте, что в вашем описании синтезатор не распознал описание сдвигового регистра с параллельным выходом и последовательным входом (угу. 595.) и нагородил 100500 корпусов элементарной логики. батхёрт? однозначно.
это в плисах хорошо. пока дизайн влазит в целевой кристалл и пока тайминги держатся — нам почти пох. а в реальной жизни это реальные деньги, реальные лишние телодвижения и очень реальные точки отказа.
0
Есть нюанс — графика действительно в большинстве случаев легче читается, а вот писать и редактировать проще текст (ИМХО).
Про завершающий в голову не понял совсем. Я же не предлагаю взять VHDL или Verilog и описывать на них логику устройства. Мне интереснее использовать язык позволяющий задать связи между выводами компонентов. Всё тоже самое, что в классической рисовалке схем, но текстом. Мне кажется должно быть нечто типа того же графиза только с учётом специфики — ноды должны не сами по себе подключаться, а иметь порты (выводы). Описание нод, опять же, делается в заранее составленных библиотеках с привязкой к футпринту. В чём проблема?
-2
я понял начальную идею ;) просто довел до наглядности. ;)
проблема в том, что или мы в языке описываем логику корпуса, или оперируем нетлистом.
первый путь упирается в поддержку производителем (и стандартами на язык)
второй путь приводит к простому нетлисту.
первое очень зависимо от вендора, второе…
второе нах. чтобы оценить такую мою оценку — просто попробуйте руками сгенерить нетлист под любимый кад в котором разводите платы.
или предлагаете некий третий вариант?
-1
Ну, в целом, я согласен. Предлагаю, конечно, первый вариант. Нетлист для любимой кадины писать даже пробовать не буду — какой смысл, если нет специализированного человеко-ориентированного языка для этого?
Просто я опираюсь на свой опыт работы с графизом и отзывы людей рисующих графику в латексе.
0
>>Предлагаю, конечно, первый вариант
Тьфу, второй, извиняюсь.
0
эм. сначала кинулся отвечать про первый вариант. ;)
впрочем, со вторым проблем не меньше. даже больше.
Нетлист для любимой кадины писать даже пробовать не буду — какой смысл, если нет специализированного человеко-ориентированного языка для этого
про ЯП напоминать надо? ;)
0
*ЯП — язаки программирования
если что…
0
Есть нюанс — графика действительно в большинстве случаев легче читается, а вот писать и редактировать проще текст (ИМХО).
Куда проще в редакторе схем удалить или добавить парой щелчков мыши микросхему, или изменить соединения, чем переписывать заново полстраницы вашего текста.
+1
А зачем его ПЕРЕПИСЫВАТЬ? И да, лично мне проще написать пару строк текста, чем дёргать мышь. Хотя, это моё ИМХО…
-2
И да, лично мне проще написать пару строк текста, чем дёргать мышь. Хотя, это моё ИМХО…
а осмысленно поправить пару десятков(сотен) строк текста тоже проще, чем пару раз дернуть мышью? ;)
кстати. это еще и камень в огород SWG. имхо, проще в одном месте поправить название приходящей цепи, чем перерисовыввать 100500 линий. (которые еще и картинку загромождают)
а pinswap в большинстве случаев далек от идеала…
-2
имхо, проще в одном месте поправить название приходящей цепи, чем перерисовыввать 100500 линий. (которые еще и картинку загромождают)
Поправить, может, и проще (хотя одну линию поправить обычно не проблема) Вот только схема получается write-only. Если она набивается только для симуляции/трассировки, то это еще приемлемо, но когда такую схему экспортируют в картинку и прикладывают к статье — это уже издевательство.
+1
ну, в статье тоже проще разобраться, чем прослеживать конкретную вихляющую линию среди 100500 однообразных.
именованные цепи хоть можно распечатать и отловить. а в сетчато-полосатой картинке порой хер разберешься.
-1
Если приблизительно представляешь схему и как оно работает — да. А когда ищешь, куда же в PS2 подключена эта сраная кнопочка — вместо отслеживания пары длинных линий приходится внимательнейшим образом просматривать все листы схемы.
+1
ну, схему PS2 не изучал. потому сложно представить.
с другой стороны, схема ведь не предназначена для публикации в паблике. или это просто схема от энтузиастов, которые накидали корпусов и вызванивали связи.
так что пример PS2 не в кассу.
-1
ну, схему PS2 не изучал. потому сложно представить.
Весьма прилично нарисованная схема, на самом деле. Просто оно на один лист не влезло. А кнопка не то что на другом листе — на другой плате. Тут и выбора нет. Но метки искать от того не легче.
с другой стороны, схема ведь не предназначена для публикации в паблике.
Ну, там была схема для сервиса. Т.е. именно для публикации и последующего чтения. Пусть и не очень публичного.
+1
Есть нюанс — графика действительно в большинстве случаев легче читается, а вот писать и редактировать проще текст (ИМХО).
И что? Write-only язык — далеко не лучшая идея.
0
Кстати, а что это «графиз»? Гугл ничего путного не подсказывает…
0
С такими темпами можно и географические карты начать текстом описывать… Не-не-не… Что быстрее: въехать взгянув на чужую схему, или чужой исходник? Графика все же гораздо нагляднее…
+2
  • avatar
  • N1X
  • 06 февраля 2013, 23:16
Я тоже об этом раньше думал. Даже сделал набросок языка (свой, очень простой HDL), парсера, и симулятора цифровых схем. Хотел ещё авторазводчик, но не дошло дело.

А сейчас мне уже кажется, что по схеме все гораздо быстрее можно понять, если она не большая и нормально нарисована.
0
Я тоже об этом раньше думал. Даже сделал набросок языка (свой, очень простой HDL), парсера, и симулятора цифровых схем. Хотел ещё авторазводчик, но не дошло дело.
более того. такое было. на спектруме. звалось «Layout 86». было чуть более чем неюзабельно.
там как раз нетлистом заводилась схема. правда, емнип, без визуализации схемы.
0
Забыл сказать, одна из первоначальных (но не реализованных) идей была связана именно с автороутером. Описывать ограничения, требования, а не просто нетлист. Напрмер соединить какую-то точку с «любым» свободным портом МК, с каким лучше разведется с тем и будет. Где-то полярность можно изменять. Ограничения на геометрию дорог.

Представил схемы на ОУ записанные текстом и снова расхотелось об этом думать :)
0
ой, ограничения и прочую требуху, еще и текстом… данунах.
вообще, такой проект есть — авторутер в альтиуме. ООчень гибко пишутся правила. под любой случай. вот только чтобы получить вменяемый результат надо потратить гораздо больше сил чем развести руками…
0
Зачем свой симулятор и авторазводчик? они есть. А вот визуализатор в языку было бы полезно, особенно если синтезируется не картинка, а нечто интерактивное =).
0
А вот визуализатор в языку было бы полезно
они есть. по крайней мере в кактусе.
особенно если синтезируется не картинка,
видушка??! =0
а нечто интерактивное =).
хм. какой смысл в интерактивности схемы? которая вынашивается порой неделями в голове.
0
Кто такой кактус?

>>правильные кады умеют подсвечивать одноименные цепи. но вам, конечно, оно просто не нужно.

Собственно, об этой интерактивности и речь
0
Кто такой кактус?
Altera Quartus II
;)
Собственно, об этой интерактивности и речь
ну, в тексте этой интерактивности не будет однозначно. так что мимо.
0
ну, в тексте этой интерактивности не будет однозначно. так что мимо.
А вот с этим можно поспорить.
+1
угу. только одна засада. для такой наглядности необходимо динамическое отслеживание и понимание не только стандартного Color.White, но и ужасов типа Tsvet.Pokazat и Krug.Kolorize
0
Там оно и посложнее фокусы понимает. Ну и подсветить все детальки, подключенные к данному узлу в нетлисте — задача куда проще.
0
Там оно и посложнее фокусы понимает.
ну хз. не пробовал. потому спорить не буду. хотя более чем уверен, что очень многое не поймет.
Ну и подсветить все детальки, подключенные к данному узлу в нетлисте — задача куда проще.
пока «деталька» идет как черный ящик. как только выйдет новая деталька, эта интерактивность моментально сядет в лужу. (до следующего сервис-пака или апдейта, если у разрабов дойдут руки)
0
Если генерировать по тексту графическую схему то получим нечитабельное нечто. Разве не очеведно, что схема содержит больше информации чем «нетлист».
+1
Да и задача получается сходная с разводкой, только здесь надо будет обеспечить «понятность схемы».
+1
присоединюсь. более того. необходимо будет узнавать типовые блоки и решения. что совсем не тривиальная задача.
0
Эм, с твоим подходом как раз никаких проблем. Раскидываем все компоненты по сетке и к каждой ножке вешаем поименованную цепь. Схема готова.
0
а распознать описание в тексте?
вообще, в сказанное мной пытался вникнуть? просто уточняю.
0
Как я понял, здесь предлагается скорее аналог нетлиста (т.е. язык описания схемы), а не аналог HDL (язык описания «что делает схема»).
Да и ветка эта ведет разговор о внятной визуализации нетлиста, насколько я понимаю.
+1
да тутничто не предлагается, а просто спрашивается «а почему нет?»
да и ветка совсем не о визуализации ой
0
да тутничто не предлагается, а просто спрашивается «а почему нет?»
Ну суть вопроса-то от того не меняется.
0
суть конечно сильно меняется. ведь ничего не предлагается
0
Действительно, отклонились от темы.
0
ну вот мы и обсуждаем, «почему нет». разве нет?
0
А чем не подходит для этого Verilog (или его расширение)? Можно сделать компилятор с выводом результата в netlist или pads/ascii.
Схема пишется на Verilog, корпуса и классы цепей (всё что нужно) аттрибутами добавляются, как метаданные. Потом вывод в указанные форматы и разводка. В середине можно моделирование сделать.
0
Схема пишется на Verilog, корпуса и классы цепей (всё что нужно) аттрибутами добавляются, как метаданные. Потом вывод в указанные форматы и разводка. В середине можно моделирование сделать.
А еще проще — найти хорошего электронщика, в двух — трех словах описать ему задачу, остальное — он сам все за вас сделает…
0
Дорого только) Даже если сравнивать с ценами на инструменты.
0
Дорого только) Даже если сравнивать с ценами на инструменты.
Так никакие инструменты свми ничего делать не будут…
0
Текст скатит разработку плат в яму. Аналогичное было с программами. Для примера можно взглянуть на старые программы которые писались на языках низкого уровня, как правило эти программы были очень стабильны в конечном итоге, ибо если там накосячил, то ни хрена работать не будет. А если взглянуть на современные программы, то что не бета, то обновление.
0
  • avatar
  • Gidof
  • 06 февраля 2013, 23:45
Я бы не сказал, что программы на ассемблере так уж стабильны. Напротив, любят грохнуться в AV или подобную жесткую ошибку. А то еще Therac-25 вспомнить можно.
Стабильные как правило или вылизаны годами, или весьма просты. А вот современный софт весьма сложен, обилие ошибок в нем неизбежно.
+1
А вот современный софт весьма сложен, обилие ошибок в нем неизбежно.
Вот же придумали себе мантру. Тем не меннее это верно: «современный» софт сложен, а хорошая вещь обязана быть простой (вне зависимости, фонарик это или ракета).
0
сделаййте простой офис с визивигом минимум. или сделайте простой эклипс.
проблем-то.
вот только, беда-беда… разрабы с бОльшим чем у вас стажем, не делают -> говноляпы?
или, может быть, они все таки больше вашего знают. а?
0
Мне больше инженеры симпатичны, чем программисты-говноляпы.
0
гхм. позвольте спросить.
ТАК КАКОГО МПХ ВЫ ДЕЛАЕТЕ СРЕДИ программистов-говноляпов?
и почему вы пользуетесь трудами этих самых ПРОГРАММИСТОВ-ГОВНОЛЯПОВ, а не Инженеров?
0
Потому что всё завязано на поделки этих программистов. Почему-то повара готовят вкусную еду, архитекторы проектируют качественные здания, конструкторы строят безопасные, удобные и экономичные самолёты. А программисты, которые всем этим пользуются (и поделками которых вынуждены пользоваться все остальные), поют про «современный софт весьма сложен, обилие ошибок в нем неизбежно».
0
Почему-то повара готовят вкусную еду,
беээээ… счастье — в незнании.
архитекторы проектируют качественные здания
лучше не чихать лишний раз. особенно после перепланировок парой жильцов.
конструкторы строят безопасные, удобные и экономичные самолёты.
про самолеты вообще не будем.

и вы будете говорить про качество после подводной группировки спутников? не смешите.
0
Халтуры везде хватает. Тем не менее, нормальные самолёты и дома становятся лучше, а программы — хуже.
и вы будете говорить про качество после подводной группировки спутников? не смешите.
Весьма вероятно, что причина именно в софте
+1
Второй закон Вейнберга.
Если бы строители строили здания так же, как программисты пишут программы, первый залетевший дятел разрушил бы цивилизацию.
Вот это наблюдение появилось далеко не на пустом месте
+1
пффф… это из законов мерфи что-ли?
тоже мне авторитет.
все равно, что в качестве авторитета советы остера приводить.
+1
Вот это наблюдение появилось далеко не на пустом месте
Угу. Она появилась во времена, когда для программы только начали появляться. А для их разработки применили традиционные инженерные подходы. Вот только очень быстро оказалось, что эти подходы при работе с проектами, которые на порядки сложнее любых инженерных конструкций, работают очень плохо, а результат получается такой, как описывает эта фраза. Многим (вам, судя по всему тоже) кажется, что это потому, что традиционные подходы применялись плохо или неправильно. Но проблема в том, что эти подходы просто не работают когда сложность проекта превышает определенный порог.
+1
Вот только очень быстро оказалось, что эти подходы при работе с проектами, которые на порядки сложнее любых инженерных конструкций, работают очень плохо, а результат получается такой, как описывает эта фраза. Многим (вам, судя по всему тоже) кажется, что это потому, что традиционные подходы применялись плохо или неправильно.
Причина возрастания сложности именно в том, что на нормальный инженерный подход забили.
Сборка программы сложная? Что же, разделим тулчейн на компилятор и линкер. Компилятор понимает определённый язык, а линкер — умеет строить определённые исполняемые файлы. И компилятор тоже разделим на парсер определённого языка, оптимизатор и кодогенератор определённой архитектуры. Эти части тоже можно разделить, пока не выяснится, что у нас есть набор простых и однозначных действий, для каждого из которых есть простая деталька, которая занимается только своим делом. И, внезапно, «сложности» больше нет. Если все компоненты системы простые, вся система простая. И нет разницы, атомная электростанция это или динамофонарик. или Это один из принципов «классического» инженерного подхода. Если им следовать, никакой сложности просто не будет.

Это правило, кстати, диаметрально противоположно такой новомодной выдумке, как инкапсуляция. Данная хрень значительно повышает сложность.
0
Причина возрастания сложности именно в том, что на нормальный инженерный подход забили.
Нет.
Сборка программы сложная? Что же, разделим тулчейн на компилятор и линкер.
Вы выбрали слишком простой пример. К тому же фаз компиляции, обычно, больше и разбивка делается на большее число частей. И да, эта задача именно так и решается в реальной жизни.
Если им следовать, никакой сложности просто не будет.
Я повторюсь: вы выбрали слишком простой пример, когда связи между частями сугубо линейные — каждый компонент взаимодействует только с двумя соседними. Таких задач достаточно мало. В большинстве практических задач связей значительно больше и вариантов взаимодействия компонентов тоже значительно больше. Именно эти связи и взаимодействие составляют сложность, а вовсе не сложность отдельного компонента.
Это правило, кстати, диаметрально противоположно такой новомодной выдумке, как инкапсуляция. Данная хрень значительно повышает сложность.
Не порите чушь, ей уже очень больно. То, что вы описали — классический пример инкапсуляции. И инкапсуляция уменьшает сложность, а не повышает ее.

P.S. похоже вы даже мысли не допускаете, что среди людей работавших и работающих в IT есть такие, кто, как минимум, не глупее вас.
P.P.S. кстати, когда я писал о «классическом инженерном подходе», то имел в виду вовсе не дизайн, а организацию процессов при разработке программ. вы и этого не поняли.
+1
P.S. похоже вы даже мысли не допускаете, что среди людей работавших и работающих в IT есть такие, кто, как минимум, не глупее вас.
Почему же. Есть не только не глупее, а куда умнее. Линус Торвальдс, Фабрис Беллар — это только самые яркие примеры. Также заслуживают уважения авторы многих маленьких и быстрых программок на Си и C++. Например, Nir Sofer. На Delphi тоже есть хорошие программки (пусть и не такие качественные, но хорошо продуманные и полезные) — например, тот же Total Commander.

А что дали миру полезного новомодные технологии? Сожрать 32 гигабайта — запросто. Разводить болтовню о фреймворках и оопах на всяких хабрах — запросто. А где полезный выхлоп? Обработка формочек и прочих запросиков? Чему тут поражаться? Переписать на Си и наверняка вместо 32 ГБ хватит 32 МБ. Любой радиолюбитель, собравший мультивибратор достоин большей похвалы, т.к. он потратил материалов примерно столько, сколько нужно, а не в 1000 раз больше. Не было бы серверов с гигагерцами и гигабайтами — всё равно бы решили все эти задачи (только быстрее, не отвлекаясь на лишний жыр).
+1
Переписать на Си и наверняка вместо 32 ГБ хватит 32 МБ.
Да нифига. Многие гигабайты тратятся на структуры данных, которые одинаковы в любом языке. Например, хоть тресни, а высокополигональный меш будет жрать NumVertices*VertexSize (Vertex при этом всегда обычная структура в стиле С). Учитывая что ныне VertexSize несколько десятков байт (20-50), а вершин под миллионы… И такой меш обычно не один… Плюс текстуры… В общем, гигабайта памяти на видеокарте оказывается маловато. И такая же ситуация во всех остальных случаях. Браузеру нужно держать данные страницы для каждой вкладки в удобном для отрисовки (а не компактном, иначе будет тормозить) виде, IDE — держать AST, желательно всего проекта (который сам иногда сотни метров текста) в опять же распарсенном и удобном для поиска виде и так далее. Все это так просто не уменьшишь.
0
Многие гигабайты тратятся на структуры данных, которые одинаковы в любом языке. Например, хоть тресни, а высокополигональный меш будет жрать NumVertices*VertexSize (Vertex при этом всегда обычная структура в стиле С). Учитывая что ныне VertexSize несколько десятков байт (20-50), а вершин под миллионы… И такой меш обычно не один… Плюс текстуры… В общем, гигабайта памяти на видеокарте оказывается маловато.
Согласен, графика — достойная задача. Впрочем, для игры качество определяется в первую очередь не графикой.
Браузеру нужно держать данные страницы для каждой вкладки в удобном для отрисовки (а не компактном, иначе будет тормозить) виде
IE6 открывается за секунду и потребляет 24 МБ. Firefox — за пять секунд и потребляет 260 МБ с одной вкладкой. Простые странички IE6 также отображает быстрее. Новые гламурные CSS3? Зачем это надо — гигабайт рюшечек на 50 КБ контента?
IDE — держать AST, желательно всего проекта (который сам иногда сотни метров текста) в опять же распарсенном и удобном для поиска виде и так далее.
Аналогично браузерам.
+1
Аналогично браузерам.
Спасибо, но после IDE работать в аскетичных иароблокнотиках грустно.
IE6 открывается за секунду и потребляет 24 МБ.
Он древний, как говно мамонта. Его ровесница Опера 5 кушала еще меньше. Теперь же, и на том же движке — 2ГБ, и то только из-за системных ограничений. Web 2.0 такой Web 2.0. Впрочем, огнелис давно известен своей любовью до ОЗУ — «а кто будет много памяти жрать — сразу получит по рыжей морде!».
-1
IE6
Ну зачем вы так… я только поел :(
0
Переписать на Си и наверняка вместо 32 ГБ хватит 32 МБ.
Удачи. С большим интересом понаблюдаю за процессом. Да, формочки, конечно, не так интересно. Куда интереснее, например, тот же лайвстрит, которым вы пользуетесь, когда пишете сюда.
0
А что дали миру полезного новомодные технологии? Сожрать 32 гигабайта — запросто. Разводить болтовню о фреймворках и оопах на всяких хабрах — запросто. А где полезный выхлоп?
То есть, мальнькая утилитка для вас выхлоп, а СУБД, обслуживающая миллионы транзакций в секунду — не выхлоп? Да еще распределённая. Да ещё не имеющая права на ошибку. И все системы, с ней связанные, за многими-многими слоями абстракций.
0
Ладно, допустим не было бы этих гигабайтов. Что, не получилось бы решить те же задачи (не конкретно эту СУБД с абстракциями, а полезный выхлоп для человека)? Да получилось бы, быстрее и проще.
+1
Попробуйте сделать реальный выхлоп, например биллинг сотового оператора в пределах страны без использования СУБД. Или закройте банковский день.

Даже проще: формочку из трёх полей, и посадить трёх операторов забивать данные, всё в один файл, с произвольным доступом. Без СУБД, без абстракций. За неделю вы её напишите, через 2-3 дня она упадёт, поправите, кое-как будет работать. Расширите до 10 операторов и будете переписывать заново. Добавите поле — будете переделывать структуру файла и опять переписывать заново. И только когда набьёте себе шишки, начнёте придумывать абстракции. Сами, добровольно!
+1
Даже проще: формочку из трёх полей, и посадить трёх операторов забивать данные, всё в один файл, с произвольным доступом. Без СУБД, без абстракций.
Нормальная задача для студента. Проблема в том, что у большинства новомодных «программистов» всё пошло бы так, как ты описал. Потому что они больше по оопам «специалисты», чем по алгоритмизации. Жаль, что железо такое мощное — иначе многие бы такие отсеялись.
+1
Для студента согласен. Их и сортировку пузырьком заставляют писать.

Да, сразу видно, не работали вы в этой сфере. В то время, когда «железо было слабым, а алгоритмы красивыми», компьютеры решали N задач, сейчас же на порядки больше. Если у бухгалтера раньше вдруг падала его красивая и стройная самописная программа, у него была бумажная копия, сейчас её нет!, при этом один бухгалтер (от силы два) тащит целое предприятие, и усложнённым во много раз налогообложением, и прочими радостями. Любые доработки делаются за считанные часы, бизнес сразу видит результат, и ему как-то срать, какие там алгоритмы.
+1
Да получилось бы, быстрее и проще.
Вам ничего не мешает это продемонстрировать.
0
Весьма вероятно
0
А Вы знакомы с процессом проектирования корпуса судна особенно до появления быдлософта для гидродинамического моделирования и какие костыли при этом применяли, и какие бока вылазят уже при эксплуатации судна. Первые два года после приемки судна работать на нем еще то удовольствие. Я был свидетелем как в один из новостроев накидали несколько сотен тонн металлолома и залили бетоном для улучшения остойчивости. Так что не нужно рассказывать о том чего не знаете.
+1
Я был свидетелем как в один из новостроев накидали несколько сотен тонн металлолома и залили бетоном для улучшения остойчивости.
Спасибо еще, что это не Ваза :)
0
конструкторы строят безопасные, удобные и экономичные самолёты.
Please, не приводите больше этот аргумент. По такому Вашему заключению можно сделать вывод, что авиацией Вы даже не интересуетесь, не то что бы разбираться. Под Вашу мантру «Простой и надежный» в авиации лучше всего подходит АН-2(1947). Великолепная в своей простоте и надежности машина, летит сама, если ей не мешать. Простота — это безбустерная система управления ИЛ-62(1967), т.е. прямое управление плоскостями, а ведь это тяжелый реактивный межконтинентальник. А сейчас мы имеем

Если в тушке отказывает бустер, это сказывается увеличением усилия на органе управления, но пилот управления не теряет, а как быть тут?
Современная авиация — это такой оверхэд, какой Java-м и ООП вместе с фреймворками просто не снился. Так что этот аргумент — мимо кассы.
+1
Факт есть факт. Я наглядно вижу, насколько выросла сложность решаемых современным софтом задач по сравнению с временами DOS. Разница не в разы — на порядки! Это неизбежно приводит к росту объема его кода, который столь же неизбежно приводит к росту количества ошибок в нем.
+1
А графику, собственно, комп и сам может сгенерить из описания — раскидать кучку прямоугольников на холсте и линии между ними
Может-то он может, но насколько это будет «смотрибельно» — вопрос. Комп имеет слабые представления о субъективной наглядности, какие элементы поместить в центр схемы, какие оставить на периферии, какие связи отобразить отдельно, а какие в шину объединить. Ему (компу) — пофиг. Сколько сталкивался с автоматическим генерированием графов — всегда приходилось таскать элементы и причесывать связи.
+1
Alatar, представьте нам свою идею, пожалуйста, в законченном виде, пусть и несовершенном. Переубеждать Вас тут никто не будет — делятся своим мнением. Но оно может быть ошибочным, пока каждый по-своему представляет то, что Вы пытаетесь донести.
0
  • avatar
  • DVF
  • 07 февраля 2013, 00:20
Идею? Какую идею? =)
Я, вообще-то, просто хотел спросить — знает ли кто систему, предлагающую задавать нетлист в текстовом виде, как основную форму создания схемы устройства. А всё остальное — лишь размышления на тему, что такая системы могла бы дать.
0
Я как-то в институте работал со старым SPICE-симулятором (P-SPICE вроде), где схемы как раз приходилось вводить ручками в виде нетлиста. Костыльно это было, очень костыльно. На следующей лабораторке, в OrCAD'e, было уже куда удобней.
0
Я, вообще-то, просто хотел спросить — знает ли кто систему, предлагающую задавать нетлист в текстовом виде, как основную форму создания схемы устройства.
все знают, кто пользуется чуть более чем спринтом. только нужно отказатьзя от гламурных(с) способов рисования схемы и пререйти на труЪ описание нетлиста текстом. :)))
0
Тащемта, текстовые описания схем есть — тот же SPICE-нетлист. Но ты пробовал изучить нормальную такую схему (не мигалка или VGA-генератор на МК) в виде нетлиста, а не нормальной картинки? Его даже набивать-то приходилось проставив карандашиком на распечатке схемы номера линий.
В ПЛИС, все же, описывается не сама схема, а выполняемые ей логические функции, из которых потом генерируется принципиальная схема. А вот описать произвольную принципиальную схему в текстовом виде так, чтобы оно было понятно — как минимум проблематично.
0
  • avatar
  • Vga
  • 07 февраля 2013, 00:28
Дык, понятно дело, но тут можно провести аналогия с языками программирования — читать исходник на сях в общем случае гораздо проще, чем на асме. Вопрос не в читабельности сырого нетлиста, а в читабельности «высокоуровневого» языка, который потом транслируется в этот самый нетлист
0
Я сомневаюсь, что такую вещь можно представить в виде адекватного языка. Тем более — для произвольной, вручную спроектированной схемы. Вот язык, из которого схема потом будет генерироваться (типа как в случае HDL-языков) — более реально выглядит.
0
с HDL проще. точнее, у синтезатора и фиттера задача гораздо проще. они оперируют очень ограниченным числом блоков.
а ТС, как я понял, предлагает HDL, но с синтаксисом, учитывающим все многообразие логики…
0
Хз. Мне показалось, он предлагает нетлист, но читабельный. Со ссылкой на HDL — вроде для похожей задачи и текстовое.
0
Мне показалось, он предлагает нетлист, но читабельный
ну, как я выше говорил, такое и кактус показывает. КАК — это уже другой разговор.
более того. «читабельный» — категория исключительно субъективная.
-1
Ну, не такая уж субъективная. Скажем, нечитабельность Malbodge сомнению не подлежит :) Нетлист тоже не особо читабелен в виде текста. Проще его отрендерить и растаскать детальки, чем попытаться читать схему прямо по нетлисту.
0
сомнению не подлежит
не подлежит сомнению кем? хм. взял крайний пример.
Нетлист тоже не особо читабелен в виде текста
а вот это сильно субъективно. (хоть как правило так и есть) примерно как взять среднестатистического ардуинщика (или драконщика/билдерщика) и выкатить ему асмовый листинг. он тебе скажет 100% что оно нечитаемо.
Проще его отрендерить и растаскать детальки, чем попытаться читать схему прямо по нетлисту.
болд мой.
0
примерно как взять среднестатистического ардуинщика (или драконщика/билдерщика) и выкатить ему асмовый листинг. он тебе скажет 100% что оно нечитаемо.
Ну, по сравнению с тем, чем оно было до компиляции — вполне нечитабельно) А если еще и ковырять выхлоп дизассемблера...)
0
Ну, по сравнению с тем, чем оно было до компиляции — вполне нечитабельно)
вот видишь! а я в свое время в выше упомянутом лайоте86 пару схемок (примерно по десятку корпусов россыпи) развел… ;)

А если еще и ковырять выхлоп дизассемблера...)
это вообще BlackMagic, хотя тоже очень интересно.
0
Сейчас взглянут на нетлисты PCAD и AltiumDesigner — ну нечитаемы они.
0
ну не читаемы. просто потому, что их читабельность как неуловимый Джо.
0
Совсем не поэтому. Скажем, отчасти много того, что касается оформления. Если это отбросить и оставить сухо суть, то возникают другие неприятности. Например в строке описано соединение вывода с цепью. Выход это или вход не понять (оформление отброшено). Соединение этой цепи с другим компонентом может быть следующей строкой, а для шестого соединения на 50 строк ниже… Теряется связанность. Если перечислять сразу все выводы с которыми соединяется цепь, то как отобразить текстом все функциональные особенности компонентов? Получается, что визуализация все равно потребуется. И опять мы придем к графическому представлению, когда взгляду представлено все сразу.
+1
Например в строке описано соединение вывода с цепью. Выход это или вход не понять (оформление отброшено).
в альтиуме — совсем не так. со всеми вытекающими.
(если не в курсе: прям в библе задается направление/тип вывода и при соединении в соответствии с правилами оно проверяется, и подчеркивается как ошибка, если что)

но по текстовому описанию — почти согласен. с другой стороны, можно реализовать как в привведенном выше(или ниже?) примере с Draw.Color. т.е. в принципе, решаемо. вот только опять возникает неуловимый Джо… ;)
0
если не в курсе: прям в библе задается направление/тип вывода
Это украшательство и есть. Если все эти описания оставить, а значит и вводить, то равно и даже натужнее, чем подготовить в среде САПР компонент и нарисовать схему.
+1
По хорошему, тип и направление вывода позволяют делать дополнительные проверки в DRC и ERC. Другой вопрос, что не везде эта функциональность хорошо поддержана.
0
Тем более придется вводить. Это попробуй потом такой нетлист прочти с пониманием всей схемы…
0
Кстати, ERC очень помогает, при создании новых схем. В рутинных соединениях часто допускаются ошибки.
-1
А я при тупом копипасте из пикада в кикад умудрился шину клавиатуры отзеркалить :(
Тут уж никакое ЕРЦ не поможет.
Пришлось добавлять в новую прошивку
#define KBRD_BUG_PATCH (1)
+1
Это украшательство и есть.
это не украшательства, а дополнительная проверка. вы, небось, и DRC при разводке платы игнорируете…
0
Я раньше с PCAD (начиная с v4.5 под DOS) работал, теперь с Altium Designer. Общий стаж в САПР около 15 лет — это, чтобы отсечь инсинуации по поводу DRC, ERC и пр.
Я, лишь, хотел сказать, что если не ограничиться только информацией о соединениях, присоединяя данные для проверки соответствий правилам, нетлист станет «пухлее». Наверно стоило взять слово «украшательства» в кавычки.
+1
Я раньше с PCAD (начиная с v4.5 под DOS) работал, теперь с Altium Designer. Общий стаж в САПР около 15 лет — это, чтобы отсечь инсинуации по поводу DRC, ERC и пр.
что не отменяет моего вопроса.
что-то я сегодня сильно язвительный.
Я, лишь, хотел сказать, что если не ограничиться только информацией о соединениях, присоединяя данные для проверки соответствий правилам, нетлист станет «пухлее». Наверно стоило взять слово «украшательства» в кавычки.
это не украшательства даже в кавычках, а очень удобный инструмент. чтобы нетлист не распухал — просто в библе описывать элемент. как, собственно, в альтиуме, скажем. а DRC — просто набитый текст не будет «компилироваться» с выдачей еррора или варнинга, в зависимости от настроек. компиляция — или явно или фоном.
-1
Ключевое слово «библе» — тогда, да.
0
ну да. а разве проекты сложнее мигалки светиками бывают в одном файле? здесь такой подход применим и вполне оправдан. вы ведь в альтиуме тоже не рисуете каждый элемент с нуля в каждой новой схеме.
0
Хотя, нет — чего это я расслабился ) Вопрос, то, стоял о пригодности нет листа для восприятия как графики в схеме. А, если описание элемента будет в библиотеке, то что остается для восприятия?
+1
в нетлисте остается сухой остаток — связи между элементами.
-1
И что это Вам даст в плане чтения схемы, понимания как она функционирует?
+1
в плане чтения — ничего не даст.
в процессе написания — надеюсь, объяснять не надо. да и в плане «чтения» (ака повторения) — простую верификацию.
-1
Поэтому я и писал, что прежде, чем пускаться в обсуждения, стоило бы автору хотя бы пример дать того, как он видит то о чем спросил.
+1
Скажем, нечитабельность Malbodge сомнению не подлежит :)
Ой. Malbolge.
0
Предлагаю прекратить обсуждение, пока не будет что пощупать.
0
  • avatar
  • DVF
  • 07 февраля 2013, 00:30
Будущее начинается сегодня.
Понедельник начинается в субботу.

Если идти по проторенной дороге, совсем не факт, что окажешься там, где хотелось бы.
Если не отправлять в мировой эфир свои запросы, то вряд ли из ничего материализуется нечто, чего бы нам хотелось. И наоборот: мысль, высказанная вслух, с каждым повтором приближается к материальному воплощению.
Взять хоть тот же «Дракон». Ещё пару лет назад — ни коня ни возу, а нынче — «кандидат в лучшие статьи на википедии» и две независимые реализации. И это только начало.
0
мне интересно. где автор учился такие холивары разводить?
+2
  • avatar
  • xar
  • 07 февраля 2013, 01:56
очевидно ведь. здесь.
0
Для нормального холивара в топике не хватает кодовых фраз, типа «Arduino», «Apple», «Linux», «Java», «ООП» :)))). А так — просто небольшой срачик получился. :))))
+2
да разве это срачик?
так, дружеское обсуждение.
0
ок, дружеский срачик :)
+1
Автор просто переобщался на буржуйском форуме и слегка забыл специфику рунета =(
0
Собственно идея не нова. Только категоричности поубавить и все будет хорошо.
В некоторых армияx есть книги с полными электрическими схемами самолёта. Полными т.е. совсем полными.
И там активно применяется все, чем можно улучшить читабельность этого многотомника.
В том числе и структурированное описание подключений. Однако для схем не имеюших сквозную шину, это несколько излишне.
-1
Технологически любой КАД так или иначе работает с текстовым описанием, это пользователь работает с графическим представлением схемы. Для чего требуется именно графическое представление, а не текстовое — для наглядности.
Например, если в отчёте данные представить в виде таблицы или текста с цифрами, то читающий не воспримет эту информацию. Он её прочитает, поймёт, но в голове его не останется ясного образа того, о чём это написано. А вот если изобразить диаграмму и сопроводить её текстовым комментарием или табличкой с цифрами, то читатель хорошо эту информацию усвоит.
Поскольку проектируемая плата есть графический образ, то текстовому описанию непременно потребуется графическое представление, как минимум одно. Но чертёж платы сам по себе не нагляден, поскольку отображает физические связи между контактами, а не логические. Принципиальная схема есть изображение логических связей между элементами схемы, каждый из которых характеризуется набором контактов, то есть это схема более высокого уровня, нежели чертёж платы.
Для чего нужны схемы разных уровней — они требуются по той простой причине, что само по себе электронное устройство есть комплексная система, состоящая на разных уровнях детализации из более простых элементов.
Например, простой элемент — транзистор. Из транзисторов состоит сложная схема, реализующая другой простой элемент — логический вентиль, или триггер например. Так получаются два разных уровня детализации — детализация на уровне транзисторов и детализация на уровне логических элементов.
При использовании текстового представления точно так же потребуется несколько разных форматов текстовых представлений, в то время как графическое изображение использует единый формат представления — логические блоки, соединённые линиями. Этот формат един для разных уровней детализации схемы.
Соответственно, если Вы пытаетесь создать систему, упрощающую проектирование устройств, то Вам просто требуется разделить этапы проектирования по уровням детализации, и тогда отдельные функции можно будет с лёгкостью автоматизировать.
+1
сферический логически мыслящий быдловузик из вакуума уже не в состоянии воспринимать образы, только унылый текст
все уже настолько плохо?
-1
сферический логически НЕмыслящий быдловузик из вакуума уже НЕ в состоянии воспринимать кроме образов.
унылый текст все уже не воспринимают. все настолько плохо?
пора опять снова к вам идти… :)))
0
А графику, собственно, комп и сам может сгенерить из описания
Человек именно нарисует схему, а программа просто соединит как получится и это будет месиво.
+1
Посмотрите схему, скажем, ноутбука :)
Ровные ряды квадратиков, ощетинившихся терминалами.
Программа нарисует такое ничуть не хуже человека.
Да хоть схему любой более-менее серьёзной евал-борды.

Вставлю свои 5коп.
Я [тоже] считаю, что разработка как схем, так и текстовых описаний (неважно чего, программ или аппаратной части) должна быть двунаправленной. Графика->Текст и Текст->Графика.
Для этого над обоими этими ипостасями должна быть третья, которая вбирает в себя всю полноту информации.
А именно БД.
Тогда любая из форм выражается из общего как некий отчет по определенным параметрам.
Сейчас особо нет времени, но если интересно, могу развить чуть позже.
0
не надо все загонять в рамку блочных девайсов. если будет кучка транзисторов и жесткой логики то тут уже нужна фантазия, чтоб все красиво лежало.
+1
Ну так в чем проблема.
Нарисовали в схематике, красиво разложили, загнали в прямоугольный сабсёкит — и вот уже перед нами очередной кирпичик.
А меня утомляют прямоугольники процессоров на поллиста, абсолютно неинформативные, обмотанные шиной, уходящей за горизонт…
-1
Я ж и говорю за дуализм.
Где удобно — вводим схему. А где легче текст — там текст.
0
Предлагаю погуглить «таблица соединений» (есть такой вид документа по ГОСТ 2.413-72) и сразу будет всё нагляднопонятно.
0
Очередной вброс состоялся=) Ждем результатов матча в виде количества комментариев!!!
Даешь срачь в теме=0)
+1
А чё, типа латеха вполне нормально, написал оно тебе рядышком отрисовало со связями удобными и не удобными, гостами и не по госту. Ещё… я правда не помню где это было, в плисах по VHDL генерирует схемки…
0
Ещё… я правда не помню где это было, в плисах по VHDL генерирует схемки…
читайте внимательнее ветку. я выше уже говорил, что кактус такое умеет. криво, но умеет.
0
Наверное он и имелся ввиду, давно это было, раздражала реалистичная симуляция и гличи. Ни одна лабараторка не работала, даже у ботанов.
0
давно это было
ВО!
начиная с семерки, а тем более девятка — очень адекватные инструменты. не без глюков, конечно. но их просто надо учитывать в работе. как и с любым инструментом.
-1
Квартус? Не? Позволяет из структурного описания получаешь граф. схему из схемы структурное описание. Можно подумать о смысле жизни — читать как «программа серьёзная».
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.