OSDev

Пиши, на Ассемблере оно понятнее получается.

Представляю небольшой туториал, в котором я попытаюсь простым рабоче-крестьянским языком описать что такое PAT и как его попользовать в свое удовольствие.

Итак PAT (Page Attribute Table), в моем вольном переводе означает "Таблица аттрибутов страниц(ы)".
Зачем это еще, а можно без этого?
Да можно, если писать ядро с текстовым интерфейсом ONLY или совсем уж ущербной графикой с низким разрешением и убогой цветовой гаммой.
А ежели хочется красивостей всяких, прозрачностей там или еще чего (3D Pipeline к примеру), хорошей графики стало быть, то без PAT все еще можно обойтись, но отрисовка пикселей будет очень медленной, что обязательно вызовет у юзера бесконечный поток нецензурной брани в адрес разраба ядра.
Что бы этого избежать, и не только этого, необходимо ускорить вывод графики одним из трех известных способов:
1. Аппаратное ускорение (Hardware acceleration) графики, то что надо, но есть некоторые ньюансы, а именно, как это программно реализовать в виде кода. Видеокарт миллионы, доков на абсолютное большинство нет и не предвидиться, а одного желания не достаточно.
2. Программное ускорение (Software acceleration) графики, на порядки хуже HW, но за неимение лучшего пойдет и так, срединный путь как говориться.
3. Взять цветные фломастеры и рисовать графику вручную прямо на экране монитора, только это очень медленно, а и не у всякого получиться, красиво что бы, да и в башню может прилететь, если моник чужой.

- Замутим?
- Ну пожалуй, а что надо делать?

Да сущие пустяки, для начала почитать, например, вот этот туториал: http://forum.osdev.org/viewtopic.php?p=257947&sid=70ea17364d329129a5a4cd029db18032#p257947,
равно как и многие другие, да собственно в самой спецификации VESA BIOS EXTENSION (VBE) "vbe3.pdf" (гуглиться за один клик), все разжевано до состояния бульона, не по нашему правда написано, но понять можно.
После того как станет понятным и родным словосочетание LFB (Linear Frame Buffer) можно и этот туториал прочитать, тут уже по нашему, для себя, что бы значит просто было и понятно.

Начнем.
PAT входит в состав так называемых MSR (Model-Specific Registers), это кусок памяти внутри камня, который не у всех камней есть, проверять надо, а как?
Проверить поддержку камнем MSR вообще и PAT в частности можно очень просто:

PAT нельзя включить или выключить, он активен всегда (даже если нам это не надо или мы вооще ничего о нем не знаем или не хотим знать), при условии, что включена страничная адресация памяти (в LONG MODE это без вариантов, стало быть обязательно ДА).
У PAT есть свой собственный регистр, он условно называется IA32_PAT, условно потому, что к нему нельзя обратиться по имени, а только по смещению 0x277 относительно памяти, которая называется MSR (Model-Specific Registers).
Прямого доступа к этой памяти разумеется нет, но мы можем запросить содержимое интересующнго нас регистра с помощью инструкции RDMSR (Read MSR), внести туда любые изменения (под нашу прямую ответственность) и записать обратно с помощью инструкции WRMSR (Write MSR).
Как уже было отмечено ранее, нас интересует исключительно регистр IA32_PAT расположенный по смещению 0x277. Давайте посмотрим что там:

Интересующая нас информация находиться в регистре RAX, именно RAX, т.к. регистр IA32_PAT 64-битный, не смотря на цифру 32 в названии.
Для нашей цели (ускорение вывода пикселей в LFB (Linear Frame Buffer)), нам будет вполне достаточно регистра EAX.
Итак запрос сделан, каков же ответ. В моем случае, на эмуляторе QEMU, регистр EAX содержит число 0x00070406. Ну и что, а зачем это? Читаем дальше.

Что же представляет из себя регистр IA32_PAT, рассмотрим для начала регистр RAX:

Как видно из рисунка, регистр RAX состоит ровно из 8 одинаковых однобайтовых (8 битовых) частей, к некоторым из них можно обратиться по имени, к большинству нельзя, но ведь это нас не останавливает, мы можем обратиться по смещению и получить значение любого байта или даже бита.
По аналогии с регистром RAX составим схему регистра IA32_PAT:

Где 00000bbb это двоичное представление данных (8 бит), из которых 00000 = 5 нулевых бит и bbb = 3 значащих бита, которые, в свою очередь, так же могут быть нулевыми, а могут и не быть.
Из рисунка-схемы видно, что регистр IA32_PAT так же как и RAX состоит из 8 одинаковых однобайтовых (8 битовых) частей, к которым нельзя обратиться по имени, а только по смещению, но мы то это умеем делать.

Напомню, что пять старших битов каждого байта PAT0 ... PAT7 ВСЕГДА равны нулю, значащими являются только 3 младших бита, с ними и будем работать.
А как же тогда понять в каких случаях младшие три бита не нулевые и что все это означает?
Как раз для такого случая Intel составила табличку, которую мы тиснем из "Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume 3A, 11.12 PAGE ATTRIBUTE TABLE (PAT)",
я только чутка ее модифицировал, для простоты.

Как видно из таблицы, столбец "БИНАРНЫЙ КОД" аккурат представлен тремя значащими битами, а столбец "РАСШИФРОВКА" дает нам однозначное толкование этих самых трех битов.
Давайте припомним наш прошлый запрос, который мы так и не распарсили, EAX = 0x00070406 = 0x00 0x07 0x04 0x06
Смотрим на табличку и видим что:
PAT0 = 0x06 = Uncached (UC-)
PAT1 = 0x04 = Write Protected (WP)
PAT2 = 0x07 = Reserved
PAT3 = 0x00 = Uncacheable (UC)
Старшие PAT'ы (PAT4 ... PAT7) нам вообще не интересны.

Ну допустим, узнали мы, что код Write Combining (WC) = 0x01, а что с ним делать то, куда прописать и главное как?

Для начала следует определиться какой из PAT'ов тиснуть, они НЕ зависимы друг от друга и брать можно любой, мы же пишем ядро мы и решаем.
PAT0 мы трогать не будем, почему, станет понятно из дальнейшего текста.
А что там у нас следующее на очереди, так ведь PAT1, а можно? Нужно!
Решено замутим с PAT1 (он ПЕРВЫЙ справа, соответствует регистру AH, а PAT0 НУЛЕВОЙ справа, соответствует регистру AL):

Ну что ты все? Почти, потерпи еще немного, я скоро.

Далее я буду излагать свое личное мнение на то как устоен этот мир, что правильно и что не правильно.
Итак, ось должна быть строго 64-битной, память внутри ядра должна быть расчехлена на 2-х мегабайтные страницы, я бы расчехлил на 1-гигабайтные, но не все камни это держат, печаль.
Тема расчехления памяти на страницы тянет на отдельный туториал, может кто его и напишет (подключайтесь), а может даже это буду я, посмотрим, а сейчас голый код со скромными коментами:

Как память расчехлять на сраницы отдельный разговор, а вот слив LFB в WC рассмотрим подробнее.
Итак через VESA мы получили адрес LFB, я сохранил его в структуру 'param', можно назвать по своему, а разве может быть иначе.
Адрес LFB выровнен, уж не знаю насколько точно, но на 2 MB можно расчитывать, поэтому делим значение адреса LFB на 2 MB, что бы узнать смещение от НАЧАЛА памяти, т.е. от НУЛЯ в 2-х мегабайтных страницах.
Например, пусть адрес LFB = 0x90000000, тогда делим 0x90000000 на 0x200000 и получаем 0x480 = 1152 2-х мегабайтных страниц. Их трогать НЕЛЬЗЯ, пропускаем.

Напомню, что каждая запись в таблице PDT занимает 8 байт, а у нас этих записей, как мы только что посчитали, 0x480 = 1152 и их трогать НЕЛЬЗЯ, а как узнать какие можно, так просто:

0 запись = 8 * 0 = 0
1 запись = 8 * 1 = 8
...
343 запись = 8 * 343 = 2744
...
1152 запись = 8 * 1152 = 9216 = 0x2400

То есть нам нужно пропустить 1152 записи в таблице PDT, каждая запись это 8 байт, значит умножаем 1152 на 8 и получаем 9216 байт, это смещение от начала PDT в байтах.

Я знаю, что можно сразу сделать так:

Но как-нибудь потом лениво будет ломать голову, а почему я здесь написал 18, а как же так вышло ..., чем проще, тем лучше.
Далее EDI присваиваем адрес PDT в памяти и смещаемся на расчитанное количество байт:

Далее нам нужно расчитать "стартовое" значение, которым мы начнем перезаписывать атрибуты конкретно взятых страниц занятых под LFB.
По тупому берем еще раз адрес LFB из структуры 'param' и прибавляем к нему магическое число 10001011b в котором зарыта вся суть.

Распарсим эту магию:
самый младший бит №0 означает, что страница реально существует из нее можно читать и в нее можно писать
следующий бит №1 означает, как раз то, что страница R/W, т.е. и читаемая и писаемая
следующий бит №2 означает, посмотрите сами что он означает, или по тупому ставим ноль
следующий бит №3 означает, ОДИН ИЗ ТРЕХ значащих битов (PAT, PCD и PWT), в данном случае это PWT = 1
следующий бит №4 означает, ОДИН ИЗ ТРЕХ значащих битов (PAT, PCD и PWT), в данном случае это PCD = 0
самый старший бит №7 означает, что это 2-х мегабайтная страница, а если страницы 4-х килобайтные, то это и есть PAT (ОДИН ИЗ ТРЕХ значащих битов (PAT, PCD и PWT)) и он ДОЛЖЕН быть нулевым!
Но т.к. у нас страницы 2-мегабайтные, то 7 бит это НЕ PAT, а PAT это бит №12, и он у нас как раз нулевой.

Подитожим:
мы имеем следующее сочетание PAT|PCD|PWT = 001b, это НЕ ОЗНАЧАЕТ, что страница слита в WC, это означает, что аттрибут страницы берется из регистра PAT1, код которого = 001b = 0x01, а вот в него то мы как раз и записали атрибут WC, который тоже, по чистой случайности = 001b = 0x01.
Далее в цикле изменяем аттрибуты 8 страниц, а почему 8, да потому что у меня размер foreground+background буфера = 1920*1080*4*2 = 16 мегабайт, делим на 2 мегабайта (размер страницы) и получаем 8, количество страниц занятых под LFB.

Ну и напоследок, почему не рекомендуется трогать PAT0, потому что его код в формате PAT|PCD|PWT = 000b = 0x00 и именно этим кодом (все нули) мы по дефолту аттрибутим ВСЕ наши страницы и только потом переаттрибутиваем нужные на WC.
Т.е. ВСЕ наши страницы при инициации получают аттрибут 000b = 0x00 = PAT0, а в нем код 0x06 = Uncached (UC-), поэтому вывод пикселей так ужастно тупит.
Не вздумайте слить ВСЕ страницы в WC, это косяк!
На этом все, проще объяснить не могу, не имею такого таланта, надеюсь будет кому то полезно.

Оформлять их как код, чтобы использовался моноширинный шрифт?

Сработало, сам бы не додумался

MTRR прекрасно работает при любом размере памяти - если всё правильно расписать.
Что довольно нетривиально для общего случая, да.

Для своей системы использовать лучше PAT - это на порядки проще, конечно.

Но если страничный режим активен не всегда или мы, например, грузим какой-ньть DOS - то MTRR - единственное средство поставить WC.

А кто-нибудь имел дело с так называемыми ПЛИС (Программируемая логическая интегральная схема), а конкретнее FPGA (field-programmable gate array).
Меня все не оставляет желание замутить аппаратное ускорение графики и раз нет вменяемых доков на существующие видяхи, так может замутить свою, в которой я и только я буду решать какие будут регистры, как они будут называться, по какому адресу находятся и какова будет их разрядность.
Я читал об этом, есть даже примеры реализации VGA контроллеров и навроде как это не сильно сложно.
Однако насколько это реалистично, замутить свою видяху, при следущих условиях:
1. Деньги на покупку ПЛИС есть, потратить не жалко, даже если ничего не получиться, тем более что сумма в пределах 50-100 баксов, плевое дело.
2. Время и желание тоже есть, я упрямый как баран и если вцепился зубами, то уже не отпущу. Жалко только тратить время на линуксовые драйвера, там абстракция на абстракции и абстракцией погоняет, мерзость одним словом, я ненавижу абстракции, люблю когда все просто и понятно.
Вопрос только в том, сколько отдельных НЕ зависимых ядер можно замутить на среднем FPGA и какова будет их производительность.
Каждое ядро само по себе слабое это и коню ясно, но их должно быть очень много и ключевой момент, что работать они должны одновременно и не зависимо друг от друга, обрабатывая каждое свой собственный пиксель.
Сразу следует отметить, что реализация 3D пайплайна с шейдерами и числами с плавающей точкой пока только мечта, на сегодняшний день интересны только целые числа и простейшие математические действия: сложение, вычитание, умножение, деление, сдвиги и логические операции.
Это позволить быстро и качественно отрисовать 2D графику, включая прозрачность, красивый GUI одним словом.
На совместимось со стандартами, в том числе и VGA, универсальность и кроссплатформенность плевать в прямом смысле этого слова, камень только INTEL, если AMD потянет, возражать не стану, а на всякие ARM и прочее, ну вы поняли ...

Я с плисинами балюсь, например. Мелкую ПЛИС купить действительно не проблема, и стоить будет недорого. Но как Вы собираетесь её присобачивать к компу? Это надо делать свою плату (под PCI Express, естественно -- других шин для плат у более-менее современных матерей уже нет). Кроме того, надо обеспечить, чтоб ПЛИС работала с шиной в полном соответствии со стандартами -- а значит, нужно либо брать ПЛИС, где имеется соответствующий аппратный блок, либо самому реализовать его внутри ПЛИС. В обоих случаях плисина будет уже не такой дешёвой, как хотелось бы.

Видеопамять тоже никто не отменял. Работать с системной? Медленно и печально, а заодно сильно тормозит проц (потому что мешает ему обращаться к памяти). Значит, на плату надо ставить микросхемы памяти, а ПЛИС должна быть способна с ними работать (опять-таки, либо готовый аппаратный контроллер, либо его реализация внутри ПЛИС).

Программная поддержка. Написать драйвер даже простого устройства не всегда легко, ну а видюху к простым устройствам отнести тяжело. Чтобы функции ускорения реально работали, они должны соответствовать ожиданиям оси от таких функций, а драйвер эти ожидания должен поддерживать. Толку, например, в суперсовременной видюхе для Вынь-95? Все навороты железа там не будут использоваться, потому что нет программной поддержки, и видюха сможет работать лишь как VGA. С другой стороны, древнюю видюху с современной Виндой использовать нельзя, поскольку она не обладает требуемым минимумом функционала. Как дела в Линухе, я не знаю; подозреваю, что древность заставить там работать можно. Но в любом случае, под какую систему ни делай, а придётся с головой зарываться в её драйверную модель и писать кучу кода.

Ну а производительность... Даже на сверхкрутой плисине, стоящей многие тысячи или даже десятки тысяч баксов, она не будет дотягивать даже до современной виндюхи начального уровня. За универсальность ПЛИС приходится платить намного более низкой, чем у специализированных микросхем, производительностью. И смотреть на максимальные частоты ПЛИС здесь бессмысленно, потому что роль играет не то, с какой частотой сможет переключаться единичный триггер или какова задержка от входа до выхода LUT, а какова частота, на которой будет работать проект в целом.

Что же касается до типа опенсорцнутых разработок железа, то, насколько знаю, даже обычную VGA вроде бы не осилили, а про ускоритель и говорить нечего.

В общем, заставить ПЛИС выводить на дисплей буфер кадра -- это простая задача, а вот сделать видюху, пригодную для установки в ПК и работы с существующими осями (пускай даже с одной осью) -- это даже не на порядок более сложная, а... не знаю, в тысячу раз или в миллион.

Да здесь все так, но не думаю, что это сложнее, чем написать драйвер под закрытую энвидию, PCI Express открыта или нет, я просто не в курсе.

Так для этого же и существуют выделенные регионы памяти, закрепленные за конкретной железкой или это не то? А как же интеловские видюхи работают, у меня только они, нареканий вообще нет, и видео декодируют и GUI рисуют со свистом, помню даже в Far Cry 3 играл на Haswell во встроенной графикой, на низких настройках, но тем не менее. Я писал под Intel в юзерспейсе графические проги, под Linux разумеется, все летает, т.е. я прямо вручную писал batch и через ioctl() отправлял в ядро на исполнение, своено рода MESA вери-вери-лайт, обратно все летало, речть идет строго о 2D.
Что то вроде этого:

К тому же мне нужна только 2D графика, отрисовать окна с учетом того, что они могут перекрываться и просвечиваться, а правило отрисовки гласит, что каждый пиксель должен быть отрисован один и только один раз, плюс быстрый и качественный композитинг пикселей, включая альфа-блендинг.

Я как раз иного мнения на этот счет, вся "тяжесть" написания драйвера на 95% обязана закрытости железки. Производители предлагают некую абстракцию тесно связанную с бинарным firmware, на эту абстракцию печатают несколько тысяч страниц с непонятными таблицами и структурами, которые ее (абстракцию) описывают, шаг вправо или шаг влево, закрытая информация, досвидос. На изучение этой абстракции можно потратить полжизни, а в конечном итоге все сводиться к тупой операции запись в порт (MMIO) или чтение из порта (MMIO) и больше НИЧЕГО.
Как пример тот же интел, все доки есть, они открыты, https://01.org/linuxgraphics/documentation/hardware-specification-prms, бери да юзай, только это абстракция, где черт ногу сломит, мне же надо прямой доступ к исполняемым ядрам, возможность кодить на ядрах видюхи как на ядрах CPU (да я знаю это тоже абстракция, но хотя бы хорошо документированная).
Только у CPU 8 ядер (максимум), а у GPU, ну скажем 20 (как у Haswell), да плюс на каждом ядре можно запустить 7 потоков (гипертрейдинг), 20 * 7 = 140 условных ядер.
А что сложного в видеокарте, ее ядра на порядки проще CPU, просты как цигане на вокзале.
Предположим есть линейный кусок памяти, я туда с помощью CPU загружаю 140 бакграунд пикселей, есть второй, такой же кусок памяти, я в него загружаю 140 фореграунд пикселей, затем пишу в порт видюхи код, скажем 0x03. Она получает код и знает, что в таком случае нужно скомпозитить 140 пикселей по заранее известным фиксированным адресам, формула простая.
Например так, поток №0 композитит пару пикселей (бакграунд-фореграунд) по смещению 0, поток №1 ... по смещению 4, поток №139 ... по смещению 556. Сложность только в синхронизации ядер и их одновременности.
Потом я тупо копирую готовые пиксели на экран и загружаю следующую порцию. Как например регистры SSE и AVX, только они очень короткие, не тянут, т.е. медленно работают.

А вот это уже грустно и практически рубит под корень порыв энтузиазма.
И все же, Вы работаете в ПЛИС, сколько независимых и очень простых ядер (add sub mul div shr shl rol ror and or neg not mov inc dec) можно реализовать на 100 долларовой плиске, чисто ради любопытства, я читал про FPGA которые прошиваются только один раз и логика работы уже не может быть изменена, но зато там уже не логические связи, а железные, типа что то там плавиться или как то так, я просто совсем не в теме.

Здесь как раз нет проблем, я пишу ядро и я же реализовываю логику работы плиски, я решаю, что в порт PCI 0x32 нужно писать код 1000100110001110b и какая реакция будет, что каждый бит значит и т.д.
А есть ли разница между ПЛИС и FPGA, или FPGA это разновидность ПЛИС, про FPGA я читал неплохие отзывы, что якобы они чуть ли не конкуренцию составляют микроконтроллерам с фиксированной логикой или это рекламная замануха, типа дай нам денег, не парься, просто дай денег.

Это всего лишь указание, что данная часть физического адресного пространства отведена такому-то устройству. Есть по этим адресам что-нибудь, нету ли -- без разницы. Настраивается всё сие динамически по большей части (PnP), лишь для унаследованного (legacy) старья есть жёсткие адреса (вроде отображения BIOS на вершину первого мегабайта и т.п.), да и те частично конфигурируются БИОСом через чипсет (например, содержимое ПЗУ с БИОСом переписывается в ОЗУ, после чего используется именно оттуда, что во много раз быстрей).



Интеловские графические процессоры интегрированы с центральными и подключены напрямую к контроллеру памяти. А устройства, висящие на PCI Express, должны пройти через как минимум один, а то и несколько мостов-коммутаторов, чтобы добраться до этой самой памяти. Плюс ширина доступа немного разная. А посему латентность памяти при обращении со стороны PCI Express существенно выше, а пропускная способность -- существенно ниже. Именно по этой причине у всех дискретных видюх на борту стоит своя видеопамять.



Честно говоря, я подозреваю, что эту работу быстрей будет делать современный ЦП без всяких ускорителей на плисине, чем плисина, если под ЦП писать прямыми руками и кривыми извилинами, а не наоборот. Во всяком случае, если сравнивать с дешёвыми плисинами начального уровня, так сказать, куда много логики просто не влезет, а значит, не получится сильно распараллелить задачу (и, опять-таки, можно упереться в пропускную способность памяти).



Ну, попробуйте написать драйвер OHCI, например. Документация имеется, сам он не особо сложный. Однако эффективный драйвер сделать не так просто, особенно если нет привычки мыслить "асинхронно".



Ну, тут ещё как минимум разрядность требуется знать. Например, в самой жирной плисине семейства Spartan-6 (например, вот она в продаже: https://www.terraelectronica.ru/catalog_info.php?CODE=1069498) имеется 180 специальных аппаратных блоков, включающих преварительный сумматор, 18-разрядный умножитель и выходной сумматор -- как раз для быстрой реализации операций умножения с накоплением и т.п. вещей, часто используемых в цифровой обработке сигналов. Соответственно, можно считать, что имеется 180 быстрых умножителей-сумматоров (вход -- 18 бит, выход -- 36). На собствено "рассыпной" логике у той же плиски можно слепить до ~11500 4-разрядных сумматоров. В общем, ресурсов довольно много, на первый взгляд, но очень значительная часть из них уйдёт на всякие вспомогательные вещи, а не на собственно вычислительные ядра.




Не слышал про такие плисины, скорей, речь шла о ПЛМ, а это -- совсем другая опера. Существуют плисины со встроенной флэш-памятью, которым не нужно загружать прошивку при включении питания, но принципиально они ничем не отличаются от плисин с внешней загрузкой. И, естественно, никаких перемычек там нет -- 100500 мультиплексоров и мелких блоков статического ОЗУ (по 16-64 бита в зависимости от плисины), на которых реализуются произвольные логические функции.



ПЛИС и FPGA -- это одно и то же, только наше и буржуйское название. На определённых задачах они, естественно, обгонят не только микроконтроллеры, но и самые мощные процессоры, но всегда безнадёжно сольют любым специализированным микросхемам, решающим ту же задачу. Собственно, их и используют там, где надо более-менее быстро решить некую задачу, плохо решаемую на имеющихся микропроцессорах, но не настолько распространённую, чтобы оправдать разработку и заказ специализированной микросхемы. Поэтому видюху делать на ПЛИС можно для освоения самого процесса разработки подобного рода устройств и т.п., но не для конкуренции с существующими.

И да, если Вы думаете, что, взяв плисину за 100 баксов, разработка готовой платы будет не сильно дороже, Вы сильно ошибаетесь. Если у Вас нет опыта в разработке сколько-нибудь серьёзной электронике, Вы потратите несколько лет и, думаю, не меньше 10 000 баксов до получения более-менее работающей платы. Вот если Вы собаку съели на разводке всех этих DDR3 и прочих скоростных интерфейсов, тогда другое дело -- в тыщу баксов и 3-6 месяцев уложиться реально. Но в любом случае проще взять готовую плату, что-то вроде такой, например: https://www.xilinx.com/products/boards-and-kits/ek-a7-ac701-g.html. Это одна из самых дешёвых плат, имеющих мощную плисину (мощней той, которую я приводил в пример выше -- у неё примерно на 30% больше ресурсов, хотя изрядную их часть отожрёт контроллер памяти), достаточно большой объём ОЗУ на борту, видеовыход и PCI Express (ну и приличное число всякой прочей дребедени). Понятно, что 1300 баксов -- это цена "у них", у нас добавляете как минимум 30 процентов, а скорей, все 50 или даже больше (и таможенные пошлины, и наценка продавца, и проблемы с ввозом: поставка нам плисин, особенно жирных, американцами запрещена из-за санкций, и это как-то обходят -- и наверняка не бесплатно). Но зато покупаешь -- и оно сразу работает, а не глючит незнамо где и почему.

Формально, спеки предоставляются только организациям-членам группы PCI-SIG (членство платное), но, как обычно, полно утекших спек. Спецификации не сильно помогут, вы не представляете себе уровень сложности шины PCIe на всех уровнях. Даже развести плату будет непросто, там накладываются требования не только на ширину проводников и зазоры между ними, но и требуется выравнивание длин между ними в жёстких пределах. Корпуса для работы с этой шиной только BGA, что практически исключает ручную пайку и печатные платы на коленках. Я не говорю, что это всё невозможно (мы разрабатывали устройства на шине PCIe), но это занятие дорогостоящее, трудно отлаживаемое, требует много времени и сил.


В случае видеокарт это совсем не так. В них уровень сложности железа запредельный.


Во-первых, сложна их организация. Это не просто линейный массив ядер. Попробуйте попрограммировать на CUDA, вы быстро убедитесь в этом. Во-вторых, сложно взаимодействие CPU и GPU, если речь идёт об аппаратном ускорении, то в данном случае помимо массива ядер присутствует сложная аппаратная прослойка между CPU и ядрами GPU, которая представляет специфичную для графики информацию, например, шейдеры.


Всё зависит от сложности отдельного ядра. Например, Удо Мёллер на плате DE0-Nano (стоимостью около 70$) реализовал 32-битный микропроцессор NS32532 (назвав свою реализацию следующим поколением – NS32632). Ядер сложностью с микроконтроллер сери PIC (без периферии), полагаю, можно разместить до десятка. Другое дело, что все эти ядра будут работать на частотах максимум в несколько десятков мегагерц, что дискредитирует всю затею по ускорению и переводит всё в область хобби.


Между ними нет принципиальной разницы в быстродействии. В перепрограммируемых ПЛИС связи тоже аппаратные, хоть и логические. Однократно программируемых ПЛИС большой сложности не делают.


Если абстрагироваться от тонкостей, то как правило, ПЛИС – это просто русский эквивалент аббревиатуры FPGA.


Микроконтроллерам – да, т.к. микроконтроллеры сами работают на небольших частотах, и если требуется какая-то сложная работа (например, перестановка бит в реальном времени), то микроконтроллер с ней может не справиться, а для ПЛИС это вообще не проблема. Всё зависит от характера задач, которые необходимо решать и от требуемой скорости.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>