У меня в одном из проектов (правда без софтпроцессора) наблюдалась подобная ситуация. Очень помог PlanAhead. Рекомендую попробовать...

[quote name='RobFPGA' date='Sep 30 2006, 14:08' post='159691']
[quote name='des00' date='Sep 29 2006, 16:14' post='159478']
[quote name='3.14' post='159475' date='Sep 29 2006, 08:09']
cut

Предлаю всем форумом написать один 16/32 бита риск к нему на эклипсе иде и пользовать его, что бы "патроны блокам подностить" (с) yes с форума сахары

наработки в этой области есть.


[/quote]

Приветствую Всех!

Я тоже готов поучаствовать в процессе создания велосипеда :-). Написать корку вобщем то не проблема. Главное обеспечит ее соответствующими КАЧЕСТВЕННЫМИ инструментами (легко адаптируемыми к конкретной архитектуре)- как минимум - компилятор С симулятор/эмулятор. Именно это (по мойму) и есть главная проблема в softprocessor строительстве. Я в течении месяца провел маленькое исследование в этой части и результаты не очень радостные - из возможных претендентов на компилятор ( если не разрабатывать с нуля) - LCC, SDCC, и GCC. LCC -прост в модификации под конкретный процессор но почти отсуствует оптимизация.
GCC - имеет хорошую оптимизацию но требует большой объем работы при модификации, SDCC - занимает промежуточное положение. Привязка же под конкретный софт/архитектуру процессора неизбежно влечет избыточность на аппаратном уровне но позволяет не ломать голову на софтварном.

Удачи! Rob.
[/quote]

Участвовать можно даже в озеленении Луны. Но перед началом проекта нелохо задаться парой-тройкой вопроов о том что же собственно делаем:

1. Это обычный проц или DSP?
2. Заточен в основном для FPGA или ASIC?
3. Какие изюминки архитектуры(регистровые окна например)?

ну и так далее, список может быть довольно длинный.

Так вот на мой непросвещенный взгляд ответы будущих пользователей этого чуда могут оказаться весьма противоречивыми.

К стати один из самых больных вопросов это действительно всякие компиляторы ибо чем сложнее и извращенней ахитектура проца тем больше надо возиться со всякими гнусными оптимизаторами и т.д.

2 klop и RobFPGA

Если вам интересно мое ИМХО, то я считаю что разрабатывать :



не имеет никакого смысла, т.к. в этом случае мы лишаемся основной фичи ФПГА- множественного параллелизма. Даже мульти векторность АЛУ не спасет, т.к. это только приведет к усложнению проца -> падению тактовой частоты и/или увеличению задержек.

Есть много обычных процев как заточенных под фпга (ниос, микроблейз, мико32) так не сильно заточеных под фпга, есть даже синтезируемые модели дсп процессоров. И под них есть и компиляторы, симуляторы, дебагеры. Но все это нето.

самое то разработать процессор,

1. с поддержкой сложных переходов (как в КА), особенно что касается обработки входных пинов.
2. расширеными возможностями интерконнекта с другими объектами (быстрые порты ввода/вывода, аппаратная поддержка шинных интерфейсов (механизма handshake), отмапливание внешних, относительно проца регистров на регистровый файл и т.д.)
3. с простым АЛУ общего назначения средней производительности (всякие адреса считать и т.д.)
4. и возможность добавить АЛУ специального назначения, на несколько комманд.

наворотов для математики в этом проце не нужно, т.к. вокруг "море" логики, на которой можно считать, но которой нужно управлять.

и утоптать все это в 200-300 плиток, и хотя бы 266-300 МГц виртекса5/4 и стратикса2

Ну а программу для такого управляющего проца, можно и на асме написать. Писали же под атмеги85хх 8 к кода на асме . Да и при граммотном разбиении задачи на блоки, больше чем 2к памяти программ потребуется очень редко.


ЗЫ. можно пойдти еще дальше, если есь подобный проц, то взяв несколько этих процев, сваять из них вычислительную цепочку, когда каждый проц пишет и читает в регистровый файл соседа, организованный как double-buffer регистровый файл.
и не будет проблем синхронизации вычислительных блоков, между собой.

Ну то есть енто проц специально для FPGA. Вот и ответ на один из вопросов!

1. NiosII Fast - шестистадийный конвейер, однотактовый перемножитель/сдвигатель (при использовании встроенных перемножителей или DSP-блоков FPGA), динамическое предсказание переходов, конфигурируемые кэши инструкций и данных. И 256 инструкций пользователя (типа создай свою систему комманд ).
2. Какой именно корки? Их в проекте несколько...


Синтезировать квартусом.
Если использовать внешний синтезатор, то NiosII можно вставить как blackbox.
А если есть желание открытый ниосовский hdl-код синтезировать (к примеру, под FPGA других фирм), то нужно врукопашную в исходнике комментарии править (там какая-то квартусовская фича используется - типа рассматривать комментарии как часть исходного текста) - уважаемый vetal про это может подробнее рассказать.

Есть два типа "любителей" софт процессоров:
первые идут "от хард микроконтроллеров" - им плевать на эффективность разработки. Дайте им AVR внутри FPGA и все! Хотим!!! Поэтому фирмы предлагают ядра "похожие" на хард микроконтроллеры. И программировать хотим только на Си. Поскольку код малоэффективный, то его будет много...

вторые, а к таковым я отношу себя и des00, мы идем от железа. Мы готовы сделать набор микроконтроллеров "под заказ", при этом само проектирование будет гораздо сложнее (хотя при известном опыте дело идет довольно быстро) и программировать придется на ассемблере, но в целом такой подход дает более производительный проект, выше тактовые частоты, более легкую аппаратную отладку. А отладка облегчается, тк на специализированном процессоре легче программировать тесты, команд надо довольно мало. Вот в моем предыдущем проекте я сделал связку из 17-ти битового процессора и 1-но битового. В 17-ти битовом было 1КСлов кода (32 чтения 12-ти битного АЦП с накоплением результата). Это примерно в 3-4 раза более эффективно (т.е меньше по объему команд), чем для стандартного. А выделение обработки блокировок для управления примерно 50 шт. реле в отдельный микроконтроллер увеличило эффективность примерно еще на порядок (но это моя субъективная оценка...)

Так что вот два пути...
Ну и соответственно две методики выбора микроконтроллеров.

Имхо, все упрется в программирование, и ассемблер не выход: упор на быстродействие приведет к "длинной" инструкции, ограничения архитектуры FPGA - к вынужденной неортогональности --> проблемы программирования.

хмм, опять же зависит от того, с какой стороны посмотреть.
если под длинной инструкцией вы понимаете програмное слово со слабым кодированием, то это не есть проблема. К тому же 64 бита ширины програмного слова не проблема на фпга.
Не стоит делать у такого проца большое кол-во команд и режимов адресаций, а достаточно заточить его под задачу, помня о назначении проца. Т.е. после написания кода, помочь синтезатору и "поотключать" все неиспользуемые команды. Синтезатор достаточно хорошо минимизирует логику.

Если вы хотите много считать, то сделайте отдельный блок математики и включите его в декодер комманд процессора и/или отмапте на регистровый файл и пару пинов ввода/вывода.

PS. Не обязательно процессор делать однотактным и без конвейера.
PPS. кстати по такому пути пошли Field Programmable Object Array (FPOA) и Ambric и т.д.

PPPS. Декодер потока команд управления, своего StateSeq я как раз и "вырвал" из своего программируемого проца, версии2 (версия2, заимствует идеи интерконекта как раз из FPOA). Посмотрите на StateSeq и вы поймете что я имею в виду, под заточкой под задачу .
http://electronix.ru/forum/index.php?showt...19202&st=15

Первые идут от того что писать серьезные задачи для одного uC нескольким людям реально при наличии OS, C компилера ну и т.д. Иначе ничего путного не получишь. Никто не говорит что второй путь плох. Просто скорее всего для получения результата надо их комбинировать.

Под длинной инструкцией понимаю несколько операций в одном программном слове. Например: переход + арифметика + пересылка. Свой софт-процессор написал (однотактный, конвейер - 2 стадии). Столкнулся с тем, что неортогональность при длинной инструкции превращает написание программы(на ассемблере) в пытку.

Сообщение отредактировал Leka - Oct 2 2006, 15:10

понятно, спасибо за разьяснение.

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

Именно поэтому и обеими руками за упрощение проца + его конфигурируемость. Основное назначение проца - управление и медленная (многотактная математика). Если нужно что то считать быстро - например ДКТ, то пишем корку и мапим регистры дкт на регистры такого проца. На этом его задача заканчиваеться. Нужна выше производительность ? поставим еще проц и будет конвейер.
нужно порулить ДМА и 10 аппаратными блоками по AMBA вообще не имплементим математику, только адреса считать.

Имхо. Одна из главных проблем софт-процессора: "правильный" многопортовый регистровый файл с асинхронным чтением. Блочная память не допускает асинхронное чтение, распределенная - многопортовую запись. Обход этого ограничения выливается либо в неортогональность системы команд, либо к дополнительным тактам/ступеням/логике(+задержке).

LatticeMico32


http://www.latticesemi.com/dynamic/index.c...=01-01-08-11-48

tam verilog RTL, eclipse based SoC design env, + GCC C compiler (s ishodnikami)

bus sistema Wishbone

RTL mozhno i v xilinx ispolsovat, tut malenki project - rabotaet ok v Virtex-4,proveril

http://www.microfpga.com/joomla/index.php?...leinfo&id=2

mozhno s ISE ISIM simulatorom tozhe simulirovat!

Antti

ja pro LatticeMico32 v drugom forume pisal, nado bylo zdesh ransche posmotret
LM32 6 stupeni konveier

no v standard variante BLOCK RAMs no wishbone sidit i po etomy OCHEN medlenno

sw r0,r0,0x100
bi -1

tokoi loop 28 cyclov berit v BLOCK RAMe !!

dolzno byt mozhno BRAM na CPU direct postavit no GUI eto poka ne poderzivaet

ja dlja ISE maleknki test TOP delal s LatticeMico32, rabotaet!
project sources mozhno kachat tut

http://www.microfpga.com/joomla/index.php?...leinfo&id=2

voobche to interesno!
compiler GCC, istochniki tozhe segodnja na Lattice web postavili

Antti

vetal

вы правы, но даже такая задача решаеться достаточно просто.
1. Честный двухпортовый регистровый файл у ксайлов делаеться на 2-х RAM16D. При этом мы можем читать 4 числа и писать 2 числа. Если не нужен доступ одновременно к 4 м числам, то все еще проще. Нужно использовать 2 однопортовки. Но при таком подходе возникает не возможность отмапливания регистров на внешние устройства.

2. Если требуеться небольшое кол-во регистров, то все просто, можно использовать набор обычных регистров. В этом случае упрощаеться реализация управления внешними устройствами + можно делать распределенную, многобайтную арфиметику.

Можно также сделать составной регистровый файл. часть на памяти, часть на регистрах.

я в програмировании не очень силен, т.к. писал на асме в основном только под х86, AVR, 51, но не могу понять зачем вы хотите именно ортогональную систему комманд, в процессоре специализированного (фпга) применения. Т.е. проц для фпга ИМХО - прежде всего не универсальное решение на все случаи жизни, а уменьшение времени разработки и отладки.


Всем:
Думаю достаточно клаву греть
Если кто-то хочет поучаствовать в разработе подобного проца, то давайте каждый подготовит описание типовых задач, которые он решал/решает в текущее время и выдвинет свои требования к процу. Затем, за несколько on-line встреч (можно в irc), можно обсудить идеи и выработать концепцию проца и стратегии разработки.
А дальше остаеться только определиться с назначением работ по разработке и реализовать, как сам проц, так и софт для разработки на нем.