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

[des00]

2 klop и RobFPGA

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

1. обычный проц или DSP?

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

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

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

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

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

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

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


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

[iosifk]

2 klop и RobFPGA

что разрабатывать обычный проц :

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


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

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

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

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