Проект "пульс": (описание идеи)
| Вид материала | Программа |
- Программа «Школа волонтеров Пульс», 453.36kb.
- Проект посвящен вопросам эксплуатации кц-1 кс «Игринская», 23.57kb.
- Как начинается проект?, 59.12kb.
- Настоящий Проект перспективного развития школы на 2011-2015 годы продолжает основные, 711.77kb.
- Тематическое планирование уроков в 7 классе, 894.98kb.
- Описание современной модели доступного и качественного образования в Хабаровском крае, 55.82kb.
- Конкурс инновационных проектов «Новый Алтай», 29.46kb.
- Анализ требований к проекту сайта (см табл. 9) 18 Согласование выработанной идеи проекта, 590.25kb.
- В. А. Заботина Утверждаю Начальник своуо в. Г. Кобозева Положение конкурс, 38.14kb.
- Программа производства и сбыта Формирование каналов сбыта продукции. Разработка мероприятий, 1030.06kb.
Программа схемной эмуляции "Пульс"
Итак, в основе предлагаемой к рассмотрению идеи лежит авторская программа Схемной Эмуляции. Что следует понимать под этим словосочетанием? Ведь любой электронщик возразит, что нет в природе программ такого класса. В качестве примера он упомянет так называемые программы-симуляторы, такие как Micro-CAP от "Spectrum SoftWare", PSpice от "MicroSim Corp." и т.д. и т.п., то, что в советскую эпоху у нас принято было называть программами моделирования электронных устройств.
Исторически симуляторы появились в ответ на законное желание разработчиков электронных устройств иметь возможность проверять работу спроектированной схемы до того, как она будет реализована с помощью паяльника.
В таких программах уровни входных сигналов, выбираемые из так называемого массива входных воздействий, шаг за шагом "подаются" на вход программной модели. Разумеется, что само слово "массив" – это атрибут программистских "штучек" и не имеет ни малейшего отношения к реальным сигналам. Проектирование можно считать выполненным правильно в случае, если получены правильные временные соотношения для уровней сигналов во всех цепях устройства.
Результатом моделирования становится некий массив уровней сигналов в цепях схемы, который можно затем вывести на принтер или дисплей в виде графиков. Только вот, такие графики отображают динамику изменений сигналов в цепях модели, а не реальной системы.
А что же тогда есть эмуляция? Эмуляция – это моделирование, выполняемое в режиме реального времени и в реальной среде окружения периферийных устройств.
Для того чтобы программа схемотехнического моделирования превратилась в программу схемной эмуляции необходимо выполнение некоторых условий.
Первое - добиться того, чтобы программа моделирования работала не с программными массивами, а с реальными сигналами. В этом случае на вход программной модели должны подаваться не комбинации входных событий, выбираемые из программного массива, а уровни сигналов, снимаемых с реальной системы. В тоже время, отклики, снимаемые с программной модели, опять-таки, должны подаваться на реальные исполняющие устройства.
Второе - добиться того, чтобы программа моделирования работала в режиме реального времени, а не какой-либо условной временной шкале. Потому что эмуляция – это имитация поведения какого-либо реального устройства, как будто его схема уже реализована с помощью паяльника.
Под "режимом реального времени" следует понимать случай, когда скорость имитации становится соизмеримой со скоростью изменения процессов в реальном объекте управления. Другими словами, когда отклик, снимаемый с программной модели, будет поспевать за процессами, протекающими в реальной среде окружения.
Третье – сделать так, чтобы программа моделирования не требовала ресурсов PC. Соблюдение этого условия позволит размещать ее не только на PC платформах, но и во встраиваемых контроллерах. Выполнение этого условия позволит существенно сократить показатели стоимости на внедряемые системы.
Программу схемотехнического моделирования, удовлетворяющую выполнению вышеперечислен-ных условий, уже по праву можно назвать – Программой Схемной Эмуляции. В основу предлагаемой мною системы положен авторский алгоритм схемной эмуляции, реализованный в авторском программном продукте - схемном эмуляторе “Пульс” (автоpское свидетельство ПА No 214 от 12.08.96, Госудаpственное Агенство Укpаины по Автоpским и Смежным Пpавам).
В тоже время, разработанный и программно реализованный мною алгоритм, успешно выполняет еще одно условие – в основу его работы положен принцип параллельных потоков.
Конечно же, в среде PC платформ или встраиваемых микропроцессоров, принцип многопоточности может только имитироваться. Для наиболее же полного раскрытия свойств алгоритма требуется и среда параллельного действия. К счастью, в настоящее время реализация такой среды известна – это т.н. матрицы вентильных массивов FPGA (Field-Programmable Gate Arrays) микросхем программируемой логики (ПЛИС).
Именно соединение этих двух компонент – авторского модуля схемной эмуляции (реализованного на принципах многопоточности), и матрицы вентильных массивов (как устройства параллельного действия), открывает широчайшие возможности для проектирования таких систем, как потоковой супер-ЭВМ (машины потоков).
Осталось только ответить на последний вопрос: а какая вообще может быть связь между программой схемной эмуляции и эмуляцией алгоритмов или систем?
А все дело только в том, что понимать под словом "схема". Ведь это действительно может быть принципиальная схема некоторого электронного устройства, аппаратно реализующего некоторый алгоритм, но это может быть и непосредственно структурная схема управления некоторой системы: к примеру, АСУ ТП, системы управления летательным аппаратом, биологической или физической модели разрабатываемой конечным пользователем и т.д. В конце концов, это может быть рисунок релейных диаграмм (LD), функциональных блоковых диаграмм (FBD) или схема алгоритма.
По сути, уровень составления проекта пользователя (рисования схемы) определяется видом использованных в нем библиотечных компонент.
Эмуляция принципиальных схем – это, конечно, частный случай. Хотя ничто не запрещает пользователю реализовывать алгоритм управления путем использования электронной схемы, просто данный пример наглядно демонстрирует всю мощь метода.
Однако самым важным преимуществом системы эмуляции состоит в том, что она дает пользователю возможность проектировать на уровне Структурных Схем. Именно такой уровень представления проектов, с одной стороны, способен стать настоящим графическим языком межпрофессионального общения и с другой – позволит проектировать системы такой сложности, которые невозможно создать в средах существующих систем графического программирования и программирования вообще!
В завершении, не могу не коснуться вопроса терминологической путаницы, сложившейся в последнее время вокруг фразы "схемная эмуляция" и захлестнувшей нынче как специальную литературу, так и весь интернет. Под нею ныне сплошь и рядом почему-то стали подразумевать средства отладки микропроцессорных систем. По этому поводу так и хочется сказать – Господа хорошие, авторы статей – не путайте себя и не вводите в заблуждение доверчивых читателей! Потому что то, про что Вы пишите, называется, все-таки, средствами "внутрисхемной эмуляции". А это, как говорится, - уже совсем другая история.
Графическое программирование и миф о SCADA системах
Справедливости ради нельзя не сказать, что в настоящее время уже существует множество инструментальных средств, в которых программирование некоторых систем также выполняется путем рисования схем. Это так называемые SCADA системы, предназначенные для программирования встраиваемых платформ систем автоматики.
Собственно говоря, наличие графического редактора рисования схем в какой-либо инструментальной среде разработки ныне и служит приметой – относится ли она к системе графического программированию или нет.
Поэтому, чтобы полнее увидеть преимущества системы графического программирования, построенной на принципах схемной эмуляции, в сравнении с огромным числом уже известных на сегодня систем, необходимо разобраться – а в чем же состоит идеология работы последних.
А для этого надо четко уяснить, что любая известная т.н. Система Графического Программирования строится на трех китах: графическом редакторе рисования схем, графическом компиляторе и системе исполнения.
Что касается редакторов рисования, то тут проблем вроде как бы и нет: даже спроектировать такую "штуку" под силу практически любому программирующему студенту.
А вот графические компиляторы – вещи гораздо более серьезные.
В "обязанности" этой компоненты входит просмотр графического рисунка проекта и генерация по нему исходного кода программы, который иначе программисту пришлось бы набирать "ручками". Затем исходный код компилируется в некоторый промежуточный код. Вся эта работа выполняется программистом на рабочей станции (ПК).
После этого файл промежуточного кода уже можно загружать во встраиваемый контроллер. Туда же загружается и специальный интерпретатор промежуточного кода – система исполнения.
Для чего нужен промежуточный код? Да лишь для того, чтобы максимально упростить интерпретатор (систему исполнения). Делается это с целью достичь возможности "всунуть" его в какую-либо микропроцессорную платформу, а также ускорить исполнение программы пользователя.
После сказанного должно стать понятным, что принципиальной разницы между SCADA системами и обычными системами визуального программирования, такими как DELPHI, VC или Visual Basic в принципе нет. Потому как в обоих случаях исходные тексты программ генерируются по визуальным компонентам, что были использованы в проекте.
Классическим примером сказанному может служить всенародно известная программа IsaGRAF (от ICS Triplex ISAGRAF Inc.). Здесь при компиляции файла графического проекта генерируется промежуточный, так называемый TIC-код, который затем загружается во встраиваемый контроллер. Туда же подгружается т.н. TIC-интерпретатор, который и выполняет функцию системы исполнения.
В не менее народной программе LabVIEW (от National Instruments) генерируемые исходные тексты кодируются в так называемый промежуточный G–код, который затем интерпретируется (исполняется) непосредственно на PC из среды LabVIEW.
Параллельно выше рассмотренной идеологии существует несколько отличная, заключающаяся в том, что еще на этапе работы графического компилятора генерируется не промежуточный код, а сразу исполняемый, который и загружается в промышленный компьютер.
Такая идеология, как правило, также предлагается известными системами графического программирования.
В LabVIEW для этого имеется приложение Application Builder for LabVIEW, которое позволяет сгенерировать оптимизированный код, сравнимый с программным кодом C-компилятора. Такой исполняемый код принято называть - RUN-TIME модулем.
Система IsaGRAF также позволяет проводить генерацию обычного C-исходного кода, откомпилировав который обычным C-компилятором мы получаем "классический" RUN-TIME модуль.
Идея RUN-TIME модулей нашла применение и в других системах класса HMI и SCADA, например в LookOut for Windows, (той же фирмы). А также широко известной UltraLogic (UltraLogic), где исполняемый файл располагается в PC-совместимых контроллерах типа ADAM.
И так далее, и тому подобное…
Какую бы другую систему мы далее не рассматривали - мы увидим все то же самое.
Не являются исключением и программирование на языке лестничных диаграмм (LD) для всех известных линеек ПЛК – MODICON, Siemens, Allen-Bradley и др.
А все по одной простой причине: ни интерпретацию, ни компиляцию в программировании пока еще никто не отменял.
Таким образом, можно сказать, что в идеологии всех без исключения современных SCADA систем прослеживается упорное стремление возвратиться от графики к обычным программным кодам, чем автоматически вызывается к жизни весь тот "геморрой", которым страдает программирование как парадигма. Поэтому, говорить о том, что все они являются системами графического программирования – не совсем корректно!
Ну не назвали же разработчики DELPHI, VC и прочих систем графическими! Они назвали их системами Визуального Программирования.
Поэтому, на мое глубокое убеждение, правильнее было бы и SCADA/SoftLogic системы также назвать системами визуального программирования.
Недостатком современных SCADA/SoftLogic систем можно также считать и то, что они "заточены" всего-лишь на облегчение труда программистов и не направлены на конечного пользователя. Поэтому даже при их использовании программист остается ключевой фигурой любого проекта, что ведет к последствиям, которые в начале статьи уже рассматривались.
Система графического программирования, в основу которой положен принцип схемной эмуляции, как раз и предоставляет уникальный шанс отказаться от исходных и исполняемых кодов, а значит и от этапов компиляции/интерпретации. Потому что программный модуль схемной эмуляции, положенный в основу всей системы, по своей сути является системой графического исполнения, позволяющий непосредственно "оживить" графический рисунок любого проекта пользователя.
Таким образом, этапы программирования и исполнения в представляемой системе полностью согласованы. "Общим знаменателем" такой согласованности выступает работа с графическим образом проекта, как на этапе проектирования, так и на этапе исполнения.
Потому именно такая система по полному праву может называться Системой Графического Программирования.
Использование идеи схемной эмуляции в основе системы графического программирования позволяет достичь сразу двух важных моментов:
первый – таким компонентам, как "графическому компилятору" (кит №2) и исполняемому интерпретатору (кит №3) – в новой идеологии места нет!
Что, в свою очередь, ведет к поразительному упрощению всей системы в функциональном плане, а значит и ценовом.
второй - позволяет достичь многих характеристик, принципиально недоступных для всех известных SCADA/SoftLogic систем: программирование на уровне Структурных Схем, поразительные возможности по масштабированию, простота реализации мультиплатформенных и потоковых вычислений и т.д. Все дальнейшее содержание статьи, по сути, и направлено на рассмотрение этих преимуществ.
Причин, по которым SCADA системы так и не стали массовым инструментарием сборки аппаратно-программных систем из готовых "кубиков" можно назвать несколько:
- Такие системы чрезвычайно дороги и рассчитаны не на уровень простого студента, инженера, частного предпринимателя или даже малого предприятия, а рассчитаны на "жирных" клиентов. Другими словами - на автоматизацию заводов и фабрик. Там, где клиент способен выложить от сотен тысяч – до миллионов долларов.
В 1998-2000 годах мне посчастливилось стать свидетелем строительства линии по производству макарон одним частным предприятием. Желание сэкономить на программистах и на разработке аппаратной части проекта у руководства было столь велико, что (начитавшись рекламных проспектов) решили строить систему из готовых "кубиков". В качестве ПО разработки была выбрана система графического программирования UltraLogic, а в качестве аппаратных "кубиков" – устройства типа ADAM.
Только вот, ознакомившись поближе - посчитали, прослезились. И построили всю систему на "самопальных" контроллерах на процессорах типа AVR. И дешево вышло, и сердито!
- Все известные SCADA – это довольно сложные системы в освоении и работе. И заверения разработчиков, что такие системы рассчитаны на технологов, есть не более чем рекламный трюк. Пока что профессиональные коллективы, состоящие из программистов и электронщиков, в состоянии эффективно эксплуатировать такой продукт.
- Возможность составлять проекты в графическом виде – это тоже, по-большому счету, – красивая рекламная упаковка на SCADA системы. Потому что, в силу примитивности используемых в них графических языков программирования (языка релейных диаграмм [LD] или функциональных блоковых диаграмм [FBD]), ни один серьезный проект таким образом составляться не будет. Для таких случаев нужен будет опытный программист, который будет программировать путем привычного написания программных операторов в среде текстового редактора.
- В силу (как уже было сказано выше) примитивности современных языков графического программирования, современные SCADA системы предназначены для реализации достаточно простых, с функциональной степени сложности, проектов. Задачи автоматизации – как раз и попадают в такой класс сложности. Да на большее, понимая это, разработчики SCADA систем и не претендуют! А как быть с широким кругом пользователей – физиков, биологов, лингвистов, специалистов в области Искусственного Интеллекта и др. – которые тоже хотели бы строить свои проекты на понятном каждому человеку уровне графического представления проектов, не пользуясь при этом услугами, как электронщиков, так и программистов? На этот счет SCADA молчит!
----------------------------------------------------------
Можно сказать, что перечисленные выше недостатки, свойственные SCADA системам – лежат на поверхности и потому должны стать понятными широкому кругу специалистов. Но вот их источник – скрыт глубоко в недрах нынешней идеологии построения всех без исключения Систем Графического Программирования.
А источник всех проблем кроется в том, что следуя реализации насущной для общества проблемы – предоставить пользователям возможность составлять проекты в графическом виде – сами разработчики SCADA систем сами-то и не поняли, а что дальше делать с этой графикой?
Ведь ни один микропроцессор в "голом виде" никакой графики не понимает. Им подавай последовательности кодовых инструкций, а "добывать" такие инструкции человечество научилось пока только одним способом – путем компиляции или интерпретации исходных программных текстов, составленных программистом.
Вот и не придумали пока разработчики SCADA систем ничего лучшего, как вставить в свои системы программный модуль, который можно назвать – модулем графической компиляции. "Просматривая" графический рисунок проекта, он генерирует по нему исходные программные тексты, те самые, которые в противном случае, программисту пришлось бы набирать ручками. А поскольку алгоритм работы такого редактора до абсурдности прост – просматривать рисунок в направлении "слева-направо" и "сверху-вниз", то должна стать понятной и причина примитивности используемых в настоящее время языков графического программирования. Сложный рисунок никакой компилятор просто не сможет "переварить".
Недостатки такого подхода очевидны. Ведь практически с появлением первых компьютеров в мире крепло осознание того, что наиболее полным способом программирования есть представление проектов на графическом уровне. Ведь именно на этапе перехода от графики к текстовому представлению программ, теряется множество параметров функциональности, первоначально присутствующих в проекте. Чем автоматически вызываются к жизни все те недостатки, которые присущи программированию как парадигме: трудность выявления неявных признаков параллельных потоков и их синхронизацию, трудности масштабирования (разбиения большой задачи на несколько вычислителей, когда мощности одного вычислителя недостаточно) и другие.
Универсальная платформа эмуляции
Итак, система графического программирования, построенная на принципах схемной эмуляции, состоит только из двух основных компонент: графического редактора рисования схем и системы графического исполнения, работа которой, собственно говоря, и основана на принципах схемной эмуляции.
Идея использования графического редактора здесь ровным счетом ничем не отличается от уже известных. Процесс проектирования какой-либо системы управления выглядит обычно: из библиотеки компонентов выбирается графический образ какой-либо компоненты и переносится на рабочую область рисунка графического редактора. Затем компоненты соединяются между собой необходимыми цепями (линиями связи). Вот и все "программирование"!
Графический компилятор (кит №2) в такой системе отсутствует, поскольку в генерации каких-либо кодов и в дальнейшей их компилировании необходимости нет. Вместо него в графическом редакторе используется программный модуль, который "просматривает" графический рисунок проекта и по нему формирует так называемый "Файл Описания Схемы" (ФОС). Затем ФОС необходимо загрузить во встраиваемую платформу. Поскольку каждая компонента, используемая разработчиком в проекте, кроме графического образа в среде графического редактора имеет еще и программный модуль в среде исполнения, – то все задействованные в проекте модули необходимо также загрузить во встраиваемую систему исполнения.
А вот в качестве системы исполнения (кит №3) используется программный модуль Схемной Эмуляции. На этапе коммерциализации проекта он с успехом может быть размещен непосредственно на платформе и закрыт битом секретности. Поэтому продаваться такая платформа будет как законченное аппаратно-программное изделие.
В самом начале своей работы модуль эмуляции "просматривает" ФОС и разворачивает в оперативной памяти встраиваемой платформы программную модель системы управления. Входные воздействия для такой модели снимаются с реальных датчиков АСУ ТП, а отклик с программной модели подается на реальные исполнительные устройства.
Модуль Эмуляции может быть запущен и непосредственно на ПК. Тогда, чтобы превратить обычную PC платформу в платформу эмуляции, в один из PCI-слотов необходимо будет вставить интерфейсную плату стыковки.
Всю библиотеку компонентов, используемую в среде графического редактора на этапе проектирования рисунка проекта, можно условно разбить на два класса. К первому относятся те компоненты, которые отображают реальное оборудование: различные датчики и исполнительные органы, например термодатчики и реле. Ко второму – не имеющие "железного" аналога. Это чисто функциональные элементы, такие как нормализаторы сигналов, частотные фильтры, сумматоры, компараторы, логика и т.д.
Поэтому, если на схеме проекта разработчик использовал графический образ, к примеру, датчика температуры, то тогда нужно не забыть подключить соответствующий ему реальный датчик к интерфейсу контроллера.
Хочу сразу подчеркнуть, что для того чтобы максимально оптимизировать работу модуля эмуляции – микропроцессорная платформа должна иметь специальную архитектуру.
Потому и назвать ее можно – эмулирующей.
Такая платформа будет еще и универсальной, потому что по своим ценовым и функциональным возможностям, а также возможностям масштабирования, она будет годиться для использования в самом широком спектре областей: от лабораторного студенческого стенда – до АСУ ТП масштаба предприятия.
Потоковый принцип, положенный в основу работы модуля эмуляции, позволяет просто и эффективно поддерживать идеологию распределенного управления – DCS-систем (дословно – распределенных систем управления)! Причем, без дополнительной аппаратной поддержки и разработки каких-либо дополнительных программных кодов для организации межплатформенного обмена, распараллеливания потоков, их синхронизации и т.д.
Это значит, что если для загрузки проекта пользователя в платформу эмуляции, мощности одной платформы окажется недостаточной, – проблема решается простым разбиением общего рисунка на некоторое число фрагментов. Под "недостаточностью мощности" следует понимать случай, когда ресурсов одной платформы окажется недостаточным, чтобы полностью вместить в себе файл описания схемы и все процедуры, сопутствующие компонентам всего рисунка пользовательского проекта. Тогда каждый фрагмент загружается в отдельную платформу. Этап разбиения может выполняться автоматически, без участия самого пользователя. А на этапе исполнения связывание и синхронизация потоков во всех платформах будет выполняться автоматически на уровне программной модели рисунка проекта. Для организации процесса межплатформенного обмена потребуется только соединить задействованное число платформ посредством общей информационной шины или сетевого концентратора.
В то время, когда архитектура обычных микропроцессорных платформ в каждом случае проектируется под конкретное приложение или сходную группу приложений, архитектура Платформы Эмуляции "заточена" исключительно под "комфортное" размещение в ней программного Модуля Эмуляции. Всю дальнейшую "заботу" по стыковке платформы с другими платформами эмуляции и окружением периферийных устройств цифро-аналогового ввода-вывода берет на себя Модуль Эмуляции.
Таким образом, сборка любой системы конечным пользователем ведется методом "складывания" из готовых "кубиков": необходимого числа Платформ Эмуляции и модулей ввода-вывода.
Интересным представляется вариант исполнения эмулирующей платформы на основе микросхемы программируемой логики (ПЛИС). Учитывая, что алгоритм эмуляции, положенный в основу работы программного Модуля Эмуляции, построен на потоковом принципе, то среда ПЛИС, как устройства параллельного действия, является наиболее оптимальной для его размещения. В среде фон Неймана (любого микропроцессора) такая многопоточность может только эмулироваться (имитироваться).
Микросхемы ПЛИС представляют собой некоторую матрицу логических ячеек, за счет программирования и коммутации которых можно создавать аппаратные реализации различных вычислительных структур. Другими словами – это "полуфабрикат" микросхемы, внутреннюю структуру которой определяет сам пользователь.
Особенностью архитектуры эмулирующей платформы на основе кристалла ПЛИС есть то, что в распоряжение пользователя предоставляется не "голый" кристалл, который еще каким-то образом необходимо запрограммировать. А такой, в котором FPGA область уже предварительно "отформатирована" структурой Модуля Эмуляции и в которую пользователю достаточно только загрузить файл описания схемы проекта пользователя.
Для пользователя переход на такую платформу ни коим образом не станет ущербным, поскольку разработка пользовательских проектов по-прежнему будет вестись в среде того же самого Графического Редактора, а верификация – в среде того же самого Графического Визуализатора.
Преимущество очевидно: нет необходимости осваивать, к примеру, такие пакеты программирования, как MAX+PLUS II или EXCALIBUR, а значит, не надо будет осваивать и соответствующие языки микропрограммирования - AHDL, VHDL или Verylog, методы верификации проекта и т.д.
Но это - даже не самое главное в вопросе выбора аппаратного метода реализации модуля эмуляции. Главный козырь в вопросе перехода на ПЛИС платформу – существенное повышение скорости исполнения проектов и существенное повышение надежности всей системы. Что касается скорости, то тут как бы все ясно. Что касается надежности – то достаточно вспомнить о высокой зависимости любого микропроцессора от температурных режимов работы, источников питания и случайных всплесков напряжения от окружающего оборудования. Оба названных преимущества являются чрезвычайно полезными в вопросе использования эмулирующей платформы в разного рода ответственных приложениях – например, бортовых компьютерах.
Идея масштабирования для DCS- систем применительно к вопросу проектирования эмулирующей платформы на основе ПЛИС особо подчеркивает красоту и высокую функциональность идеи схемной эмуляции. Ведь проектирование больших решающих полей на нескольких микросхемах программируемой логики традиционными способами является достаточно сложной задачей, требующей преодоления ряда проблем. Одна из которых – т.н. негативный эффект страниц, возникающий на стыках отдельных кристаллов программируемой логики. Но без ее разрешения не обойтись, когда приложение (задача) пользователя по своему объему превышает ресурсы одного кристалла.
Ситуация существенным образом меняется, если в основу функционирования ПЛИС – платформы положить авторский модуль схемной эмуляции, по своей сути который выполняет роль цементирующей среды для всех "ПЛИС – кирпичиков".
Положительный эффект здесь достигается тем, что объединение фрагментов схемы проекта пользователя, разнесенного по нескольким микросхемам программируемой логики, осуществляется не на физическом уровне (как в случае традиционного программирования), а на уровне программной модели всего проекта.
Представляется естественным первоначальную разработку платформы эмуляции выполнить на стандартных микросхемах ПЛИС. В дальнейшем, следуя активно развиваемой в настоящее время идеологии SoC (Sistem on Chip), станет целесообразной разработка специализированной микросхемы, архитектура которой будет полностью "заточена" под Систему Эмуляции. Это уже позволит говорить об эмулирующем кристалле, а не платформе. Скажу более того, что фирма, реализовавшая такой проект, совершит революционный прорыв в вопросе превращения микросхем программируемой логики в по-настоящему массовый продукт, поскольку овладеть работой с таким кристаллом под силу будет даже школьникам. Реализация идеи, с одной стороны, будет ценна для использования в том сегменте рынка, где сейчас используются системы на базе 8- и 16- разрядных микропроцессорных контроллеров. С другой – при организации мощных вычислительных матриц.
Принципы схемной эмуляции, положенные в основу работы Системы Эмуляции, позволит без проблем организовать этапы тестирования и верификации отлаживаемых проектов. Для этого достаточно будет подсоединить ПК к платформе на время отладки. А программа-визуализатор, установленная на таком ПК, позволит отображать уровни сигналов в любых ветвях схемы проекта.
Осталось только дело за фирмой, которая возьмется за коммерциализацию данного проекта.
Область применения Платформы Эмуляции уже сегодня видится мне для достаточно широкого круга приложений, к примеру:
- комплексы диагностики, сбора и обработки информации;