Хотелось бы узнать где вообще актуально применение встраиваемых процессорных ядер ПЛИС? Не пойму зачем сначала прошивать в ПЛИС процессорное ядро, а потом еще и писать программу для этого экзотического процессора? Двойная работа получается... Если все равно без программатора не перезальешь на ПЛИС новую программу для микропроцессорного ядра.
Наверное, я что-то не так понимаю, но мне казалось, что ПЛИС тем и ценны, что можно сделать оптимизированное решение, которое будет работать быстрее универсального.
И еще вопросик.
Для освоения работы с процессорными ядрами ПЛИС можно обойтись без отладочных плат? Можно ли запускать моделирование системы программно в каком-нибудь симуляторе?
ktb писал(а):Хотелось бы узнать где вообще актуально применение встраиваемых процессорных ядер ПЛИС? Не пойму зачем сначала прошивать в ПЛИС процессорное ядро, а потом еще и писать программу для этого экзотического процессора? Двойная работа получается... Если все равно без программатора не перезальешь на ПЛИС новую программу для микропроцессорного ядра.
Наверное, я что-то не так понимаю, но мне казалось, что ПЛИС тем и ценны, что можно сделать оптимизированное решение, которое будет работать быстрее универсального.
И еще вопросик.
Для освоения работы с процессорными ядрами ПЛИС можно обойтись без отладочных плат? Можно ли запускать моделирование системы программно в каком-нибудь симуляторе?
Программа для микропроцессора не заливается. Ядро синтезируется и упаковывается в плисину как любой другой проект. В результате получаем проц с ногами шины адреса, данных итд. Прелесть в том, что пишем программу на ассемблере, а не на vhdl. Следовательно писать может программер далекий от vdhl. Ассемблер может быть свой собственный. Гибкая система получается.
Симулятор можно использовать. Ему все равно что на vhdl написано.
PicoBlaze даже в кулранер запихивают.
Ядра могут быть "мягкими" (написанными на ВХДЛ/Верилоге и запихиваемые в ПЛИС как обычная схема) и "жёсткими" (намертво реализованными на аппаратном уровне, у Хилинх в Виртех-4 и 5 так реализуются ядра ПоверПЦ). Назначение самым разным может быть. Например, сложный, но не слишком критичный по времени алгоритм обычно проще и удобнее реализовывать программно, в то время как критичные по времени вещи можно реализовать только аппаратно, поэтому может оказаться наиболее выгодным решать задачу программно-аппаратным способом, а не чисто аппаратным. Другой вариант -- использование ПЛИС при проектировании процессора (т.е. в ПЛИС зашивается сам проектируемый процессор, и лишь после его отладки переходят к выпуску "настоящих" процессоров).
Что касается ассемблера, то он свой у каждой архитектуры. Поэтому у ПикоБлазы он один, у МикроБлазы -- другой, и т.д. Тут ничего не поделаешь: если используешь некоторый процессор, то изволь его изучать. Однако, если человек достаточно хорошо разобрался с ассемблером одной архитектуры, все остальные не составят для него никаких проблем. Кроме того, для достаточно мощных процов (для той же МикроБлазы) обычно имеются компиляторы с языков высокого уровня.
В результате получаем проц с ногами шины адреса, данных итд.
Откуда же подаются данные на эти ноги процессора? Они ведь где-то хранятся...
Прелесть в том, что пишем программу на ассемблере, а не на vhdl.
А программируем с помощью чего? Я имею в виду как эту программу залить потом? Еще один программатор нужен?
Ассемблер может быть свой собственный.
Не очень понял фразу. Ассемблер вроде для каждого процессора свой.
Если код ядра открытый, то инструкции можно модифицировать. Можно даже выкинуть некоторые функциональные блоки что не нужны и сэкономить ресурсы.
Если шина команд и адреса торчит наружу, то рассматривай его просто как "обыкновенный" проц. Как например Z80 подключают.
Цитирую "Базовая система команд микропроцессорного ядра PicoBlaze, встраиваемого в проекты, выполняемые на основе ПЛИС семейства CoolRunner-II, включает в себя 49 инструкций [2]. При классификации команд по функциональному признаку они подразделяются на шесть уже известных групп. Изменения произошли только в формате команд. В ряде инструкций поменялась длина полей и коды выполняемых операций. При этом полная длина команд не изменилась и по-прежнему составляет шестнадцать двоичных разрядов. В некоторых командах изменилось взаимное расположение полей. Мнемоническая форма записи инструкций сохранилась без изменений.
При необходимости разработчик может расширить существующую систему команд, дополнив ее собственными инструкциями. Для этого нужно внести соответствующие изменения в файлы исходного описания микропроцессорного ядра picoblaze.vhd и ассемблера asm.cpp."
Если ресурсы позволяют, можно использовать встроенное пзу программ. Код для него можно писать прямо в среде. Поддерживается С и ASM. Заливается как и прошивка. Через тотже Jitag например.
Угу... Значит, вырисовываются две основных причины использовании ядер: быстрое прототипирование процессоров и использование более привычных средств разработки в виде ассемблера, который в данном случае является более "высокоуровневым" по сравнению с HDL.
Если код ядра открытый, то инструкции можно модифицировать.