Evgeny_CD, Архитектор (11.03.2018 21:29, просмотров: 66) ответил lloyd на Никто в здравом уме небудет забесплатно восстанавливать архитектуру периферии по Technical Reference Manual.Исходников не дадут, даже ARM дает их только в зашифрованном виде под конкретную платформу, но задача на SystemC решаемая. Вот смотри. http://www.asic-world.com/systemc/tutorial.html
Нормальные фирмы дают вполне подробные описания ядер. Включая растактовку. См. описания на SH-2A и SH-4A. в 500 стр. ужато все - растактовка, описание принципа суперскалярности, разбиение команд на группы, какие можно исполнять параллельно, какие нет, работа конвейера, работа с памятью. Весь конвейер эмулировать не надо, но время исполнения и время ожидания при очистке конвейера сэмулировать нетрудно. Кеши тоже подробно описаны - размер, ассоциативность, алгоритм - и их тоже несложно сэмулировать. На выходе такой "частично тактово-аккуратной модели" мы имеем шину, по которой процессор проводит транзакции. Контроллер прерываний тоже не самая сложная штука. Далее получаем некий "черный ящик", который подцепляем к SystemC ядру. У SystemC простой и понятный набор базовых сущностей - регистр ("вектор"), сигнал ("провод"), массив чего-либо -> + описание времени и описание поведения сущностей. Вот при помощи этого описания поведения и описываем поведение UART. Нам не важна структура, нам важно что в нейкий момент (вычисленный по скорости) он родил событие, которое вызвало прерывание. У проца своя тактовая, у таймера своя - SystemC все отработает. Также подразумевается некое десткое конфигурирования под задачу - полной побитной реализации всех регистров камня не будет! Таким образом, более-менее точно мы получим симуляцию камня. Важнейший момент, который легко отработать на модели, и что устанешь отрабатывать в жизни - асихронность всех событий. Типа прерывание от UART пришло позже или раньше "среднего значения" (по скорости), но средняя скорость при этом сохранилась. Реальные события пошли быстрее или медленее, чем на прошлой итерации и т.д. Вот тут все косяки синхронизации всех частей программы и вылезут. Дальше все переносится в железо, совмещается с реальными дровами - отладку в железе ничто не заменит.
Нормальные фирмы дают вполне подробные описания ядер. Включая растактовку. См. описания на SH-2A и SH-4A. в 500 стр. ужато все - растактовка, описание принципа суперскалярности, разбиение команд на группы, какие можно исполнять параллельно, какие нет, работа конвейера, работа с памятью. Весь конвейер эмулировать не надо, но время исполнения и время ожидания при очистке конвейера сэмулировать нетрудно. Кеши тоже подробно описаны - размер, ассоциативность, алгоритм - и их тоже несложно сэмулировать. На выходе такой "частично тактово-аккуратной модели" мы имеем шину, по которой процессор проводит транзакции. Контроллер прерываний тоже не самая сложная штука. Далее получаем некий "черный ящик", который подцепляем к SystemC ядру. У SystemC простой и понятный набор базовых сущностей - регистр ("вектор"), сигнал ("провод"), массив чего-либо -> + описание времени и описание поведения сущностей. Вот при помощи этого описания поведения и описываем поведение UART. Нам не важна структура, нам важно что в нейкий момент (вычисленный по скорости) он родил событие, которое вызвало прерывание. У проца своя тактовая, у таймера своя - SystemC все отработает. Также подразумевается некое десткое конфигурирования под задачу - полной побитной реализации всех регистров камня не будет! Таким образом, более-менее точно мы получим симуляцию камня. Важнейший момент, который легко отработать на модели, и что устанешь отрабатывать в жизни - асихронность всех событий. Типа прерывание от UART пришло позже или раньше "среднего значения" (по скорости), но средняя скорость при этом сохранилась. Реальные события пошли быстрее или медленее, чем на прошлой итерации и т.д. Вот тут все косяки синхронизации всех частей программы и вылезут. Дальше все переносится в железо, совмещается с реальными дровами - отладку в железе ничто не заменит.