Автор |
Сообщение |
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
diver писал(а): Ну... Это из области тайной высшей магии, доступной лишь горстке избранных) Да в целом нет. Это топологические ограничения, они обычно делаются в xdc, но так неинтересно, это надо к каждому проекту привязывать. В Verilog можно компактнее все указать, там в комментариях есть шаблон - ставится FD, а к нему рядом пишется "LOC=" и координаты. Вместо того, чтобы воевать с САПР и пытаться заставить его генерировать линейно изменяющиеся координаты, сделано проще - программка на Форте сгенерировала 256строк на Verilog с прямой расстановкой отдельных триггеров.
[quote="diver"]Ну... Это из области тайной высшей магии, доступной лишь горстке избранных)[/quote] Да в целом нет. Это топологические ограничения, они обычно делаются в xdc, но так неинтересно, это надо к каждому проекту привязывать. В Verilog можно компактнее все указать, там в комментариях есть шаблон - ставится FD, а к нему рядом пишется "LOC=" и координаты. Вместо того, чтобы воевать с САПР и пытаться заставить его генерировать линейно изменяющиеся координаты, сделано проще - программка на Форте сгенерировала 256строк на Verilog с прямой расстановкой отдельных триггеров.
|
|
|
|
Добавлено: Чт сен 10, 2020 23:57 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Hishnik писал(а): Total Vacuum писал(а): Не совсем понятно, что в коде происходит. Неужели замена или надстройка над verilog/vhdl? Это генерация кода на Verilog с топологической привязкой регистров стека. Что и видно на скриншоте, где 256 триггеров встали плотным прямоугольником. В Форте там стоит ORIGINX, ORIGINY, которые и задают координаты вот такой, по сути ручной, упаковки компонентов. Авторазмещение обычно работает плохо. Ну... Это из области тайной высшей магии, доступной лишь горстке избранных)
[quote="Hishnik"][quote="Total Vacuum"]Не совсем понятно, что в коде происходит. Неужели замена или надстройка над verilog/vhdl?[/quote] Это генерация кода на Verilog с топологической привязкой регистров стека. Что и видно на скриншоте, где 256 триггеров встали плотным прямоугольником. В Форте там стоит ORIGINX, ORIGINY, которые и задают координаты вот такой, по сути ручной, упаковки компонентов. Авторазмещение обычно работает плохо.[/quote] Ну... Это из области тайной высшей магии, доступной лишь горстке избранных)
|
|
|
|
Добавлено: Чт сен 10, 2020 07:52 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Total Vacuum писал(а): Не совсем понятно, что в коде происходит. Неужели замена или надстройка над verilog/vhdl? Это генерация кода на Verilog с топологической привязкой регистров стека. Что и видно на скриншоте, где 256 триггеров встали плотным прямоугольником. В Форте там стоит ORIGINX, ORIGINY, которые и задают координаты вот такой, по сути ручной, упаковки компонентов. Авторазмещение обычно работает плохо.
[quote="Total Vacuum"]Не совсем понятно, что в коде происходит. Неужели замена или надстройка над verilog/vhdl?[/quote] Это генерация кода на Verilog с топологической привязкой регистров стека. Что и видно на скриншоте, где 256 триггеров встали плотным прямоугольником. В Форте там стоит ORIGINX, ORIGINY, которые и задают координаты вот такой, по сути ручной, упаковки компонентов. Авторазмещение обычно работает плохо.
|
|
|
|
Добавлено: Вт сен 08, 2020 14:12 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Форт... Форт-процессор... Подсознательно чувствую, что какая-то связь есть... Не совсем понятно, что в коде происходит. Неужели замена или надстройка над verilog/vhdl?
Форт... Форт-процессор... Подсознательно чувствую, что какая-то связь есть... :))
Не совсем понятно, что в коде происходит. Неужели замена или надстройка над verilog/vhdl?
|
|
|
|
Добавлено: Вт сен 08, 2020 14:02 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Пригодился Форт. И даже очень: Код: " stack_template.vt" NEWFILE TO HF-OUT
// (*LOC="X0Y0"*) FDRE DFF_INSTA (.C(clk), .D(din[0]), .Q(areg[0]), .CE(wea), .R(1'b0));
: PRINTF HF-OUT SWAP COUNT WRITEFILE ;
?TRAILINGSPACE OFF
8 CONSTANT ORIGINX 25 CONSTANT ORIGINY
: GEN 32 0 DO " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTA" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(areg[" PRINTF I .F " ]), .CE(wea), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 1 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTB" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(breg[" PRINTF I .F " ]), .CE(web), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 2 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTC" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(creg[" PRINTF I .F " ]), .CE(wec), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 3 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTD" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(dreg[" PRINTF I .F " ]), .CE(wed), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 4 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTE" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(ereg[" PRINTF I .F " ]), .CE(wee), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 5 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTF" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(freg[" PRINTF I .F " ]), .CE(wef), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 6 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTG" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(greg[" PRINTF I .F " ]), .CE(weg), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 7 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTH" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(hreg[" PRINTF I .F " ]), .CE(weh), .R(1'b0)); " PRINTF CRF
LOOP
;
GEN
HF-OUT CLOSE
Вложения: |
stack_floorplan.png [ 78.48 Кб | Просмотров: 32720 ]
|
Пригодился Форт. И даже очень:
[code]" stack_template.vt" NEWFILE TO HF-OUT
// (*LOC="X0Y0"*) FDRE DFF_INSTA (.C(clk), .D(din[0]), .Q(areg[0]), .CE(wea), .R(1'b0));
: PRINTF HF-OUT SWAP COUNT WRITEFILE ;
?TRAILINGSPACE OFF
8 CONSTANT ORIGINX 25 CONSTANT ORIGINY
: GEN 32 0 DO " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTA" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(areg[" PRINTF I .F " ]), .CE(wea), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 1 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTB" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(breg[" PRINTF I .F " ]), .CE(web), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 2 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTC" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(creg[" PRINTF I .F " ]), .CE(wec), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 3 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTD" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(dreg[" PRINTF I .F " ]), .CE(wed), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 4 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTE" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(ereg[" PRINTF I .F " ]), .CE(wee), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 5 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTF" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(freg[" PRINTF I .F " ]), .CE(wef), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 6 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTG" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(greg[" PRINTF I .F " ]), .CE(weg), .R(1'b0)); " PRINTF CRF " (*LOC=" PRINTF 34 EMITF " SLICE_X" PRINTF ORIGINX 7 + .F " Y" PRINTF I 8 / ORIGINY + .F 34 EMITF " *) FDRE DFF_INSTH" PRINTF I .F " (.C(clk), .D(din[" PRINTF I .F " ]), .Q(hreg[" PRINTF I .F " ]), .CE(weh), .R(1'b0)); " PRINTF CRF
LOOP
;
GEN
HF-OUT CLOSE[/code]
|
|
|
|
Добавлено: Вс сен 06, 2020 17:40 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Да, везде Spartan-7, в одном варианте в паре с WiFi (ARM в МК cc3200), в другом - модуль Bluetooth.
Да, везде Spartan-7, в одном варианте в паре с WiFi (ARM в МК cc3200), в другом - модуль Bluetooth.
|
|
|
|
Добавлено: Вт сен 01, 2020 16:25 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Ох, красота какая. А в BGA-корпусах Xilinx?
Ох, красота какая. А в BGA-корпусах Xilinx?
|
|
|
|
Добавлено: Вт сен 01, 2020 12:32 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Вот и платформа для нового процессора появилась.
Вложения: |
Xilinx_IoT1.jpg [ 353.36 Кб | Просмотров: 33087 ]
|
Вот и платформа для нового процессора появилась.
|
|
|
|
Добавлено: Пт авг 28, 2020 18:23 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Total Vacuum писал(а): Интересная задумка. Только не совсем понимаю, как такой "конвейер" будет работать в условиях, когда программа скачет по коду как ошпаренная (шитый код все-таки)... С таким конвейером можно использовать подход data bypass. Если прочитанная команда является командой перехода, можно оперативно подменить адрес памяти программ на фрагмент этой команды. Тогда цепочки call/jmp будут выполняться без штрафов. Ну и шитого кода там в целом нет, формально это машинный код для соответствующей архитектуры. То есть слова уровня DUP + ! - это не вызовы, а просто команды процессора.
[quote="Total Vacuum"]Интересная задумка. Только не совсем понимаю, как такой "конвейер" будет работать в условиях, когда программа скачет по коду как ошпаренная (шитый код все-таки)... [/quote] С таким конвейером можно использовать подход data bypass. Если прочитанная команда является командой перехода, можно оперативно подменить адрес памяти программ на фрагмент этой команды. Тогда цепочки call/jmp будут выполняться без штрафов.
Ну и шитого кода там в целом нет, формально это машинный код для соответствующей архитектуры. То есть слова уровня DUP + ! - это не вызовы, а просто команды процессора.
|
|
|
|
Добавлено: Пт авг 14, 2020 19:14 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Hishnik писал(а): Успешно проверенный макет основан на двупортовой памяти. Читается два последовательных слова по 32 бита, команда - 8 бит, литерал, соответственно, 32 бита. При любом положении команды, загружающей литерал, за ней есть 32 бита. Если обозначить байты цифрами, то: 1234 5678... Интересная задумка. Только не совсем понимаю, как такой "конвейер" будет работать в условиях, когда программа скачет по коду как ошпаренная (шитый код все-таки)... Тут, кстати, тоже "символизм", т.к. 8 байт за раз читается...
[quote="Hishnik"]Успешно проверенный макет основан на двупортовой памяти. Читается два последовательных слова по 32 бита, команда - 8 бит, литерал, соответственно, 32 бита. При любом положении команды, загружающей литерал, за ней есть 32 бита. Если обозначить байты цифрами, то: 1234 5678...[/quote]Интересная задумка. Только не совсем понимаю, как такой "конвейер" будет работать в условиях, когда программа скачет по коду как ошпаренная (шитый код все-таки)... Тут, кстати, тоже "символизм", т.к. 8 байт за раз читается... :)
|
|
|
|
Добавлено: Пт авг 14, 2020 12:45 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
Victor__v писал(а): То есть литералы только 4 байтные? То ж решение) С точки зрения схемы, раз регистр 4-байтный, то 4 байта в него и должны быть записаны. Хоть расширением нулями, хоть знакорасширением, войти в компонент должны 32 провода. Как это будет в системе команд - можно смотреть. По крайней мере, ширина команды должна быть "2 раза по ширине максимального литерала".
[quote="Victor__v"]То есть литералы только 4 байтные? То ж решение)[/quote] С точки зрения схемы, раз регистр 4-байтный, то 4 байта в него и должны быть записаны. Хоть расширением нулями, хоть знакорасширением, войти в компонент должны 32 провода. Как это будет в системе команд - можно смотреть. По крайней мере, ширина команды должна быть "2 раза по ширине максимального литерала".
|
|
|
|
Добавлено: Ср авг 12, 2020 15:33 |
|
|
|
|
|
Заголовок сообщения: |
Re: Oxygen Forth CPU |
|
|
То есть литералы только 4 байтные? То ж решение)
То есть литералы только 4 байтные? То ж решение)
|
|
|
|
Добавлено: Ср авг 12, 2020 13:41 |
|
|
|
|
|
Заголовок сообщения: |
Oxygen Forth CPU |
|
|
По результатам тестирования концепции проекта можно констатировать, что очередное (8-е) поколение форт-процессора, видимо, движется к воплощению. После некоторых попыток найти ему имя (а практика показывает, что полезно, хотя бы на уровне "как файлы называть") и перебора разных восьмерок с их символизмом, был взят 8-й элемент таблицы Менделеева, то есть кислород (oxygen).
В чем основное архитектурное отличие. Для стекового процессора имеется важный эффект - из-за отсутствия операндов в команде сама команда может быть компактной. Использовались 8 и даже 6 бит, и это позволяет хорошо экономить память, которой в ПЛИС не так много. Однако тут есть и обратная сторона - если все же надо загрузить на стек литерал, в 8 бит он явно не вписывается, поэтому положить на стек константу означает потратить несколько тактов. Какие возможны варианты из напрашивающихся: 1. Десериализатор. На большой частоте команды поступают в буфер, где накапливаются, так что при необходимости узнать значение литерала его можно быстро "обнаружить" в буфере. Явным недостатком является необходимость чтения данных с кратно большей частотой, а это проблема. Например, если за 8-битной командой требуются сразу 32 бита, то частота работы с памятью должна быть в 5 раз выше. 2. Широкое командное слово. Да, тогда можно будет класть литерал за командой. Например, будут упакованные команды (4 раза по 8 бит) и неупакованные литералы. Недостаток - а если нужны не 4 команды, а 1-2-3? Остаток пропадает. Простор для оптимизации, попытки представить недостаток как особенность, апелляция к программистам, которые "ну должны же разобраться и оптимизировать". По факту - спихивание проблем.
Успешно проверенный макет основан на двупортовой памяти. Читается два последовательных слова по 32 бита, команда - 8 бит, литерал, соответственно, 32 бита. При любом положении команды, загружающей литерал, за ней есть 32 бита. Если обозначить байты цифрами, то:
1234 5678 - если команда в байте 1, то литерал - 2345 если команда в байте 2, то литерал - 3456 если команда в байте 3, то литерал - 4567 если команда в байте 4, то литерал - 5678
Если же команда в байте 5... то такого не бывает, потому что после обработки первого слова будет подгружено еще одно, и новым состоянием этой пары станет
5678 90AB
Таким образом, имеется возможность произвольно чередовать команды и литералы, загружая их за 1 такт по мере необходимости.
По результатам тестирования концепции проекта можно констатировать, что очередное (8-е) поколение форт-процессора, видимо, движется к воплощению. После некоторых попыток найти ему имя (а практика показывает, что полезно, хотя бы на уровне "как файлы называть") и перебора разных восьмерок с их символизмом, был взят 8-й элемент таблицы Менделеева, то есть кислород (oxygen).
В чем основное архитектурное отличие. Для стекового процессора имеется важный эффект - из-за отсутствия операндов в команде сама команда может быть компактной. Использовались 8 и даже 6 бит, и это позволяет хорошо экономить память, которой в ПЛИС не так много. Однако тут есть и обратная сторона - если все же надо загрузить на стек литерал, в 8 бит он явно не вписывается, поэтому положить на стек константу означает потратить несколько тактов. Какие возможны варианты из напрашивающихся: 1. Десериализатор. На большой частоте команды поступают в буфер, где накапливаются, так что при необходимости узнать значение литерала его можно быстро "обнаружить" в буфере. Явным недостатком является необходимость чтения данных с кратно большей частотой, а это проблема. Например, если за 8-битной командой требуются сразу 32 бита, то частота работы с памятью должна быть в 5 раз выше. 2. Широкое командное слово. Да, тогда можно будет класть литерал за командой. Например, будут упакованные команды (4 раза по 8 бит) и неупакованные литералы. Недостаток - а если нужны не 4 команды, а 1-2-3? Остаток пропадает. Простор для оптимизации, попытки представить недостаток как особенность, апелляция к программистам, которые "ну должны же разобраться и оптимизировать". По факту - спихивание проблем.
Успешно проверенный макет основан на двупортовой памяти. Читается два последовательных слова по 32 бита, команда - 8 бит, литерал, соответственно, 32 бита. При любом положении команды, загружающей литерал, за ней есть 32 бита. Если обозначить байты цифрами, то:
1234 5678 - если команда в байте 1, то литерал - 2345 если команда в байте 2, то литерал - 3456 если команда в байте 3, то литерал - 4567 если команда в байте 4, то литерал - 5678
Если же команда в байте 5... то такого не бывает, потому что после обработки первого слова будет подгружено еще одно, и новым состоянием этой пары станет
5678 90AB
Таким образом, имеется возможность произвольно чередовать команды и литералы, загружая их за 1 такт по мере необходимости.
|
|
|
|
Добавлено: Ср авг 12, 2020 03:00 |
|
|
|
|