Средства и методы разработки

Так так! Продолжаем развивать идею -> гетерогеной многопроцессорной системы как идеального средства для отладки. Теперь посмотрим на LPC43xx как на виртуализируемый хард. Real-Time Operating System Modelling and Simulation Using SystemC --> http://caxapa.ru/483151.html
http://caxapa.ru/488662.html
Пусть у нас в LPC43xx отлаживаемый код живет во FLASH, а все данные для него - в SDRAM. Нас не волнует падение скорости, главное, что функционально это эквивалентно системе с FLASH и большим ОЗУ. Cortex-M0 работает из SRAM и свои данные хранит там же. И он работает как гипервизор для Cortex-M4. Которые ничего на знает про периферию, он все сигналы получает только от М0. Шедулер отлаживаемой ОСи устроен так, что после получения управления он ждет команды от М0 - а то что дальше делать-то? А тот ее получает от SystemC суперсимулятора! Т.е. мы пишем высокоуровневую модель неких реальных процессов в транзационной методологии SystemC - когда симулируются только актуальные для блока фронты, а не один и тот же фронт 100 Мгц для всего на свете. Что сильно ускоряет процесс. Модель реального процесса (от UART до модели станка с ЧПУ): - формирует данные - формирует событие для ПО - получает данные от ПО - получает от него событие. Потом эти данные, скажем, через Ethernet, получает Cortex-M0, кладет их в память, и передает сигнал отлаживаемой ОСи и управляемой ею задаче. Обратный путь аналогичен. И есть некий механизм обмена этими самыми транзакционными моментами. Что касается медленности, то это + рассматриваемой системы. Отсутствие кеша большой +, об этом ниже. Если целевая система событийно-управляемая, то медленность не влечет за собой вероятности появления срытых дефектов. Если система не успевает - это будет обнаружено, и можно в деталях отследить - что именно не успело. Т.е. все действия происходят в какое-то определенное время, и это время можно протоколировать, можно запускать таймер валидного окна обработки этого события, и отслеживать - успели или нет. Преимущества по отношению к полностью софтовой эмуляции: * вопрос о корректности модели снимается. Работаем с живым процом. * по скорости - софтовые эмуляторы быстры при симуляции голого ядра с минимумом периферии. Если симулировать память, да еще и отслеживать, были ли там изменения - скорость будет не такой высокой. * контроль изменения памяти можно сделать так. Внешнюю большую память делим на 3 куска. Один кусок - это рабочая зона, два куска - снимки памяти. Остановили М4, через DMA память - память скопировали рабочий кусок в первый буфер, сравнили со вторым (можно на ПЛИСке какой-нибудь "сравниватель" сделать), второй буфер сделали первым для следующего шага. В конце-концов, даже если рабочей памяти 1Мбайт, можно по Ethernet отсосать ее на пысюк за 100мс - не так и плохо. Вообще говоря, если немного подумать, то становится ясно, что гетерогенная многопроцессорность не обязательна :) Делаем старый добрый монитор в отлаживаемом чипе, а далее - все как я сказал :) Шедулер прыгнул в монитор, тот работает в своих изолированных кусках ОЗУ, ничего не портит в основной памяти. MPU современных процов, кстати, сильно поможет быть уверенным в этом. Критика? Кто-то что-то подобное делал?