Здравствуйте, Курилка, Вы писали:
К>Ну да, если отказаться от софта, то проблем с софтом не будет, эт и ежу понятно.
Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня?
К>BTW это ничего, что логику процессоров описывают алгоритмами? Так же как вся математика этими алгоритмами пропитана, её тоже выкинем? И физику, коль она математикой пользуется
Так может это потому, что он специально для выполнения алгоритмов и создается? Когда же уже вы оставите этот процессор, и возьмете другое устройство?
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
К>>Что за "те же проблемы" на примере эрланга? К>>Понятие алгоритма и наличие зависимостей — вещи совершенно разные (причём зависимости — вещь неизбежная, т.к. программа без I/O никому не нужна)
Кё>Автор заявил, что невозможность достигнуть уровня качества других инженерных областей присуща только алгоритмам и их разработке, а если разрабатывать другим способом, например, разработка устройств из обменивающихся сигналами стандартных элементов, то это станет возможно. А т.к. ерланговские процессы конструируются из алгоритмов, то... в общем понятно. Это в теории, если хочется на практике и строго об эрланге, то лучше в комментарии к тому блогу пойти.
Т.е. он заявил, а ты ему поверил на слово?
Хороший подход.
А по поводу этого 'rebelscience' и эрланга я уже писал.
BTW на эрланге разработка системы идёт из обменивающихся сигналами процессов (отчасти стандартных)
Здравствуйте, Курилка, Вы писали:
К>Т.е. он заявил, а ты ему поверил на слово?
Форум называется философия программирования. Философия — это когда мы обсуждаем идею, думаем, и приходим в выводу, что она неверна, что верна, или что нам не хватает информации. Где-то так. Я нашел интересную идею, но ни в коем случае не пытаюсь убедить тебя в неё уверовать, а хочу обсудить и обдумать.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
К>>Ну да, если отказаться от софта, то проблем с софтом не будет, эт и ежу понятно.
Кё>Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня?
В чём аналогичны? В порядке сложности? Я тебе уже предлагал сравнить, ответа так и не последовало.
К>>BTW это ничего, что логику процессоров описывают алгоритмами? Так же как вся математика этими алгоритмами пропитана, её тоже выкинем? И физику, коль она математикой пользуется
Кё>Так может это потому, что он специально для выполнения алгоритмов и создается? Когда же уже вы оставите этот процессор, и возьмете другое устройство?
Да возьми любую плату (звуковую, сетевую, тюнер), на ней хоть микросхема стопудов есть, её код наверняка на Verilog'е/VHDL каком-нибудь писали. Кстати последние три буквы VHDL — hardware description language.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
К>>Т.е. он заявил, а ты ему поверил на слово?
Кё>Форум называется философия программирования. Философия — это когда мы обсуждаем идею, думаем, и приходим в выводу, что она неверна, что верна, или что нам не хватает информации. Где-то так. Я нашел интересную идею, но ни в коем случае не пытаюсь убедить тебя в неё уверовать, а хочу обсудить и обдумать.
Я пытаюсь (в данной ветке) понять твою точку зрения, или (не прошу воспринять за наезд) ты только в качестве ретранслятора готов выступать?
Здравствуйте, Кодёнок, Вы писали:
Кё>Не думаю, но речь не о достижении абсолютной идеальной надежности, а о её повышении. Каково твое мнение, если разрабатывать софт так же, как разрабатывают железо, то
Повысится стоимость разработки.
Потому, что разработка железа — довольно дорогой процесс. И в том числе он включает в себя прогон железки на эмуляторе, и сборку (и выброс) нескольких прототипов.
Кё>А других устройств? Еще раз — процессор это частный случай. А звуковуха или модем?
Я уже написал свое мнение по поводу звуковухи и модема. Автор, судя по всему, либо плохо знаком с электроникой, либо намеренно пренебрегает важными деталями.
В частности, проблемами паразитного взаимодействия и того, что не все сигналы достигают точек назначения.
Далее, программирование, о котором говорит автор, реализовано в Екселе. Уже. Можно вживую посмотреть, насколько улучшения в диспетчеризации отдельных "событий" повышают надежность программ. Да, действительно, сам ексель не ляжет от ошибки в формуле. В общем случае даже можно оценить масштаб катастрофы, построив транзитивное замыкание зависимых ячеек. Ну и какое отношение это имеет к надежности? Появляется другой класс ошибок, которые крайне трудно отлавливать.
А главное — что мы вкладываем в понятие "надежности"? Если программа расчета зарплаты упала, то она упала. А если сбой в формуле экселя, то кто-то получит мало денег.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Курилка, Вы писали:
Кё>>Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня? К>В чём аналогичны?
В своей природе...
К>В порядке сложности? Я тебе уже предлагал сравнить, ответа так и не последовало.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
Кё>>>Ну если софтверные объекты будут полностью аналогичны хардверным, то в чем проблема будет довести характер и результаты разработки до того же уровня? К>>В чём аналогичны?
Кё>В своей природе...
Очень чёткий и конструктивный ответ
К>>В порядке сложности? Я тебе уже предлагал сравнить, ответа так и не последовало.
Кё>А как её оценить? В чем измерять?
Как вариант — возьми за оценку — мощность множества входов/выходов (фактически это и есть взаимосвязи компонентов), причём в случае винды учти неявные входы.
Здравствуйте, Курилка, Вы писали:
Кё>>Форум называется философия программирования. Философия — это когда мы обсуждаем идею, думаем, и приходим в выводу, что она неверна, что верна, или что нам не хватает информации. Где-то так. Я нашел интересную идею, но ни в коем случае не пытаюсь убедить тебя в неё уверовать, а хочу обсудить и обдумать.
К>Я пытаюсь (в данной ветке) понять твою точку зрения, или (не прошу воспринять за наезд) ты только в качестве ретранслятора готов выступать?
Моя текущая точка зрения (которая скоро наверняка будет другой): я не вижу препятствий, чтобы то, о чем говорит автор, могло получиться.
Здравствуйте, Sinclair, Вы писали:
Кё>>Не думаю, но речь не о достижении абсолютной идеальной надежности, а о её повышении. Каково твое мнение, если разрабатывать софт так же, как разрабатывают железо, то S>Повысится стоимость разработки. S>Потому, что разработка железа — довольно дорогой процесс. И в том числе он включает в себя прогон железки на эмуляторе, и сборку (и выброс) нескольких прототипов.
Стоимость имелась ввиду количество усилий, конечно же. Неужели разработка модема настолько сложнее, чем у тулсы на 10000 строк, что первый релиз модема работает до сих пор, а во второй находят баги в коде, написанном 5 лет назад?
S>В частности, проблемами паразитного взаимодействия и того, что не все сигналы достигают точек назначения.
А это существенно? Если паразитного взаимодействия не будет, и сигналы будут доставляться гарантированно, железо станет глючить как софт?
S>А главное — что мы вкладываем в понятие "надежности"? Если программа расчета зарплаты упала, то она упала. А если сбой в формуле экселя, то кто-то получит мало денег.
Не так. Если бы формула «упала», то в некоторых ячейках было бы «internal error», или вроде того, вместо падения всего экселя. А от другого класса ошибок, приводящих к неверным результатам, не застрахован ни тот, ни другой подход.
Этот спор уже проходили в обсуждении Singularity, между прочим. Я думал, неубежденных не осталось.
Железо проектируется из фиксированного числа элементов. Это как если писать софт только на сингтонах, без возможности создавать новые объекты. Такие конфигурации можно верифицировать на любые исходы за конечное (и легко рассчитываемое) время.
Отличие же софта в его виртуальной «бесконечности», когда объекты и связи между ними могут рождаться во время выполнения, и самое главное, зависеть от внешних сигналов, которые непредсказуемы. Во время компиляции нельзя предугадать все комбинации новых связей (NP-полная задача), а проводить верификацию во время выполнения на каждом новом сигнале есть те же самые ошибки времени выполнения (ибо если верификация не прошла, что делать, кроме как умертвить процесс?).
Таким образом, на ограниченном числе частных случаев действительно можно применить те же методы и получать то же качество, но к 99% софта это не имеет отношения.
Неудивительно, что у этого парня нет никакой даже самой примитивной черновой модели того, что он пишет. Потому что на первой же реальной задаче метод перестанет работать.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Кодёнок, Вы писали:
Кё>Разобрался, в чем дело.
Кё>Железо проектируется из фиксированного числа элементов. Это как если писать софт только на сингтонах, без возможности создавать новые объекты. Такие конфигурации можно верифицировать на любые исходы за конечное (и легко рассчитываемое) время.
Кё>Отличие же софта в его виртуальной «бесконечности», когда объекты и связи между ними могут рождаться во время выполнения, и самое главное, зависеть от внешних сигналов, которые непредсказуемы. Во время компиляции нельзя предугадать все комбинации новых связей (NP-полная задача), а проводить верификацию во время выполнения на каждом новом сигнале есть те же самые ошибки времени выполнения (ибо если верификация не прошла, что делать, кроме как умертвить процесс?).
Кё>Таким образом, на ограниченном числе частных случаев действительно можно применить те же методы и получать то же качество, но к 99% софта это не имеет отношения.
Кё>Неудивительно, что у этого парня нет никакой даже самой примитивной черновой модели того, что он пишет. Потому что на первой же реальной задаче метод перестанет работать.
, которое по идее защищено от бесконечности и прочих _|_
Правда на данный момент оно существует практически только в рамках идеи (за исключением не очень сложных случаев).
Гипотетически подход применим к реальным задачам, только вот усилия, которые придётся затратить, немаленькие.
Здравствуйте, Кодёнок, Вы писали:
Кё>Автор пишет, что хаотичность и ненадежность софта в целом применяется только к алгоритмическим системам, и Брукс подразумевал только их, не рассматривая другие возможные вычислительные модели. Показывает, что есть сложные вычислительные системы (электроника), где количество багов (и трудность разработки вообще) не растет экспоненциально со сложностью.
Во-первых, оно и в грамотно спроектированном софте не растет по экспоненте. Во-вторых, в микроэлектронике разработка несколько отличается от софта — там акцент на других сложностях. В-третьих, на активности по верификации там тратится почти столько же времени, как и на разработку. Помимо программирования, я два с половиной года руководил отделом разработки микроэлектроники, и могу раскрыть тему подробно, на примере вот этого проекта разработки достаточно сложного микроэлектронного блока, который велся в моей лаборатории. http://rnd.cnews.ru/tech/electronics/news/line/index_science.shtml?2008/06/02/302983
Это, вероятно, наиболее успешный наш проект — 9 месяцев, 7 человек, строго на графике, сделано ровно то, что требовалось. В этом проекте, ironically, мы задействовали как раз _программистские_ практики организации разработи, что позволило нам сильно снизить затраты не в ущерб качеству. У микроэлектронщиков вообще организация разработки отстает от программистов лет на десять (если сравнивать их практики с лучшими практиками организации разработки ПО, а не с тем бардаком, который мы наблюдаем на практике на многих местах у нас).
Для начала, остановимся на разнице в микроэлектронике и программировании с точки зрения проектировщика/архитектора.
1. Их системы сильно проще программных систем по одному показателю. Там сильно меньше юз-кейсов, и они сами по себе существенно проще. Кроме того, в этих системах состояние хорошо локализовано (нет памяти — нет состояния), и не может меняться откуда попало. Оно по большей части локально. То есть, аппаратчики почти не имеют проблем программистов, связанных с мутабельным состоянием, которое неконтроллируемо меняется откуда попало, а это важно в плане природы самых геморройных ошибок.
2. Сложнее же они тем, что это hard-realtime системы. Представьте, что у вас на каждую функцию есть жесткое ограничение по времени, за которое она должна отработать при любых входных данных.
3. На задержки влияет геометрия и взаимное положение элементов — еще один фактор, в принципе отсутствующий в разработке ПО. Не то, чтобы это слишком сильно играло для встраиваемых систем на этапе проектирования, но это принимается во внимание, потому что может влиять на архитектуру.
4. Площадь — один из самых критичных факторов. Каждый лишний миллиметр площади кристалла — это бабки, прибавляемые к стоимости каждого кристалла. Это порядка 6 центов для техпроцесса 0,13. И такие безобидные вещи, как память — жрут площадь особенно быстро.
5. Вы можете получить ошибку на каждом этапе работы — в том числе, вы не застрахованы от ошибки САПР-ов.
6. Ошибок в кристалл должно попасть как можно меньше. Одна итерация с прототипом — это минимум 4 месяца (два из них фабрика делает прототип, если это быстрая фабрика), и в реальности будет больше. Ошибки, как вы видите, очень дороги.
7. В конечном кристалле ошибок для работы в заявленных режимах быть по возможности не должно. Перевыпуск фотошаблона — это от сотен тысяч баксов до порядка миллиона (или выше), если речь идет о современных тонких техпроцессах. Плюс, конечно, задержка времени с поставками.
Все это означает следующее. Типов и источников возможных ошибок гораздо больше, чем в случае софта. Цена ошибки необычайно высокая, и надо стараться обнаруживать раньше. К счастью, это делать сильно проще, чем в случае софта, потому что с одной стороны, само устройство гораздо проще с точки зрения своих юз-кейсов, и с другой, многие компоненты системы не имеют состояния, либо оно локализованно и очень простое.
С точки зрения проектирования, аппаратчики применяют то, что программист назвал бы "моделью потоков данных". Система бьется на относительно мелкие модули с четко прописанными функциями и интерфесами, сильносвязных блоков уних нет либо их мало, глобальное состояние у них отсутствует, имногие блоки лишены собственного состояния, т.е. "функционально чисты".
Когда аппаратчики объединяют крупные блоки в систему, она пользуются для их связи "шинами" и "коммутационными средами" разной топологии. Среда передачи данных и алгоритм арбитража у них слабо не зависит от интерфейса блоков (для стандартных шин вообще не зависят), что позволяет хорошо развязать крупные блоки друг от друга, и тестрировать их независимо. Они четко разделяют "системный" дизайн, когда проектируется шинная иерархия и анализируются общесистемные потоки данных и юзкейсы (надо рассчитать параметры коммутационной среды, для этого так же применяются модели потоков данных), и разработку составных блоков системы. Это реально очень круто, в программировании сейчас становится модным подобный подход, часто в сочетании с SOA. Смотрите D-bus и AMQP.
Итак, говоря программистскими терминами, аппаратчики при построении систем вооружены подходом SOA, асинхронными сообщениями и Enterprise Bus Architecture, моделью dataflow, и функциональной чистотой. Ничего из перечисленного не является новым и революционным в программной инженерии. Поэтому, говорить о серебряных пулях — не стоит. Не тянет перечисленное на нее.
Кроме того, в силу простоты юзкейсов, они имеют возможность писать полные тестпланы, и вовсю практикуют автоматические тесты (которые традиционно пишутся отдельными людьми по пухлым спецификациям, которых примерно стоко же, сколько и разработчиков). Кроме того, они в практикуют раннее (в том числе и архитектурное) прототипирование — это называется "поведенческими моделями", которые бывают очень разные.
Теперь о процессе разработки. То, о чем я расскажу дальше, тем более не тянет на серебряную пулю.
Что поменяли в традиционных процессах мы, когда делали видеоконтроллер. У нас был жесткий бюджет, и я выкинул из проекта отдельных верификаторов. Кроме того, в проект на правах архитектора был включен программист, который знаком с видеообработкой, и умеет писать модели аппаратуры. Штука в том, что нам прототип ключевых аспектов архитектуры нужен был до того, как закончен архитектурный этап, и готова документация по ней. Поэтому, группу высокоуровневого моделирования не привлекали, а обошлись одним Сергеем Зефировым (thesz), включив его в состав команды как архитектора, и подчинив непосредственно руководителю проекта. Модели он писал на Хаскеле, в одиночку, без ТЗ, потому что сам был автором ТЗ и соавтором архитектуры. Таким образом, мы устранили тормозное звено в коммуникации "через бумагу", и ускорили "итерации" дизайна. Применяй мы на этом этапе SystemC как все — нихрена бы нас это не прокатило, для модели бы отдельная спецификация потребовалась.
Второе, что мы сделали — это была применена вполне программистская теория PSP/TSP для управления качеством. На первом этапе все возможные ошибки были отклассифицированы по типам и стадиям внесения, и далее была разработана стратегия тестирования, которая перечислял процедуры отлова ошибок на каждом этапе разработки, порядок и конкретные способы тестрирования блоков, и доказывал, что мы этими процедурами надежно накрываем все возможные типы ошибок на всех этапах. Задача, которую я ставил при разработке стратегии тестирования — максимальное использование автоматического тестирования на всех этапах, и применение поведенческих моделей для генерации тестовых векторов. В этой работепринимали участие как программисты, так и микроэлектронщики.
Тестовый план, разработанный также на раннем этапе, являлся следтсвием ТЗ, перечисляющего все юзкейсы, и стратегии тестирования, перечисляющей виды тестов. Он определял уже конкретный план работ по обеспечению качества, которые распределялись по разработчикам блоков, и программистам. В результате, мы обошлись ОДНИМ выделенным апарратчиком, который отвечал за стратегию тестирования и тестплан, и смогли обеспечить великолепное качество.
Тем временем, Женя Янкевич (руководитель проекта) заранее зарядил разработку эмуляторов памяти и внешней обвязки, которая позволила бы нам прогонять общесистемные тесты на модели, а программисты усиленно писали скрипты на Перле, которые позволяли задувать картинки во все модели, и просматривать выход видеоконтроллера также в виде картинок.
Еще одно новшество из мира программирования. В разработке не было выделенных архитекторов, не занятых кодированием. В проекте применялась любимая мной техника группового дизайна. Каждому инженеру была назначена зона ответственности, за дизайн которой он отвечает лично, ониперекрестно проверяли дизайн соседей, и совместно работали над общей архитектурой (по схеме научных семинаров — помните по ВУЗам?). Таким образом, когда они приступали к реализации, они прекрасно знали свои блоки, и разбирались в блоках соседей. Кроме того, им вовремя предоставили тестовое окружение и тулзы.
В результате, когда на переговорах по сдаче второго этапа работ (на котором, по условиям контракта, у нас должно быть собранная вместе модель устройства, но она не обязына проходить системные тесты), я в ответ на вопрос о работоспособности модели сообщил заказчику, что она уже показывает картинки в разрешении SECAM, у заказчика, который в микроэлектронном бизнесе не в первый год (Фомин, 1-й зам НТЦ Модуль), случился шок. В сугубо положительном смысле этого слова. Он не мог понять, как такое возможно. Мы объяснили, и показали картинки .
Итак, все завершилось хорошо, ребята молодцы, и сработали великолепно. Мы здесь-то во многом эффективно сработали потому, что смогли избежать "традиционного" для разработки аппаратуры сдвига акцента на документацию, сохранили маленький размер команды, и очень вдумчиво и к месту применили элементы PSP/TSP и agile-практик. Действуй мы "традиционно" — мы бы вылетили за бюджет и график к чертям и качество не смогли бы обеспечить. Но главное, конечно, в том, что у нас была отличная команда. Парни молодцы.
Однако, стал бы я применять подобный процесс для разработки софта, скажем, веб сервиса, где ошибки дешевы в исправлении? Нет. Никогда. Это overkill. Причина в том, что цена ошибки несопоставимо меньше в софте, и поэтому — не имеет смысл делать мероприятия по отлову ошибок на ранних этапах настолько дорогими, и не имеет смысла так из кожи вон лезть, чтобы обнаружить ошибки раньше. они должны быть соизмеримы цене ошибки. Хотя, в общем, нам удалось их сильно удешевить по сравнению с остальными.
Вероятно, ореол мистики вокруг микроэлектроники развеется окончательно, если я скажу вам, что в терминах транзисторов цифровые микросхемы давно никто не проектирует. Наши браться микроэлектронщики давным давно применяют для описания микросхем полноценные языки программирования. Один из них VHDL, другой Verilog. Они отличаются от наших языков тем, что ориентированны на описание высокопараллельных процессов, и напрямую поддерживают знакомые аппаратчикам идеомы, такие, как "провода", и "конечные автоматы". Никто уже не работает в терминах транзисторов (кроме аналоговых дихайнеров и топологов), никто даже не работает в терминах вентилей вроде 2и-не. Более того, например, сумматоров давно уже никто не делает сам, достаточно написать просто + и САПР сам сгенерирует сумматор по схеме ускоренного переноса.
VHDL — вполне человеческий язык программирования, имеет свои корни из Ады.
Verilog — по уровню ниже чем наш С. Он не позволяет определять своих типов данных — вы оперируете на уровне отдельных проводов и групп проводов (то есть, булевскиепеременные и массивы таких переменных). Именно этот убогий язык, который вызовет у любого программиста рвотный рефлекс, как ни странно, наиболее распространен в коммерческих компаниях, да и вообще. Например, Intel и Sun применяют для описания процов менно его. Его развитие, которое еще на что-то приличное похоже — это SystemVerilog. В Intel начали переходить на него только недавно.
В обоих языках есть "синтезируемое подмножество", которое может быть засинтезировано в описание микросхемы. Циклы, например, вы употреблять не можете в коде, который должен быть синтезируемым. То есть, в данной области, казалось бы, макросредства и всякий полиморфизм времени компиляции должны рулить со страшной силой. Однако, например, на популярном Verilog нельзя сделать практически ничего полиморфно-генерящегося, все что там есть — это убогая конструкция generate.
Короче говоря, и у этих людей, значит, мы предлагаем учится серебрянным пулям? Да они даже языков себе нормальных придумать не могут . Я бы, кстати, с удовольствием попридумывал для них макроязычок.
Здравствуйте, prVovik, Вы писали:
V>А какой был объем "исходников" у вашего видео-контроллера?
Самых настоящих исходников, на языке Verilog было, внимание...
...3000 (три тысячи) строк кода. Не считая тестовых окружений и моделей на самых разных языках. Это еще одна особенность аппаратуры. Там отлаженные, рабочие строки кода весят гораздо тяжелее, чем в софте, и даются куда геморройнее. Средняя продуктивность наших микроэлектронщиков на данном проекте по данным project postmortem составила порядка 2,5-3 строк на Verilog в час.
Весь проект, вместе с тестамии окружением — 7000 строк на Verilog.
Поведенческая модель на Хаскеле — 1800 строк.
Плюс, алгоритмическая модель на С алгоритма масштабирования изображения — 800 строк.
Ну, плюс 300 строк кода на Перле — это преобзразователи логов сигналов в картинки tga и обратно.
Для сравнения. Процессорное ядро Leon3 (SPARCv8) порядка 3 тыщи строк на VHDL.
Sun UltraSPARC T1 (SPARCv9, считается не ядро, а весь кристалл, кажется, с тестамии и окружением) — порядка 160 тыщ строк на Verilog, если мне память не изменяет. У них в дизайн-центре над этим процом 200 инженеров работали несколько лет
Здравствуйте, Gaperton, Вы писали:
V>>А какой был объем "исходников" у вашего видео-контроллера?
G>Самых настоящих исходников, на языке Verilog было, внимание... G>...3000 (три тысячи) строк кода. Не считая тестовых окружений и моделей на самых разных языках. Это еще одна особенность аппаратуры. Там отлаженные, рабочие строки кода весят гораздо тяжелее, чем в софте, и даются куда геморройнее. Средняя продуктивность наших микроэлектронщиков на данном проекте по данным project postmortem составила порядка 2,5-3 строк на Verilog в час.
Стоили аналогичные блоки на рынке интеллектуальной собственности год назад порядка 100К-500К USD. HDTV-блоки дорогие, ближе к верхней границе, и их было мало. Теперь, что эти три тыщи строк кода умеют, и как результат соотносится с конкурентами. Берем для сравнения, как ближайший по функциональности, видеоконтроллер высокой четкости от немецкой компании SciWorks. Который нихрена не дешевый.
1) У нас накладывается меньше видео-слоев, чем у них — всего три, один для видео, и один для меню (у них 6). На сложность это почти никак не влияет, слоев добавить небольшая проблема. Трех слоев в большинестве приложений, которые мы рассматривали, хватит, плюс лишние слои жрут площадь, и увеличивают количество режимов для верификации. Последнее — это время разработки, которого у нас не было.
2) У нас у контроллера всего один интерфейс AXI Master. У них — весь тракт от шины AXI дублируется 6 раз для каждого слоя по разу. Халявят ребята — упрощают отдельные DMA-машины для выборки видеоданных по слоям, и всю работу по смешиванию возлагают на арбитра шины AXI. У нас — внутри стоит умная DMA-машина, которая дает выборку по памяти оптимальным образом через единственный интерфейс. Это, при прочих равных экономит нам площадь. Хотя, если честно, это было требование заказчика, я думаю, мы бы тоже схалявили при возможности .
3) У нас меньше цветовых режимовдля слоя меню, чем у них. Технически поддержать эти режимы — ерунда, не проблема, но они увеличивают объем сценариев тестирования, и мы из боязни вылететь за график поддержали только разумный минимум (1 байт 2r2g2b2a, 2 байта 5:5:5:1 и 4:4:4:4, 4 байта на точку честного RGBA, никаких палитр, экзотики, и трех байтов). Тем более, зоопарк режимов цвета для меню нафиг никому не нужен.
4) У нас существенно, радикально качественнее и лучше сделано масштабирование видео-изображения. Начать с того, что оно выполняется с плавным шагом. Вы сможете сделать плавный zoom в своем плеере, если там будет применяться наш контроллер. Второе — коэффициенты по X и Y могут меняться независимо — по одной координате он может сжимать, а по другой — растягивать. То есть, вы сможете откорректировать aspect ratio картинки. В третьих, у нас применяются существенно более качественные фильтры, чем у них, при этом — они занимают немного площади. Выбору алгоритмов фильтрации, их прототипированию, и проверке на реальных картинках, было посвящего очень много временина ранних этапах. Наши тупые фильтры дают картинку лучше и четче, чем сложные полифазные фильтры.
5) У нас нет второго блока, который уменьшает картинку (для функции picture in picture). Однако, этот блок внутрь контроллера не вставишь (развертку генерирует независимо от основного), он все равно вешается сбоку от видеоконтроллера на отдельном DMA-мастере, рядом на шину, и никак от контроллера не зависит — добавить его в систему потом будет легко. Во вторых, у нас контроллер для бюджетных устройств, и там такой блок не нужен. Нет блока — нет занимаемой им площади, которая — деньги .
6) То же самое касается разнообразных bitblitting и 2D accelerator. Их нет и у SciWorx — за ненадобностью, и они также все равно должны висеть снаружи контроллера, и тупо писать во внешнюю видеопамять.
Резюмируя — у нас очень простой и симпатичный контроллер, он занимает меньше площади, чем ближайший конкурент, имеет чуть меньше цветовых режимов (ну кому сейчас нафиг нужны режимы с 8-битной палитрой? А палитра, между прочим — это внутренняя память, которая жрет площадь кристалла, даже если вы ей не пользуетесь), не поддерживает picture in picture (сбоку прикручивается, и у них на самом деле тоже сбоку), имеет только необходимый минимум слоев, зато имеет весьма хороший (заметно лучше, чем уконкурента) для бюджетного устройства блок масштабирования. Для видеокамер, DVD-плееров (которым picture in picture не вперся) и бюджетных ТВ-приставок — самое то.
G>Самых настоящих исходников, на языке Verilog было, внимание... G>...3000 (три тысячи) строк кода. Не считая тестовых окружений и моделей на самых разных языках. Это еще одна особенность аппаратуры. Там отлаженные, рабочие строки кода весят гораздо тяжелее, чем в софте, и даются куда геморройнее. Средняя продуктивность наших микроэлектронщиков на данном проекте по данным project postmortem составила порядка 2,5-3 строк на Verilog в час.
G>Весь проект, вместе с тестамии окружением — 7000 строк на Verilog.
7965, разница в 16%. Это моя вина, я называл данные по памяти.
G>Поведенческая модель на Хаскеле — 1800 строк.
2194. Тоже одна шестая отличия, тоже меня память подвела.
G>Плюс, алгоритмическая модель на С алгоритма масштабирования изображения — 800 строк.
Да, здесь 800 строк. Здесь не подвела. Удивительно!
Собственно, моих, программистских строк кода и было — 2200 Хаскельных и 800 сишных. ~3000 строк. Что-то около 5-7 строк в час.
Инженеров было четверо, так что я всего в два раза превосходил по скорости инженеров.
Общая низкая скорость связана с тем, что надо было все это симулировать в специальных средах, что не очень быстро. И тяжесть отладки — обычного отладчика нет, надо умом понять причину ошибки и ее выявить. Ошибки, причем, встречались и в результатах моих программ тоже.
Кстати, мы для видеоконтроллера сделали два мультика на POVray, на 90 кадров, с размытием движения (чтобы возможные артефакты проверить).
G>Ну, плюс 300 строк кода на Перле — это преобзразователи логов сигналов в картинки tga и обратно.
И здесь я все правильно указал.
G>Для сравнения. Процессорное ядро Leon3 (SPARCv8) порядка 3 тыщи строк на VHDL. G>Sun UltraSPARC T1 (SPARCv9, считается не ядро, а весь кристалл, кажется, с тестамии и окружением) — порядка 160 тыщ строк на Verilog, если мне память не изменяет. У них в дизайн-центре над этим процом 200 инженеров работали несколько лет
Это я подсчитывать не буду, поскольку T1 я у себя снес, а просто так скачать его не получается.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Кё>>http://www.rebelscience.org/Cosas/Reliability.htm
M>Чукча. "Что вижу — то пою". M>Эмулятор среднего процессора пишется студентом за пару месяцев. M>Ну, пусть не студентом и за пол-года — чтоб достичь такой-же степени безбаговости. M>Теперь понятна степень сложности процессоров и софта? M>Для программ тоже есть методики доказательства их корректности, правда не настолько сильно развитые, в силу их невостребованности. M>А невостребованность проистекает из стоимости разработки таких программ. Она даже не на порядок, на два, на три порядка дороже. M>Вы сейчас за винду сколько платите? 100 баксов. Платите 100 килобаксов, и будет вам щастье.
Час работы программиста в США стоит $125. В день программист работает 4 часа. За час он производит ~20 строк кода. Итого, $12,5 за строку кода.
Насколько мне известно, стоимость правильно, по всем стандартам NASA, пересмотренной строки кода возрастает до $1000. Это два порядка. Такая высокая цена получается, как раз, из-за использования code review и тщательного документирования кода.
Что еще? Верифицированный от разбора синтаксиса до кодогенерации компилятор с Си (написанный на Coq) занял (по-моему) полтора года работы коллектива из 4-х человек. Это, по-моему, даже не порядок разницы в стоимости для такого продукта.
Система доказательства программ (proof assistant) Coq совершенно бесплатна. Также, как Agda2, Maude и многие другие.
Рекомендую ознакомиться с состоянием дел, прежде, чем делать громкие заявления.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, Курилка, Вы писали:
К>>Для корректной работы процессора нам не нужно знать из каких транзисторов он состоит, фактически контрактом являются напряжения на ножках этого процессора (суть входы/выходы), которые есть по сути реализация эмулятора. И этот контракт жёстко зафиксирован и соблюдение его гарантируется (хотя помнится были и процессоры с багами).
Кё>Эмуляция процессора состоит из эмуляции отдельных команд, между которыми нет никаких зависимостей, и которые сами по себе простые. Исправь баги в каждой команде — и готово. Простые компоненты без зависимостей — это совсем не похоже ни на современный софт, ни на железо, на этом примере ничего по теме не доказать.
Создание потактово-точной модели процессора — 2 месяца, один человек. "Потактово-точная" означает, что воспроизведены как внутренняя структура, так и машины состояний.
Грубо говоря, я описал "железо", только на Хаскеле.
Yours truly, Serguey Zefirov (thesz NA mail TOCHKA ru)
