Кто -нибудь знаком с openmsp430, Это синтезабельное подобие MSP430 Опции

[Yra]

openMSP430 - интересная штучка на мой взгляд. есть даже GCC и порт FreeRtos. Опен соурс проект. Напрягает только это:

// ROM Size
// 9 -> 1kB
// 10 -> 2kB
// 11 -> 4kB
// 12 -> 8kB
// 13 -> 16kB
`define ROM_AWIDTH 10
// RAM Size
// 6 -> 128 B
// 7 -> 256 B
// 8 -> 512 B
// 9 -> 1 kB
// 10 -> 2 kB
`define RAM_AWIDTH 6

Я тут только начал читат про эту штуку - особых проблемм с поднятием не вижу (игрался раньше с picoblaze), но это - огорчает... или всё таки нет в ядре ограничения на размер кода\данных (не игрался ещё с исходниками...).

p.s. не спрашивайте зачем - хочу... умная периферия всегда нужна...

[LordVader]

Ограничение вроде одно - из ОЗУ выполняться не может. А я озу ставил и до 32 кило (с сотвествтуеющей правкой линкер-скрипта, ессно). И даже внешнее на ДЕ1 подключал ОЗУ. В целом, ядро хорошее, относительно мелкое (без дебага - в районе 1600 LE), а вот попытки сэмулировать периферию реальных чипов имхо нафиг не нужны.

Да,и ещё у автора там некий бардак с инклудами (он и сам признаёт). Я эту тему, впрочем, уже тут поднимал...

Сообщение отредактировал LordVader - Nov 8 2009, 20:13

[Yra]

периферия своя. Если чего нет- додумаем. главное чтоб ядро было не кривое. Я давненько искал нечто подобное. Наконец-то появилось ).
На какой тактовой работать может? 50 МГц?

[LordVader]

периферия своя. Если чего нет- додумаем. главное чтоб ядро было не кривое. Я давненько искал нечто подобное. Наконец-то появилось ).
На какой тактовой работать может? 50 МГц?

Ну как и любое не оптимированное под ФПГА ядро, да ещё и цыск (что бы там не писали в ТИ), оно жрёт много, а работает медленно. Чуть-чуть до 40мгц не дотягивало, но это был ква 6.1 (для циклона 2).

PS: Я автору кинул фикс под ДЕ1, он обещал выложить как только, так сразу (у него ребятёнок родился).

Сообщение отредактировал LordVader - Nov 8 2009, 20:59

[Yra]

что -то cтранности какието наблюдаю в работе:
вот фрагмент кода на С:

Код

int main(void) {
volatile short *pA = 0x0206;
volatile short B;
*pA = 0xABCD;
pA = 0;
B = *(volatile short *)(0x206);

*(volatile short *)(0x80) = B;
*(volatile short *)(0x84) = B;
*(volatile short *)(0x86) = B;
*(volatile short *)(0x88) = B;
for(;;);

вот то что компильнул mspgcc:

Код

int main(void) {
    f036:    31 40 fe 02     mov    #766,    r1;#0x02fe

volatile short *pA = 0x0206;
volatile short B;
*pA = 0xABCD;
    f03a:    b2 40 cd ab     mov    #-21555,&0x0206;#0xabcd
    f03e:    06 02

pA = 0;

B = *(volatile short *)(0x206);
    f040:    91 42 06 02     mov    &0x0206,0(r1);0x0000(r1)
    f044:    00 00

*(volatile short *)(0x80) = B;
    f046:    a2 41 80 00     mov    @r1,    &0x0080    
*(volatile short *)(0x84) = B;
    f04a:    a2 41 84 00     mov    @r1,    &0x0084    
*(volatile short *)(0x86) = B;
    f04e:    a2 41 86 00     mov    @r1,    &0x0086    
*(volatile short *)(0x88) = B;
    f052:    a2 41 88 00     mov    @r1,    &0x0088    

for(;;);
    f056:    ff 3f           jmp    $+0;abs 0xf056

}

В область периферии копируется по адресу 0x0080 чиселка 0xABCD - это всё нормально.
В область периферии копируется по адресу 0x0084 чиселка 0x0300 - это НЕ ПРАВИЛЬНО !!!.
В область периферии копируется по адресу 0x0086 чиселка 0xABCD - это всё нормально.
В область периферии копируется по адресу 0x0088 чиселка 0x0300 - это НЕ ПРАВИЛЬНО !!!.

Ничего не понятно (: баг в ядре чтоль? Симулятор M*o*d S*E*6*1
Для чистоты эксперимента периферию заменил регистром

Код

always @(posedge CLK)
  if(per_en && per_wen)
    PER_REG <= #1 per_din;

Огорчает в ядре то, что хотя оно и 16-тиразрядное - Програм Коунтер (PC) ТОЖЕ ШЕСТНАДЦАТИРАЗРЯДНЫЙ. т.е. без изврата со страницами памяти можно адресовать 64 КСлов. Архитектура ФонНеймана - тоесть из 64К надо вычесть размер памяти данных и размер страницы периферии (. В общем получается памяти меньше чем у AVR

Прикрепленные файлы

 ise_9_1_probe1.zip ( 471.72 килобайт ) Кол-во скачиваний: 25
 mspgcc_cygwin_probe1.zip ( 18.15 килобайт ) Кол-во скачиваний: 28

 

[Ynicky]

что -то cтранности какието наблюдаю в работе:

А Вы правильно подключили ROM и RAM?
По описанию ram_cen, rom_cen, ram_wen активны нулем.
Может быть дело в этом?
Но может и не только в этом.

Николай.

PS. Подключил как надо ROM и RAM - все заработало.

Сообщение отредактировал Ynicky - Nov 15 2009, 13:40

[Yra]

А Вы правильно подключили ROM и RAM?
По описанию ram_cen, rom_cen, ram_wen активны нулем.
Может быть дело в этом?
Но может и не только в этом.
Код программы в "leds.mem" не соответствует вашему.

Это у меня учтено. Программа работает и доходит до того места без проблемм. Как видно из кода - сначала осуществляется разного рода адресация в RAM с целью записать и считать ячейку. Считанную ячейку я пытаюсь поместить в область периферии несколько раз подряд - помещается через раз почемуто. Файл leds.mem один и тотже (я перепроверил содержимое архивов на всякий случай.) Сам этот файл копировал из одной папочки в другую.
Пристёгиваю к проекту мою временную диаграмму и чуть подкорректированные два проектных файла (чтобы получить эту диаграмму). Диаграмм вместе с gtkwave в архиве

....не получается загрузить архив в 5 МБайт (
....залил на местный фтп в /upload/FPGA/GTKwave/winXP/

Прикрепленные файлы

 top_level_tb.v ( 539 байт ) Кол-во скачиваний: 42
 top_level.v ( 1.88 килобайт ) Кол-во скачиваний: 57
 leds.vcd.gz ( 2.78 килобайт ) Кол-во скачиваний: 23

 

[Ynicky]

В top_level.v подключите ram следующим образом:

.WE_I(~nWE_MSP_RAM),
.STB_I(~nSTB_MSP_RAM)//,

Николай.

[zltigo]

не спрашивайте зачем - хочу...

И тем не менее....А смысл? MSP430 практически ценен уникальным сочетанием периферии и ядра дружно заточенных под энергосбережение. Само по себе нечто исполняющее код MSP430 достаточно бессмысленно к применению.

[Ynicky]

И тем не менее....А смысл? MSP430 практически ценен уникальным сочетанием периферии и ядра дружно заточенных под энергосбережение. Само по себе нечто исполняющее код MSP430 достаточно бессмысленно к применению.

+1

[Yra]

И тем не менее....А смысл? MSP430 практически ценен уникальным сочетанием периферии и ядра дружно заточенных под энергосбережение. Само по себе нечто исполняющее код MSP430 достаточно бессмысленно к применению.

Мне нужно разгрузить основную систему от рутины. Основная система - Linux - её нельзя дёргать по каждой ерунде. Время латентности высокое. Умонй периферии в данном случае недостаточно (типа ком-порт, заточенный под приёмы/передачу пакетов). Выход - или создавать стэйты или ставить ещё процессор для обработки рутины или освоить синтезированное ядро. Каждый из 3-х методов имеет достоинства и недостатки. Третий метод мне никак не даётся - я уже несколько раз поднимал этот вопрос на форумах: искал относительно небольшое ядро с открытым исходным кодом на RTL-уровне с с-компилятором. picobase(и клон типа pacoblase) - слишком убогое, microblase в чистом виде - не RTL (его клоны на опенкорках - сырые) и много ресурса плис скушает. MSP430 - как вариант устраивает. Появилось там относительно недавно. Захотел попробовать. Есть ещё вариант обратиться в сторону 51w от ментора, но оно больше ресурса вроде скушает чем это.

[zltigo]

51...

51? Больше? Тут я, конечно, не специалист, но 51 вроде чистая и простая классика при оптимальной функциональности. Куча реализаций за прошедшие десятиления. А как дела Cortex-M0 на Xilinx? http://www.arm.com/products/CPUs/ARM-Cortex-M0.html Сейчас это сейчас, полагаю, для IP ядер самый писк моды.

[Yra]

51? Больше? Тут я, конечно, не специалист, но 51 вроде чистая и простая классика при оптимальной функциональности. Куча реализаций за прошедшие десятиления. А как дела Cortex-M0 на Xilinx? http://www.arm.com/products/CPUs/ARM-Cortex-M0.html Сейчас это сейчас, полагаю, для IP ядер самый писк моды.

посмотрите на это:
/pub/FPGA/_IPcores_/Mentor.Decrypted/m*8*0*5*1*e*w*.tar.gz
по моему совсем не проще (минимум 12 тактов на инструкцию не устраивает)
Cortex-M0 - не смотрел ещё. Xilinx славится тем, что корки его выглядят вот так:

LUT4 mux3_lut
(.I0(bit_select[0]),
.I1(data_in[4]),
.I2(data_in[5]),
.I3(Tx_run),
.O(data_45) )/* synthesis xc_props = "INIT=E4FF"*/;
// synthesis translate_off
defparam mux3_lut.INIT = 16'hE4FF;
// synthesis translate_on

LUT4 mux4_lut
(.I0(bit_select[0]),
.I1(data_in[6]),
.I2(data_in[7]),
.I3(Tx_run),
.O(data_67) )/* synthesis xc_props = "INIT=E4FF"*/;
// synthesis translate_off
defparam mux4_lut.INIT = 16'hE4FF;
// synthesis translate_on

MUXF5 mux5_muxf5
( .I1(data_23),
.I0(data_01),
.S(bit_select[1]),
.O(data_0123) );

- не RTL (уровень вентилей)

[Leka]

главное чтоб ядро было не кривое

А конкретнее(идеального быть не может в принципе)?

[Yra]

А конкретнее(идеального быть не может в принципе)?

без багов, полностью синхронное.

кстати, запахало. Не доглядел между строк: регистр инструкций в модуле
uut/openMSP430_1/frontend_0/ir на самом деле никакой не регистр, а

Код

// Instruction register
wire [15:0] ir  = mdb_in;

где mdb_in - выведено на внешнюю шину. Таким образом, надо ожидать от ПЗУ поведения:

Код

always @(posedge CLK_I)
  if(STB_I)        
    DAT_O  <= #1 ram[ADR_I];

- типа синхронное ПЗУ с буферизацией, чтобы содержимое регистра инструкций не менялось во время выполнения инструкции.

это вроде работает...

[des00]

без багов, полностью синхронное.

если вам без разницы ядро почему бы не взять xsoc16 http://www.fpgacpu.org/ проект давно вылизан, есть си компилятор. При этом проц затачивался под фпга

[Yra]

если вам без разницы ядро почему бы не взять xsoc16 http://www.fpgacpu.org/ проект давно вылизан, есть си компилятор. При этом проц затачивался под фпга

Это вот чтоли? :
If you accept the license terms, you may download xsoc-beta-093.zip. (3.3 MB)
Последняя новость на сайте датирована 2003 годом. Сделан в Xilinx 1.5. Есть Verilog - версия.
В нете запрос на тему xsoc16 практически ничего не дал.
В общем создаётся впечатление умершего проекта. Почему его нет на опенкорках?
Вы пробовали работать с ним? Как впечатления? Какие достоинства и недостатки (архитектуру не нашел ещё, как компилятор? ANSI - c со структурами ?)
А так интересный проект. попробую поковыряться на днях

[Ynicky]

Это вот чтоли? :
If you accept the license terms, you may download xsoc-beta-093.zip. (3.3 MB)
Последняя новость на сайте датирована 2003 годом. Сделан в Xilinx 1.5. Есть Verilog - версия.
В нете запрос на тему xsoc16 практически ничего не дал.
В общем создаётся впечатление умершего проекта. Почему его нет на опенкорках?
Вы пробовали работать с ним? Как впечатления? Какие достоинства и недостатки (архитектуру не нашел ещё, как компилятор? ANSI - c со структурами ?)
А так интересный проект. попробую поковыряться на днях

Вставлю свои пару строк.
С этого процессора начинал обучаться разработке своих процессоров.
Очень оказался полезен в плане изучения архитектуры и системы команд.
Из всех изученных мною 16ти разрядных процессоров - этот оказался самым лучшим.
У него очень простая и в то же время объемная система команд.
И даже остался резерв (можно дополнить своими командами).
С компилятор - LCC. Легко настраивается на нужную архитектуру и систему команд посредством .md(machine description) файла. Добавить новые команды не составляет большого труда.
Ассемблер правда простенький, без компоновщика, но для большинства приложений этого достаточно.
Есть исходники. Добавить свои команды тоже не трудно.
Единственный, на мой взгляд, недостаток - это нет средств внутрисхемной отладки.
Но это можно сделать самому.

Николай.

[des00]

Ynicky уже сказал плюсы этого проекта, немного добавлю

Последняя новость на сайте датирована 2003 годом. Сделан в Xilinx 1.5. Есть Verilog - версия.
В нете запрос на тему xsoc16 практически ничего не дал.
В общем создаётся впечатление умершего проекта. Почему его нет на опенкорках?

если проц отлажен, оптимален (по критерию ресурса фпга), самодостаточен и доведен до логического конца зачем его развивать? Лежит себе рабочая вешь, есть не просит. На опенкоресы не выкладывают потому как не нужно %)

я его реверсил в исследовательских целях, уж больно у него алу красиво уложено %)

[SM]

51? Больше?

Да, реально больше, несмотря на 8-битность. У 51 декодер инструкций такой, что ужос. Плюс умножитель, который практически во всех реализациях параллельный. Плюс всякие там da a, xchd которые создают лишние мультиплексоры и функциональные узлы. В отличие от MSP, который голимый RISC вплоть аж до того, что счетчик команд и указатель стека в РОНах, вследствие чего декодера инструкций, можно сказать, почти нет, все сигналы идут проводами прямо на исполнительные блоки, да и самих команд (классов команд по формату опкода) раз, два и обчелся.


Автору - а чем LatticeMico8 не устраивает? И под фпга заточен, и компилер есть, и исходники...

[LordVader]

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

Я конечно извиняюсь, но какой же мсп430 риск? Он вообще без регистров работать может (ну кроме пц, сп, константных), держа все переменные в памяти. И в пределах 1 команды делать 2 раза чтения и 1 раз запись в память модифицированного значения. Что-то как-то других рисков ТАКИХ я не видел

[SM]

Я конечно извиняюсь, но какой же мсп430 риск? Он вообще без регистров работать может

Я конечно, извиняюсь, но каким образом выражение "Reduced Instruction Set" относится к количеству регистров и/или методов адресации? Это показатель количества инструкций, которых у MSP430 всего лишь 27 штук. Для сравнения - даже у Microchip PIC12 их 33, что больше, чем у MSP (кстати он, pic, тоже "вообще без регистров" работать может, только W и счетчик команд). Не говоря про пресловутый ARM. Но собственно, основной показатель "risc-овости" - сложность декодера инструкций - у MSP "risc-ее", чем у многих-многих других risc-ов.

ЗЫ. А вообще - это дежавю. Уже обобсуждались в оффтопике на эту тему.

[Leka]

Пусть выполнение инструкций: a = b * c, a = b << c, a = b >> c, ...(и тд и тп) организовано через обращение к внешнему устройству N(задается в поле команды): a = port_N(b, c). Сколько инструкций? 1 ? 3+ ?

[LordVader]

Ну можно конечно посчитать кол-во команд, и сказать что риск (ага, меньше чем у пика).
А можно подумать вот как:
каждлая команда в 430 имеет длину от 1 до 3 слов. При этом она может инициировать от 0 до 3 аксессов в память, выполняя вычисления с выбранными и записываемыми данными.
А теперь сравним с настоящими рисками: mips, sparc, power, arm: длина команды фиксированная, операции или внутри регистров, или запись-чтение регистров из памяти без операций над данными.

Сообщение отредактировал LordVader - Nov 17 2009, 20:02

[SM]

При этом она может инициировать от 0 до 3 аксессов в память, выполняя вычисления с выбранными и записываемыми данными. Какой же это, пардон, риск?

Еще раз вопрос. Где в аббревиатуре "Reduced Instruction Set" говорится о количестве доступов в память, о том, сколько действий выполняет инструкция, и т.п. параметрах системы команд? Исключительно о количестве инструкций. Reduced по отношению к CISC. И ничего более. Решит производитель, что вот это у него CISC, а это - RISC. И так и будет. И не путайте LOAD-STORE архитектуру и RISC - это две не пересекающиеся вещи. RISC не обязан быть LOAD-STORE, и наоборот, LOAD-STORE не обязан быть RISC.

Что касается переменной длины инструкций у MSP - это кажущаяся с первого поверхностного взгляда вещь. Обман зрения. На самом деле длина инструкции у него всегда 16 бит, а все эти якобы удлинения - это автоинкрементная адресация с регистром R7 - просто выборка операнда из памяти.

PS. Я продолжать этот бессмысленный спор не буду. Что же касается реальных архитектурных решений и примененных технологий - тут прав лишь разработчик/производитель. Только он один знает, что и зачем применил, и как построил декодер инструкций, как у RISC, из кучи проводов, или как у CISC, из кучи логики и дешифраторов. И только он вправе корректно определять архитектуру своего детища, если ее не открывает в виде схем и/или исходных текстов.

[Yra]

Автору - а чем LatticeMico8 не устраивает? И под фпга заточен, и компилер есть, и исходники...

всего не углядиш... у кажной штуки свои прибамбасы.
http://electronix.ru/forum/lofiversion/index.php/t38902.html

[SM]

всего не углядиш...

Ну уверенности в безглючности других ядер ведь тоже нет. На то оно и в исходниках, что можно поправить.

[SM]

И, заметьте, сейчас версия 3.0, а не 2.4, о которой речь была в той ветке. По крайней мере глюк с переносом точно устранен:

Код

//Carry flag
always@(posedge clk or negedge rst_n)
begin
if (!rst_n)
carry_flag_int <= 0;
else
   if ((clrc ) | (setc ) | (update_c ) | (iret))
            carry_flag_int <= (~(clrc) & ((update_c & cout_alu) | setc | (iret & pushed_carry)));
   else
            carry_flag_int <= carry_flag_int;
end

Думаю, что и с прерываниями все ОК, так как они там тоже много переделали.

[LordVader]

И не путайте LOAD-STORE архитектуру и RISC - это две не пересекающиеся вещи. RISC не обязан быть LOAD-STORE, и наоборот, LOAD-STORE не обязан быть RISC.

Я вправе иметь своё мнение. И моё мнение таково, что RISC я не понимаю как дословную аббревиатуру. И знакомство с некоторым кол-вом процессоров заставляет думать, что риск - это не кол-во команд, а прежде всего их простота. и в том числе load-store. И почему-то так считают некоторые умные люди, которые пишут книги.

Что касается переменной длины инструкций у MSP - это кажущаяся с первого поверхностного взгляда вещь. Обман зрения. На самом деле длина инструкции у него всегда 16 бит, а все эти якобы удлинения - это автоинкрементная адресация с регистром R7 - просто выборка операнда из памяти.

Автоинкрементация она, когда проц не конвееризированный, как 430ый в оригинале или как топиковый. Посмотрите, как извращаются в современных x86-процах на этапе "fetch opcode".

И только он вправе корректно определять архитектуру своего детища, если ее не открывает в виде схем и/или исходных текстов.

Да ради бога. А я вправе определять архитектуру его детища, как мне удобно

[yes]

Еще раз вопрос. Где в аббревиатуре "Reduced Instruction Set" говорится о количестве доступов в память, о том, сколько действий выполняет инструкция, и

не придирайтесь к словам
в этом случае редьюсед подразумевает, что редуцированы операции работающие с операндами из/в памяти

например РРС - общепризнано, что RISC - но инструкций там побольше чем у х86

--------------

чего-то примера хорошего не придумал - но например, в доке на ОМАР-L138 всюду упоминается, что это супер-лоу-павер девайс, а цифирька то - пол ватта

[SM]

не придирайтесь к словам
в этом случае редьюсед подразумевает, что редуцированы операции работающие с операндами из/в памяти
например РРС - общепризнано, что RISC - но инструкций там побольше чем у х86

А я как раз к словам не придираюсь. Я придираюсь к лицам, узко и ограниченно интерпретирующим это понятие. Не важно, что именно и относительно чего редуцировали, главное - что редуцировали, и все. Поэтому и риск. И от того, что отдельно взятый "LordVader" не признает MSP риском, MSP им не перестает быть. И система команд у него - Reduced Instruction Set от PDP-11.

[Yra]

Автору - а чем LatticeMico8 не устраивает? И под фпга заточен, и компилер есть, и исходники...

Откуда бы достать? На сайте зарегаться не могу. Тут лежит где-нибудь. Желательно ссылку и на компилятор и на утилиты.

[SM]

Зачем и где регаться? Все так лежит.

http://www.latticesemi.com/documents/Latti...3_0_Verilog.zip
http://www.latticesemi.com/documents/LatticeMico8_Tools.zip
http://www.latticesemi.com/lit/docs/refdesigns/isp8_demo.zip
http://www.latticesemi.com/lit/docs/refdesigns/rd1026.pdf

[LordVader]

Я придираюсь к лицам,

Переход на личности.

И система команд у него - Reduced Instruction Set от PDP-11.

Это вам тоже TI сказала?

[Leka]

RISC, CISC - не все-ли равно? Например, я не знаю, к какому типу отнести свое собственное ядро. И как считать число инструкций. И меня это не волнует.

Сообщение отредактировал Leka - Nov 18 2009, 19:19

[Omen_13]

Прошу участников воздержаться от религиозных войн и перехода на личности
Модератор

[Yra]

Зачем и где регаться? Все так лежит.
http://www.latticesemi.com/documents/Latti...3_0_Verilog.zip
http://www.latticesemi.com/documents/LatticeMico8_Tools.zip
http://www.latticesemi.com/lit/docs/refdesigns/isp8_demo.zip
http://www.latticesemi.com/lit/docs/refdesigns/rd1026.pdf

Спасибо. Скачал. Ссылочку на с-компилятор (или иде) дадите. Какие рекомендации по применению? Ломать там что-нибудь надо?
Кстати пароль требует если попытаться войти в каталог http://www.latticesemi.com/documents/
На прямые ссылки из этого каталога не ругается

[SM]

Какие рекомендации по применению? Ломать там что-нибудь надо?

Ломать там ничего не надо, оно же в исходниках все. Рекомендаций не дам, я сам ни разу не применял FPGA-ориентированные ядра, лишь анализировал их по занимаемым ресурсам и производительности. А до дела так и не дошло, все мое ПЛИСовое пока что решалось без ядер, я лишь был на грани применения ядра. Вам его присоветовал лишь из-за того, что оно мне показалось наиболее элегантным из доступных, поддерживаемым серьезным производителем и легко портируемым на разные архитектуры ПЛИС.

Про С - на сколько я знаю, сам Lattice поддерживает только Mico32 компилятор (http://www.latticesemi.com/forums/forum/messageview.cfm?catid=164&threadid=10282&enterthread=y), считая такую мелкоту не достойным С. Ну а компилятор ассемблера - по ссылке должен был быть.

[yes]

у самого руки не доходят (нету задачи), но вроде активный проект с С/С++

http://opensource.zylin.com/zpu.htm

[Yra]

у самого руки не доходят (нету задачи), но вроде активный проект с С/С++
http://opensource.zylin.com/zpu.htm

Вроде в симуляторе фунциклит (zpu4_small) - программа вроде работает по шагам... правда недолго... (красное просачивается в RAM непонятно по какой причине...)
Я в VHDL не силён: модель памяти программ/данных в виде:

Код

entity dualport_ram is
port (clk : in std_logic;
    memAWriteEnable : in std_logic;
    memAAddr : in std_logic_vector(maxAddrBitBRAM downto minAddrBit);
    memAWrite : in std_logic_vector(wordSize-1 downto 0);
    memARead : out std_logic_vector(wordSize-1 downto 0);
    memBWriteEnable : in std_logic;
    memBAddr : in std_logic_vector(maxAddrBitBRAM downto minAddrBit);
    memBWrite : in std_logic_vector(wordSize-1 downto 0);
    memBRead : out std_logic_vector(wordSize-1 downto 0));
end dualport_ram;

architecture dualport_ram_arch of dualport_ram is


type ram_type is array(natural range 0 to ((2**(maxAddrBitBRAM+1))/4)-1) of std_logic_vector(wordSize-1 downto 0);

shared variable ram : ram_type :=
(
0 => x"0b0b0b0b",
1 => x"82700b0b",
2 => x"80d5f40c",
3 => x"3a0b0b80",
4 => x"c4fb0400",



    others => x"00000000"
);

begin

process (clk)
begin
    if (clk'event and clk = '1') then
        if (memAWriteEnable = '1') and (memBWriteEnable = '1') and (memAAddr=memBAddr) and (memAWrite/=memBWrite) then
            report "write collision" severity failure;
        end if;
    
        if (memAWriteEnable = '1') then
            ram(to_integer(unsigned(memAAddr))) := memAWrite;
            memARead <= memAWrite;
        else
            memARead <= ram(to_integer(unsigned(memAAddr)));
        end if;
    end if;
end process;

process (clk)
begin
    if (clk'event and clk = '1') then
        if (memBWriteEnable = '1') then
            ram(to_integer(unsigned(memBAddr))) := memBWrite;
            memBRead <= memBWrite;
        else
            memBRead <= ram(to_integer(unsigned(memBAddr)));
        end if;
    end if;
end process;




end dualport_ram_arch;

синтезабельна в плане начального заполнения кодом ячеек памяти? При попытке синтеза пишет что :

Код

Device Utilization Summary:

   Number of BUFGMUXs                        1 out of 8      12%
   Number of External IOBs                  91 out of 141    64%
      Number of LOCed IOBs                   0 out of 91      0%

   Number of RAMB16s                         8 out of 16     50%   - типа всё таки используется блочное ОЗУ для памяти
   Number of Slices                        312 out of 3584    8%
      Number of SLICEMs                      0 out of 1792    0%

НО нигде в отчёте не видно чем он заполнил это блочное ОЗУ:

Код

0 => x"0b0b0b0b",
1 => x"82700b0b",
2 => x"80d5f40c",
3 => x"3a0b0b80",
4 => x"c4fb0400",

- этой информации я не вижу в логах синтезатора.

Тоесть нужно - ли искать/создавать транслятор который заполняет блочное ОЗУ явно?

Код

   RAMB16_S1_S1_inst : RAMB16_S1_S1
   generic map (
      INIT_A => "0", --  Value of output RAM registers on Port A at startup
      INIT_B => "0", --  Value of output RAM registers on Port B at startup
      SRVAL_A => "0", --  Port A ouput value upon SSR assertion
      SRVAL_B => "0", --  Port B ouput value upon SSR assertion
      WRITE_MODE_A => "WRITE_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
      WRITE_MODE_B => "WRITE_FIRST", --  WRITE_FIRST, READ_FIRST or NO_CHANGE
      SIM_COLLISION_CHECK => "ALL", -- "NONE", "WARNING", "GENERATE_X_ONLY", "ALL"
      -- The following INIT_xx declarations specify the initial contents of the RAM
      -- Address 0 to 4095
      INIT_00 => X"1122330000000000000000000000000000000000000000000000000000000000",
      INIT_01 => X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_02 => X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_03 => X"0000000000000000000000000000000000000000000000000000000000000000",
      INIT_04 => X"0000000000....

[Yra]

Кстати, вот наиболее интересные фрагменты кода для ZPU:

Код

если volatile unsigned char *p = (unsigned short *)(0xF000);
и      volatile unsigned char k;

то

00000541 <.LM7>:
k = *p;
541:    91              im 17
542:    d8              im -40
543:    08              load
544:    51              storesp 4
545:    70              loadsp 0
546:    33              loadb
547:    99              im 25
548:    8c              im 12
549:    34              storeb

0000054a <.LM8>:
p++;
54a:    81              im 1
54b:    11              addsp 4
54c:    91              im 17
54d:    d8              im -40
54e:    0c              store

сказывается отсутствие банка регистров... зато мальнькое

[valerony]

если вам без разницы ядро почему бы не взять xsoc16 http://www.fpgacpu.org/ проект давно вылизан, есть си компилятор. При этом проц затачивался под фпга

Здесь на форуме https://www.embeddedrelated.com/showthread/...-cpu/1381-1.php автор пишет что данный проц затачивался под Xilinx семейство XC4000E, и не рекомендует использовать его в альтерах. Пробовал кто-нибудь запускать их в циклонах например?