Кто-нибудь пробовал моделировать работу микроконтроллеров в САПР типа OrCAD'а и ему подобных?

Я имею ввиду следующее:
Т.к. в библиотеках OrCAD'а есть элементы (жаль не все ) позволяющие собирать схемы (в пакете) и моделировать их работу (просмотр временных диаграм и др.), нет ли возможности включать в схему МК с написанными программами и отслеживать работу этих МК непосредственно в схеме? Конечно об встраивании в OrCAD отладчиков программ я не говорю, но что мешает, например генерировать элемент не основе программы на ассемблере, который полностью соответствует прошитому МК и включать этот элемент в схему?

Если кто-то с этим сталкивался, прошу отзовитесь!

В Оркаде , по-моему нельзя , но есть Протеус http://www.radio.ru/ubb/Forum4/HTML/000639.html
хотя, все равно все зависит от качества модели, но игрушка красивая.

OrCad (до 9.2 по крайней мере) поддерживает PSpice A/D (9.2 еще и VHDL) - это все-таки больше аналоговый симулятор, но в нем есть возможность так же моделировать цифровые вещи.
Моделей микроконтроллеров на PSpice я не встречал - под PSpice нет синтезаторов, все-таки он создавался как язык описания и МОДЕЛИРОВАНИЯ аналоговых схем.
Если Вам необходимо проверить работу аналоговой схемы на основе MCU до ее изготовления могу посоветовать такую последовательность действий:
1. написать цифровую модель (примитивную) вашего MCU - это могут быть только порты и логика функционирования - например изменение уровня на одном из пинов с программируемой задержкой по прерыванию. Модель должна быть проверена на правильность с симулятором (эмулятором) MCU.
2. проверить работу системы с этой моделью.
Фактически получается две параллельные проверки - на симуляторе MCU и на PSpice.
Из-за больших временных затрат такой метод хорош при производстве систем с памятью ROM (когда нет возможности перепрошить память) и аналогово-цифровых микросхем. Но сейчас большинство контроллеров поддерживают in-system programming и будет намного быстрее и эффективнее собрать макет и попробовать живьем.

В принципе есть лучшие системы для совместного моделирования цифры и аналога - но не на наши деньги. Кроме того Вам понадобится полная модель микроконтроллера, что бы запустить на нем hex код программы на ассемблере.
Еще раз рекомендую сделать макет.

Кроме in-system-programming существует не менее хорошая вещь - on-chip-debugging.
Обе эти вещи в целом существенно экономят время разработки, т. к. позволяют работать с РЕАЛЬНЫМ железом в противовес абстрактным моделям, какими бы точными они не были.
Хотя, не спорю, можно найти применение последним.
Я, например, в своё время увлекался всё тем же Протеусом, но когда разнообразие и сложность применяемых МК возросло настолько, что лень стало искать или создавать модели, я перешёл на внутрисхемную отладку.

1. по симуляции - именно так поступает Долинский, их САД позволяет все это делать. (http://NewIT.gsu.unibel.by) Поищите в архивах журнала КиТ.
2 я лично применял встроенные лог. анализаторы. лет 6 назад машины слабые были, долго ждать симуляцию приходилось. А с Nios'ом P3-500 при 256 памяти справиться вообще не мог. Так, что будете симулить очень-очень долго.
Удачи.

Спасибо всем, кто ответил!

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

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

Посмотрите реализацию Вашей темы в DXP от Альтиум (Board on Chip). В Нексаре ряд примеров посвящен именно этому: использование одного-двух МК + внешние компоненты (VGA,PS/2,Mouse)+виртуальные измерительные приборы (генераторы,анализаторы). Программа для МК на С, встроенный компилятор Таскинг, есть дебаггер.

Не совсем пойму, о какой программе идет речь. Немогли бы Вы дать ссылки?

Я имел в виду программу Nexar, входящую в состав DXP от фирмы Altium
Altium Products

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

Бегло просмотрел http://www.altium.com/files/IntroducingNexar.pdf.
К сожалению Nexar поддерживает только моделирование, при котором элементы подключаются в виде блоков, а это не совсем то, что я хотел (я гнался за возможностью моделировать "реальную схему").
Как бы там ни было, за ссылку спасибо.

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

К сожалению, если нет серьёзной школы разработок и опыта работы в этой области, то искомые Вами программы мало чем помогут.
Реальная жизнь имеет тенденцию отличаться от идеальной.
Особенно при колебаниях температуры и напряжения питания.
А вот серьёзные нарушения при разводке питания и общего провода как промоделировать?
Что касается возможностей зависания и задержек, то и в дейташитах масса подсказок на эту тему, как то:
- если цикл внешней шины МК 70 нс, то не искушайте судьбу и не ставьте внешнюю память с таким же циклом, а выберите хотябы 55 нс;
- если говорится, что в качестве защёлки адреса надо применять AHC серию, то не следует надеяться, что и обычная HC справится;
- если заметили, что вышли эрраты на тему вотчдога, ставьте внешний;
- землю разводите не скупясь на толщину проводников и полигоны;
- и прочая, и прочая, и прочая...

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

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