Эта привязка делается с помощью записи текущего PC - Program Counter-а. Хардверу не нужно хранить внутри имя файла и строки. Это может вычислить софтвер, которые получает массив троек (текущий такт, program counter, событие), и при этом имеет информацию от компилятора и линкера какому номеру строки соответствует PC.
Да, и что вы называете кастомной реализацией и некастомной? Сейчас все реализации - это код на языке Verilog который превращается в ASIC standard cells. Если вы хотите фиксировать событие типа выталкивания строки кэша, то вам все равно нужно завести сигнал и подсоединить его от места где вырабатывается решение на выталкивание к месту где увеличивается счетчик (новая группа D-триггеров), после чего иметь возможность значение с этого счетчика куда-то отправить (скажем на шину данных при декодировании адреса, на который отображается доступ к этому регистру). Эту логику придется завести с микрокодом или без, тут он никак не поможет. Блок микрокода не может узнать через телепатию, что кэш решил вытолкнуть строку. Микрокод - это просто способ хранения изменяемых конечных автоматов в памяти.
Я делал кастомную реализацию performance counters для GPU. Количество транзисторов для того, чтобы завести новый счетчик и логику, привязывающую событие к этому счетчику разумеется меньше, чем счетчик + эта же логика в микрокоде. Вообще вы пробовали сами реализовать какой-нибудь игрушечный процессор с микрокодом и без него? Возьмите к примеры schoolRISCV (такой образовательный процессор на 240 строк верилога), перепишите его сначала в многотактовый, а потом в процессор с микрокодом, а потом в конвейерный, и сравните все четыре реализации. Вопрос с микрокодом сам отпадет.
А из чего, по вашему, состоит "интерпретатор микрокода"? В основном из куска памяти, к которой еще и нужна логика, чтобы ее загружать.Он что, бесплатный? Если заменить каждый конечный автомат в типичном современном ASIC на microcoded конечный автомат с встроенным SRAM и интерфейсом для загрузки его снаружи, то это приведет к сильному увеличению размера чипа и увеличению энергопотребления - так просто не делается кроме особых случаев. А большинство дизайнов еще и конвейерные, где micrcoded state machine вообще не вписывается.
Сгенерировать прерывание по переполнению счётчика - это так банально, что я даже не буду это спрашивать у студента на интервью. Для записи информации в буфер тоже микрокода не нужно - достаточно конечного автомата, который это делает. В роутерных чипах даже связные списки в памяти обрабатывают без микрокода. Без всякого микрокода можно даже текст парсировать чистым хардвером - я написал пост об этом "Как делать парсинг текста голым хардвером, без процессора и без софтвера" https://habr.com/ru/articles/278681/
А может вы просто путаете логику с комбинационной логикой? То есть предполагаете, что весь хардверный дизайн сводится к и/или/не, а любые сложные или повторяющиеся действия требуют микрокода?
Если так, то спешу пояснить: помимо комбинационной логики есть ещё последовательностная логика, то есть кроме и/или/не есть ещё и элементы состояния - d-триггеры. Как только мы вводим элементы состояния, то можно строить (безо всякого микрокода), конечные автоматы, конвейеры и очереди, с помощью которых можно вычислять сложные формулы, писать в память какая была латентность итд.
Я с ARM PMU не работал, но из общих соображений и по его описанию - зачем там нужен микрокод? Для измерения производительности в ядрах и чипах, с которыми я работал, просто заводится куча счётчиков, которые увеличиваются при определенных событиях (скажем сбрасывании строки кэша в память). Доступ к этим счётчикам можно сделать через memory-mapped регистры или отладочный интерфейс. Ведь чистая логика - это не только прямолинейные A and B or C, но с логикой без лишнего уровня микрокода можно строить конечные автоматы, итеративно обрабатывать таблицы в памяти, привязывающие строки исходного кода к событиям через program counter итд.
Микрокод - это конкретный очень специальный способ построения последовательных конечных автоматов. Он удобен, когда выбор следующего действия (активации контрольных сигналов) делается на основе небольшого количества сигналов, а цепочка действия напротив длинная. Например одна команда, как у VAX-11 в 1970-е, делает несколько обращений к памяти, аутоинкременты итд, а то и целую формулу считает. Их тогда реализовывали микрокодом.
Но когда процессор конвейерный, комбинации сигналов из разных стадий конвейера неудобно учитывать микрокодом, потому что будет слишком много случаев и микрокода будет много. Так как микрокод хранится в памяти, то придется заводить большие статические памяти, появится проблема с ее латентностью, размерами, энергопотреблением.
Во современных процессорных ядрах (от ARM, RISC-V) как правило микрокода вообще нет. Все решения принимаются комбинационной логикой без всяких обращений к памяти микрокода. Эта логика синтезируется из кода на языке описания аппаратуры Verilog или VHDL, и это описание микрокодом не является.
(Вообще с термином микрокод часто бывает путаница - есть даже люди которые путают его с инструкциями которые выполняет процессор)
В процессорах с легасу микрокод где-то есть если нужно чего-то остановить и долго последовательно делать цепочку действий (с таким не работал).
То что у интела называется c середины 1990-х "микроинструкции" - это не микрокод, это просто превращение CISC-инструкций в RISC-подобные, которые удобнее обрабатывать динамическим конвейером.
"сейчас" - это когда? В 1970-х годах, когда были популярны процессоры на основе микрокода? Так как их трудно конвейеризировать, то процессоры в 1980-х стали hardwired, с микрофоном для редко используемых инструкций. Или вы путаете микрокод с превращением CISC инструкций в RISC-образные микроинструкции в PentiumPro 1996 года? И когда вы говорите про компиляцию, вы имеете в виду именно компилятор типа GCC или LLVM - или бинарную компиляцию в процессорах типа Trasmets в 2000 году?
А вы часом не путаете латентность, latency, количество тактов - и задержки внутри такта, связанные с propagation delay - пикосекундными задержками на комбинационной логике? А также архитектуру (системы команд) и микроархитектуру (устройство конвейера)?
Он не может быть с нуля, посколько вся линейка лонгсунов делалась уже 25 лет, это была сложная история, причем ещё до 2010 года они купили у MIPS Technologies архитектурную лицензию на MIPS64 (то есть были совместимы по системе команд с MIPS, хотя и сделали собственную микроархитектуру, структуру конвейера). Так как я в то время работал в MIPS Technologies в Sunnyvale, California, я лично знаю VP Sales который летал в КНР и продал им лицензию. Конечно они потом добавили кучу дополнительных инструкций, но это все равно не с нуля.
Аутсорсинг не может быть использован для критичных для компании проектов. Например Apple не будет аутсорсить проектирование ядра MacOS или системы на кристалле Айфона аутсорсерам. То есть все рассуждения поста - это про вещи некритичные, которые если сделают на отцепись, то компанию не повалят, особенно если это все сдублировано и в случае чего можно взять другого аусорсера.
We are thinking about remote hackathons and making the events in multiple cities. If you send me your email via private message, I can add you to the mailing list for future events.
Вы читаете только комментарии и не читаете посты? Я привел видео, где Габриэле это объясняет. Сам я в этом не разбираюсь и просто передаю его рассуждения:
Не, это чисто для вау-фактора, чтобы развлечь студентов. По этой же причине среди примеров, которые мы сделали с соратниками, есть распознавание мелодий с микрофона (без dsp, чисто определитель частоты + конечный автомат) и графика на vga. Просто без таких примеров, если чисто показывать FIFO и разбирать прохождение инструкций по стадиям конвейера в симуляторе - многие студенты начинают скучать и бросают это дело. А если ориентироваться на физматовских школьников - то и подавно.
Предложите последовательность лаб на верилоге для обучения от начального уровня до специалиста. Допустим лаба номер 1 - две кнопочки и LED, а лаба номер 100 - это многоядерный гетерогенный процессорный кластер с кэш-когерентностью и интеграцией CPU и GPU. Что между ними?
Типа:
Лаба 1 . led = button1 XOR button2 .... Лаба 10. Интерфейс I2C для датчика температуры .... Лаба 20. Однотактовое процессорное ядро Лаба 21. Процессорное ядро с тремя стадиями конвейера .... Лаба 30. Очередь FIFO .... Лаба 100 - Многоядерный гетерогенный процессорный кластер с кэш-когерентностью и интеграцией CPU и GPU
То есть вы предлагаете будущих проектировщиков скажем чипов для сматрфонов обучать не лабами на верилоге на FPGA, а лабами с FSM RPI PIco? И если у вас не 8 счетчиков гейгера, а 9 - тоже получится c точностью тактового сигнала?
Chisel используется в Berkeley и в SiFive. Остальная индустрия его не приняла.
То есть лучше фокусироваться на изучении микроархитектура, а не Chisel-а)
Эта привязка делается с помощью записи текущего PC - Program Counter-а. Хардверу не нужно хранить внутри имя файла и строки. Это может вычислить софтвер, которые получает массив троек (текущий такт, program counter, событие), и при этом имеет информацию от компилятора и линкера какому номеру строки соответствует PC.
Да, и что вы называете кастомной реализацией и некастомной? Сейчас все реализации - это код на языке Verilog который превращается в ASIC standard cells. Если вы хотите фиксировать событие типа выталкивания строки кэша, то вам все равно нужно завести сигнал и подсоединить его от места где вырабатывается решение на выталкивание к месту где увеличивается счетчик (новая группа D-триггеров), после чего иметь возможность значение с этого счетчика куда-то отправить (скажем на шину данных при декодировании адреса, на который отображается доступ к этому регистру). Эту логику придется завести с микрокодом или без, тут он никак не поможет. Блок микрокода не может узнать через телепатию, что кэш решил вытолкнуть строку. Микрокод - это просто способ хранения изменяемых конечных автоматов в памяти.
Я делал кастомную реализацию performance counters для GPU. Количество транзисторов для того, чтобы завести новый счетчик и логику, привязывающую событие к этому счетчику разумеется меньше, чем счетчик + эта же логика в микрокоде. Вообще вы пробовали сами реализовать какой-нибудь игрушечный процессор с микрокодом и без него? Возьмите к примеры schoolRISCV (такой образовательный процессор на 240 строк верилога), перепишите его сначала в многотактовый, а потом в процессор с микрокодом, а потом в конвейерный, и сравните все четыре реализации. Вопрос с микрокодом сам отпадет.
А из чего, по вашему, состоит "интерпретатор микрокода"? В основном из куска памяти, к которой еще и нужна логика, чтобы ее загружать.Он что, бесплатный? Если заменить каждый конечный автомат в типичном современном ASIC на microcoded конечный автомат с встроенным SRAM и интерфейсом для загрузки его снаружи, то это приведет к сильному увеличению размера чипа и увеличению энергопотребления - так просто не делается кроме особых случаев. А большинство дизайнов еще и конвейерные, где micrcoded state machine вообще не вписывается.
Сгенерировать прерывание по переполнению счётчика - это так банально, что я даже не буду это спрашивать у студента на интервью. Для записи информации в буфер тоже микрокода не нужно - достаточно конечного автомата, который это делает. В роутерных чипах даже связные списки в памяти обрабатывают без микрокода. Без всякого микрокода можно даже текст парсировать чистым хардвером - я написал пост об этом "Как делать парсинг текста голым хардвером, без процессора и без софтвера" https://habr.com/ru/articles/278681/
А может вы просто путаете логику с комбинационной логикой? То есть предполагаете, что весь хардверный дизайн сводится к и/или/не, а любые сложные или повторяющиеся действия требуют микрокода?
Если так, то спешу пояснить: помимо комбинационной логики есть ещё последовательностная логика, то есть кроме и/или/не есть ещё и элементы состояния - d-триггеры. Как только мы вводим элементы состояния, то можно строить (безо всякого микрокода), конечные автоматы, конвейеры и очереди, с помощью которых можно вычислять сложные формулы, писать в память какая была латентность итд.
Я с ARM PMU не работал, но из общих соображений и по его описанию - зачем там нужен микрокод? Для измерения производительности в ядрах и чипах, с которыми я работал, просто заводится куча счётчиков, которые увеличиваются при определенных событиях (скажем сбрасывании строки кэша в память). Доступ к этим счётчикам можно сделать через memory-mapped регистры или отладочный интерфейс. Ведь чистая логика - это не только прямолинейные A and B or C, но с логикой без лишнего уровня микрокода можно строить конечные автоматы, итеративно обрабатывать таблицы в памяти, привязывающие строки исходного кода к событиям через program counter итд.
Микрокод - это конкретный очень специальный способ построения последовательных конечных автоматов. Он удобен, когда выбор следующего действия (активации контрольных сигналов) делается на основе небольшого количества сигналов, а цепочка действия напротив длинная. Например одна команда, как у VAX-11 в 1970-е, делает несколько обращений к памяти, аутоинкременты итд, а то и целую формулу считает. Их тогда реализовывали микрокодом.
Но когда процессор конвейерный, комбинации сигналов из разных стадий конвейера неудобно учитывать микрокодом, потому что будет слишком много случаев и микрокода будет много. Так как микрокод хранится в памяти, то придется заводить большие статические памяти, появится проблема с ее латентностью, размерами, энергопотреблением.
Во современных процессорных ядрах (от ARM, RISC-V) как правило микрокода вообще нет. Все решения принимаются комбинационной логикой без всяких обращений к памяти микрокода. Эта логика синтезируется из кода на языке описания аппаратуры Verilog или VHDL, и это описание микрокодом не является.
(Вообще с термином микрокод часто бывает путаница - есть даже люди которые путают его с инструкциями которые выполняет процессор)
В процессорах с легасу микрокод где-то есть если нужно чего-то остановить и долго последовательно делать цепочку действий (с таким не работал).
То что у интела называется c середины 1990-х "микроинструкции" - это не микрокод, это просто превращение CISC-инструкций в RISC-подобные, которые удобнее обрабатывать динамическим конвейером.
"сейчас" - это когда? В 1970-х годах, когда были популярны процессоры на основе микрокода? Так как их трудно конвейеризировать, то процессоры в 1980-х стали hardwired, с микрофоном для редко используемых инструкций. Или вы путаете микрокод с превращением CISC инструкций в RISC-образные микроинструкции в PentiumPro 1996 года? И когда вы говорите про компиляцию, вы имеете в виду именно компилятор типа GCC или LLVM - или бинарную компиляцию в процессорах типа Trasmets в 2000 году?
А вы часом не путаете латентность, latency, количество тактов - и задержки внутри такта, связанные с propagation delay - пикосекундными задержками на комбинационной логике? А также архитектуру (системы команд) и микроархитектуру (устройство конвейера)?
Он не может быть с нуля, посколько вся линейка лонгсунов делалась уже 25 лет, это была сложная история, причем ещё до 2010 года они купили у MIPS Technologies архитектурную лицензию на MIPS64 (то есть были совместимы по системе команд с MIPS, хотя и сделали собственную микроархитектуру, структуру конвейера). Так как я в то время работал в MIPS Technologies в Sunnyvale, California, я лично знаю VP Sales который летал в КНР и продал им лицензию. Конечно они потом добавили кучу дополнительных инструкций, но это все равно не с нуля.
А я у Джона Маккарти дома был, чай с ним пил с лимоном в 1993 году. После его лекции по fuzzy logic в Стенфорде.
It is a real woman, a graduate of Moscow State University, cofounder of a startup that designs drones
Аутсорсинг не может быть использован для критичных для компании проектов. Например Apple не будет аутсорсить проектирование ядра MacOS или системы на кристалле Айфона аутсорсерам. То есть все рассуждения поста - это про вещи некритичные, которые если сделают на отцепись, то компанию не повалят, особенно если это все сдублировано и в случае чего можно взять другого аусорсера.
We are thinking about remote hackathons and making the events in multiple cities. If you send me your email via private message, I can add you to the mailing list for future events.
Он в видео показал график. https://www.linkedin.com/in/gabriele-gorla/ - старший директор NVidia, 13 патентов
Вы читаете только комментарии и не читаете посты? Я привел видео, где Габриэле это объясняет. Сам я в этом не разбираюсь и просто передаю его рассуждения:
https://youtu.be/kwIYfLErZtA
Он большой начальник в NVidia по проектированию печатных плат, откуда я заключаю, что он говорит отвественно.
Не, это чисто для вау-фактора, чтобы развлечь студентов. По этой же причине среди примеров, которые мы сделали с соратниками, есть распознавание мелодий с микрофона (без dsp, чисто определитель частоты + конечный автомат) и графика на vga. Просто без таких примеров, если чисто показывать FIFO и разбирать прохождение инструкций по стадиям конвейера в симуляторе - многие студенты начинают скучать и бросают это дело. А если ориентироваться на физматовских школьников - то и подавно.
Предложите последовательность лаб на верилоге для обучения от начального уровня до специалиста. Допустим лаба номер 1 - две кнопочки и LED, а лаба номер 100 - это многоядерный гетерогенный процессорный кластер с кэш-когерентностью и интеграцией CPU и GPU. Что между ними?
Типа:
Лаба 1 . led = button1 XOR button2
....
Лаба 10. Интерфейс I2C для датчика температуры
....
Лаба 20. Однотактовое процессорное ядро
Лаба 21. Процессорное ядро с тремя стадиями конвейера
....
Лаба 30. Очередь FIFO
....
Лаба 100 - Многоядерный гетерогенный процессорный кластер с кэш-когерентностью и интеграцией CPU и GPU
Что должно быть между ними?
То есть вы предлагаете будущих проектировщиков скажем чипов для сматрфонов обучать не лабами на верилоге на FPGA, а лабами с FSM RPI PIco? И если у вас не 8 счетчиков гейгера, а 9 - тоже получится c точностью тактового сигнала?