Lattice бросился вдогонку за альтерой, LatticeMico32 Open, Free 32-Bit Soft Processor Опции

[Stewart Little]

The LatticeMico32 is a 32-bit Harvard, RISC architecture "soft" microprocessor, available for free with an open IP core licensing agreement. Everything you need is provided, including software development tools and an evaluation board to try out your designs in hardware.

http://www.latticesemi.com/products/intell...036;3Fp$3F

В общем, тот же ниос2, только без крыльев.
Три варианта - Basic, Standard, Full
Периферия Whishbone-совместимая.

Среда разработки Micro System Builder - ну очень на SOPC Builder похож!
http://www.latticesemi.com/products/intell...opmenttools.cfm

[Leka]

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

[des00]

Имхо, все упрется в программирование, и ассемблер не выход: упор на быстродействие приведет к "длинной" инструкции, ограничения архитектуры 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

[Leka]

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

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

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

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

[des00]

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

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

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

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

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

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

[Leka]

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

[des00]

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

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

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

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

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


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

[Leka]

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

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

У меня "красиво" не получилось. True dual port у меня реализуется на 2-х RAM16D и дополнительной логике, но тактовая падает вдвое при 8-кратном росте числа LUT --> теряется всякий смысл. На 2-х однопортвках однотактовый true dual port не реализуется, имхо. Можно примеры?

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

У меня проект - многоядерный микроконтроллер, с прицелом на перевод в ASIC, отсюда все требования к ядру. Проверка софт-процессора "на вшивость": чисто программная (т.е. без использования каких-либо аппаратных костылей) реализация цветного текстового контроллера VGA (640*480 @25МГц) - задача управления в чистом виде со строгим таймингом. Для 8 цветов у меня с этим справляются 2 ядра(по 300..400 LUT) @50МГц (starter kit spartan3e).