Многоядерные процессоры с низким энергопотреблением

IDE VentureForth

Среда VentureForth имеет достаточно простую структуру директорий:

• docs - содержит документацию на процессор и среду разработки;
• projects – директории проектов приложений;
• vf рабочая директория среды, содержит:
  • поддиректории с настройками среды и компилятора, специфичными для конкретных версий процессора;
  • - файлы с исходными текстами симулятора и вспомогательные библиотеки компилятора.

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

Желательно для каждого нового приложения создавать новую Директорию проекта. Проще всего это сделать при помощи копирования существующей директории проекта и использования ее как шаблон. Рассмотрим пример приложения s40blink, демонстрирующий работу с внешними выводами процессора и с ЦАП.

Директория приложения содержит следующие файлы:

blinkLED.vf - вывод импульсов с меняющейся длительностью на внешние выводы

sawtooth.vf - генерация пилообразного сигнала на выводах ЦАП;

toggle17-1.vf - переключение состояния пары выводов;

blinktest.vf - центральный файл проекта, собирающий отдельные его части воедино;

project.vfp - исполняемый средой файл проекта.

Компиляция, Симуляция и загрузка кода

В этом примере, файл blinktest.vf определяет, что код будет запущен в каждом узле (т.е. в каждом чипе С18) и что порядок кода может доставляться узлу (рисунок 4.11).

Компиляция

Программа для каждого узла компилируется в 5 шагов.

1. Выбирается узел, к примеру: 02 {node
2. Определяется адрес, с которого начинается компиляция: 0 org
3. Определяется адрес точки входа для кода: here =p (это делается каждый раз перед выходом из узла)
4. Далее следует исходный код узла. Источник может быть включен в файл, компилирован как макро или подключен.
5. Вызывается node} в конце кода каждого узла.

В этом примере директивы {node org =p и node} используются в основном в главном файле приложения, но оны могут быть использованы и в макросах или подключаемых файлах, как представлено в BlinkLed.

Рис. 4.11. Вид файла Blinkеtest.vf

Подключаемые файлы и определение путей файлов

Файлы загружаются относительно директории проекта, директории установки среды или относительно указанных директорий (полный путь). Слово +include" ( a n) на входе берет строку пути и выделяет имя файла из входного потока.

Для загрузки файла, находящегося в директории проекта, используется include <filename>.

В заголовке файле подключается файл с библиотеками, специфичными для текущей версии процессора, надстройки симулятора, библиотеки для формирования загрузочного бинарного кода:

v.VF +include" c7Jr01/romconfig.f"
v.VF +include" ptools.f"   \ Host tools
v.VF +include" loader.f"   \ Alternate stream builder

Симуляция

Когда исходный код скомпилирован, объектный код для каждого узла располагается в виртуальном пространстве, представляющим собой содержимое ROM и RAM каждого узла. Оттуда мы можем скомпилированный объект переслать в реальный процессор, используя. Как правило, во время симуляции пропускается процесс загрузки и выполнение программы начинается так, как будто весь код уже загружен в процессор SEAforth.

Команда reset запускает симулятор так, как будто код уже в RAM SEAforth. Альтернативно, мы можем подключить тестовую плату, которая симулирует внешнее подключение. Командой power мы говорим симулятору симулировать процесс загрузки перед запуском кода приложения.

Команда simulate (короткий вариант sym ) запускает процесс симуляции. После выполнения - появляется двумерный массив, отображающий статус всех ядер. Нажатие пробела выполняет один шаг симуляции работы процессора (по умолчанию, скорость – один шаг на нажатие).

Основные команды симулятора

• simulate or sim – запускает или останавливает процесс симуляции;
• <space-bar> - шаг симуляции;
• <any-key> - останавливает симуляцию;
• ( n) setmax – устанавливает максимально возможное число шагов симуляции – n. Симуляция останавливается по достижении заданного числа шагов или после нажатия на клавишу. -1 – запускает бесконечную симуляцию. Значение по умолчанию – ;.
• ( n) setstep - Симуляция выполняется без обновления экрана в течении n шагов по умолчанию =1 ;
• ( n) upto - Симулируется n шагов без отображения, после чего симуляция завершается. Для продолжения требуется повторный запуск simulate. В это время возможно обновление значений setmax, setsteps.
• watch4 – вывод детальной информации по четырем выбранным ядрам, например - 03 04 05 -1 watch4 отобразит состояние 19, 20 и 5 ядер.

Следующие два рисунка отражают, как выглядит процесс симуляции в SwiftForth. Первая – перед процессом симуляции. Вторая после выполнения 273 шагов (рисунки 4.12, рисунки 4.13). На обоих рисунках, красным обозначены узлы, которые активны в данный момент. Черные узлы - спят (в состоянии покоя/низкого энергопотребления), ожидая инициализации/запуска через порт, или завершения процесса обмена данными с соседними узлами.

Рис. 4.12. Дисплей после запуска симуляции приложения

Рис. 4.13. Дисплей после 273 шагов

Загрузка кода в процессор

После того, как приложение скомпилировано и отлажено в симуляторе, следующий шаг – загрузка кода в чип SEAforth. Единственный путь поместить приложение в SEAforth – послать его на один из выводов, способных загрузит приложение через внешний вывод. Каждый из узлов SEAforth, который имеет загрузочный драйвер понимает протокол, созданный для загрузки приложения. Обычно это spi интерфейс или асинхронный последовательный порт (точнее ядра, имеющие загрузчик с асинхронного порта), реже синхронные линии или интерфейсы SERDES.

Наиболее простой путь синтезировать загрузочный код для процессора - используя слова из библиотеки ptools.f , модифицированной Советовым.

Например, следующий пример иллюстрирует создание загрузочного образа для spi-флеш памяти для всех 40 ядер процессора:

macro: s40>32 
32 31 30 20 10 00 01 11 
21 22 12 02 03 13 23 33 
34 24 14 04 05 15 25 35 
36 26 16 06 07 17 27 37 
38 28 18 08 09 19 29 39 
40 >stream 
macro;

0 :xnode s40>32 StreamFlash bsave blink.bin

Для загрузки с serial используется:

0 :xnode s40>33 xserial serial.bin

Аналогичное макро определение s40>33:

macro: s40>33
33 32 31 30 20 21 22 23 24 25 
26 27 28 18 17 16 15 14 13 12 
11 10 00 01 02 03 04 05 06 07 
08 09 19 29 39 38 37 36 35 34 
40 >stream 
macro;