UG0837
Посібник користувача
IGLOO2 і SmartFusion2 FPGA
Симуляція системних служб
червень 2018 р

Історія версій

Історія переглядів описує зміни, внесені в документ. Зміни перераховані за версіями, починаючи з останньої публікації.
1.1 Версія 1.0
Редакція 1.0 була опублікована в червні 2018 р. Це була перша публікація цього документа.

Моделювання системних служб IGLOO2 та SmartFusion2 FPGA

Блок системних служб сімейства SmartFusion®2 FPGA містить набір служб, що відповідають за різні завдання. Сюди входять служби моделювання повідомлень, служби покажчиків даних і служби дескрипторів даних. Доступ до системних служб можна отримати через Cortex-M3 у SmartFusion2 і з інтерфейсу FPGA через контролер інтерфейсу інтерфейсу (FIC) як для SmartFusion2, так і для IGLOO®2. Ці методи доступу надсилаються до системного контролера через COMM_BLK. COMM_BLK має розширений інтерфейс периферійної шини (APB) і діє як канал передачі повідомлень для обміну даними з системним контролером. Запити на системні послуги надсилаються до системного контролера, а відповіді системних служб надсилаються до CoreSysSerrvice через COMM BLK. Розташування адреси для COMM_BLK доступне всередині підсистеми мікроконтролера (MSS)/підсистеми високопродуктивної пам’яті (HPMS). Для отримання додаткової інформації див. UG0450: SmartFusion2 SoC і системний контролер IGLOO2 FPGA.
Посібник користувача
На наступній ілюстрації показано потік даних системних служб.
Рисунок 1 • Діаграма потоку даних системної службиДля симуляції системної служби IGLOO2 і SmartFusion2 вам потрібно надіслати запити на системну службу та перевірити відповіді системної служби, щоб переконатися, що симуляція правильна. Цей крок необхідний для доступу до системного контролера, який надає системні служби. Спосіб запису та читання з системного контролера відрізняється для пристроїв IGLOO2 і SmartFusion2. Для SmartFusion2 доступний Coretex-M3, і ви можете записувати та читати з системного контролера за допомогою команд функціональної моделі шини (BFM). Для IGLOO2 Cortex-M3 недоступний, а системний контролер недоступний за допомогою команд BFM.
2.1 Типи доступних системних служб
Доступні три різні типи системних служб, і кожен тип послуги має різні підтипи.
Сервіси моделювання повідомлень
Сервіси покажчиків даних
Служби дескриптора даних
У розділі «Додаток – Типи системних служб» (див. сторінку 19) цього посібника описано різні типи системних служб. Для отримання додаткової інформації про системні служби див. UG0450: Посібник користувача системного контролера SmartFusion2 SoC і IGLOO2 FPGA.
2.2 Симуляція обслуговування системи IGLOO2
Системні служби передбачають запис і читання з системного контролера. Для запису в системний контролер і зчитування з нього з метою моделювання потрібно виконати наведені нижче дії.

1. Створіть екземпляр програмного IP-ядра CoreSysServices, доступного в каталозі SmartDesign.
2. Напишіть код HDL для кінцевого автомата (FSM).

HDL FSM взаємодіє з ядром CoreSysServices, яке служить майстром для шини AHBLite. Ядро CoreSysServices ініціює запит системної служби до COMM BLK і отримує відповіді системної служби від COMM BLK через FIC_0/1, контролер інтерфейсу інтерфейсу, як показано на наступній ілюстрації.
Рисунок 2 • Топологія моделювання системних служб IGLOO22.3 Симуляція обслуговування системи SmartFusion2
Щоб імітувати системні служби в пристроях SmartFusion2, вам потрібно записувати та читати з системного контролера. Доступні два варіанти доступу до системного контролера з метою моделювання.
Варіант 1. Напишіть код HDL для FSM для взаємодії з програмним IP-ядром CoreSysService, яке служить майстром інтерфейсу AHBLite та ініціює запит системної служби до COMM BLK і отримує відповіді системної служби від COMM BLK через структуру FIC_0/1 інтерфейс, як показано на наступній ілюстрації.
Рисунок 3 • Топологія симуляції системних служб SmartFusion2

Варіант 2 — Оскільки Cortex-M3 доступний для пристроїв SmartFusion2, ви можете використовувати команди BFM для безпосереднього запису та читання з простору пам’яті системного контролера.
Використання команд BFM (варіант 2) позбавляє від необхідності писати коди HDL для FSM. У цьому посібнику користувача варіант 2 використовується для показу симуляції системних служб у SmartFusion2. За допомогою цього параметра здійснюється доступ до простору пам’яті системного контролера, щоб знайти карту пам’яті COMM BLK і блок контролера переривань інтерфейсу фабрики (FIIC), коли ви пишете свої команди BFM.
2.4 Моделювання Прampлес
Посібник користувача охоплює наступне моделювання.

• Симуляція служби серійного номера IGLOO2 (див. сторінку 5)
• Симуляція служби серійного номера SmartFusion2 (див. стор. 8)
• Симуляція служби обнулення IGLOO2 (див. стор. 13)
• Симуляція служби обнулення SmartFusion2 (див. стор. 16)

Подібні методи моделювання можна застосувати до інших системних служб. Повний список доступних системних служб див. у Додатку – Типи системних служб (див. сторінку 19).

2.5 Симуляція служби серійного номера IGLOO2
Щоб підготуватися до симуляції служби серійних номерів IGLOO2, виконайте наведені нижче дії.

1. Викличте конструктор системи, щоб створити свій блок HPMS.
2. Поставте прапорець HPMS System Services на сторінці Device Features. Це вкаже розробнику системи відкрити інтерфейс шини HPMS_FIC_0 SYS_SERVICES_MASTER (BIF).
3. Залиште всі інші прапорці непозначеними.
4. Прийміть значення за замовчуванням на всіх інших сторінках і натисніть «Готово», щоб завершити створення блоку побудови системи. У редакторі HDL Libero® SoC напишіть код HDL для FSM (File > Новий > HDL) . Включіть наступні три штати у свій FSM.
   INIT стан (початковий стан)
   SERV_PHASE (стан запиту на обслуговування)
   RSP_PHASE (стан відповіді служби).
   На наступному малюнку показано три стани FSM.
   Рисунок 4 • FSM із трьома станами
5. У вашому коді HDL для FSM використовуйте правильний код команди («01» Hex для служби серійного номера), щоб увійти в стан запиту на обслуговування зі стану INIT.
6. Збережіть HDL file. FSM відображається як компонент в ієрархії проектування.
7. Відкрийте SmartDesign. Перетягніть свій блок конструктора системи верхнього рівня та блок FSM на полотно SmartDesign. З каталогу перетягніть програмне IP-ядро CoreSysService на полотно SmartDesign.
8. Клацніть правою кнопкою миші програмне IP-ядро CoreSysService, щоб відкрити конфігуратор. Поставте прапорець Сервіс серійних номерів (у розділі Інформаційні служби пристроїв і дизайну).
   групу), щоб увімкнути службу серійного номера.
9. Залиште всі інші прапорці непозначеними. Натисніть OK, щоб вийти з конфігуратора.
   Малюнок 5 • Програмний конфігуратор CoreSysServices IP
   
10. Підключіть HPMS_FIC_0 SYS_SERVICES_MASTER BIF блоку побудови системи до AHBL_MASTER BIF блоку CoreSysService.
11. Підключіть вихід блоку HDL FSM до входу програмного IP-ядра CoreSysService. Виконайте всі інші з’єднання на полотні SmartDesign, як показано на малюнку нижче.
    Рисунок 6 • SmartDesign Canvas із блоком HDL, CoreSysServices Soft IP та блоками HPMS
12. На полотні SmartDesign клацніть правою кнопкою миші > Створити компонент, щоб створити дизайн верхнього рівня.
13. В ієрархії проектування view, клацніть правою кнопкою миші дизайн верхнього рівня та виберіть створити Testbench > HDL .
14. Використовуйте текстовий редактор для створення тексту file під назвою “status.txt” .
15. Включіть команду для системної служби та 128-бітний серійний номер. Щоб отримати додаткові відомості, див. Таблицю 1 (Значення команд/відповідей системних служб) у Посібник CoreSysServices v3.1 для кодів команд (HEX), які будуть використовуватися для різних системних служб. Для служби серійного номера код команди – «01» Hex.

Формат status.txt file для служби серійного номера виглядає наступним чином.
< 2 шістнадцяткові цифри CMD><32 шістнадцяткові цифри серійного номера>
Example: 01A1A2A3A4B1B2B3B4C1C2C3C4D1D2D3D4
Збережіть status.txt file у папці Simulation вашого проекту. Тепер дизайн готовий до моделювання.
Після початку виконання служби у вікні стенограми ModelSim відображається повідомлення із зазначенням місця призначення та серійного номера, як показано на малюнку нижче.
Рисунок 7 • Вікно стенограми моделювання ModelSimКонтролер системи проводить запис AHB на адресу з серійним номером. Після завершення служби в RXFIFO COMM_BLK буде завантажено відповідь служби.
Примітка. Щоб отримати повний перелік кодів команд, які будуть використовуватися для різних системних служб, див. Таблицю 1 (Значення команд/відповідей системних служб) у посібнику CoreSysServices v3.1 або UG0450: Посібник користувача системного контролера SmartFusion2 SoC і IGLOO2 FPGA.
2.6 Симуляція служби серійного номера SmartFusion2
У цьому посібнику користувача команди BFM (варіант 2) використовуються для доступу до системного контролера для обслуговування системи. Команди BFM використовуються, оскільки процесор Cortex-M3 доступний на пристрої для симуляції BFM. Команди BFM дозволяють вам безпосередньо записувати та читати з COMM BLK, коли ви дізнаєтесь про відображення пам’яті COMM_BLK.
Щоб підготувати свій проект для симуляції служби серійних номерів SmartFusion2, виконайте наступні кроки.

1. Перетягніть MSS з каталогу на полотно дизайну вашого проекту.
2. Вимкніть усі периферійні пристрої MSS, крім MSS_CCC, контролера скидання, керування перериваннями та FIC_0, FIC_1 і FIC_2.
3. Налаштуйте керування перериваннями для використання MSS для створення переривань.
4. Підготуйте serialnum.bfm file у текстовому редакторі або в редакторі HDL Libero. Збережіть serialnum.bfm file у папці Simulation проекту. Serialnum.bfm має містити такі відомості.
   • Відображення пам'яті на COMM BLK (CMBLK)
   • Відображення пам'яті на периферію керування перериваннями (FIIC)
   • Команда для запиту служби системи серійного номера («01» Hex)
   • Адреса розташування серійного номера
   Колишнійampфайл serialnum.bfm file полягає в наступному.
   memmap FIIC 0x40006000; #Відображення пам'яті для керування перериваннями
   memmap CMBLK 0x40016000; #Відображення пам'яті в COMM BLK
   memmap DESCRIPTOR_ADDR 0x20000000; #Address розташування для серійного номера
   #Код команди в шістнадцятковій системі
   постійна CMD 0x1 # Код команди для Serial NumberService
   Регістри конфігурації #FIIC
   константа FICC_INTERRUPT_ENABLE0 0x0
   Регістри конфігурації #COMM_BLK
   постійний CONTROL 0x00
   постійний СТАТУС 0x04
   константа INT_ENABLE 0x08
   константа DATA8 0x10
   константа DATA32 0x14
   константа FRAME_START8 0x18
   константа FRAME_START32 0x1C
   серійний номер процедури;
   int x;
   написати w FIIC FICC_INTERRUPT_ENABLE0 0x20000000 #Налаштувати
   #FICC_INTERRUPT_ENABLE0 # Зареєструйтеся, щоб увімкнути COMBLK_INTR #
   #переривання від блоку COMM_BLK до мережі
   #Фаза запиту
   write w CMBLK CONTROL 0x10 # Налаштування COMM BLK Control #Зареєструватися на
   увімкнути передачу через інтерфейс COMM BLK
   write w CMBLK INT_ENABLE 0x1 # Налаштувати COMM BLK Interrupt Enable
   #Зареєструйтесь, щоб увімкнути переривання для TXTOKAY (відповідний біт у
   #Реєстр статусу)
   waitint 19 # очікування COMM BLK Переривання, тут #BFM очікує
   #поки COMBLK_INTR не буде встановлено
   readstore w CMBLK STATUS x # Читання реєстру статусу COMM BLK для #TXTOKAY
   # Переривання
   встановити xx & 0x1
   якщо х
   написати w CMBLK FRAME_START8 CMD # Налаштувати COMM BLK FRAME_START8
   #Зареєструйтесь, щоб отримати послугу серійного номера
   endif
   endif
   waitint 19 # очікування COMM BLK Переривання, тут
   #BFM чекає, доки не буде встановлено COMBLK_INTR
   readstore w CMBLK STATUS x # Читання COMM BLK Status Register for
   #TXTOKAY Переривання
   встановити xx & 0x1
   встановити xx & 0x1
   якщо х
   write w CMBLK CONTROL 0x14 #Налаштувати COMM BLK Control
   #Зареєструйтеся, щоб увімкнути перекази через інтерфейс COMM BLK
   написати w CMBLK DATA32 DESCRIPTOR_ADDR
   напишіть w CMBLK INT_ENABLE 0x80
   напишіть w CMBLK CONTROL 0x10
   endif
   чекай 20
   #Фаза відповіді
   зачекай 19
   readstore w CMBLK STATUS x
   встановити xx & 0x80
   якщо х
   перевірка читання з CMBLK FRAME_START8 CMD
   напишіть w CMBLK INT_ENABLE 0x2
   endif
   зачекай 19
   readstore w CMBLK STATUS x
   встановити xx & 0x2
   якщо х
   перевірка читання w CMBLK DATA8 0x0
   напишіть w CMBLK CONTROL 0x18
   endif
   зачекай 19
   перевірка читання з FIIC 0x8 0x20000000
   readstore w CMBLK STATUS x
   встановити xx & 0x2
   якщо х
   перевірка читання w CMBLK DATA32 DESCRIPTOR_ADDR
   endif
   перевірка читання w DESCRIPTOR_ADDR 0x0 0xE1E2E3E4; #Readcheck, щоб перевірити S/N
   перевірка читання w DESCRIPTOR_ADDR 0x4 0xC1C2C3C4; #Readcheck, щоб перевірити S/N
   перевірка читання w DESCRIPTOR_ADDR 0x8 0xB1B2B3B4; #Readcheck, щоб перевірити S/N
   перевірка читання w DESCRIPTOR_ADDR 0xC 0xA1A2A3A4; #Readcheck, щоб перевірити S/N
   повернення
5. Створіть статус. txt file у редакторі HDL Libero або в будь-якому текстовому редакторі. Включіть системну службову команду серійного номера («01» у Hex) і серійний номер у статусі. txt file. Перегляньте довідник CoreSysServices v3.1 для використання правильного коду команди.
6. Синтаксис цього file для служби серійного номера: <2 шістнадцяткова цифра CMD>< 32 шістнадцяткова цифра серійного номера> . Прample: 01A1A2A3A4B1B2B3B4C1C2C3C4E1E2E3E4.
7. Збережіть статус .txt file у папці Simulation проекту.
8. Відредагуйте файл користувача .bfm (розташований у папці Simulation), щоб включити серійний номер. bfm file і викликайте процедуру серійного номера, як показано в наступному фрагменті коду.
   включити “serialnum.bfm” #include the serialnum.bfm
   процедура user_main;
   надрукувати «INFO: Simulation Starts»;
   надрукувати “INFO:Код команди служби в десятковому вигляді:%0d”, CMD ;
   назва серійного номера; #виклик процедури serialnum
   надрукувати «INFO:Simulation Ends»;
   повернення
9. В ієрархії проектування view, згенеруйте тестовий стенд (клацніть правою кнопкою миші, Дизайн верхнього рівня > Створити тестовий стенд > HDL ), і ви готові до запуску моделювання служби серійних номерів.

Після початку виконання служби з’являється повідомлення із зазначенням місця призначення та серійного номера. Контролер системи проводить запис AHB на адресу з серійним номером. Після завершення служби в RXFIFO COMM_BLK буде завантажено відповідь служби. У вікні стенограми ModelSim відображається адреса та отриманий серійний номер, як показано на малюнку нижче.
Рисунок 8 • Симуляція служби серійних номерів SmartFusion2 у вікні стенограми ModelSim

2.7 Моделювання сервісу обнулення IGLOO2
Щоб підготуватися до симуляції служби обнулення IGLOO2, виконайте наведені нижче дії.

1. Викличте конструктор системи, щоб створити блок HPMS. Поставте прапорець HPMS System Services у розділі Device Features SYS_SERVICES_MASTER BIF. Залиште всі інші прапорці непозначеними. Прийміть значення за замовчуванням на всіх інших сторінках і натисніть сторінку. Це вказує розробнику системи відкрити HPMS_FIC_0 Finish для завершення конфігурації блоку побудови системи.
2. У редакторі HDL Libero SoC напишіть код HDL для FSM. У вашому коді HDL для FSM включіть наступні три стани.
   INIT стан (початковий стан)
   SERV_PHASE (стан запиту на обслуговування)
   RSP_PHASE (стан відповіді служби)
   На наступному малюнку показано три стани FSM.
   Рисунок 9 • FSM із трьома станами

    

3. У вашому коді HDL використовуйте код команди “F0″(Hex), щоб увійти в стан запиту на обслуговування зі стану INIT.
4. Збережіть HDL file.
5. Відкрийте SmartDesign, перетягніть свій блок побудови системи верхнього рівня та блок HDL FSM на полотно SmartDesign. З каталогу перетягніть програмне IP-ядро CoreSysService на полотно SmartDesign.
6. Клацніть правою кнопкою миші програмне IP-ядро CoreSysServices, щоб відкрити конфігуратор і встановіть прапорець Zeroization Service у групі Data Security Services. Залиште всі інші прапорці непозначеними. Натисніть, щоб вийти.
   Рисунок 10 • Конфігуратор CoreSysServices
   
7. Підключіть HPMS_FIC_0 SYS_SERVICES_MASTER BIF блоку побудови системи до AHBL_MASTER BIF блоку CoreSysService.
8. Підключіть вихід блоку HDL FSM до входу програмного IP-ядра CoreSysService. Зробіть усі інші з’єднання на полотні SmartDesign.
   Малюнок 11 • SmartDesign Canvas із блоками HDL, CoreSysServices Soft IP та блоками HPMS
   9. На полотні SmartDesign згенеруйте дизайн верхнього рівня (клацніть правою кнопкою миші > Створити компонент).
   10. В ієрархії проектування viewклацніть правою кнопкою миші дизайн верхнього рівня та виберіть створити Testbench > HDL. Тепер ви готові до запуску моделювання.
   Після початку виконання служби відображається повідомлення про те, що обнулення завершено в момент часу x, як показано на малюнку нижче.
   Малюнок 12 • Вікно стенограми моделювання служби обнулення системи IGLOO2
   

Контролер системи проводить запис AHB на адресу з серійним номером. Після завершення служби в RXFIFO COMM_BLK буде завантажено відповідь служби. Слід зазначити, що імітаційна модель імітує обнулення шляхом зупинки моделювання, а не обнулення самого проекту.
Примітка. Щоб отримати повний перелік кодів команд, які будуть використовуватися для різних системних служб, див. Таблицю 1 (Значення команд/відповідей системних служб) у Посібник CoreSysServices v3.1:. або UG0450: Посібник користувача системного контролера SmartFusion2 SoC і IGLOO2 FPGA

2.8 Моделювання служби обнулення SmartFusion2
У цьому посібнику команди BFM (варіант 2) використовуються для доступу до системного контролера для обслуговування системи.
Команди BFM використовуються, оскільки процесор Cortex-M3 доступний на пристрої для симуляції BFM. Команди BFM дозволяють вам безпосередньо записувати та читати з COMM BLK, коли ви дізнаєтесь про відображення пам’яті COMM_BLK. Щоб підготувати свій проект для симуляції служби обнулення SmartFusion2, виконайте наступні кроки.

1. Перетягніть MSS з каталогу на полотно дизайну вашого проекту.
2. Вимкніть усі периферійні пристрої MSS, крім MSS_CCC, контролера скидання, керування перериваннями та FIC_0, FIC_1 і FIC_2.
3. Налаштуйте керування перериваннями для використання MSS для створення переривань.
4. Підготуйте zeroizaton.bfm file у текстовому редакторі або в редакторі HDL Libero. Ваше обнулення. bfm має включати:

• Відображення пам'яті на COMM BLK (CMBLK)
• Відображення пам'яті на периферію керування перериваннями (FIIC)
• Команда для запиту служби обнулення («F0» Hex для обнулення)

Колишнійampфайл serialnum.bfm file показано на наступному малюнку.
Рисунок 13 • Zeroization.bfm для симуляції системних служб обнулення SmartFusion2

5. Збережіть zeroization.bfm file у папці Simulation проекту. user.bfm
6. Відредагуйте файл (розташований у папці Zeroization.bfm Simulation), щоб включити за допомогою наступного фрагмента коду.
включити “zeroization.bfm” #include zeroization.bfm file процедура user_main;
надрукувати «INFO: Simulation Starts»;
надрукувати “INFO:Код команди служби в десятковому вигляді:%0d”, CMD ;
обнулення виклику; #повернення процедури обнулення виклику
7. У Design Hierarchy згенеруйте Testbench (клацніть правою кнопкою миші верхній рівень > Create Testbench > HDL), і ви готові до запуску моделювання обнулення SmartFusion2.
Після того, як послуга почала виконання, відображається повідомлення про те, що пристрій було обнулено в момент часу x. Слід зазначити, що імітаційна модель імітує обнулення шляхом зупинки моделювання, а не обнулення самого проекту. Вікно стенограми ModelSim на наступному малюнку показує, що пристрій було обнулено.

Малюнок 14 • Журнал симуляції обслуговування системи SmartFusion2 Zeroization System

Додаток: Типи системних служб

У цьому розділі описано різні типи системних служб.
3.1 Служби моделювання повідомлень
У наступних розділах описуються різні типи служб симуляції повідомлень.
3.1.1 Спалах*Стоп
Симуляція перейде в стан Flash*Freeze, коли на COMM_BLK буде надіслано відповідний запит на обслуговування з FIC (у випадку пристроїв IGLOO2) або Cortex-M3 (у пристроях SmartFusion2). Після виявлення служби системним контролером симуляція буде зупинена та відобразиться повідомлення про те, що система перейшла в режим Flash*Freeze (разом із вибраним параметром). Після відновлення симуляції RXFIFO COMM_BLK буде заповнено відповіддю служби, яка складається з команди служби та статусу. Слід зазначити, що для виходу Flash*Freeze не підтримується симуляція.
3.1.2 Обнулення
Обнулення наразі є єдиною високопріоритетною службою в системних службах, які обробляються COMM_BLK. Симуляція перейде в стан обнулення, як тільки COMM_BLK виявить правильний запит на службу. Виконання інших служб буде зупинено та відкинуто системним контролером, а замість них буде виконано службу обнулення. Після виявлення запиту на службу обнулення симуляція припиняється та відображається повідомлення про те, що система ввела обнулення. Перезапуск симуляції вручну після обнулення недійсний.
3.2 Служби вказівників даних
У наступних розділах описано різні типи служб покажчиків даних.
3.2.1 Серійний номер
Служба серійного номера запише 128-бітний серійний номер до адреси, зазначеної в запиті на службу. Цей 128-бітний параметр можна встановити за допомогою підтримки симуляції системної служби file (див. стор. 22) . Якщо параметр 128-бітного серійного номера не визначено в межах file, буде використано стандартний порядковий номер 0. Після початку виконання служби з’являється повідомлення із зазначенням місця призначення та серійного номера. Контролер системи проводить запис AHB на адресу з серійним номером. Після завершення служби в RXFIFO COMM_BLK буде завантажено відповідь служби.
3.2.2 Код користувача
Служба коду користувача записує 32-розрядний параметр коду користувача до адреси, наданої як частина запиту служби. Цей 32-розрядний параметр можна встановити за допомогою підтримки симуляції системної служби file (див. стор. 22). Якщо 32-розрядний параметр не визначено в межах file, використовується значення за замовчуванням 0. Після початку виконання служби з’являється повідомлення із зазначенням цільового розташування та коду користувача. Контролер системи проводить запис AHB на адресу з 32-бітним параметром. Після завершення служби RXFIFO COMM_BLK завантажується відповіддю служби, яка включає команду служби та цільову адресу.
3.3 Служби дескриптора даних
У наступних розділах описано різні типи служб дескрипторів даних.

3.3.1 AES
Підтримка симуляції для цієї служби пов’язана лише з переміщенням вихідних даних від джерела до місця призначення без фактичного виконання будь-якого шифрування/дешифрування даних. Дані, які потрібно зашифрувати/розшифрувати, і структуру даних слід записати до надсилання запиту на обслуговування. Після того, як служба почала виконуватися, відображається повідомлення, яке вказує на виконання служби AES. Служба AES зчитує як структуру даних, так і дані, які потрібно зашифрувати/дешифрувати. Вихідні дані копіюються та записуються на адресу, надану в структурі даних. Після завершення служби команда, статус і адреса структури даних надсилаються в RXFIFO.
Примітка: Ця послуга призначена лише для 128- і 256-бітних даних, і 128-бітні, і 256-бітні дані мають різну довжину структури даних.

3.3.2 SHA 256
Підтримка моделювання для цієї служби пов’язана лише з переміщенням даних без фактичного виконання будь-якого хешування даних. Функція SHA 256 призначена для створення 256-бітного хеш-ключа на основі вхідних даних. Дані, які потрібно хешувати, і структура даних повинні бути записані на відповідні адреси перед тим, як запит на обслуговування буде надіслано до COMM_BLK. Довжина в бітах і покажчик, визначені в структурі даних SHA 256, повинні правильно відповідати довжині та адресі даних, які потрібно хешувати. Після того, як служба почала виконуватися, відображається повідомлення, яке вказує на виконання служби SHA 256. Замість того, щоб виконувати фактичну функцію, хеш-ключ за замовчуванням буде записаний у покажчик призначення зі структури даних. Ключ гешу за замовчуванням – шістнадцятковий «ABCD1234». Для налаштування спеціального ключа перейдіть до розділу «Налаштування параметрів» (див. сторінку 23). Після завершення служби RXFIFO завантажується відповіддю служби, що складається з команди служби, статусу та покажчика на структуру даних SHA 256.
3.3.3 HMAC
Підтримка моделювання для цієї служби стосується лише переміщення даних без фактичного виконання будь-якого хешування даних. Дані, які потрібно хешувати, і структура даних повинні бути записані на відповідні адреси перед тим, як запит на обслуговування буде надіслано до COMM_BLK. Служба HMAC потребує 32-байтового ключа на додаток до довжини в байтах, покажчика джерела та покажчика призначення. Після початку виконання служби відображається повідомлення, яке вказує на виконання служби HMAC. Ключ зчитується, і 256-бітний ключ копіюється зі структури даних у вказівник призначення. Після завершення служби RXFIFO завантажується відповіддю служби, що складається з команди служби, статусу та покажчика структури даних HMAC.

3.3.4 Створення DRBG
Генерація випадкових бітів виконується цим сервісом. Слід зазначити, що імітаційна модель не точно відповідає тій самій методології генерації випадкових чисел, яку використовує silicon. Структура даних повинна бути правильно записана в призначене місце, перш ніж запит на обслуговування буде надіслано в COMM_BLK. Структура даних, покажчик призначення, довжина та інші відповідні дані зчитуються системним контролером. Служба генерації DRBG генерує псевдовипадковий набір даних потрібної довжини (0-128). Системний контролер записує випадкові дані в покажчик призначення. Під час симуляції відображається повідомлення, яке вказує на виконання служби генерації DRBG. Після завершення служби команда, статус і адреса структури даних надсилаються в RXFIFO. Якщо запитана довжина даних не входить у діапазон 0-128, код помилки «4» (Max Generate ) буде передано в RXFIFO. Якщо довжина додаткових даних не входить до діапазону Request Too Big 0-128, код помилки «5» (максимальна довжина додаткових даних перевищено) буде передано в RXFIFO. Якщо запитувана довжина даних для створення та додаткова довжина даних не входять у визначений діапазон (0-128), код помилки «1» (Катастрофічна помилка) надсилається в RXFIFO.

3.3.5 Скидання DRBG
Фактична функція скидання виконується шляхом видалення екземплярів DRBG і скидання DRBG. Після виявлення запиту на службу симуляція відображає повідомлення про завершення скидання служби DRBG. Відповідь, яка включає службу та статус, надсилається в RXFIFO.
3.3.6 Самоперевірка DRBG
Підтримка моделювання для самотестування DRBG фактично не виконує функцію самотестування. Після виявлення запиту на службу симуляція відобразить повідомлення про виконання служби самоперевірки DRBG. Відповідь, яка включає послугу та статус, буде передано в RXFIFO.
3.3.7 Екземпляр DRBG
Підтримка моделювання для служби створення екземпляра DRBG фактично не виконує службу створення екземпляра. Структура даних повинна бути правильно записана в призначене місце, перш ніж запит на обслуговування буде надіслано в COMM_BLK. Після виявлення запиту на послугу буде прочитано структуру та рядок персоналізації, визначені в адресному просторі MSS. Симуляція відобразить повідомлення про те, що служба DRBG Instantiate почала виконання. Після завершення служби відповідь, яка включає команду служби, статус і покажчик на структуру даних, буде передано в RXFIFO. Якщо довжина даних (PERSONALIZATIONLENGTH) знаходиться за межами діапазону 0-128, код помилки «1» (Катастрофічна помилка) буде передано в RXFIFO для стану.
3.3.8 DRBG Uninstantiate
Підтримка моделювання для служби без екземплярів DRBG фактично не виконує службу без екземплярів видалення попередньо створеного екземпляра DRBG, як це робить кремній. Запит на обслуговування має містити як команду, так і дескриптор DRBG. Після виявлення запиту на обслуговування дескриптор DRBG буде збережено. Симуляція відобразить повідомлення про те, що службу без екземплярів DRBG ініціалізовано. Після завершення служби відповідь, яка включає команду служби, статус і дескриптор DRBG, буде передано в RXFIFO.
3.3.9 Повторне заповнення DRBG
Через імітаційну природу блоку системних служб служба повторного заповнення DRBG у симуляції не виконується автоматично після кожного генерування 65535 служб DRBG. Структура даних має бути правильно записана в призначене місце, перш ніж запит на обслуговування буде надіслано до COMM_BLK. Після виявлення запиту на послугу буде зчитано структуру та додатковий вхідний параметр у просторі адрес MSS. Буде відображено повідомлення про те, що служба повторного заповнення DRBG почала виконуватися. Структура даних має бути правильно записана в призначене місце, перш ніж запит на обслуговування буде надіслано до COMM_BLK. Після завершення служби відповідь, яка включає команду служби, статус і покажчик на структуру даних, буде передано в RXFIFO.
3.3.10 Дерево ключів
Фактична функція не виконується в симуляції для служби KeyTree. Структура даних служби KeyTree складається з 32-байтового ключа, 7-бітових даних оптипу (MSB ігнорується) і 16-байтового шляху. Дані в структурі даних мають бути записані за відповідними адресами, перш ніж запит на обслуговування буде надіслано до COMM_BLK. Після того, як служба почне виконання, буде відображено повідомлення про виконання служби KeyTree. Вміст структури даних буде прочитано, 32-байтовий ключ буде збережено, а вихідний ключ, розташований у структурі даних, буде перезаписано. Після цього запису AHB значення ключа в структурі даних не повинно змінитися, але транзакції AHB для запису відбуватимуться. Після завершення служби RXFIFO завантажується відповіддю служби, яка складається з команди служби, статусу та покажчика структури даних KeyTree.
3.3.11 Відповідь на виклик
Фактична функція, наприклад автентифікація пристрою, не виконується в симуляції для служби відповіді на виклик. Структура даних для цієї служби потребує покажчика на буфер, щоб отримати 32-байтовий результат, 7-бітний тип опції та 128-бітний шлях. Дані в структурі даних мають бути записані за відповідними адресами до того, як запит на обслуговування буде надіслано до COMM_BLK. Після того, як служба почне виконання, буде відображено повідомлення про виконання служби відповіді на виклик. Загальна 256-бітна відповідь буде записана в покажчик, наданий у структурі даних. Типовим ключем є шістнадцятковий «ABCD1234». Щоб отримати спеціальний ключ, перевірте налаштування параметрів (див. сторінку 23). Після завершення служби в RXFIFO буде завантажено відповідь служби, що складається з команди служби, статусу та покажчика структури даних відповіді на виклик.
3.4 Інші послуги
У наступних розділах описано різні інші системні служби.
3.4.1 Перевірка дайджесту
Фактична функція перерахунку та порівняння дайджестів вибраних компонентів не виконується для служби перевірки дайджесту під час симуляції. Цей запит на службу складається з команд служби та параметрів служби (5-бітовий LSB). Після того, як служба почне виконання, буде відображено повідомлення з детальним описом виконання служби перевірки дайджесту разом із вибраними параметрами запиту. Після завершення служби в RXFIFO буде завантажено відповідь служби, яка складається з команди служби та прапорів перевірки дайджесту.
3.4.2 Нерозпізнана відповідь на команду
Коли на COMM_BLK надсилається нерозпізнаний запит на обслуговування, COMM_BLK автоматично відповість нерозпізнаним командним повідомленням, яке надсилається в RXFIFO. Повідомлення складається з команди, надісланої в COMM_BLK, і статусу нерозпізнаної команди (252D). Також відобразиться повідомлення про те, що виявлено нерозпізнаний запит на обслуговування. COMM_BLK повернеться в стан очікування, очікуючи прийняття наступного запиту на обслуговування.
3.4.3 Непідтримувані служби
Непідтримувані служби, для яких встановлено значення COMM_BLK, ініціюють повідомлення під час моделювання, яке вказує на те, що запит на службу не підтримується. COMM_BLK повернеться в стан очікування, очікуючи прийняття наступного запиту на обслуговування. PINTERRUPT не буде встановлено, вказуючи, що послугу завершено. Поточний список непідтримуваних служб включає: IAP, ISP, сертифікат пристрою та службу DESIGNVER.
3.5 Підтримка симуляції системних служб File
Для підтримки моделювання системних служб, текст file «status.txt» можна використовувати для передачі інструкцій щодо необхідної поведінки імітаційної моделі в імітаційну модель. Це file має розташовуватися в тій же папці, з якої запускається симуляція. The file можна використовувати, серед іншого, для примусової відповіді на певні помилки для підтримуваних системних служб або навіть для встановлення деяких параметрів, необхідних для моделювання (наприклад,ample, серійний номер). Максимальна кількість рядків, підтримуваних у ”status.txt” file дорівнює 256. Інструкції, що з’являються після рядка номер 256, не використовуватимуться в симуляції.
3.5.1 Примусові відповіді на помилки
Користувач може змусити певну відповідь на помилку для певної служби під час тестування, передавши інформацію в імітаційну модель за допомогою «status.txt» file, який слід розмістити в папці, з якої виконується моделювання. Щоб примусово відповідати певній службі на помилку, команду та необхідну відповідь слід ввести в одному рядку в такому форматі:ample, до Command> ; наказати імітаційній моделі створити відповідь про помилку доступу до пам’яті MSS для служби серійного номера, команда виглядає наступним чином.
Сервіс: Серійний номер: 01
Запитане повідомлення про помилку: Помилка доступу до пам’яті MSS: 7F
Ви повинні ввести рядок 017F у «status.txt» file.
3.5.2 Налаштування параметрів
"status.txt" file також можна використовувати для встановлення деяких параметрів, необхідних у моделюванні. Як колишнійample, щоб встановити 32-бітний параметр для коду користувача, формат рядка має бути в такому порядку: <32 Bit USERCODE>; де обидва значення вводяться у шістнадцятковій формі. Щоб встановити 128-бітний параметр для серійного номера, формат рядка має бути в такому порядку: <128-бітний серійний номер [127:0]> ; де обидва значення вводяться у шістнадцятковій формі. Щоб встановити 256-бітний параметр для ключа SHA 256; формат рядка має бути в такому порядку: <256 Bit Key [255:0]>; де обидва значення вводяться у шістнадцятковій формі. Щоб встановити 256-бітний параметр для ключа відповіді на виклик, формат рядка має бути в такому порядку: <256 Bit Key [255:0]>;
де обидва значення вводяться у шістнадцятковій формі.
3.5.3 Пріоритет пристрою
Системні служби та COMM_BLK використовують систему з високим пріоритетом. Наразі єдиною пріоритетною послугою є обнулення. Щоб виконати послугу з високим пріоритетом, під час виконання іншої служби поточна служба зупиняється, а замість неї виконується служба з вищим пріоритетом. COMM_BLK відкине поточну послугу, щоб виконати послугу з вищим пріоритетом. Якщо кілька непріоритетних служб надсилаються до завершення поточної послуги, ці послуги будуть поставлені в чергу в TXFIFO. Після завершення поточної служби буде виконано наступну послугу в TXFIFO.

Microsemi не дає жодних гарантій, заяв або гарантій щодо інформації, що міститься в цьому документі, або придатності її продуктів і послуг для будь-якої конкретної мети, а також не бере на себе жодної відповідальності, що випливає із застосування або використання будь-якого продукту чи схеми. Продукти, що продаються за цією Угодою, та будь-які інші продукти, що продаються Microsemi, пройшли обмежене тестування і не повинні використовуватися разом із критично важливим обладнанням або програмами. Будь-які технічні характеристики вважаються надійними, але не перевірені, і Покупець повинен провести та завершити всі випробування продуктивності та інші випробування продуктів окремо та разом із будь-якими кінцевими продуктами чи встановленими в них. Покупець не повинен покладатися на будь-які дані та характеристики або параметри, надані Microsemi. Покупець зобов’язаний самостійно визначати придатність будь-яких продуктів, а також тестувати та перевіряти це. Інформація, надана Microsemi за цією Угодою, надається «як є, де є» та з усіма недоліками, і весь ризик, пов’язаний з такою інформацією, повністю несе Покупець. Microsemi не надає, явно чи неявно, жодній стороні будь-які патентні права, ліцензії чи будь-які інші права інтелектуальної власності, що стосується самої такої інформації чи будь-чого, що описується такою інформацією. Інформація, представлена ​​в цьому документі, є власністю Microsemi, і Microsemi залишає за собою право вносити будь-які зміни в інформацію в цьому документі або в будь-які продукти та послуги в будь-який час без попередження.
Microsemi, дочірня компанія, що повністю належить Microchip Technology Inc. (Nasdaq: MCHP), пропонує повний асортимент напівпровідникових і системних рішень для аерокосмічної та оборонної промисловості, комунікацій, центрів обробки даних і промислових ринків. Продукти включають високоефективні та радіаційно захищені аналогові інтегральні схеми зі змішаними сигналами, FPGA, SoC та ASIC; продукти керування живленням; пристрої хронометражу та синхронізації та рішення точного часу, що встановлює світовий стандарт часу; пристрої обробки голосу; радіочастотні рішення; дискретні компоненти; корпоративні рішення для зберігання та зв'язку; технології безпеки та масштабована антитamper продукти; рішення Ethernet; Інтегральні схеми та проміжні панелі Power-over-Ethernet; а також можливості та послуги індивідуального дизайну. Штаб-квартира Microsemi розташована в Алісо-В’єхо, штат Каліфорнія, і налічує близько 4,800 співробітників по всьому світу. Дізнайтесь більше на www.microsemi.com.

Штаб Microsemi
One Enterprise, Алісо В'єхо,
CA 92656 США
У межах США: +1 800-713-4113
За межами США: +1 949-380-6100
Продажі: +1 949-380-6136
Факс: +1 949-215-4996
Електронна пошта: продажі.support@microsemi.com
www.microsemi.com
© 2018 Microsemi. Всі права захищені. Microsemi та логотип Microsemi
є товарними знаками Microsemi Corporation. Усі інші торгові марки та послуги
знаки є власністю відповідних власників.

Документи / Ресурси

Симуляція системних служб Microsemi UG0837 IGLOO2 та SmartFusion2 FPGA [pdfПосібник користувача UG0837, UG0837 Моделювання системних сервісів IGLOO2 та SmartFusion2 FPGA, моделювання системних сервісів IGLOO2 та SmartFusion2 FPGA, моделювання системних сервісів SmartFusion2 FPGA, моделювання системних сервісів FPGA, моделювання сервісів

Список літератури

• Посібник користувача