Тут стоит добавить, что посадка «не до упора» приведет к увеличению паразитной индуктивности, что может плохо сказаться на вашем блоке питания. Для аудиоаппаратуры это не имеет значения — частоты не те, а высокочастотная электроника, потребляющая десятки ампер (например, типичный современный десктопный процессор) вам спасибо не скажет.
Грубо говоря, таблица страниц — это структура данных, в которой содержатся сведения о том, по каким физическим адресам в памяти расположены виртуальные страницы (и расположены ли они вообще — они могут быть не в оперативке, а на диске), права доступа к ним и т.д.
Только операционная система может добавлять или удалять записи из этой таблицы. Каждая запись соответствует одной странице, поэтому записей очень много и таблица занимает много места. Кроме как в оперативную память поместить ее некуда, т.к. ее размер может быть несколько мегабайт. TLB — это как кэш-память для этой огромной таблицы, TLB хранит несколько наиболее часто используемых записей.
Кэши в ARC 700 можно сконфигурировать как VIVT. Но вообще VIVT-кэши сейчас не очень-то популярны. А про более популярные варианты (PIPT и VIPT) будет в следующей части
Тема необходимости функциональных симуляторов не раскрыта. Я вот не очень представляю, кому они могут быть полезны. Вот к cycle-accurate симуляторам вопросов у меня нет — там тебе и сайд-эффекты от промахов кэша, и от неправильно предсказанных переходов, и от латентности памяти. Вот это симуляторы так симуляторы. Если они еще и работают хотя бы порядка на три быстрее, чем RTL-симуляторы, то цены им нет! А функциональные симуляторы — так, баловство (имхо, разумеется).
Наверное, не совсем корректно сравнивать Low Power процессы c 28HP, поэтому вот данные по «быстрым» процессам из того же документа:
— 90GP: 420 МГц (90нм — это как раз времена позднего Pentium 4)
— 40GP: 770 МГц
То есть только за счет перехода с 40 нм на 28 нм увеличение частоты составляет 16%.
А вот данные по интеловским процам с одинаковой архитектурой (Nehalem/Westmere) и сопоставимыми техпроцессами (брал самую высокую частоту отсюда: en.wikipedia.org/wiki/List_of_Intel_Core_i7_microprocessors):
45 нм: 3,33 ГГц
32 нм: 3,47 ГГц (+4%)
Рост частоты ограничен способностью корпуса микросхемы рассеивать тепло. До тех пор, пока это не проблема, как в случае с относительно маленькими кристаллами, частота действительно значительно растет при переходе на техпроцесс с меньшими нормами (при прочих равных условиях)!
Вот циферки для процессора Synopsys ARC EM6 из официального даташита (http://www.synopsys.com/dw/doc.php/ds/cc/arc_em6.pdf), конфигурация процессора идентичная:
Этот процессор на 65-нм процессе занимает 0,04 мм2 и рассеивает 5 мВт. Очевидно, что такое мизерное тепловыделение никак не ограничивает рост частоты.
В случае, когда кристалл значительно большего размера, именно тепловыделение играет решающую роль. Микросхема, изготовленная по техпроцессу 40LP с кристаллом площадью примерно 10 мм2, засунутым в пластиковый корпус размером 15х15мм, может работать без радиатора на 400 МГц. На 700 МГц ей нужен радиатор, и он уже весьма теплый.
Что происходит, когда у вас кристалл в районе 100 мм2, работающий на частоте за 2 ГГц, можете догадаться сами. Поэтому частоту повышают на столько, сколько может выдержать корпус.
Так что стадии конвейера тут не при чем. Мало того, имхо, именно проблемы с тепловыделением позволили вернуть длину конвейера к приличным значениям наперекор маркетологам.
На самом деле у UART и SPI два входа тактовой частоты — один для системной частоты, второй для передачи данных. Дело в том, что и UART, и SPI висят на системной шине, соответственно каждый из них содержит контроллер этой шины, который просто обязан работать на той же частоте (и не просто на той же частоте, а точно от того же тактового сигнала). Передача же осуществляется на совсем другой частоте (которая, в общем случае, вовсе не кратна системной, и может вдобавок иметь произвольный сдвиг фазы). Поэтому внутри UART и SPI есть специальные синхронизаторы, которые обеспечивают надежную передачу данных из одной области синхронизации (clock domain) в другой.
Подождите. Вы говорите, что процессор «читает значение по адресу 0x00000004 и записывает его в PC (PC – регистр, который указывает на текущую инструкцию + 4 байта)». По адресу 0х4 у нас 0х69. Это не адрес текущей команды + 4, это адрес следующей команды!
Доступ к 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» — это как раз то, как работает мой абстрактный процессор (который работает так же, как один широко известный в узких кругах реальный процессор). Очевидно, что он может потребовать некоторых усилий от программиста, особенно если тот пишет драйвер или программу для многоядерной системы.
С тем же успехом можно под полным программным контролем заливать нужные области памяти по DMA в on-chip SRAM, у которой латентность как раз один такт (такая память называется Scratchpad Memory, Closely Coupled Memory или Tightly Coupled Memory, как кличет ее ARM). На этот счет есть любопытные исследования, могу дать ссылок. В общем, варианты есть, и кэш не должен рассматриваться как панацея.