Основной вопрос, почему библиотеки, созданные разными компиляторами C++, по разному воспринимает "Proteus",
мы совместными усилиями уяснили - всё дело в несколько разной реализации не указанных явно соглашений о
вызове функции у разных компиляторов C++.
И поскольку мы решили поработать над серьёзной моделью процессора, я позволю себе сказать несколько слов
о принципах симуляции в "Proteus", чтобы мы одинаково понимали, как саму задачу, так и друг друга, и не возвращались
к этому по ходу дела.
В "Proteus" (да и в Electronics Workbench) моделирование цифровых и аналоговых устройств реализовано несколько разными путями, хотя, по сути, основной принцип схож.
В аналоговом устройстве симулятор "просматривает" схему, которую мы рисуем на графической консоли, и автоматически составляет по нашему рисунку SPICE-модель. При включении симуляции, SPICE-библиотека пакета симуляции составляет систему нелинейных дифференциальных уравнений методом узловых потенциалов и решает её (интегрирует) численными методами трапеций или Гира. Поэтому, если "Proteus" (или Electronics Workbench, а они оба используют похожую SPICE-библиотеку) не может что-то посчитать, не надо называть программу г...ном, а надо вспомнить, что она "играет как велели", и может быть, следует заменить численный метод трапеций на метод Гира (он безусловно устойчив), выбрать более мелкий шаг или изменить точность.


Очень большое значение порой имеет выбор начальных условий.

Хорошо настроенный симулятор даёт точность расчета 95-98%.
Значит основной принцип симуляции аналоговых устройств - сдвиг малыми шажками по времени и одновременное интегрирование системы дифференциальных уравнений, описывающих нашу схему, на каждом таком интервале. Этот результат расчета мы обычно и видим в качестве осциллограммы.
Основной принцип симуляции цифровых устройств более прост: есть минимальный шаг по времени - в "Proteus" это 1 пикосекунда - с этим шагом по времени осуществляется проверка всех входов и выходов цифровых схем, и, согласно логике их работы, состояния на выходах меняются с учётом стандартных для каждой серии времён задержки распространения по входу и по выходу (или среднего времени задержки распространения). Этот принцип гораздо более быстр, но при нём, естественно, мы не увидим, присущих цифровым сигналам переходных процессов по фронту и спаду. Такие ньюансы попросту не моделируются.


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

Если этот принцип всем понятен, и никто не считает, что надо что-то уточнить, то дальше перейдём к тому, как в "Proteus" реализуется цифровая модель в форме динамической библиотеки, а она гораздо быстрее всех прочих видов моделей, почему я, наконец, и решил ими вплотную заняться.
--------------------------------------------
Любая модель в "Proteus" состоит из двух частей: графической, которую мы видим на экране в виде условного графического обозначения симулируемого элемента, и, собственно, "симулирующей" поведение элемента, в качестве которой может выступать SPICE-модель, схемотехническая модель, модель в представлении Proteus-а, и DLL-модель, написанная на C++.
В нашем случае мы будем использовать DLL-модель, написанную на C++.
В дальнейшем изложении я опираюсь на документ Creation VSM - Modelos Digitales.PDF, который описывает создание модели довольно кратко и доходчиво, но с некоторыми опечатками и на английском языке. Но, тем не менее, вся процедура была мной проверена и приводит к нужным результатам.
Начнём с создания графической части модели.
В качестве тестового экземпляра я решил попробовать создать несколько упрощенный аналог прозрачной защёлки К155ТМ2, чтобы попробовать привязку к конкретным временным задержкам данной микросхемы, и чтобы мы смогли обсудить механизм создания "времянки".

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

Размеры прямоугольника можно изменять, растягивая и сжимая его изображение курсором мыши за показанные на рисунке "реперные" метки.
Неплохо предварительно убедиться, что шаг сетки выставлен, равным 100. К сетке с таким шагом желательно "привязать" этот прямоугольник и выводы элемента. Остальные детали можно (и местами даже нужно) "привязывать" к более мелкой сетке. Но сетка с шагом, равным 100, выставляется по умолчанию, и по ней идут соединения элементов. Выводы, "привязанные" к более мелкой сетке могут искривляться на схеме.
Честно говоря, то, что мы нарисуем, никак не повлияет на функциональность модели, но я предпочитаю условное графическое обозначение близкое отечественному ГОСТУ и пропорциональное по отношению к остальным логическим элементам схемы…
Добавим линию…

Установим текстовое обозначение элемента…

Элементы внутри прямоугольника удобнее выставлять по самой мелкой сетке с шагом, равным 10.

Укажем "начало координат" нашего элемента, относительно которого позиционируются остальные элементы схемы (иногда его устанавливают на начало левого верхнего вывода)…

Теперь, установив шаг сетки, равным 100, будем располагать выводы логического элемента:

Как только мы помещаем каждый вывод на лист проекта, сразу же придётся ввести необходимые обозначения во вкладке редакции свойств вывода (Edit Pin).
И это очень важный момент, поскольку…
Имена выводов (Pin Name) "C, D, Q, /Q" - это то единственное, что связывает нашу картинку с DLL-моделью!
Номера выводов (Default Pin Number) - это параметры, используемые при разводке печатной платы по разработанной схеме…
![]() |
Входы элемента можно обозначить как Passive или Input, ну а выходы - Output.
После того, как элемент обзавёлся выводами, добавим под его изображением текстовый скрипт его свойств:

Сразу же появится текстовое окно, куда необходимо ввести следующие строки:
Code: Select all
{*DEVICE}
NAME=DCFF
{PREFIX=DD}
{*PROPDEFS}
{MODDLL="VSM Model DLL",HIDDEN STRING}
{PRIMITIVE="PrimitiveType",HIDDEN STRING}
{*COMPONENT}
{MODDLL=Flipflop.dll}
{PRIMITIVE=DIGITAL,DCFF}

В принципе изначально достаточно только следующих строк:
Code: Select all
{*DEVICE}
NAME=DCFF
{PREFIX=DD}
Префикс {PREFIX=DD} - это обозначение, которое с порядковым номером будет появляться над нашим элементом в симуляциях: DD1, DD2, DD3… и т.д.
Собственно говоря, остальные параметры можно ввести при компиляции графического элемента в библиотеку Proteus, и в дальнейшем все эти свойства могут быть изменены повторной компиляцией. Но на этом этапе, как мне показалось их ввести проще, а при компиляции мы лишь убедимся, что они попали на свои места.
Рассмотрим остальные параметры:
{*PROPDEFS}
{MODDLL="VSM Model DLL",HIDDEN STRING}
эта строка обозначает, что нашу модель будет симулировать DLL-библиотека.
{PRIMITIVE="PrimitiveType",HIDDEN STRING}
изображение нашей модели создано из графических примитивов
{*COMPONENT}
{MODDLL=Flipflop.dll}
DLL-библиотека, симулирующая наш графический примитив носит название Flipflop.dll - я выбрал такое, ограничений никаких нет. (Эта строка - связка графической части модели с симулирующей DLL-библиотекой).
{PRIMITIVE=DIGITAL,DCFF}
модель цифровая и связана с классом элементов DCFF (имя элемента DCFF и класс могут не совпадать, так как в классе может быть описано сразу несколько похожих по свойствам элементов).
После того, как указанный текстовый скрипт введен, наша графическая часть модели готова к компиляции в библиотеку Proteus.

--------------------------------------------
Я так подробно рассмотрел создание графической части модели, чтобы у всех было ясное представление о том, какой графический примитив отвечает за ту или иную часть отрисовки условного графического обозначения логического элемента в проекте Proteus, чтобы в случае необходимости можно было оперативно нужный примитив использовать.
В действительности, есть возможность этот процесс в значительной мере ускорить, если воспользоваться наиболее близким к желаемому готовым условным графическим изображением элемента из существующих библиотек Proteus.
В нашем случае без особо долгих раздумий я выбрал бы модель JK–триггера JKFF из меню выбора элемента (Pick Devices), в подразделе "Примитивы Моделирования" (Modelling Primitives) – как это видно на следующем рисунке.

Но меня, прежде всего, интересовал вопрос, как авторы Proteus разрешили вопрос с уникальными именами для вывода "Q" и его инверсии "/Q", которые нам необходимы для связи с нашей DLL-моделью. Дело в том, что в Proteus есть специальный префикс к имени вывода – $Q$, в результате применения которого инверсный вывод отрисовывается на схеме точно, как принято в ГОСТ–е.

Но вот поймёт ли сам Proteus это имя – $Q$ – как уникальное, я сомневался, и авторы этот префикс к имени инверсного выхода также не применили. Именно поэтому я применил обозначение "/Q", поскольку "!Q", мне не понравилось.
Но у aav8 это получилось: pinReset=instance->getdsimpin("$RESET$",true); // Reset
После того, как мы поместим выбранную в подразделе "Примитивы Моделирования" (Modelling Primitives) модель JK–триггера JKFF на чистый лист нового проекта Proteus, нам следует провести её декомпозицию, то есть, разобрать модель на графические примитивы, выводы и текстовый скрипт её описания.
Для этого выделим рисунок модели контуром, как на рисунке, или активизируем её правым кликом мыши, чтобы модель стала красного цвета, после чего в меню Library выберем опцию Decompose (или кликнем соответствующую пиктограмму молотка в панели инструментов).

После того, как графическое изображение модели разделено на отдельные составляющие, в первую очередь необходимо отредактировать текстовый скрипт её свойств, заменив его нашим собственным.
Code: Select all
{*DEVICE}
NAME=DCFF
{PREFIX=DD}
{*PROPDEFS}
{MODDLL="VSM Model DLL",HIDDEN STRING}
{PRIMITIVE="PrimitiveType",HIDDEN STRING}
{*COMPONENT}
{MODDLL=Flipflop.dll}
{PRIMITIVE=DIGITAL,DCFF}

Итак, построенная тем или другим способом графическая часть модели Proteus готова к компиляции в его библотеку!
Именно таким способом мы сконструируем условное графическое обозначение микропроцессора i8080 из имеющейся графической модели процессора Z80.

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

Файл проекта, подробности - здесь...
И следующее, что я наметил в наших планах, — рассмотреть последовательность компиляции графической части модели в библиотеку Proteus.
--------------------------------------------
Рассмотрим в деталях процедуру компиляции графической части модели в библиотеку Proteus.
Выделим рисунок модели контуром, захватывая текстовый скрипт, как это показано на следующем рисунке.
Для этого обводим, удерживая левую кнопку мыши, наш рисунок, включая текстовый скрипт, и в меню Library выбираем опцию – Маке Device – создать устройство. Эту же операцию можно вызвать, кликнув по пиктограмме – Маке Device – в панели инструментов.

Далее в этом процессе создания устройства для ввода параметров модели на экране последовательно появятся пять вкладок.
В первой вкладке отражаются строки
Code: Select all
{*DEVICE}
NAME=DCFF
{PREFIX=DD}

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

На следующей вкладке отражены следующие строки текстового скрипта:
Code: Select all
{*PROPDEFS}
{MODDLL="VSM Model DLL",HIDDEN STRING}
{*COMPONENT}
{MODDLL=Flipflop.dll}

Code: Select all
{PRIMITIVE="PrimitiveType",HIDDEN STRING}
...
{PRIMITIVE=DIGITAL,DCFF}

Следующая вкладка позволяет сопоставить нашей модели help–файл…

И на последней вкладке в окна Категория устройства (Device Category) и Изготовитель устройства (Device Manufacturer) установим через сопутствующие кнопки New соответственно Прочее (Miscellaneous) и ExUSSR (я обычно делаю так, поскольку чаще всего подходящей фирмы-изготовителя в списке не находится). Принципиального значения эти настройки не имеют, и делается это более для того, чтобы не потерять нашу модель позже в оригинальных библиотеках Proteus. Поэтому, если есть желание, можно заполнить и поля Описание устройства (Device Description – я написал здесь D-Flip-Flop), а также Заметки по устройству (Device Notes - Test model).

Скорее всего, Proteus предложит разместить нашу модель в библиотеке USERDVC и другой альтернативы не предоставит.
Заканчиваем процесс создания устройства нажатием кнопки ОК.
Вновь созданная модель DCFF теперь существует в библиотеке USERDVC Proteus, она доступна для выбора любому проекту из вкладки Выбор Устройства (Pick Devices).

После выбора наша модель также появляется в левой панели выбора устройств (DEVICES), что позволяет поместить её на лист проекта и запустить проект на симуляцию.

Попытка симуляции закончится ошибкой компиляции проекта симулятором:
Что совершенно справедливо, поскольку Flipflop.dll мы ещё не написали.SIMULATION LOGS
===============
...
FATAL: [ OD1 ] External model DLL "FLIPFLOP.DLL" not found. GLE=.0x00000002.
Simulation FAILED Due To Fatal Simulator Errors.
Это и будет нашим следующим этапом: написать требуемую динамическую библиотеку в среде MSVC++, придерживаясь правил и соглашений VSM SDK от Labcenter Electronics, скомпилировать нашу Flipflop.dll и поместить её в папке MODELS в директории, где установлен симулятор Proteus.
Продолжение следует...