Система графического программирования-исполнения, построенная на принципах схемной эмуляции

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

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

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

Преимущество очевидно: нет необходимости осваивать, к примеру, такие пакеты программирования, как MAX+PLUS II или EXCALIBUR, а значит, не надо будет осваивать и соответствующие языки микропрограммирования - AHDL, VHDL или Verylog, методы верификации проекта и т.д.

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

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

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

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

Представляется естественным первоначальную разработку платформы эмуляции выполнить на стандартных микросхемах ПЛИС. В дальнейшем, следуя активно развиваемой в настоящее время идеологии SoC (Sistem on Chip), станет целесообразной разработка специализированной микросхемы, архитектура которой будет полностью "заточена" под Систему Эмуляции. Это уже позволит говорить об эмулирующем кристалле, а не платформе. Скажу более того, что фирма, реализовавшая такой проект, совершит революционный прорыв в вопросе превращения микросхем программируемой логики в по-настоящему массовый продукт, поскольку овладеть работой с таким кристаллом под силу будет даже школьникам. Реализация идеи, с одной стороны, будет ценна для использования в том сегменте рынка, где сейчас используются системы на базе 8- и 16- разрядных микропроцессорных контроллеров. С другой - при организации мощных вычислительных матриц.

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

Осталось только дело за фирмой, которая возьмется за коммерциализацию данного проекта.

Область применения Платформы Эмуляции уже сегодня видится мне для достаточно широкого круга приложений, к примеру:

- комплексы диагностики, сбора и обработки информации;

- системы автоматики и АСУ ТП масштаба предприятия;

- бортовые системы управления;

- системы диспетчеризации и принятия решений;

- организация мощных вычислительных матриц;

- универсальная среда проектирования нейрокомпьютеров;

- проектирование интеллектуальных систем нового поколения:

Экспертных Систем, систем понимания, машин Баз Знаний и других направлений Искусственного Интеллекта (ИИ);

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

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

Преимущества эмуляции

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

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

1) Система Эмуляции позволяет проектировать на уровне Структурных Схем;

Не лишним будет еще раз напомнить, что работа любого графического компилятора в графических Системах Программирования состоит в просмотре рисунка проекта (притом, достаточно тривиальным способом, в порядке - "слева-направо" и "сверху-вниз") и генерации по нему программных кодов. А раз мы возвращаемся к программированию, то совершенно очевидно, что на каком бы графическом языке мы не рисовали схему - будь-то язык последовательных функциональных блоков (SFC), релейных диаграмм (LD) или функциональных блоковых диаграмм (FBD) - она непременно будет приведена к обычному рисунку алгоритма программы.

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

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

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

К тому же, проектирование на уровне структурных схем позволит поднять степень представления рисунков проектов на более высокий уровень, действительно понятному самому широкому кругу специалистов. Потому что, будучи даже графическими, такие языки как SFC, LD или FBD - все равно остаются языками программирования (да еще и с ограниченными возможностями) и требуют участия в проекте программиста.

Ниже я попытаюсь показать, что язык СС - соответствует более высокому уровню представления проектов, чем Уровень Алгоритмов и что CASE - SoftLogic системам вообще не под силу компиляция и исполнение проектов, представленных на уровне СС.

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

¦ обратные связи и их виды

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

Они наглядно демонстрируют, что ветви a, b и c - это т.н. "указатели" на адрес компоненты, с которой программу следует повторить, пока в компонентах k2, k5 и k6 (соответственно) будут соблюдаться определенные условия.

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

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

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

рис. 1а Простые циклы.

рис. 1б Простые вложенные циклы

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



a)

б)

рис. 2 а, б Примеры перекрестных обратных связей.

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

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

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

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

¦ учет временных соотношений сигналов в цепях проекта

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

Поэтому, первейшей задачей любого графического компилятора в СП является определение порядка размещения программных модулей (Mn) в теле программы, согласно связям (ветвям) соединяющих графические образы соответствующих им компонент (Kn) на рисунке проекта.

К примеру, на рис. 3а представлена схема проекта на уровне языка FB. На рис. 3б представлен вариант ее программной реализации, представленной в виде последовательности сгенерированных компилятором программных модулей.

Рис. 3а Проект системы содержащий параллельные ветви

Рис. 3б Порядок выполнения программных модулей для рис. 3а.

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

Как показано на рис. 3б, модуль М3 может быть расположен только в конце тела программы, поскольку оба входных его параметра (идентификаторы - б, в) должны быть определены к началу его исполнения.

О какой же динамичности процессов в таком случае может идти речь?

В свою очередь, в Системе Эмуляции вычисление значений в каждой ветви рисунка проекта осуществляется параллельно, соблюдая при этом всю динамику распространения процессов между ветвями. Если проектирование системы управления будет вестись на уровне Структурной Схемы (уровне систем), то в проект, представленный на рис. 3а может быть вложен совершенно другой смысл, к примеру, как на рис. 4. Здесь подразумевается, что при изменении сигнала на входе компоненты К1 с уровня логического нуля ("0") до уровня логической единицы ("1"), на выходе К3 формируется строб (импульс).

Рис. 4 Фрагмент проекта на уровне структурной схемы (уровень системы)

Приведенный на рис.4 фрагмент наглядно показывает, что сложный во времени вид сигнала на выходе компоненты К3 может формироваться в результате "гонки" сигналов, проходящих одновременно по параллельным ветвям 1 и 2 схемы, что есть совершенно нормальным явлением для уровня схем электронных систем. Но представляется абсолютным нонсенсом для схем алгоритмов, составленных в среде Систем Программирования.

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



Рис. 5 Фрагмент структурной схемы представленной на уровне СС.

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

¦ сложный вид и природа сигналов в каждой цепи

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

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

Потому как современные языки программирования не позволяют иного, а нарушение этого правила может привести программу в непредсказуемое состояние, другими словами - к аварии.

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

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

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

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

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

Более того, в Системе Эмуляции допускается многовекторность сигнала в каждой цепи!

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

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

2) Простое распараллеливание и синхронизация процессов;

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

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

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

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

3) Простое масштабирование;

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

Идея масштабирования в Системе Эмуляции основана, всего лишь (!), на механизме разбиения рисунка проекта на фрагменты и размещения каждого такого фрагмента в отдельной платформе.

Хотелось бы указать на три варианта фрагментации:

вариант первый - "фрагментация вширь". Это случай, когда один большой проект условно делится на N частей, каждая из которых, к примеру, будет локально управлять своим объектом (рис.6).

Рис. 6 Фрагментация рисунка проекта "вширь"

В этом случае графический рисунок алгоритма управления разбивается на фрагменты и каждый фрагмент размещается на отдельной платформе. Каждая платформа управляет локально только тем станком, алгоритм управления которым соответствует фрагменту рисунка в нее загруженному. И все! Межплатформенный обмен синхронизирующими сигналами по сетевому интерфейсу организовывается Системой Эмуляции автоматически и основывается на естественном принципе многопоточности алгоритма эмуляции.

Еще раз подчеркну, что Система Эмуляции, находящаяся в среде фон Неймана (микропроцессорной платформе), только имитирует всякую параллельность. Тем не менее, уже это позволяет реализовать распараллеливание процессов, не прибегая к традиционным методам организации межпроцессорного обмена и синхронизации процессов (использования разного рода "флагов", "семафоров" и т.п.).

Современным Системам Программирования такое не под силу. В случае распараллеливания общего процесса всю "графику" необходимо отложить в сторону и "вручную" (средствами языков программирования) разрабатывать программное обеспечение межпроцессорного обмена и синхронизации процессов.

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

Рис. 7 Фрагментация рисунка проекта "вглубь"

вариант третий - смешанный, когда задействованы одновременно оба предыдущих варианта.

4) Система Эмуляции - это, по сути, "машина потоков";

Механизм масштабирования, приведенный выше, основывается на естественном принципе алгоритма эмуляции - многопоточности.

Многопоточность процессов поддерживается как на уровне самой платформы, так и вне ее. Примеры, рассмотренные на рис. 6 и 7 касаются как раз второго случая, которое назовем - межплатформенной многопоточностью. Тогда принцип многопоточности в пределах самой эмулирующей платформы можно назвать - внутриплатформенной многопоточностью.

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

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

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

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

Микросхемы ПЛИС со структурой FPGA подходят для этих целей наилучшим образом, потому как изначально являются устройствами параллельного действия и поэтому наилучшим образом соответствуют реализации концепции потоков.

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

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

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

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

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

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

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

5) Отсутствует эффект "узкого горлышка" для мультипроцессорных систем;

Под этим термином в вычислительной технике подразумевается эффект ограничения мощности мультипроцессорной системы, приводящий к замедлению ее работы, вызванный ограниченной пропускной способностью канала память - процессоры. Из-за этого эффекта решение мультипроцессорной обработки, в традиционных вычислительных системах, приводит лишь к частичному успеху. Согласно гипотезе Минского (Minsky), ускорение, достигаемое при использовании параллельной системы, пропорционально двоичному логарифму от числа процессоров. То есть, при использовании 1000 процессоров на одной платформе возможное ускорение оказывается равным всего 10 (!).

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

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

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

6) Существенно повышается надежность управляющих систем;

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

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

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

Надежность проектов, разработанных на уровне Системы Эмуляции, повышается в сравнении с проектами, разработанными в среде Систем Программирования благодаря следующему:

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

Это позволяет, наконец-то, реализовать во всей красе давнюю мечту проектировщиков о единой спецификации проекта в цепочке всех специалистов, участвующих в реализации проекта.

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

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

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

- никакого исходного кода, в котором можно "закопаться", а значит и "скрытых" ошибок программирования (!);

- простая верификация проектов;

Для верификации проекта достаточно будет к эмулирующей платформе (или сети платформ) подключить ПК с программой визуализации.

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

- отсутствуют такие явления свойственные программированию как "зависание" программы или "сбой";

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

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

Если предположить, что в программе используются только двоичные управляющие переменные (флаги), то в этом случае количество состояний будет стремиться к 2n. Поэтому нет никакой гарантии, что в процессе работы программы не возникнет неожиданное сочетание входных воздействий, тогда программа перейдет в непредусмотренное состояние.

Системе Эмуляции все это не свойственно. Просто потому, что из нее исключен как программист, так и сами программные коды!

- идентификаторы строго привязаны к ветвям рисунка проекта;

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

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

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

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

- идея эмуляции органично стыкуется с идеей т.н. SWITCH- программирования;

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

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

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

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

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

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

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

Поэтому вся красота соединения идеи эмуляции и теории автоматов состоит в том, что по окончании проектирования схемы графа переходов совершенно нет необходимости браться за написание программных SWITCH структур - а достаточно просто эмулировать спроектированный граф автомата!!!

7) Позволяет эффективно реализовать систему проектирования и исследования нейросетей;

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

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

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

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

8) Возможность проектирования саморазвивающихся систем;

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

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

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

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

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

9) Единая среда разработки;

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

программный эмуляция схемный архитектура

Нет необходимости осваивать программирование микропроцессоров или учить языки программирования типа AHDL или VHDL для микросхем программируемой логики.

К тому же, никаких средств отладки микропроцессоров, несчетного числа дорогостоящих внутрисхемных эмуляторов и т.д. и т.п.

10) Низкая цена разработки и внедрения проектов;

Такое утверждение основано на свойстве универсальности эмулирующей платформы и отсутствием программирования.

Универсальность обеспечивается тем, что такая платформа годится для самого широкого круга задач: от простейших комплексов сбора и обработки информации - до АСУ ТП масштабов предприятия. От одноплатформенных - до мультиплатформенных сосредоточенных и распределенных систем.

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

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

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

11) Возможность эмуляции сложных аппаратно-программных систем еще на стадии разработки

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

Наверно я не ошибусь, если скажу, что история создания и использования таких систем длится уже более полувека (!), но что самое удивительное - они так и остались системами симуляции электронных устройств в масштабах кристалла или электронной платы.

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

12) Во всей красе позволяет реализовать идею о "единой спецификации проекта"

Система Эмуляции прекрасным образом, наконец-то(!), позволяет реализовать давнюю мечту проектировщиков систем о единой спецификации проекта. Теперь это стало реальным, поскольку в ней, в силу полного отсутствия какого-либо программного кода, разработка любого проекта проводится только на уровне рисунков.

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

13) Прекрасным образом способствует решению проблемы: "Движение за открытую проектную документацию";

Что означает "Движение за открытые исходные тексты" ("Open Source Software") представлять, думаю, никому не надо. Смысл такого движения понятен уже из самого его названия. Но проблема кроется в том, что сегодня уже и этого мало. Объемы программ настолько выросли, что разобраться в любой из них, ковыряясь в мегатоннах исходных текстов, - просто невозможно. В этом случае все проектные решения, задуманные автором проекта, просто растворяются в деталях кодирования. И проблема эта нарастает экспоненциально росту объема кода.

Выходит, что без исходных кодов плохо, но и с ними не очень хорошо. Чего не хватает для счастья? Проектной документации!