Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, FragMent, Вы писали:
V>>>А взять сложную схему с многообразием технологий (а не только одну булевскую логику)... я с трудом представляю как разбираться в принципиальной схеме без графического представления. Ты банально не поймешь принцип работы схемы, если там кол-во элементов перевалит за единицы десятков. Если же я не прав, просьба привести примеры, где бы в тексте разнообразная электроника смотрелась бы лучше. (Может я и не прав и сильно отстал за последние годы, когда уже не занимаюсь этим). FM>>Ну вот посмотри скриншот схемы, сгенерированной из верилога. Слишком много связей и понять, что происходит, сложно. А ведь это еще не самый тяжелый случай.
V>Ну вижу много связей. Вижу лишь слабость инструмента. Почему не произведено группрование связей по шинам? ТАм будет всего 2-3 шины (разрешение скриншота не позволяет сказать точно), и порядка десятка отдельных управляющих концов. полнейший примитив, если правильно представить в графике. Сложные схемы начинаются от полусотни цифровых и от несколькьких сотен аналоговых элементов и от десятков шин.
А я вот вижу, что они уже сгруппированы по шинам (толстые линие на рисунке), а остальное отдельные связи.
V>Кстати, а можно посмотреть на соответствующий этой схеме исходный код?
Не знаю.
Если интересно, сейчас есть бесплатные приложения для синтеза цифровых схем. Поставь, поиграйся, сравни работу на больших схемах (от десятков тысяч вентилей)
V>>>Одна цифровая логика? FM>>Да, учитывая что цифра сейчас самый распространенный тип дизайна.
V>Учитывая распространенность мобильных, обычных проводных сетевых технологий, встроенных жжидкокристаллических и т.д. — ты сильно заблуждаешься. Просто тебе из подвала не видно.
Я восхищаюсь твоими телепатическими способностями! Особенно, если учитывать что в эти подвалы ты вообще не заглядывал.
Давай спросим у экспертов http://www.electronicsweekly.com/blogs/david-manners-semiconductor-blog/2009/10/how-big-is-the-analoguemixed-s.html
Как видишь они спорят составляет ли аналоговый и цифроаналоговый дизайн 16% или 34% от всего рынка. Причем сюда включаются и те цифровые схемы, в которых аналог служит чисто для вспомогательных целей (трансиверы-ресиверы).
Видел оценку, что только 2% транзисторов "аналоговые", хотя, конечно, время разработки сравнимо.
Можем еще сравнить по количеству вакансий.
FM>>>>С аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты.
V>>>Есть примеры достаточно сложных схем в текстовом виде с адаптивными фильтрами, умножителями (сигналов и частот), ФАПЧ и т.д.? FM>>Странно, что тебя нужно убеждать, что декларативное лучше императивного FM>>Из чего больше понятно, что происходит с сигналом? FM>>Из формулы или из схемы?
V>Я бы взял чуть другую схему для бОльшей добротности, но не суть.
Опять телепатия.
FM>>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.
V>Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.
Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.
Основная проблема не в самой конфигурации, а выборе нужной из design constraints и последующем выборе оптимальных размеров элементов. На это уходит основное время.
Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.
Единственным поставщиком системы промышленного качества была Magma Design Automation. Вот здесь описание системы.
Истории успеха Fujitsu Fraunhofer IIS
Финал немного предсказуем: Magma DA приобретена Synopsys за полмиллиарда. Причем из непересекающихся продуктов у них фактически только FlexCells и FinSim.
FM>>В графическом виде ты получишь: FM>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
V>Для того и существуют взаимные экспорты в разные популярные форматы.
Разумеется в таком случае тебе не составит труда взять какой-нибудь пример из LTSpice и сконвертировать его, скажем, в SIMetrix.
FM>>2. Отсутствие diff
V>Почти все форматы таки текстовые и даже вполне читабельные.
Что же это за форматы?
FM>>3. Отсутствие version control
V>См. предыдущий пункт.
Ага, в соседнем топике ты предлагал нетлисты таскать с собой. Самому не смешно? Хочешь сравнить
FM>>4. Сотни связей для сложного блока.
V>Это от неумения готовить графику. Пример тут показывает это неумение: http://svenand.blogdrive.com/archive/16.html V>Вместо трех шин развели обычную грязь. Такая же грязь будет в коде.
Это машина генерировала. И качество отображение показывает какой приоритет данной функции у разрабочиков.
FM>>5. Слабую интеоперабельность между различными тулзами (только не надо про edif )
V>Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области.
Так назови же мне их.
FM>>Повторюсь. Цифровая схемотехника очень быстро упёрлась в ограничение графического представления и в настоящий момент полностью перешла на текстовый формат.
V>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто.
И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты,
так называемые Standard Cell Library Design Engineers.
FM>>Аналоговый дизайн еще использует графическое представление, но активно исследует возможности ухода от него. У меня половина блоков имеют дополнительное описание на аналоговом варианте HDL под названием verilog-a (очень удобно для ускорения моделирования).
V>Я таки не увидел для сравнения соответствующую аналоговую схему и текстовое описание, чтобы можно было всерьез сравнивать.
Пожалуйста (схему для соответствия можешь найти в любом учебнике, где описывается сигма-дельта ацп первого порядка)
module firstorder_sigmadelta(in,clk,out);
input in,clk;
output out;
voltage in,clk,out;
parameter real quantizer_vth=0.0;
parameter real clk_vth=2.5;
parameter real d2a_gain=5.0;
real vsum;
real vd;
real vint;
real vout;
real hi,lo;
analog
begin
@(initial_step)
begin
vd=0;vint=0;vout=0;
hi = 1; lo = -1;
end
@(cross(V(clk) - clk_vth,1))
begin
// summing junction
vsum = V(in) - vd ;
// integrator
vint = vint + vsum;
// quantizerif (vint > quantizer_vth) vout = hi ;
else vout = lo ;
// D to A
vd = d2a_gain*vout ;
end
V(out) <+ vout ;
end
endmodule
Еще раз этот код не для синтеза, а для ускорения моделирования.
Я обычно делаю так: в процессе создания аналоговых блоков, одновременно пишу поведенческую модель, которую затем подставляю вместо реальной ячейки, когда мне не нужно точное функционирования данного блока.
Здравствуйте, FragMent, Вы писали:
FM>Если интересно, сейчас есть бесплатные приложения для синтеза цифровых схем. Поставь, поиграйся, сравни работу на больших схемах (от десятков тысяч вентилей)
Я вот этого аргумента не понимаю насчет десятка тыщ вентилей... Это точно всерьез аргумент не ради троллинга? По основанию 2 — это 11 уровней иерархии всего. А если взять нормальную декомпозицию по основанию несколько десятков, то получим всего лишь 4 уровня иерархии типовых "кирпичиков". Полнейшая ерунда.
Если спор идет в ~2 раза, то таким спором можно подтереться, согласись... В любом случае, бери любую аппаратуру вокруг тебя: цифровая начинка во-многом "типовая", а аналоговый дизайн каждый раз уникальный. Опять же, что они тамсравнивают? Гибридные и аналоговые микросхемы с цифровыми? Когда я говорил о конечном изделии, включающем в т.ч. всю аналоговую обвеску? Боюсь, если сравнивать в деньгах, то конечное устройство стоит многократно больше стоимости примененных цифровых элементов. Даже взять микроволновку — там излучатель и обвеска к нему на порядок дороже управляющего микропроцессора. Даже такой факт — презиционный АЦП стоит сранимо с микропроцессором, который способен обрабатывать с той скоростью, с которой АЦП способен оцифровывать данные. Вот почему встраиваемые контроллеры с хорошим АЦП стоят относительно дорого — за счет своей гибридной части.
Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.
FM>Причем сюда включаются и те цифровые схемы, в которых аналог служит чисто для вспомогательных целей (трансиверы-ресиверы).
ИМХО, вот он взгляд из подвала. Это цифра идет как вспомогательная.
FM>Видел оценку, что только 2% транзисторов "аналоговые", хотя, конечно, время разработки сравнимо.
Напоминаю, что речь о разнообразии дизайнов, а не о кол-ве транзисторов. Цифровой транзистор проще многократно, к нему идут низкие требования относительно шумов и нагрузок... к тому же их в одних только центральных процессорах миллиарды... Но блин, если только в кеш-памяти сидит миллиард транзисторов, разве это означает миллиард уникальных дизайнов? Это размноженный один и тот же дизай. Это единица.
FM>Можем еще сравнить по количеству вакансий.
Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств.
V>>Я бы взял чуть другую схему для бОльшей добротности, но не суть. FM>Опять телепатия.
Чего-чего?
Приведена не самая удачная композиция для фильтра 2-го порядка. Есть другая, где можно достичь бОльшей добротности.
FM>>>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.
V>>Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.
FM>Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.
Одних фильтров многие десятки, если не многие сотни. Не получится с формулой-то. Тем более, что отталкиваясь от формулы, мы отрезаем себе самую фишку аналогового дизайна — это "уровень полезности" каждого элемента. В хорошем аналоговом идзайне на активных элементах зачастую более одной ф-ии. Например, "образцовая" точка компрессора может служить дополнительно ФВЧ с нужной частотой среза. Формулой и кирпичиками это не выразить в общем случае, надо смотреть конкретный дизайн. Ну и я плохо себе представляю тектовую аннотацию к формуле, когда у нас выбор кирпичиков идет из сотен. Эта аннотация становится невыразительной, т.е. китайской грамотой. Уже захочется именно посмотреть на саму схему реализации. Т.е. опять придем к графическому отображению.
FM>Основная проблема не в самой конфигурации, а выборе нужной из design constraints и последующем выборе оптимальных размеров элементов. На это уходит основное время.
Это в простейших случаях так... Например, для подбора кондеров по питающим шинам.
FM>Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.
Т.е. я таки прав относительно обобщенного дизайна? Я правильно понимаю приведенный тобой факт?
FM>>>В графическом виде ты получишь: FM>>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
V>>Для того и существуют взаимные экспорты в разные популярные форматы. FM>Разумеется в таком случае тебе не составит труда взять какой-нибудь пример из LTSpice и сконвертировать его, скажем, в SIMetrix.
FM>>>2. Отсутствие diff
V>>Почти все форматы таки текстовые и даже вполне читабельные. FM>Что же это за форматы?
Ну мне приходилось переносить м/у 3-мя разными сапрами и я не видел проблем. Правда, в одном случае накатал за пол-дня конвертер сам, т.к. автоматом не умел. Но там текстовый формат таков, что как раз хорошо подходит для машинного чтения. Реально сложных форматов у САПР-ов из этой области я не видел. Покажи сложный формат, на котором у тебя случились те самые проблемы.
V>>Вместо трех шин развели обычную грязь. Такая же грязь будет в коде. FM>Это машина генерировала. И качество отображение показывает какой приоритет данной функции у разрабочиков.
Это показывает уровень разработчиков и ничего более. Если для 4-х компонент мы имеем такую грязь, то там разговаривать сразу не о чем.
V>>Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области. FM>Так назови же мне их.
Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают.
V>>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто. FM>И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты, FM>так называемые Standard Cell Library Design Engineers.
Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет?
V>>Я таки не увидел для сравнения соответствующую аналоговую схему и текстовое описание, чтобы можно было всерьез сравнивать. FM>Пожалуйста (схему для соответствия можешь найти в любом учебнике, где описывается сигма-дельта ацп первого порядка)
(скипнул код)
FM>Еще раз этот код не для синтеза, а для ускорения моделирования.
Отличный пример, спасибо. Сравни теперь со схемой функциональной из 3-х квадратиков. ИМХО, приведенный код — китайская грамота в сравнении с наглядным представлением. По крайней мере, объяснить принцип этого способа АЦП новичку по исходному коду невозможно никак. В тексте отсутствует важный момент — наглядность одновременности происходящего.
FM>Я обычно делаю так: в процессе создания аналоговых блоков, одновременно пишу поведенческую модель, которую затем подставляю вместо реальной ячейки, когда мне не нужно точное функционирования данного блока.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, FragMent, Вы писали:
FM>>Для этого придется раздвинуть старые блоки, разместить новый символ, изменить соединения, если между старыми блоками еще остались связи, провести их мимо нового блока. В результате любая система version control не будет иметь смысла, поскольку за изменениями визуального представления не видно сути.
V>Суть см. по нетлисту.
А зачем? Если суть можно смотреть по тексту на VHDL?
N>>>А что плохого в сотнях связей для сложного блока, если он действительно сложный? FM>>1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.
V>Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись.
Ой, ну тогда ручками будешь перерисовывать сотни связей. Кстати, что это у тебя за трассировка такая умная, что знает что у тебя net0078 не должна быть закорочена с net0126?
FM>>2. Допустим есть глобальная связь, которая идет во множество блоков (например какой-нибудь clock). Нужно проверить все входы к которым эта связь подключена. В текстовом варианте, ты запускаешь поиск по файлам и легко видишь все вхождения. В графическом режиме ты подсвечиваешь нужную связь и обнаруживаешь, что она представляет собой ломанную линию с множеством ответвлений.
V>А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам.
Пожалуйста, назови хотя бы три САПРа, поддерживающих такую функциональность.
FM>>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.
V>Враки.
Это следует понимать как "Я, vdimas, создал N схем с более чем 10К элементов и ни разу не сталкивался с такой проблемой" или "я -- болтун-теоретик не воспринимающий факты, которые противоречат моему мнению"?
N>>>Они друг другу не противоречат. FM>>Не противоречат, но по факту в современной цифровой схемотехнике используют vhdl, verilog, а не schematic capture.
V>Это если цифровая схемотехника "сама в себе" и собрана из готовых кирпичиков (или вентилей). А если требуется эти кирпичики разрабатывать с 0-ля — то увы.
Жаль тебя разочаровывать, но эти цифровые кирпичики разрабатываются даже в случае схемотехнического ввода схемы.
Еще одну причину вспомнил. В нормальной цифровой схеме обычно применяется Boundary scan testing. Представляешь как весело руками последовательно соединить все ячейки?
И работа с нетлистом тебе в этом случае особо не поможет, потому что в нетлисте нет информации о взаимном расположении ячеек и можешь получить лишние проводники из одного края кристалла на другой. В то же время синтезатор знает какой регистр за каким следует и может, при необходимости, перекоммутировать BS связи.
А представляешь какую визуальную грязь добавит эта дополнительная куча связей, идущая сквозь все ячейки по иерархии?
FM>>Все что я выше описывал — это поиск причин post factum. Как только появилась возможность синтезировать схемы из HDLs, FM>>цифровики стройными рядами двинулись в этом направлении.
V>Да пожайлуйста. Для цифровых подзадач вполне пойдет. Как когда-то процессоры заменили автоматику и вместо разработки автоматики стали писать программы на процессора на других языках. Только это не отменяет этапа разработки схемы даже на основе процессора со всей требуемой обвеской, когда процессор управляет некоим реальным блоком вместо автоматики. Все-равно конечную схемы на основе процессора без графики не представить, хоть тресни. Пусть даже в нем "унутре" сколь угодно сложная программа. Даже возьми материнки современных компов или любые платы раширения. Я периодически взглядываюьс в разводку и расположение и могу тебя заверить, что там ручками доводилось обязательно как первое, так и второе. Но в тексте это на сегодня невозможно ни в одном из тулзов. Получается, что де-факто компьютерные платы таки разрабатывают в графике? Просто ты работаешь в другом направлении.
Итак, ты согласился, что для цифровых подзадач текст подходит. А, учитывая полную победу цифровых HDLs над schematic entry, текст подходит для них лучше графики.
В этом то и суть. Ни ты (со стороны board level engineers), ни я (со стороны analog IC designers) не можем утверждать, что графика по удобству превосходит текст, поскольку мы просто не имеем дело со схемами таких масштабов. Цифровые инженеры первыми столкнулись с дизайнами в сотни тысяч и миллионы элементов и деньгами проголосовали за текст.
N>>>Вопрос, наверно, больше в выборе оптимального для всех САПР стандарта описания? Каждое конкретное запихнуть в текст будет несложно. FM>>Нет. Чуть выше в том посте я описал, что имею в виду (синтез аналоговых схем из формул и язык verilog-a (не путать c verilog) для моделирования FM>>аналоговых блоков на более высоком уровне).
V>С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать?
Да кто тебе мешает? Имеешь нетлист, перерисовываешь его руками и меняй сколько хочешь.
FM>>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая). FM>>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.
V>А что за САПР-ы были?
Cadence Composer -> Mentor Graphics DesignArchitect
Mentor Graphics DXDesigner -> Cadence Composer
FM>>P.S. Я не противник графического представления. Более того, мне с графикой приходится работать больше, чем с текстом. Просто vdimas выбрал не очень удачный пример для демонстрации преимуществ графического dsl.
V>Я выбрал из своего опыта. Как раз делал довольно много микропроцессорных плат и для радиосвязи и для самолетных блоков. Не вижу там даже близко сценария работы "text-only", т.к. микрпроцессор всегда чем-то управляет и от чего-то получает сигналы и полно всякой обвязки. И никто не показал пока в реальной жизни "text-only" кроме FPGA или аналогичных сугубо цифровых самодостаточных микросхем.
V>Но даже расположи эти сугубо цифровые схемы на плате. Пусть автоматом. Зато мы потом берем и измеряем мощность*длину/ширину питающих соединений, полученных де-факто после размещения и разводки (даже если они автоматические). Уже кое-где требуется кондеры вставлять по питанию, а кое-где увеличивать их емкость. И вот уже появляются новые элементы в схеме или меняются номиналы имеющихся, что влечет за собой изменение их размеров и заход на новую итерацию размещения и разводки. В голом тексте это вообще никак не работает.
Еще раз. Когда у тебя окажется сотня тысяч связей, то руками ты физически не сможешь модифицировать все сложные места за приемлемое время. Ты просто синтезируешь схему (например при помощи IC compiler), экстрагируешь паразитные параметры (StarRC) и моделируешь схему с их учетом (PrimeTime для проверки целостности сигналов и проблем с мощностью). Если есть проблемы с какими-то связями, то возвращаешься к IC Compiler и вписываешь дополнительные ограничения в скрипт для синтеза (например команда set_clock_latency, set_clock_transition для установки правильного тайминга сигналов генератора)
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, FragMent, Вы писали:
FM>>Если интересно, сейчас есть бесплатные приложения для синтеза цифровых схем. Поставь, поиграйся, сравни работу на больших схемах (от десятков тысяч вентилей)
V>Я вот этого аргумента не понимаю насчет десятка тыщ вентилей... Это точно всерьез аргумент не ради троллинга? По основанию 2 — это 11 уровней иерархии всего. А если взять нормальную декомпозицию по основанию несколько десятков, то получим всего лишь 4 уровня иерархии типовых "кирпичиков". Полнейшая ерунда.
Обычный эффект масштаба. Тебя не смущает, что СУБД для хранения 100Мб данных и 1 Тб данных, скорее всего потребуются разные.
V>>>>>Одна цифровая логика? FM>>>>Да, учитывая что цифра сейчас самый распространенный тип дизайна.
FM>>Как видишь они спорят составляет ли аналоговый и цифроаналоговый дизайн 16% или 34% от всего рынка.
V>Если спор идет в ~2 раза, то таким спором можно подтереться, согласись...
Не соглашусь. Тут вопрос только в определении.
Вот есть микроконроллер, у которого схема тактирования работает от внешнего кварца (маленький аналоговый блочок в десяток транзисторов), он какой? Цифровой или цифроаналоговый? Скорее всего цифровой.
А если мы добавим внутрь микроконтроллера PLL как черный ящик, он превратиться в цифро-аналоговую схему? На мой взгляд — нет, но кто-то может думать иначе.
V>В любом случае, бери любую аппаратуру вокруг тебя: цифровая начинка во-многом "типовая", а аналоговый дизайн каждый раз уникальный. Опять же, что они тамсравнивают? Гибридные и аналоговые микросхемы с цифровыми? Когда я говорил о конечном изделии, включающем в т.ч. всю аналоговую обвеску? Боюсь, если сравнивать в деньгах, то конечное устройство стоит многократно больше стоимости примененных цифровых элементов. Даже взять микроволновку — там излучатель и обвеска к нему на порядок дороже управляющего микропроцессора. Даже такой факт — презиционный АЦП стоит сранимо с микропроцессором, который способен обрабатывать с той скоростью, с которой АЦП способен оцифровывать данные. Вот почему встраиваемые контроллеры с хорошим АЦП стоят относительно дорого — за счет своей гибридной части.
Мне это говорит о том, что стоимость аналоговых схем выше за счет более сложного техпроцесса, более низкого выхода годных, и маркетинговых соображений.
А также, что производительность цифровых дизайнеров выше, чем аналоговых.
Кстати, здесь написано, что производительность дизайнера на уровне схемы 100-200 гейтов в неделю, а на уровне HDL — 1-2 килогейта.
V>Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.
Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо?
FM>>Причем сюда включаются и те цифровые схемы, в которых аналог служит чисто для вспомогательных целей (трансиверы-ресиверы).
V>ИМХО, вот он взгляд из подвала. Это цифра идет как вспомогательная.
Значит если между процессором и видеокартой связь осуществляется через аналоговые трансиверы-ресиверы, то цифра в процессоре стала вспомогательной?
FM>>Можем еще сравнить по количеству вакансий.
V>Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств.
Там где ищут одновременно аналоговых и цифровых спецов.
Например сегодня на http://www.ic-resources.com/ Digital IC 233 вакансии, analog/rf IC 112 вакансий.
Зачем столько цифровиков, если можно просто вставить MIPS ядро?
V>>>Я бы взял чуть другую схему для бОльшей добротности, но не суть. FM>>Опять телепатия.
V>Чего-чего? V>Приведена не самая удачная композиция для фильтра 2-го порядка. Есть другая, где можно достичь бОльшей добротности.
Всего лишь первая попавшаяся картинка фильтра, поэтому пытаться что-либо получить из нее имхо есть телепатия.
FM>>>>И если будет нормальный инструмент позволяющий переводить формулы в схемы с гибкой настройкой конфигурации (тип фильтра, power/area/noise margin etc) с учетом используемой технологии, то вполне им вполне можно будет пользоваться для ускорения дизайна.
V>>>Можно. Но только в узких рамках заранее заготовленных кирпичиков, увы. Точно так же как в графике можно строить на заранее заготовленных кирпичиках. Но если их не хватает — определять их самим. Покажи мне как в тексте определить свой, достаточно сложный кирпичик? Я уже 3-й пост подряд прошу показать пример на языке для аналоговых схем.
FM>>Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.
V>Одних фильтров многие десятки, если не многие сотни. Не получится с формулой-то. Тем более, что отталкиваясь от формулы, мы отрезаем себе самую фишку аналогового дизайна — это "уровень полезности" каждого элемента. В хорошем аналоговом идзайне на активных элементах зачастую более одной ф-ии. Например, "образцовая" точка компрессора может служить дополнительно ФВЧ с нужной частотой среза. Формулой и кирпичиками это не выразить в общем случае, надо смотреть конкретный дизайн. Ну и я плохо себе представляю тектовую аннотацию к формуле, когда у нас выбор кирпичиков идет из сотен. Эта аннотация становится невыразительной, т.е. китайской грамотой. Уже захочется именно посмотреть на саму схему реализации. Т.е. опять придем к графическому отображению.
Вот ты используешь в своем фильтре операционый усилитель. Ты как его описываешь? В виде полной электрической схемы или используешь как черный ящик модель, предоставляемую изготовителем? А теперь представь себе, что ты описываешь нужные тебе характеристки ОУ в виде текста, а программа автоматически находит подходящий компонент либо генерит свой собственный. Неужели это не ускорит разработку?
И не всегда нужны такие навороченные фильтры, иначе бы не существовало кучи генераторов фильтров.
Ты, почему-то, занимаешь экстремальную позицию, или текст или графика. Ради бога, никто не мешает в нужных местах спуститься на уровень ниже и немного подшаманить.
FM>>Основная проблема не в самой конфигурации, а выборе нужной из design constraints и последующем выборе оптимальных размеров элементов. На это уходит основное время.
V>Это в простейших случаях так... Например, для подбора кондеров по питающим шинам.
Это для печатных плат. А для чипов, если у тебя операционник из десятка транзисторов, то ты должен выбрать правильный размер (длина, ширина) каждого из них, исходя из взаимосвязанных критериев: Noise, Linearity, Gain, Supply Voltage, Voltage Swing, Speed, Input/Output Impedance, Power Dissipation
FM>>Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.
V>Т.е. я таки прав относительно обобщенного дизайна? Я правильно понимаю приведенный тобой факт?
Очередной раз повторяю
"C аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты."
Что может быть непонятного? Да, в аналоге используются схемы. При этом с точки зрения количества элементов аналог с сотни раз проще цифры.
Считать при этом, что из-за простоты составляющих элементов, цифровой дизайн проще, чем аналоговый, это такая же глупость, как считать
что программа в 1000 строк на ассемблере сложнее 100К строк на C++.
FM>>>>В графическом виде ты получишь: FM>>>>1. Проблему, если поставщик схемы не имеет версии для твоего САПР-а
V>>>Для того и существуют взаимные экспорты в разные популярные форматы. FM>>Разумеется в таком случае тебе не составит труда взять какой-нибудь пример из LTSpice и сконвертировать его, скажем, в SIMetrix.
FM>>>>2. Отсутствие diff
V>>>Почти все форматы таки текстовые и даже вполне читабельные. FM>>Что же это за форматы?
V>Ну мне приходилось переносить м/у 3-мя разными сапрами и я не видел проблем. Правда, в одном случае накатал за пол-дня конвертер сам, т.к. автоматом не умел. Но там текстовый формат таков, что как раз хорошо подходит для машинного чтения. Реально сложных форматов у САПР-ов из этой области я не видел. Покажи сложный формат, на котором у тебя случились те самые проблемы.
V>>>Это у тебя опять же от незнания. Давно устоялось относительно малое число стандартов файлов в этой области. FM>>Так назови же мне их. V>Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают.
Это стандарт? Вот openAcces более менее можно назвать стандартом (сюрпрайз — формат бинарный).
edif можно назвать стандартом.
V>>>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто. FM>>И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты, FM>>так называемые Standard Cell Library Design Engineers.
V>Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет?
Да, нарисовали схему, сделали нетлист, и началась основная работа. Написание скриптов для corner analysis, для monte-carlo simulation, скриптов для обработки результатов симуляции, написания правил drc, lvs, erc, синтеза.
V>(скипнул код)
FM>>Еще раз этот код не для синтеза, а для ускорения моделирования.
V>Отличный пример, спасибо. Сравни теперь со схемой функциональной из 3-х квадратиков. ИМХО, приведенный код — китайская грамота в сравнении с наглядным представлением. По крайней мере, объяснить принцип этого способа АЦП новичку по исходному коду невозможно никак. В тексте отсутствует важный момент — наглядность одновременности происходящего.
Прости, зачем мне наглядность для данного случая? Я не буду использовать ее чтобы объяснять новичку. Мне нужно чтобы оно моделировалось не сутки, а хотя бы часов 6.
Твоя схема из трех квадратиков может состоять из таких же блоков написанных на verilog-a. FM>>Я обычно делаю так: в процессе создания аналоговых блоков, одновременно пишу поведенческую модель, которую затем подставляю вместо реальной ячейки, когда мне не нужно точное функционирования данного блока.
V>А Симулинк не пробовал?
Нет, потому что мне нужно одновременно использовать блоки из реальных элементов. Симулинк получил возможность совместного моделирования с моим симулятором не очень давно.
Здравствуйте, FragMent, Вы писали:
V>>Я вот этого аргумента не понимаю насчет десятка тыщ вентилей... Это точно всерьез аргумент не ради троллинга? По основанию 2 — это 11 уровней иерархии всего. А если взять нормальную декомпозицию по основанию несколько десятков, то получим всего лишь 4 уровня иерархии типовых "кирпичиков". Полнейшая ерунда. FM>Обычный эффект масштаба. Тебя не смущает, что СУБД для хранения 100Мб данных и 1 Тб данных, скорее всего потребуются разные.
Признаюсь, я не понял сути возражения... если это было возражение, конечно...
FM>Вот есть микроконроллер, у которого схема тактирования работает от внешнего кварца (маленький аналоговый блочок в десяток транзисторов), он какой? Цифровой или цифроаналоговый? Скорее всего цифровой.
Ес-но цифро-аналоговый прямо по-определению. К тому же, а порты вводы/вывода прямо таки цифровые у всего девайса в целом? Да фактически никогда. Т.е. еще будет согласование и преобразование. Итого, в типовой схеме из полусотни элементов цифровым будет только один элемент — микроконтроллер... Который, повторюсь, типовой, а схема на нем — уникальна.
FM>А если мы добавим внутрь микроконтроллера PLL как черный ящик, он превратиться в цифро-аналоговую схему? На мой взгляд — нет, но кто-то может думать иначе.
Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи. Всякие уникальности должен обыгрывать софт.
Ну я конечно всерьез не рассматриваю FPGA. Эта штука изначально предназначалась для прототипирования. Делать на ней конечные решения — это получать то самое "решение для бедных". И скорости не те и шум и потребление и вообще...
FM>Мне это говорит о том, что стоимость аналоговых схем выше за счет более сложного техпроцесса, более низкого выхода годных, и маркетинговых соображений.
Нет, просто меньшая масштабируемость. Вот выпустили партию печатных плат под материнки из 10000 шт и всё. А выпуск цифровых микросхем идет на миллионы. Поэтому в большинстве конечных потребительских схем сидит приличная доля стоимости разработки. Да и сложнее эти схемы, чем цифровые. Слишком много подробностей технологии нужно учитывать в дизайне. Сравни с голой булевской логикой, где ничего не надо учитывать, кроме задержек.
FM>А также, что производительность цифровых дизайнеров выше, чем аналоговых.
Потому что специализация Уже, а работа однообразнее. Производительность веб-мастеров тоже выше производительности С++ программистов, если в тиках процессора считать по готовой программе...
Потому что меньше болит голова о технологической стороне продукта. Знай себе в песочнице ковыряй.
FM>Кстати, здесь написано, что производительность дизайнера на уровне схемы 100-200 гейтов в неделю, а на уровне HDL — 1-2 килогейта.
Когда тебе порты выхода с реальными исполнительными устройствами сопрягать надо будет, не поможет тебе никакой HDL. Будут те же 100-200 компонент в неделю.
V>>Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте. FM>Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо?
Дык и я про то, что меняется существенно только гибридная часть, которую на HDL писать не эффективно до сих пор.
V>>ИМХО, вот он взгляд из подвала. Это цифра идет как вспомогательная. FM>Значит если между процессором и видеокартой связь осуществляется через аналоговые трансиверы-ресиверы, то цифра в процессоре стала вспомогательной?
Да, цифра изначально и задумывалась как вспомогательный инструмент, апроксимирующий требуемые аналоговые сигналы, что не так?
По мере своего удешевления цифра заменяет аналог. Решение-то в цифре сложнее, ес-но, но при этом все дешевле и дешевле, именно из-за той самой однородности дизайна и гибкости через софт или микропрограммы (таблицы истинности ф-ий переходов автоматов, вшитые в ПЗУ).
FM>>>Можем еще сравнить по количеству вакансий.
V>>Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств. FM>Там где ищут одновременно аналоговых и цифровых спецов. FM>Например сегодня на http://www.ic-resources.com/ Digital IC 233 вакансии, analog/rf IC 112 вакансий. FM>Зачем столько цифровиков, если можно просто вставить MIPS ядро?
Цифровой дизайн сложнее гораздо. Для эмуляции простого бивадратного аналогового фильтра на 15 элементах надо десятки тысяч вентилей для умножителей, сумматора, ПЗУ микропрограммы, ЦАП/АЦП.
И вообще, ты не туда смотришь. Надо смотреть на вакансии разработчиков конечных схем и интересоваться, чем они занимаются. Я работал по цифровой "половине" дизайна, но почему-то минимум половину трудозатрат шло на разработку сопряжений с аналоговой частью, в т.ч. через софт. Думаю, ты не верно представляешь себе занятость цифровика в процессе разработки конечных устройств.
V>>>>Я бы взял чуть другую схему для бОльшей добротности, но не суть. FM>>>Опять телепатия.
V>>Чего-чего? V>>Приведена не самая удачная композиция для фильтра 2-го порядка. Есть другая, где можно достичь бОльшей добротности. FM>Всего лишь первая попавшаяся картинка фильтра, поэтому пытаться что-либо получить из нее имхо есть телепатия.
Э нет, коль в исходной формуле участвует добротность и шла речь об отображении формулы на схему, а не наоборот, то пример был неудачен. Читать предыдущее предложение до просветления.
Задача отображения схему на формулу и формулы на схему — они ой какие разные.
FM>>>Про кирпичики: количество конфигураций ограничено, например токовых зеркал я могу вспомнить около десятка, число дифкаскадов тоже невелико и т.д.
V>>Одних фильтров многие десятки, если не многие сотни. Не получится с формулой-то. Тем более, что отталкиваясь от формулы, мы отрезаем себе самую фишку аналогового дизайна — это "уровень полезности" каждого элемента. В хорошем аналоговом идзайне на активных элементах зачастую более одной ф-ии. Например, "образцовая" точка компрессора может служить дополнительно ФВЧ с нужной частотой среза. Формулой и кирпичиками это не выразить в общем случае, надо смотреть конкретный дизайн. Ну и я плохо себе представляю тектовую аннотацию к формуле, когда у нас выбор кирпичиков идет из сотен. Эта аннотация становится невыразительной, т.е. китайской грамотой. Уже захочется именно посмотреть на саму схему реализации. Т.е. опять придем к графическому отображению. FM>Вот ты используешь в своем фильтре операционый усилитель. Ты как его описываешь? В виде полной электрической схемы или используешь как черный ящик модель, предоставляемую изготовителем? А теперь представь себе, что ты описываешь нужные тебе характеристки ОУ в виде текста, а программа автоматически находит подходящий компонент либо генерит свой собственный. Неужели это не ускорит разработку?
Дык, а в чем тогда профит текста, если я и так в графике могу нарисовать в виде черного ящика любой, сколь угодно сложный элемент.
Ты же ведь манипулирующие высказывания приводил (из разряда рекламных, очевидно), что вот мол в графике 200 гейтов в неделю. Реально будет 200 компонент, а не гейтов. А при правильно выбранной декомпозии/иерархии счет гейтов может пойти на миллионы, а не на тысячи. Просто работать в графике надо уметь. Без ложной скромности скажу так, что очень и очень немногие люди обладают умением проектировать конечные схемы хотя бы близко к потребительскому качеству. Или те самые упомянутые "трюки", типа ячейки динамической памяти на обычном транзисторе с висящим эмиттером. Т.е. полноценно проектировать и в графике в т.ч. (а реальное проектирование любых технологических вещей идет только в графике), в общем, работать с этим с нужной отдачей могут очень немногие. Сие факт, наблюдаемый мною много лет. Зато с текстом работать может любой, кому под силу освоить язык хотя бы уровня BASIC. ИМХО, причины распространенности текста ровно такие же, почему убогая Джава стала мейнстримом. В ограниченности сила, бо меньше поле для ошибок.
FM>И не всегда нужны такие навороченные фильтры, иначе бы не существовало кучи генераторов фильтров.
Если бы не нужны, то генераторов было бы немного, не находишь? Да и генераторы-то по большей части для цифровых фильтров.
"Навороченные фильтры", как ты говоришь, они от экономии. Например, некоторые структуры биквадратных могут работать как ФНЧ, ФВЧ, ПФ, РФ. Всё в одном. Ну и при распознавании сигналов действительно сначала аппроксимируют передаточную ф-ию, а потом подбирают структуру фильтра, чтобы эта ф-ия была заведомо реализуемой. Цифра-то на сегодня все еще способна обслужить лишь низкочастотный диапазон, се ля ви. Остальное как и прежде. Поломай как-нить сотовый да распили ему экранирующие запаянные коробки в радиочасти, полюбуйся.
FM>Ты, почему-то, занимаешь экстремальную позицию, или текст или графика. Ради бога, никто не мешает в нужных местах спуститься на уровень ниже и немного подшаманить.
Я? Боже упаси. Если читал сначала, то наоборот. Я говорил, что максимальная отдача от обоих. Более того, высказывал такую мысль, что многую рутину удобнее бывает набить в тексте, но просматривать результат таки в графике. Как всем понятный пример приводил ход работы веб-дизайнера. Пишет он HTML-код, но смотрит затем на графическое представление страницы. Что есть "графическое" я пытался дать определение здесь: http://www.rsdn.ru/forum/philosophy/4755042.1.aspx
V>>Это в простейших случаях так... Например, для подбора кондеров по питающим шинам. FM>Это для печатных плат. А для чипов, если у тебя операционник из десятка транзисторов, то ты должен выбрать правильный размер (длина, ширина) каждого из них, исходя из взаимосвязанных критериев: Noise, Linearity, Gain, Supply Voltage, Voltage Swing, Speed, Input/Output Impedance, Power Dissipation
И че? Все эти тулзы автоматом никак?
FM>>>Еще раз. Такие системы еще не слишком распространены, поэтому в открытом доступе инфы практически нет.
V>>Т.е. я таки прав относительно обобщенного дизайна? Я правильно понимаю приведенный тобой факт? FM>Очередной раз повторяю FM>"C аналоговым дизайном это пока не так. Хотя и там понемногу ситуация меняется. Появляются коммерческие решения, в которых аналоговые блоки описываются уравнениями, из которых генерируются нетлисты." FM>Что может быть непонятного? Да, в аналоге используются схемы. При этом с точки зрения количества элементов аналог с сотни раз проще цифры.
С т.з. кол-ва элементов да. А т.з. характеристик происходящих процессов — гораздо сложнее. Ну и про кол-во уникальных дизайнов замечание делал многократно.
FM>Считать при этом, что из-за простоты составляющих элементов, цифровой дизайн проще, чем аналоговый, это такая же глупость, как считать FM>что программа в 1000 строк на ассемблере сложнее 100К строк на C++.
Сложность обычно оценивается в трудоемкости помноженной на требуемую квалификацию. Да, я считаю, что "голый" цифровой дизайн относительно несложный. Не сложнее программирования на Джава или VB. Собственно, уже все процессы и наработки из управления разработкой в ПО перешли в отрасль цифрового дизайна. Потому что характеры работ близки.
V>>Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают. FM>Это стандарт?
Обрати внимание на смешной размер снипетта кода, полностью решающего проблему.
FM>Вот openAcces более менее можно назвать стандартом (сюрпрайз — формат бинарный).
На мой взгляд бинарные форматы парсить несоизмеримо легче текстовых. Во-первых они более детерминированы, во-вторых, меньше требуется преобразований числовых значений. А если еще разработчики формата, не будь дураки, описали его спецификацию через ASN.1 — вообще сказка. Само будет парсится... Или таки дураки?
V>>>>Боюсь, динамическую ячейку памяти в текстовом формате не спроектировать, это сугубо технологический трюк. Хотя, упомянуть заранее спроектированную ячейку затем из текста — запросто. FM>>>И как это противоечит моим словам? А разработкой ячеек памяти, как, впрочем, и цифровых ячеек занимаются отдельные аналоговые специалисты, FM>>>так называемые Standard Cell Library Design Engineers.
V>>Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет? FM>Да, нарисовали схему, сделали нетлист, и началась основная работа.
Основная работа — это разработка работющей схемы. Остальное — это лишь ее расчеты и доводка. Во многом автоматизированная и не творческая стадия... которую женщины, по моим наблюдениям, делают лучше мужчин.
V>>А Симулинк не пробовал? FM>Нет, потому что мне нужно одновременно использовать блоки из реальных элементов.
Здравствуйте, FragMent, Вы писали:
V>>Суть см. по нетлисту. FM>А зачем? Если суть можно смотреть по тексту на VHDL?
Дык, если только булевскую логику — то ради бога. А если сложная схема из активных/пассивных элементов, то я без графики даже не разберусь, как она работает. Надо в голове представить одновременно происходящие аналоговые процессы в куче связанных элементов и без графического отображения это просто нереально.
N>>>>А что плохого в сотнях связей для сложного блока, если он действительно сложный? FM>>>1. Та же самая ситуация со вставкой нового блока. Раздвигаем старые блоки и случайно закорачиваем две из сотен связей. Очень легко упустить этот момент, особенно если у связей нету имен.
V>>Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись. FM>Ой, ну тогда ручками будешь перерисовывать сотни связей.
Ниче не понял... что за CAD?
Почему нельзя просто подвинуть блоки и почему связи сами не двигаются за блоками? А если использовать шины, то подвинуть целую шину — это вообще ерунда.
FM>Кстати, что это у тебя за трассировка такая умная, что знает что у тебя net0078 не должна быть закорочена с net0126?
Дык, если на получившуются результирующую линию выйдет пара out-пинов, то какие проблемы?
V>>А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам. FM>Пожалуйста, назови хотя бы три САПРа, поддерживающих такую функциональность.
Как минимум PCAD, ORCAD и если склероз не изменяет — Protel.
FM>>>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.
V>>Враки. FM>Это следует понимать как "Я, vdimas, создал N схем с более чем 10К элементов и ни разу не сталкивался с такой проблемой" или "я -- болтун-теоретик не воспринимающий факты, которые противоречат моему мнению"?
Нет, не сталкивался на сотнях схем ни разу. А факты мы сейчас рассматриваем очень субъективные. И 10К элементов, требующих ревью — это нубство, сорри. На любом уровне иерархии не должно быть более нескольких десятков/сотен элементов, иначе такой дизайн только в мусорку. Если же тебе понадобилось просмотреть ЛЮБОЙ сигнал сквозь мн-во уровней иерархии, то это лишь говорит о кривизне дизайна и ни о чем более. В ПО я тоже наблюдал аналогичные косяки, но, тем не менее, на попытки подобных заявлений, о необходимости сквозного ревью сразу нескольких уровней иерархии, буду отвечать — враки. Не требуется! При нормальной декомпозиции и грамотном разделении функциональности этого не надо. Принципы "грамотного" разделения давно сформулированы и они универсальны как для ПО, так и для схемотехники... аналоговой в т.ч.
V>>Это если цифровая схемотехника "сама в себе" и собрана из готовых кирпичиков (или вентилей). А если требуется эти кирпичики разрабатывать с 0-ля — то увы. FM>Жаль тебя разочаровывать, но эти цифровые кирпичики разрабатываются даже в случае схемотехнического ввода схемы.
Дык, я не против кирпичиков, я говорю о том, что возможности разрабатывать кирпичики исключительно в тексте очень ограничены, т.к. могут стартовать лишь с уровня других, заранее предопределенных кирпичиков.
FM>Еще одну причину вспомнил. В нормальной цифровой схеме обычно применяется Boundary scan testing. Представляешь как весело руками последовательно соединить все ячейки?
Зачем руками? И почему все?
FM>И работа с нетлистом тебе в этом случае особо не поможет, потому что в нетлисте нет информации о взаимном расположении ячеек и можешь получить лишние проводники из одного края кристалла на другой. В то же время синтезатор знает какой регистр за каким следует и может, при необходимости, перекоммутировать BS связи.
Похоже ты уже грубо путаешь то, что делаешь ручками и то, что делают тулзы. Так вот, verilog (коль ты его упоминаешь) прекрасно отображается на схематику и обратно. Поэтому всё, что доступно после этапа текстовой набивки схемы, доступно и после этапа ее графической набивки. Более того, есть тулзы, которые позволяют и так и так практически одновременно.
FM>А представляешь какую визуальную грязь добавит эта дополнительная куча связей, идущая сквозь все ячейки по иерархии?
Курить понятие "шины" до полного просветления. Пример Ленинград-1 я уже приводил. Это пример относительно несложной схемы, которая, темне менее, имеет несколько сотен связей. Без шин была бы грязь. А представь более сложные блоки?
V>>Да пожайлуйста. Для цифровых подзадач вполне пойдет. Как когда-то процессоры заменили автоматику и вместо разработки автоматики стали писать программы на процессора на других языках. Только это не отменяет этапа разработки схемы даже на основе процессора со всей требуемой обвеской, когда процессор управляет некоим реальным блоком вместо автоматики. Все-равно конечную схемы на основе процессора без графики не представить, хоть тресни. Пусть даже в нем "унутре" сколь угодно сложная программа. Даже возьми материнки современных компов или любые платы раширения. Я периодически взглядываюьс в разводку и расположение и могу тебя заверить, что там ручками доводилось обязательно как первое, так и второе. Но в тексте это на сегодня невозможно ни в одном из тулзов. Получается, что де-факто компьютерные платы таки разрабатывают в графике? Просто ты работаешь в другом направлении.
FM>Итак, ты согласился, что для цифровых подзадач текст подходит.
Я с этим не спорил ни разу. Наоборот, я поправляю все твои попытки неправомерного обобщения, что речь идет сугубо об однородном цифровом дизайне.
FM>А, учитывая полную победу цифровых HDLs над schematic entry, текст подходит для них лучше графики.
Для этой весьма узкой этой ниши дизайна кристаллов — да ради бога. Это пришло из FPGA, напомню. Эдакое прототипирование, только не в софте, а железе. Сам бог велел писать ПО. Но как-то ты весело уже наверно 10-й раз игнорируешь момент разработки конечных схем на основе цифровых. И вот сейчас про упомянутые материнки сделал вид что понял. Сколько разновидностей материнок приходится на один чипсет?
И тут я писал:
Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи.
Поэтому я лишь вижу, что дизайнов конечных схем на несколько порядков больше дизайнов цифровых микросхем, а в этих дизайнах конечных схем обязательно используется графика. Итого, в современной схемотехнике работают в графике на порядки больше, чем с текстом.
FM>В этом то и суть. Ни ты (со стороны board level engineers), ни я (со стороны analog IC designers) не можем утверждать, что графика по удобству превосходит текст, поскольку мы просто не имеем дело со схемами таких масштабов. Цифровые инженеры первыми столкнулись с дизайнами в сотни тысяч и миллионы элементов и деньгами проголосовали за текст.
Потому что цифровая разработка сегодня — это разработка модели. Это классическое прототипирование. Это и есть ПО. И дело тут не в кол-ве вентилей. Это упирание на кол-во вентилей нубство и еще рекламный трюк (мне уже надоело упоминать иерархии и декомпозицию, которые разруливают хоть миллионы вентилей на раз). Дело в самой однородности процесса. Все происходит в "песочнице", т.е. в изолированных от подробностях абстракциях. Поэтому наработки ПО вполне прокатывают. Но таки при проектировании тех же микропроцессоров, все-равно графика используется и видел не раз. Основные блоки, их функциональность и связи, протокол м/у ними и т.д., все это разрабатывается в графике, хоть пусть подробности реализации потом — в тексте. Дык, подробности всегда было удобней в тексте, даже вовремена PCAD. Например, проставить ли быстро заменить номиналы транзисторов на аналоги и т.д. — нет ничего удобнее чем работа через текст в таких операциях, ес-но, но лишь потому, что идет редактирование сугубо текстовых св-в элементов. Это надо понимать.
V>>С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать? FM>Да кто тебе мешает? Имеешь нетлист, перерисовываешь его руками и меняй сколько хочешь.
В нетлисте из более десятка связей утонешь, уже ничего не понятно. Тем более, если делаешь всякие технологические трюки. Поэтому без графики — никуда.
Да и вообще, посмотри хоть раз за работой разработчика схемотехнических решений (трюков). Даже если он "салфетке" что-то чиркает, поверь, он не текстовую таблицу связей там чиркает, а графические элементы и связи.
FM>>>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая). FM>>>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.
V>>А что за САПР-ы были? FM>Cadence Composer -> Mentor Graphics DesignArchitect FM>Mentor Graphics DXDesigner -> Cadence Composer
Ну, посмотрел форматы... Коллега, не прими за наезд, но похоже от программирования ты малость далек, что написать утилиту конвертирования вылилось в "такую-то матерь" и еще пришлось что-то делать ручками. Кстати, именно во время работы схемотехником мне пришлось написать просто тонны утилит. В т.ч. для расчета параметров схем и моделирования. Возьмите полноценного программиста в команду. Вы даже не представляете, какой буст разработки это даст.
V>>Но даже расположи эти сугубо цифровые схемы на плате. Пусть автоматом. Зато мы потом берем и измеряем мощность*длину/ширину питающих соединений, полученных де-факто после размещения и разводки (даже если они автоматические). Уже кое-где требуется кондеры вставлять по питанию, а кое-где увеличивать их емкость. И вот уже появляются новые элементы в схеме или меняются номиналы имеющихся, что влечет за собой изменение их размеров и заход на новую итерацию размещения и разводки. В голом тексте это вообще никак не работает. FM>Еще раз. Когда у тебя окажется сотня тысяч связей, то руками ты физически не сможешь модифицировать все сложные места за приемлемое время. Ты просто синтезируешь схему (например при помощи IC compiler), экстрагируешь паразитные параметры (StarRC) и моделируешь схему с их учетом (PrimeTime для проверки целостности сигналов и проблем с мощностью). Если есть проблемы с какими-то связями, то возвращаешься к IC Compiler и вписываешь дополнительные ограничения в скрипт для синтеза (например команда set_clock_latency, set_clock_transition для установки правильного тайминга сигналов генератора)
Т.е. загублять параметры дизайна вместо того, чтобы попытаться переиначить декомпозицию и связь м/у "блоками"?
А что схема делает, если не секрет?
Здравствуйте, vdimas, Вы писали:
FM>>Обычный эффект масштаба. Тебя не смущает, что СУБД для хранения 100Мб данных и 1 Тб данных, скорее всего потребуются разные. V>Признаюсь, я не понял сути возражения... если это было возражение, конечно...
Не притворяйся. Методы работающие для малых систем (или для малого числа элементов) не всегда подходят для больших. Примеров тысячи.
FM>>Вот есть микроконроллер, у которого схема тактирования работает от внешнего кварца (маленький аналоговый блочок в десяток транзисторов), он какой? Цифровой или цифроаналоговый? Скорее всего цифровой.
V>Ес-но цифро-аналоговый прямо по-определению. К тому же, а порты вводы/вывода прямо таки цифровые у всего девайса в целом? Да фактически никогда. Т.е. еще будет согласование и преобразование. Итого, в типовой схеме из полусотни элементов цифровым будет только один элемент — микроконтроллер... Который, повторюсь, типовой, а схема на нем — уникальна.
Не понял. Я спросил микропроцессор цифровой или цифроаналоговый. Ты ответил "Ес-но цифро-аналоговый прямо по-определению" и буквально в следующей строчке пишешь "цифровым будет только один элемент — микроконтроллер". Ты уж определись.
FM>>А если мы добавим внутрь микроконтроллера PLL как черный ящик, он превратиться в цифро-аналоговую схему? На мой взгляд — нет, но кто-то может думать иначе.
V>Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи. Всякие уникальности должен обыгрывать софт.
Противоречие. Если цифровых дизайнов немного, то и вакансий должно быть мало. Чего в природе не наблюдается. V>Ну я конечно всерьез не рассматриваю FPGA. Эта штука изначально предназначалась для прототипирования. Делать на ней конечные решения — это получать то самое "решение для бедных". И скорости не те и шум и потребление и вообще...
Фирма Xilinx смотрит на тебя с недоумением. FPGA отличное решение, когда не нужно большое количество конечных устройств или перепрограммирование налету. Опять же количество вакансий говорит само за себя. FM>>Мне это говорит о том, что стоимость аналоговых схем выше за счет более сложного техпроцесса, более низкого выхода годных, и маркетинговых соображений.
V>Нет, просто меньшая масштабируемость. Вот выпустили партию печатных плат под материнки из 10000 шт и всё. А выпуск цифровых микросхем идет на миллионы. Поэтому в большинстве конечных потребительских схем сидит приличная доля стоимости разработки. Да и сложнее эти схемы, чем цифровые. Слишком много подробностей технологии нужно учитывать в дизайне. Сравни с голой булевской логикой, где ничего не надо учитывать, кроме задержек.
Попробуй спроектировать простой процессор с 5-stage конвейером и блоком предсказания переходов и потом обсудим простоту цифрового дизайна.
FM>>А также, что производительность цифровых дизайнеров выше, чем аналоговых.
V>Потому что специализация Уже, а работа однообразнее. Производительность веб-мастеров тоже выше производительности С++ программистов, если в тиках процессора считать по готовой программе... V>Потому что меньше болит голова о технологической стороне продукта. Знай себе в песочнице ковыряй.
А у ассемблерщиков еще круче! Сидят эти C++ программисты в своей скучной песочнице и не болит у них голова о распределении регистров.
И C++ программы состоят из типовых решений. Везде там for-ы да if-ы.
FM>>Кстати, здесь написано, что производительность дизайнера на уровне схемы 100-200 гейтов в неделю, а на уровне HDL — 1-2 килогейта.
V>Когда тебе порты выхода с реальными исполнительными устройствами сопрягать надо будет, не поможет тебе никакой HDL. Будут те же 100-200 компонент в неделю.
А когда тебе потребуется сделать в железе свою систему для high frequency trading ты тоже будешь пилить 100-200 компонент в неделю или перейдешь все же на более подходящий инструмент?
FM>>Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо? V>Дык и я про то, что меняется существенно только гибридная часть, которую на HDL писать не эффективно до сих пор.
Я не про гибридную часть, а про сопряжение покупных IP блоков между собой (например ядро ARM, DSP core, MPEG-декодер).
V>Да, цифра изначально и задумывалась как вспомогательный инструмент, апроксимирующий требуемые аналоговые сигналы, что не так? V>По мере своего удешевления цифра заменяет аналог. Решение-то в цифре сложнее, ес-но, но при этом все дешевле и дешевле, именно из-за той самой однородности дизайна и гибкости через софт или микропрограммы (таблицы истинности ф-ий переходов автоматов, вшитые в ПЗУ).
Я тебя не пойму. То ты говоришь, что цифры очень мало, то что она все больше заменяет аналог.
FM>>>>Можем еще сравнить по количеству вакансий. V>>>Смотря где искать вакансии. Мне постоянно приходят предложения, связанные с дизайном схем и конечных устройств. FM>>Там где ищут одновременно аналоговых и цифровых спецов. FM>>Например сегодня на http://www.ic-resources.com/ Digital IC 233 вакансии, analog/rf IC 112 вакансий. FM>>Зачем столько цифровиков, если можно просто вставить MIPS ядро?
V>Цифровой дизайн сложнее гораздо. Для эмуляции простого бивадратного аналогового фильтра на 15 элементах надо десятки тысяч вентилей для умножителей, сумматора, ПЗУ микропрограммы, ЦАП/АЦП.
Цитирую тебя
Ну и опять же, учитывая относительно большую повторяемость цифровых компонент, то бишь относительно малое их разнообразие, оценивать объем дизайна по денежному обороту — это самое настоящее нубство. Например, на одних и тех же ядрах MIPS без переделок выпускают многие сотни (если не тысячи) номиналов якобы "железных" микросхем: видео/аудио/сетевых кодеков. А реально там один и тот же цифровой дизайн, где отличия идут в основном в гибридной части и в прошитом софте.
и повторяю вопрос: зачем столько цифровиков? V>И вообще, ты не туда смотришь. Надо смотреть на вакансии разработчиков конечных схем и интересоваться, чем они занимаются. Я работал по цифровой "половине" дизайна, но почему-то минимум половину трудозатрат шло на разработку сопряжений с аналоговой частью, в т.ч. через софт. Думаю, ты не верно представляешь себе занятость цифровика в процессе разработки конечных устройств.
Да без проблем. Первая страница Приглашаем на работу на электониксе. Вакансий инженеров-разработчиков три. В двух из них требуется знание
verilog/VHDL
V>Э нет, коль в исходной формуле участвует добротность и шла речь об отображении формулы на схему, а не наоборот, то пример был неудачен. Читать предыдущее предложение до просветления. V>Задача отображения схему на формулу и формулы на схему — они ой какие разные.
Спасибо, что разоблачил товарищей Сталлена и Кея, предложивших данную структуру полвека назад.
V>Дык, а в чем тогда профит текста, если я и так в графике могу нарисовать в виде черного ящика любой, сколь угодно сложный элемент.
Нарисуй мне, например, корректор фактора мощности из элементов в виде черного ящика.
V>Ты же ведь манипулирующие высказывания приводил (из разряда рекламных, очевидно), что вот мол в графике 200 гейтов в неделю. Реально будет 200 компонент, а не гейтов. А при правильно выбранной декомпозии/иерархии счет гейтов может пойти на миллионы, а не на тысячи. Просто работать в графике надо уметь.
Конечно, ты просто мастер. А те "манипулирующие высказывания приводил (из разряда рекламных, очевидно" написал какой-то лох из University of California, Berkeley. V>Без ложной скромности скажу так, что очень и очень немногие люди обладают умением проектировать конечные схемы хотя бы близко к потребительскому качеству. Или те самые упомянутые "трюки", типа ячейки динамической памяти на обычном транзисторе с висящим эмиттером. Т.е. полноценно проектировать и в графике в т.ч. (а реальное проектирование любых технологических вещей идет только в графике), в общем, работать с этим с нужной отдачей могут очень немногие. Сие факт, наблюдаемый мною много лет. Зато с текстом работать может любой, кому под силу освоить язык хотя бы уровня BASIC. ИМХО, причины распространенности текста ровно такие же, почему убогая Джава стала мейнстримом. В ограниченности сила, бо меньше поле для ошибок.
Мой тезис: переход от схем к тексту в цифровом дизайне позволил увеличить продуктивность разработчиков и разрабатывать более сложные конструкции.
Все разговоры о дураках только от непонимания специфики.
FM>>Ты, почему-то, занимаешь экстремальную позицию, или текст или графика. Ради бога, никто не мешает в нужных местах спуститься на уровень ниже и немного подшаманить.
V>Я? Боже упаси. Если читал сначала, то наоборот. Я говорил, что максимальная отдача от обоих. Более того, высказывал такую мысль, что многую рутину удобнее бывает набить в тексте, но просматривать результат таки в графике. Как всем понятный пример приводил ход работы веб-дизайнера. Пишет он HTML-код, но смотрит затем на графическое представление страницы. Что есть "графическое" я пытался дать определение здесь: http://www.rsdn.ru/forum/philosophy/4755042.1.aspx
V>>>Это в простейших случаях так... Например, для подбора кондеров по питающим шинам. FM>>Это для печатных плат. А для чипов, если у тебя операционник из десятка транзисторов, то ты должен выбрать правильный размер (длина, ширина) каждого из них, исходя из взаимосвязанных критериев: Noise, Linearity, Gain, Supply Voltage, Voltage Swing, Speed, Input/Output Impedance, Power Dissipation
V>И че? Все эти тулзы автоматом никак?
Я ж и говорю. Только магма делала что-то автоматическое. Там ведь еще сложности, что параметры внутри схемы имеют огромный разброс. +/- 30% номинала резистора это нормальная ситуация. По прежнему больше искусство, чем наука.
V>>>Форматы PCAD в свое время поддерживали почти все и до сих многие поддерживают. FM>>Это стандарт?
V>Да. Все популярные тулзы для проектирования схем и печатных плат умели экспортировать/импортировать его форматы файлов. V>Кстати, с первых страниц гугля нашел насчет DIFF файлов от P-CAD: V>http://billauer.co.il/blog/2010/07/net-pcad-netlist-files-perl/
Ни один из САПРов, с которыми я работал его не поддерживал
V>Обрати внимание на смешной размер снипетта кода, полностью решающего проблему.
Ты сам когда-нибудь сравнивал нетлисты? Мне приходилось не раз. Удовольствие ниже среднего
FM>>Вот openAcces более менее можно назвать стандартом (сюрпрайз — формат бинарный).
V>На мой взгляд бинарные форматы парсить несоизмеримо легче текстовых. Во-первых они более детерминированы, во-вторых, меньше требуется преобразований числовых значений. А если еще разработчики формата, не будь дураки, описали его спецификацию через ASN.1 — вообще сказка. Само будет парсится... Или таки дураки?
Дураки. Они сразу код предоставляют. Но появился он относительно недавно. И не все его поддерживают, да и вряд ли будут.
V>>>Ну так у этих специалистов должен быть какой-то инструмент? Или они по-старинке ручками рисуют? А если я сам хочу разработать такой кирпичик, что мне делать? Таки будет мне нужна графика или нет? FM>>Да, нарисовали схему, сделали нетлист, и началась основная работа.
V>Основная работа — это разработка работющей схемы. Остальное — это лишь ее расчеты и доводка. Во многом автоматизированная и не творческая стадия... которую женщины, по моим наблюдениям, делают лучше мужчин.
Витать в облаках и придумывать новое — для молокососов . А вот сделать дизайн ячейки памяти работающей во всем диапазоне разбросов параметров, напряжений и температур с шестью сигмами (значит один дефект на миллиард ячеек) — вот работа для настоящих инженеров, которые не боятся ковыряться в деталях.
V>>>А Симулинк не пробовал? FM>>Нет, потому что мне нужно одновременно использовать блоки из реальных элементов.
V>А какие проблемы импортировать туда VHDL/verilog?
При чем тут VHDL? Мне нужно допустим, чтобы интегратор состоял из реальных транзисторов и конденсаторов, а компаратор был упрощенной моделью.
Кстати, даже с том же симулинке, если вдруг не окажется модели компаратора (я знаю что он там есть), все равно его придется описывать на языке m.
Здравствуйте, vdimas, Вы писали:
V>>>Для этого надо двигать элементы из режима прокладки связей, что есть "сам себе злобный буратино". Иначе их закоротить никак. Ну и после трассировки выдаст ошибку, не боись. FM>>Ой, ну тогда ручками будешь перерисовывать сотни связей.
V>Ниче не понял... что за CAD? V>Почему нельзя просто подвинуть блоки и почему связи сами не двигаются за блоками? А если использовать шины, то подвинуть целую шину — это вообще ерунда.
Я подумал, ты под режимом "прокладки связей" имеешь в виду как раз когда связи тянуться за блоками. Поэтому и предложил вариант, когда сначала отключаешь связи от блока, перемещаешь его и снова доводишь их. Но раз я тебя не так понял, то проблема закоротки, если связи случайно совпали остается. Пару раз у меня такое было. Повезло, словил быстро.
FM>>Кстати, что это у тебя за трассировка такая умная, что знает что у тебя net0078 не должна быть закорочена с net0126? V>Дык, если на получившуются результирующую линию выйдет пара out-пинов, то какие проблемы?
А если два in-пина?
V>>>А всего-то надо попросить вывести список всех пинов всех компонент, подключенных туда. Это многократно удобнее поиска по всем файлам. FM>>Пожалуйста, назови хотя бы три САПРа, поддерживающих такую функциональность.
V>Как минимум PCAD, ORCAD и если склероз не изменяет — Protel.
Надо будет поставить — посмотреть.
FM>>>>Нужно просмотреть каждую ветку, заходя рекурсивно в каждый блок. Очень легко пропустить что-нибудь.
V>>>Враки. FM>>Это следует понимать как "Я, vdimas, создал N схем с более чем 10К элементов и ни разу не сталкивался с такой проблемой" или "я -- болтун-теоретик не воспринимающий факты, которые противоречат моему мнению"?
V>Нет, не сталкивался на сотнях схем ни разу.
Переформулирую: "я написал 100 десятистрочных программ, поэтому знаю как написать программу в 100 тыс. строк" V>А факты мы сейчас рассматриваем очень субъективные. И 10К элементов, требующих ревью — это нубство, сорри. На любом уровне иерархии не должно быть более нескольких десятков/сотен элементов, иначе такой дизайн только в мусорку. Если же тебе понадобилось просмотреть ЛЮБОЙ сигнал сквозь мн-во уровней иерархии, то это лишь говорит о кривизне дизайна и ни о чем более. В ПО я тоже наблюдал аналогичные косяки, но, тем не менее, на попытки подобных заявлений, о необходимости сквозного ревью сразу нескольких уровней иерархии, буду отвечать — враки. Не требуется! При нормальной декомпозиции и грамотном разделении функциональности этого не надо. Принципы "грамотного" разделения давно сформулированы и они универсальны как для ПО, так и для схемотехники... аналоговой в т.ч.
Да даже в программировании есть такая проблема. Если бы ее не было, не появилось бы Аспектно-ориентированное программирование.
А уж для электроники и подавно. Нарисуй токовое зеркало и проведи от него два тока в разные блоки. Повесь на один из них шумящую схему — получишь шум на второй ветке. И блоки могут оказаться на разных уровнях иерархии. И цифровых сигналов по всей иерархии полно: POR, reset, clock, boundary scan.
FM>>Еще одну причину вспомнил. В нормальной цифровой схеме обычно применяется Boundary scan testing. Представляешь как весело руками последовательно соединить все ячейки?
V>Зачем руками? И почему все?
Это такой метод быстрого тестирования работоспособности цифровых схем. В тестовом режиме все регистры соединяются последовательно и на вход микросхемы подается последовательность сигналов, если она появляется на выходе без искажений, значит как минимум нет неработающих регистров и имеет смысл выполнять функциональное тестирование.
FM>>И работа с нетлистом тебе в этом случае особо не поможет, потому что в нетлисте нет информации о взаимном расположении ячеек и можешь получить лишние проводники из одного края кристалла на другой. В то же время синтезатор знает какой регистр за каким следует и может, при необходимости, перекоммутировать BS связи.
V>Похоже ты уже грубо путаешь то, что делаешь ручками и то, что делают тулзы. Так вот, verilog (коль ты его упоминаешь) прекрасно отображается на схематику и обратно. Поэтому всё, что доступно после этапа текстовой набивки схемы, доступно и после этапа ее графической набивки. Более того, есть тулзы, которые позволяют и так и так практически одновременно.
Это ты путаешь RTL verilog с Verilog netlist, который в принципе ничем не отличается от обычного нетлиста.
Вот тебе пример RTL кода
always @(posedge clk) begin
for (int i=0; i<3; i++) begin
if (enable[i]) begin
foo[i] <= newval[i];
end
end
end
В каком случае у программы больше информации о дизайне думаю объяснять не нужно.
V>Я с этим не спорил ни разу. Наоборот, я поправляю все твои попытки неправомерного обобщения, что речь идет сугубо об однородном цифровом дизайне.
Где я обобщал? Я всего лишь отметил, что люди столкнувшиеся со структурной сложностью, ушли от графики к тексту.
FM>>А, учитывая полную победу цифровых HDLs над schematic entry, текст подходит для них лучше графики.
V>Для этой весьма узкой этой ниши дизайна кристаллов — да ради бога. Это пришло из FPGA, напомню. Эдакое прототипирование, только не в софте, а железе. Сам бог велел писать ПО. Но как-то ты весело уже наверно 10-й раз игнорируешь момент разработки конечных схем на основе цифровых. И вот сейчас про упомянутые материнки сделал вид что понял. Сколько разновидностей материнок приходится на один чипсет?
Любой проц по сложности уделывает все материнки на его основе вместе взятые. В Интеле несколько сот инженеров работают над одним ядром в течении некольких лет.
V>Поэтому я лишь вижу, что дизайнов конечных схем на несколько порядков больше дизайнов цифровых микросхем, а в этих дизайнах конечных схем обязательно используется графика. Итого, в современной схемотехнике работают в графике на порядки больше, чем с текстом.
Напоминаю начало разговора: V>>А как же железки разрабатывают? Ты утонешь уже в сотнях элементов на одном уровне, а их сейчас на многие тысячи и даже миллионы в процах. WH>Verilog, VHDL,...
V>Дудки, это только 30% работы или меньше, остальные все равно в графике. Текст хорош исключительно для copy&paste и прочего быстрого размножения похожих частей, или для глобального поиска/земены, собсно, для таких работ в него и переключаются. А так в нем работать невозможно, ты на экране максимум пару десятков строчек кода увидишь, а это катастрофически мало. Поэтому все эти редакторы Verilog на самом деле графические.
На что тебе справедливо возразили, что процы в графике не разрабатывают. Теперь ты отстаиваешь другую позицию, что цифра однородна, поэтому ее можно в тексте описывать, и зачем-то переводишь разговор на конечные схемы. Думаю этот разговор стоит продолжать только если ты предъявишь современный графический дизайн (неважно цифровой или аналоговый) в сотню тысяч элементов.
V>Потому что цифровая разработка сегодня — это разработка модели. Это классическое прототипирование. Это и есть ПО. И дело тут не в кол-ве вентилей. Это упирание на кол-во вентилей нубство и еще рекламный трюк (мне уже надоело упоминать иерархии и декомпозицию, которые разруливают хоть миллионы вентилей на раз). Дело в самой однородности процесса. Все происходит в "песочнице", т.е. в изолированных от подробностях абстракциях. Поэтому наработки ПО вполне прокатывают. Но таки при проектировании тех же микропроцессоров, все-равно графика используется и видел не раз. Основные блоки, их функциональность и связи, протокол м/у ними и т.д., все это разрабатывается в графике, хоть пусть подробности реализации потом — в тексте. Дык, подробности всегда было удобней в тексте, даже вовремена PCAD. Например, проставить ли быстро заменить номиналы транзисторов на аналоги и т.д. — нет ничего удобнее чем работа через текст в таких операциях, ес-но, но лишь потому, что идет редактирование сугубо текстовых св-в элементов. Это надо понимать.
"Любую проблему можно решить путём введения дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции"
Непонятно, где ты мог видеть разработку микропроцессоров, ну да ладно. В топике про ДРАКОН ты ратовал за графику для программистов. Вот тебе, как ты сам говоришь, фактически программеры, которые имея выбор предпочли текст.
V>>>С аналоговыми упираемся в отображение "формул" на конкретную схему. Слово "конкретное" — ключевое. А если я хочу сами схемы пробовать/варьировать? FM>>Да кто тебе мешает? Имеешь нетлист, перерисовываешь его руками и меняй сколько хочешь.
V>В нетлисте из более десятка связей утонешь, уже ничего не понятно. Тем более, если делаешь всякие технологические трюки. Поэтому без графики — никуда.
Можешь использовать SpiceVision например V>Да и вообще, посмотри хоть раз за работой разработчика схемотехнических решений (трюков). Даже если он "салфетке" что-то чиркает, поверь, он не текстовую таблицу связей там чиркает, а графические элементы и связи.
Что мне смотреть, я сам придумываю схемотехнические решения
FM>>>>А стандарт на графическое типа есть, я уже упоминал edif. Дважды пытался его использовать, первый раз обломался и перерисовал все руками (благо схема была небольшая). FM>>>>Второй раз, при помощи питоновского скрипта и такой-то матери удалось худо-бедно перенести схему между САПРами. Но все равно пришлось еще пару тысяч элементов поправлять ручками.
V>>>А что за САПР-ы были? FM>>Cadence Composer -> Mentor Graphics DesignArchitect FM>>Mentor Graphics DXDesigner -> Cadence Composer
V>Ну, посмотрел форматы... Коллега, не прими за наезд, но похоже от программирования ты малость далек, что написать утилиту конвертирования вылилось в "такую-то матерь" и еще пришлось что-то делать ручками. Кстати, именно во время работы схемотехником мне пришлось написать просто тонны утилит. В т.ч. для расчета параметров схем и моделирования. Возьмите полноценного программиста в команду. Вы даже не представляете, какой буст разработки это даст.
"Такая-то матерь" была, потому что надо сделать быстро. Проблема была не в том, чтобы написать парсер, а в том что во-первых некоторые проперти разным софтом воспринимались по разному, а во-вторых разные координатные сетки и гриды приводили к тому, что элементы оказались слегка сдвинутыми относительно своих связей и уменьшенными. Первая проблема была решена регулярными выражениями, а вот бы вторая потребовала полноценного парсера, на который просто не было времени. В результате немного схитрил и сдвинул символы и потом руками довел шины.
Эта функциональность понадобилась мне два раза за 14 лет. Предлагаешь держать программиста ради такого случая? Если буду знать, что понадобится еще раз, сделаю без проблем.
А утилиты пишутся конечно. От лиспа до плюсов И dsl-и используются в полный рост.
FM>>Еще раз. Когда у тебя окажется сотня тысяч связей, то руками ты физически не сможешь модифицировать все сложные места за приемлемое время. Ты просто синтезируешь схему (например при помощи IC compiler), экстрагируешь паразитные параметры (StarRC) и моделируешь схему с их учетом (PrimeTime для проверки целостности сигналов и проблем с мощностью). Если есть проблемы с какими-то связями, то возвращаешься к IC Compiler и вписываешь дополнительные ограничения в скрипт для синтеза (например команда set_clock_latency, set_clock_transition для установки правильного тайминга сигналов генератора)
V>Т.е. загублять параметры дизайна вместо того, чтобы попытаться переиначить декомпозицию и связь м/у "блоками"?
Не понял. V>А что схема делает, если не секрет?
Какая схема, я тебе описываю как делается дизайн цифровых микросхем.
Здравствуйте, iHateLogins, Вы писали:
HL>А можно почитать спеки по этому продукту, документацию по API и какие-нибудь презы с кейсами?
Вопрос не ко мне. Я занимаюсь разработкой платформы, которая сама по себе не продается, а не маркетингом. Основной сайт — https://tornado.parus.ru:8181/, там вроде бы все, что публично доступно. Остальное — только для партнеров.
... << RSDN@Home 1.2.0 alpha 5 rev. 52 on Windows 7 6.1.7601.65536>>
Здравствуйте, FragMent, Вы писали:
V>>Нет, не сталкивался на сотнях схем ни разу. FM>Переформулирую: "я написал 100 десятистрочных программ, поэтому знаю как написать программу в 100 тыс. строк"
Ну дык, даже программу из миллиона строк я пишу как набор программ из 100 строк. Вот и посчитай (грубо), сколько надо слоёв ПО, чтобы получить миллион по основанию ~100. Как раз стандартные 3-4 слоя и получаются. В схемотехнике примерно аналогично.
Какой смысл было указывать на общее кол-во вентилей, если я использую в некоей цифро-аналоговой схеме микросхемы относительно высокого уровня? Да, я не делал ничего на FPGA и не разрабатывал кристаллы, но почему-то я уверен, что регистр-защелку на нужное кол-во бит или дешифратор на нужное кол-во бит ты каждый раз с 0-ля не делаешь. Я прав? Т.е. даже если нужного библиотечного элемента нет и его надо делать, то эти библиотечные элементы создаются на своём уровне иерархии и потом исопльзуются как такие же точно библиотечные элементы "изкаробки". В итоге ты оперируешь примерно одинаковой сложностью на каждом уровне.
Ну и такой момент, что после схемотехники обнаружил в себе способность быстро "въезжать" именно в большие программные продукты в сравнении с коллегами (на относительно небольших проектах этот эффект незаметен). Т.е. мне наоборот всегда казалось, что электронщики умеют декомопозицию лучше программистов... А ты пытаешься меня убедить в обратном.
FM>Да даже в программировании есть такая проблема. Если бы ее не было, не появилось бы Аспектно-ориентированное программирование. FM>А уж для электроники и подавно. Нарисуй токовое зеркало и проведи от него два тока в разные блоки. Повесь на один из них шумящую схему — получишь шум на второй ветке.
И? Для любых парных каналов в аналоге есть коэф. взаимного влияния в децибелах. Задача разработчика выбрать минимальный (т.е. самый дешевый) вариант, удовлетворяющий заданным параметрам. Этих схем токовых зеркал всяко побольше одной — выбирай нужную.
FM>И блоки могут оказаться на разных уровнях иерархии.
Нам не блоки нужны, а спецификации: уровень шумов * коэф. взаимного влияния. Ты ЛЮБОЙ другой блок можешь рассматривать как черный ящик. Иначе утонешь.
FM>И цифровых сигналов по всей иерархии полно: POR, reset, clock, boundary scan.
Ну так отлаживал я процессоры от ЕС-1033... куча плат на шасси, куча рассыпухи в каждой и тактовых сигналов. И абсолютно никаких сложностей как на уровне конкретной платы так и на уровне всего процессора, потому что каждый раз сложность вполне обозримая. Короче, я все-равно не поверю, что все ваши 100 тыщ вентилей расположены на одном уровне подробностей. Человек такое не осилит.
Ладно... На самом деле я уже говорю тоже самое, что в предыдущих постах, ничего нового не изобрету. Если перводить на кол-во элементарных логических ключей, то схемы в десятки тыщ и более ключей тоже разрабатывал, ес-но... Хотя не припомню ни одной схемы сложнее сотни "корпусов". Неужели наличие пластикового корпуса вокруг выделенной логической сущности что-то кардинально меняет? Вот он, вопрос на миллион $$.
V>>Зачем руками? И почему все? FM>Это такой метод быстрого тестирования работоспособности цифровых схем. В тестовом режиме все регистры соединяются последовательно и на вход микросхемы подается последовательность сигналов, если она появляется на выходе без искажений, значит как минимум нет неработающих регистров и имеет смысл выполнять функциональное тестирование.
Хм... что-то мне подсказывает, что общее кол-во вентилей должно вырасти на ощутимое кол-во %.
V>>Я с этим не спорил ни разу. Наоборот, я поправляю все твои попытки неправомерного обобщения, что речь идет сугубо об однородном цифровом дизайне. FM>Где я обобщал? Я всего лишь отметил, что люди столкнувшиеся со структурной сложностью, ушли от графики к тексту.
Скорее, они столкнулись с недостатками инструментов разработки.
V>>Для этой весьма узкой этой ниши дизайна кристаллов — да ради бога. Это пришло из FPGA, напомню. Эдакое прототипирование, только не в софте, а железе. Сам бог велел писать ПО. Но как-то ты весело уже наверно 10-й раз игнорируешь момент разработки конечных схем на основе цифровых. И вот сейчас про упомянутые материнки сделал вид что понял. Сколько разновидностей материнок приходится на один чипсет? FM>Любой проц по сложности уделывает все материнки на его основе вместе взятые. В Интеле несколько сот инженеров работают над одним ядром в течении некольких лет.
А сколько инженеров разрабатвают потом материнки на этих процах?
Напомню, что тут мы всё еще бодаемся про общее кол-во аналоговых дизайнов и этих аналоговых в любом случае будет больше. Даже если цифровой дизайн сложнее.
FM>На что тебе справедливо возразили, что процы в графике не разрабатывают. Теперь ты отстаиваешь другую позицию, что цифра однородна, поэтому ее можно в тексте описывать, и зачем-то переводишь разговор на конечные схемы. Думаю этот разговор стоит продолжать только если ты предъявишь современный графический дизайн (неважно цифровой или аналоговый) в сотню тысяч элементов.
Любая плата с богатой обвеской на проце пойдет?
Ничем не отличается от того же самого, выполненого по гибридной технологии, когда делается спец-чип на основе стандартного ядра.
V>>Да и вообще, посмотри хоть раз за работой разработчика схемотехнических решений (трюков). Даже если он "салфетке" что-то чиркает, поверь, он не текстовую таблицу связей там чиркает, а графические элементы и связи. FM>Что мне смотреть, я сам придумываю схемотехнические решения
Ну дык, и в каком виде? Вот сознайся сейчас на весь и-нет.
Здравствуйте, FragMent, Вы писали:
FM>Не притворяйся. Методы работающие для малых систем (или для малого числа элементов) не всегда подходят для больших. Примеров тысячи.
Дык, дело-то не размерах системы, а в изменении взаимных пропорций значений основных св-в. Тут размер — дело десятое. Просто при изменении размера пропорции (например, задержек) плывут, что корректирует сценарии использования.
V>>Ес-но цифро-аналоговый прямо по-определению. К тому же, а порты вводы/вывода прямо таки цифровые у всего девайса в целом? Да фактически никогда. Т.е. еще будет согласование и преобразование. Итого, в типовой схеме из полусотни элементов цифровым будет только один элемент — микроконтроллер... Который, повторюсь, типовой, а схема на нем — уникальна. FM>Не понял. Я спросил микропроцессор цифровой или цифроаналоговый. Ты ответил "Ес-но цифро-аналоговый прямо по-определению" и буквально в следующей строчке пишешь "цифровым будет только один элемент — микроконтроллер". Ты уж определись.
Это ты определись, о чем ты споришь. Речь шла о дизайне. Соответствено, вопрос я прочитал так: "Он (дизайн) цифровой или цифро-аналоговый?".
V>>Я думаю, что цифровых дизайнов относительно немного. Относительно всех дизайнов. Практически ВСЕГДА одни и те же цифровые компоненты используются более чем в одной конечной схеме. И коэффициент тут несколько порядков обычно, от 3-х и более. Т.е. на одну цифровую микросхему рано или поздно наберется тысячи схем, где ее применяют со всевозможной аналоговой обвеской. Мне вообще кажутся смешными эти споры, каких дизайнов больше. Похоже, кое-кто кое-что не догоняет. Высокоинтегрированная цифра от того и стала популярна, что она инкапсулирует в себе некое типовое решение. Ведь высокоинтегрированные микросхемы окупаются только в приличных партиях. Поэтому, если где-то цифра уникальна — это заведомая профанация всей идеи. Всякие уникальности должен обыгрывать софт. FM>Противоречие. Если цифровых дизайнов немного, то и вакансий должно быть мало. Чего в природе не наблюдается.
Демагогия. Ты же сам сказал, что на одну схему надо 100 человек. И я это подтвердил, что да, она сложнее, поэтому нужна массовость. Т.е. малое кол-во дизайнов относительно дизайнов конечных схем на ней.
Даже взять самое-самое популярное направление сегодня: вот выпускает Samsung новый чип на ядрах ARM, и этот чип идет в десятки конечных моделей устройств.
V>>Ну я конечно всерьез не рассматриваю FPGA. Эта штука изначально предназначалась для прототипирования. Делать на ней конечные решения — это получать то самое "решение для бедных". И скорости не те и шум и потребление и вообще... FM>Фирма Xilinx смотрит на тебя с недоумением. FPGA отличное решение, когда не нужно большое количество конечных устройств или перепрограммирование налету. Опять же количество вакансий говорит само за себя.
На вкус и цвет, как говорится...
FM>Попробуй спроектировать простой процессор с 5-stage конвейером и блоком предсказания переходов и потом обсудим простоту цифрового дизайна.
И ты проектируешь блок предсказания переходов? А если спроектирую в схеме функциональной, что тогда?
V>>Потому что специализация Уже, а работа однообразнее. Производительность веб-мастеров тоже выше производительности С++ программистов, если в тиках процессора считать по готовой программе... V>>Потому что меньше болит голова о технологической стороне продукта. Знай себе в песочнице ковыряй. FM>А у ассемблерщиков еще круче! Сидят эти C++ программисты в своей скучной песочнице и не болит у них голова о распределении регистров. FM>И C++ программы состоят из типовых решений. Везде там for-ы да if-ы.
Да. Я ведь с этим не спорю, а ты пытаешься. Ес-но на С++ всяко проще даже чем на Си, не то, что на ассемблере.
Аналоговая схемотехника — это до сих пор тот самый ассемблер, а цифровой дизайн — это джава. На неё тоже вакансий больше, чем на асеемблер... и системы на ней разрабатывают объемнее, чем типовые ассемблерные задачи. )))
V>>Когда тебе порты выхода с реальными исполнительными устройствами сопрягать надо будет, не поможет тебе никакой HDL. Будут те же 100-200 компонент в неделю. FM>А когда тебе потребуется сделать в железе свою систему для high frequency trading ты тоже будешь пилить 100-200 компонент в неделю или перейдешь все же на более подходящий инструмент?
Я пилю даже горадо меньше, чем 100-200 компонент в неделю. Просто за счет иерархичности и повторного использования библиотечных компонент, после компиляции в инструкции процессора выходят совсем другие цифры, на порядок больше твоих. Вот как выглядит твоя демагогия об измерении всего и вся в "логических ключах" (С).
FM>>>Да, да. Просто вставить ядро процессора и никаких проблем. А цифровую обвязку для него и аналоговой части писать не надо? V>>Дык и я про то, что меняется существенно только гибридная часть, которую на HDL писать не эффективно до сих пор. FM>Я не про гибридную часть, а про сопряжение покупных IP блоков между собой (например ядро ARM, DSP core, MPEG-декодер).
Гы, а как же это раньше делали вообще на обвеске? Раньше даже сами DSP собирали из "запчастей" и никто не считал это чем-то сложным... ИМХО, сейчас всё гораздо проще, бо у тебя мильон библиотек и огромный интернет в минутной доступности. В любом случае сопрягать м/у собой сугубо цифровые блоки — это всегда считалось ерундой. Там же все характиристики детерминированные. Давай спеки, т.е. формулируй задачу, и ответ можно выдавать начинать практически сразу, без долгих раздумий. В аналоге так не получается — думать надо.
FM>Я тебя не пойму. То ты говоришь, что цифры очень мало, то что она все больше заменяет аналог.
Дизайнов мало. И чем дальше, тем меньше, из-за монопролизации. Как пример — на сегодня выжило смешное кол-во архитектур процов. Т.е. остается всё меньше и меньше дизайнов. Десятки заводов штампуют один и тот же покупной дизайн ARM-ядер.
В общем ладно, тебе захотелось просто пободаться, и ты делаешь вид, что не понимаешь аргументы..
Здравствуйте, Mamut, Вы писали:
M>Хотя, о чем это я. Вон, Ruby on Rails — это, посути, один большой DSL, который позволяет двумя строчками описать то, что обычно описывается сотней строчек. В итоге шаг вправо-влево (за рамки DSL) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный DSL. С истинно правильным труъ DSL'ем такого не бывает, потому что такого не может быть никогда.
ДСЛ-и не решают задачи автоматически. Задачу все так же придется решать. Прост при правильном подходе, решение окажется более легким.
Хотя, о чем это я. Вон, Java (С++, C#, Python, ...) — это, посути, один высокоуровенвый язык, который позволяет двумя строчками описать то, что обычно описывается сотней строчек на ассемлере. В итоге шаг вправо-влево (за рамки ЯОН) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный ЯОН. С истинно правильным труъ ЯОН'ем такого не бывает, потому что такого не может быть никогда.
M>Хотя не спорю — DSL'и на самом деле рулят. Только вот они тоже далеко не панацея, и применять их лучше дозированно.
+1 Только вот на сегодня дозы микроскопически. А в большинстве случаев нулевые.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
M>>Хотя не спорю — DSL'и на самом деле рулят. Только вот они тоже далеко не панацея, и применять их лучше дозированно.
VD>+1 Только вот на сегодня дозы микроскопически. А в большинстве случаев нулевые.
Здравствуйте, VladD2, Вы писали:
VD>Хотя, о чем это я. Вон, Java (С++, C#, Python, ...) — это, посути, один высокоуровенвый язык, который позволяет двумя строчками описать то, что обычно описывается сотней строчек на ассемлере. В итоге шаг вправо-влево (за рамки ЯОН) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный ЯОН. С истинно правильным труъ ЯОН'ем такого не бывает, потому что такого не может быть никогда.
Для 90% насущных задач этого за глаза хватает. Точки просаживания по производительности вобщем то хорошо известны, описаны чуть нигде угодно. Для дотнета это стало известно примерно в тот же месяц, когда он вышел.
Здравствуйте, Mamut, Вы писали:
M>Хотя, о чем это я. Вон, Ruby on Rails — это, посути, один большой DSL, который позволяет двумя строчками описать то, что обычно описывается сотней строчек. В итоге шаг вправо-влево (за рамки DSL) — расстрел, во что разворачиваются вызовы этих двух строчек, неизвестно никому, и точки просаживания по производительности тоже неочевидны. Хотя да, это, видимо, плохо спроектированный DSL. С истинно правильным труъ DSL'ем такого не бывает, потому что такого не может быть никогда.
Я тоже так думал про РоР, пока не познакомился чуть ближе. Нет там особой магии, все довольно предсказуемо разворачивается. Расстрелов, при выходе за рамки, не больше чем в том же ASP.NET MVC (в MVC эти рамки даже построже будут). Вообще конечно хотелось бы увидеть эти рамки для РоР, может быть они просто от незнания.
Просадки производительности конечно есть, что заставляет включать кеши заметно раньше того же ASP.NET, но включать их все равно приходится и там и там. Есть конечно и те пессемизации производительности в которых виноваты именно DSL, но в этом плане ruby сильно проигрывает nemerle в возможностях оптимизации генерируемого кода.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
VD>>>Этот код никто кроме авторов понять не может.
AVK>>Ну я то понял.
VD>А ты найди на этом форуме еще одного человека который бы понял этот код, но не работал бы в Парусе. ;)
А, так это был Парус? То-то у меня возникло дежавю при взгляде на этот код. Я писал интеграцию одной системы с Парусом. InventoryObject, InventoryObjectItem, Operations, Repairs, я до сих пор это помню...
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sinclair, Вы писали:
S>6. Опять даункаст. В целом, выглядит, как размазанная запись правила, которое в оригинале звучало как "убить все карточки, которые входят в бла-бла-бла". DSL, который бы позволял написать "убить все карточки, которые входят в бла-бла-бла", не отвлекаясь на порядок обхода итераторов, даункасты, и скобочки, был бы крайне уместен.
Этот т.н. "ДСЛ" представляет собой одну функцию по обходу дерева с условием.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>>Этот т.н. "ДСЛ" представляет собой одну функцию по обходу дерева с условием. S>Тем лучше.
Вообще, сторонники DSL в этом топике игнорируют одну простую вещь. В приведенном примере уже используется DSL — это модель предметной области, выполненная на ОО-языке. Которая, кстати говоря может быть элементарно сгенерирована. Я например в последние годы вообще редко пишу модель руками. Хоть модели и не принято называть этим словом, очевидно, это есть самый что ни на есть настоящий DSL в понимании WH и прочих (по крайней мере част этого DSL,остальное привносится средствами языка). Причем этот подход — он оптимален для большинства т.н. "бизнес-задач".
Социализм — это власть трудящихся и централизованная плановая экономика.
)
