Доступ к IEEE Transactions on Nuclear Science у меня есть (к моему удивлению, оно включено в нашу корпоративную подписку). Спасибо за наводку, сам бы ни в жизнь туда не полез!
Я могу вкратце перечислить, что было бы интересно мне:
1. Резервирование on-chip: есть ли в нем вообще смысл, возможные варианты (троирование, lock-step, и т.д.), логические выкрутасы типа самодвойственной логики и т.д. Плюсы и минусы резервирования отдельных регистров/вентилей против резервирования блоков, и соответсвенно против резервирования микросхем или модулей.
2. Помехоустойчивое кодирование: в случае кодов Хэмминга используется ли гражданское «обнаружение двух ошибок, исправление одной», или нечто большее? Опять же, добавляют ли защиту во все регистры, например между стадиями конвейера, или только в архитектурно видимые? Например, согласно Википедии, в «космическом» процессорном ядре LEON3-FT обеспечивается коррекция до четырех ошибок на 32-битное слово, но только в кэше и регистровом файле.
Если у вас есть на примете какие-нибудь действительно хорошие статьи, был бы рад ссылкам (чтоб в ручную не перелопачивать выдачу гугла).
АРМы бывают разные. Например, когда случается исключение в Cortex-M4, в регистр адреса возврата сохраняется адрес, который в конце обработчика нужно вручную уменьшить на 8 и записать в PC, если требуется повторить команду, и на 4, если команду повторять не нужно. То есть вполне возможно, что в явном виде АСК там нет. При этом точные прерывания этот процессор поддерживает (да даже ARM7TDMI поддерживает — например, к нему можно прикрутить внешний MMU).
Интереснее было бы посмотреть на реализацию прерываний в Cortex-R или Cortex-A. Минимальная длина конвейера в этих процессорах — восемь стадий, в отличие от трехстадийных Cortex-M, и я не очень представляю, как они могли бы работать без АСК.
Ну все же упомянуть синтез стоило. Это же краегольный камень, так сказать. А вдруг студент какой прочтет, да потом на экзамене ляпнет? Конфуз выйдет-с :)
А в случае топографического синтеза (который дает гораздо лучшее совпадение результатов post-synthesis и post-layout, начиная то ли с 90нм, то ли с 65нм), Design Compiler и размеры ячеек использует.
IC Compiler читает не верилог, а нетлист. Верилог в нетлист преобразует логический синтезатор, например Design Compiler. Соотвественно, именно он ходит в библиотеку за логическими функциями standard cell'ов. IC Compiler ходит в ту же библиотеку за физическими размерами ячеек.
С тех пор, как прикрыли Гигапедию, с книгами тяжко :) Я бы рекомендовал начать вот с этого: AMBA 2 Specification. Это не книга, а спецификация, но написана очень понятно, много картинок, к тому же бесплатная (надо только зарегистрироваться). Если есть какой-никакой бэкграунд, хотя бы на уровне институтского курса по цифровой схемотехнике — разобраться не составит труда. Читать можно только про AHB и APB — они до сих пор актуальны, в отличие от ASB.
Разумеется, речь не идет про SRAM, висящий на внешней шине вместе с периферийными устройствами. С точки зрения процессора это такая же внешняя память, как какой-нибудь DDR, даже если физически она находится на том же кристалле. Даже если память сама по себе обеспечивает доступ за один такт, все равно будет дополнительная задержка в бридже между процессором и шиной, а также накладные расходы на арбитраж.
CCM/TCM — совсем другое дело. Этот тип памяти фактически встроен в конвейер. Если в процессоре есть кэши, то CCM/TCM расположены бок о бок с ними, а не за ними, как SRAM на внешней шине. В процессоре с гарвардской архитектурой CCM/TCM для команд и данных раздельные, как и кэши. Кроме того, такая память может быть двухпортовой, и тогда процессор может читать из нее, скажем, команды, а DMA-контроллер одновременно может копировать в нее блок из внешней памяти.
«Write burst» — это не просто запись в ОЗУ, это пакетная запись в ОЗУ строки кэша для минимизации задержек на внешней шине процессора. Это настолько критично с точки зрения производительности, что все современные протоколы системных шин (те же AHB, AXI и т.д.) поддерживают специальные команды для записи/чтения строк кэша (так называемые «wrap bursts»), специально заточенные под режим «critical word first».
Совершенно точно можно заставить кэш данных записать свое содержимое в ОЗУ при «write-back» стратегии, причем в некоторых случаях это можно сделать как для всего кэша целиком, так и для конкретной строки. Для этого в процессоре предусмотрены команды или управляющие регистры. Запись измененных данных из кэша в ОЗУ называется «cache flushing». Для х86 это делается так: stackoverflow.com/questions/1756825/cpu-cache-flush
Статья про конкретный кусок кода и его испонение процессором с кэшами. Про то, как реально происходят запросы в память и чего можно от них ожидать. Цели объяснять азы работы кэша я не ставил (благо ссылка на неплохую статью имеется в начале).
«Write burst» показан на последнем рисунке слева — он происходит, пока сигнал «Писать» выставлен в единицу. «Write-back» — это как раз то, как работает мой абстрактный процессор (который работает так же, как один широко известный в узких кругах реальный процессор). Очевидно, что он может потребовать некоторых усилий от программиста, особенно если тот пишет драйвер или программу для многоядерной системы.
infocenter.arm.com/help/topic/com.arm.doc.faqs/ka13089.html
1. Резервирование on-chip: есть ли в нем вообще смысл, возможные варианты (троирование, lock-step, и т.д.), логические выкрутасы типа самодвойственной логики и т.д. Плюсы и минусы резервирования отдельных регистров/вентилей против резервирования блоков, и соответсвенно против резервирования микросхем или модулей.
2. Помехоустойчивое кодирование: в случае кодов Хэмминга используется ли гражданское «обнаружение двух ошибок, исправление одной», или нечто большее? Опять же, добавляют ли защиту во все регистры, например между стадиями конвейера, или только в архитектурно видимые? Например, согласно Википедии, в «космическом» процессорном ядре LEON3-FT обеспечивается коррекция до четырех ошибок на 32-битное слово, но только в кэше и регистровом файле.
Если у вас есть на примете какие-нибудь действительно хорошие статьи, был бы рад ссылкам (чтоб в ручную не перелопачивать выдачу гугла).
Интереснее было бы посмотреть на реализацию прерываний в Cortex-R или Cortex-A. Минимальная длина конвейера в этих процессорах — восемь стадий, в отличие от трехстадийных Cortex-M, и я не очень представляю, как они могли бы работать без АСК.
Если есть возможность, можно полистать вот эти книжки: On-Chip Communication Architectures: System on Chip Interconnect или Networks on Chips: Technology and Tools
CCM/TCM — совсем другое дело. Этот тип памяти фактически встроен в конвейер. Если в процессоре есть кэши, то CCM/TCM расположены бок о бок с ними, а не за ними, как SRAM на внешней шине. В процессоре с гарвардской архитектурой CCM/TCM для команд и данных раздельные, как и кэши. Кроме того, такая память может быть двухпортовой, и тогда процессор может читать из нее, скажем, команды, а DMA-контроллер одновременно может копировать в нее блок из внешней памяти.
Вот несколько ссылок, которые были под рукой:
Predictable Programming on a Precision Timed Architecture
Software-based Instruction Caching for Embedded Processors
An Optimal Memory Allocation Scheme for Scratch-Pad-Based Embedded Systems
Совершенно точно можно заставить кэш данных записать свое содержимое в ОЗУ при «write-back» стратегии, причем в некоторых случаях это можно сделать как для всего кэша целиком, так и для конкретной строки. Для этого в процессоре предусмотрены команды или управляющие регистры. Запись измененных данных из кэша в ОЗУ называется «cache flushing». Для х86 это делается так: stackoverflow.com/questions/1756825/cpu-cache-flush
«Write burst» показан на последнем рисунке слева — он происходит, пока сигнал «Писать» выставлен в единицу. «Write-back» — это как раз то, как работает мой абстрактный процессор (который работает так же, как один широко известный в узких кругах реальный процессор). Очевидно, что он может потребовать некоторых усилий от программиста, особенно если тот пишет драйвер или программу для многоядерной системы.