Author Topic: RISC-V microcontrollers from GigaDevice  (Read 8570 times)

0 Members and 1 Guest are viewing this topic.

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1113
  • Country: fi
Re: RISC-V microcontrollers from GigaDevice
« Reply #75 on: November 25, 2019, 03:24:00 pm »
Quote
"this J-Link does not support RISCV over JTAG"You need J-Link HW version 10+ unfortunately.
What?  Why?  I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?
Two options come to mind: The J-Link dongles are supposed to contain some smarts, which needs device-specific support. IIRC the MCU in the revision 10 is significantly more capable than in the previous version, so it's possible they just ran out of space. The more sinister possibility is forcing a wave of hardware upgrades ahead of the Next Big Thing.

Offline coppice

  • Super Contributor
  • ***
  • Posts: 5055
  • Country: gb
Re: RISC-V microcontrollers from GigaDevice
« Reply #76 on: November 25, 2019, 04:11:58 pm »
Quote
"this J-Link does not support RISCV over JTAG"You need J-Link HW version 10+ unfortunately.
What?  Why?  I thought JTAG was JTAG, and it was only a matter of software whether you could program a given device?
Two options come to mind: The J-Link dongles are supposed to contain some smarts, which needs device-specific support. IIRC the MCU in the revision 10 is significantly more capable than in the previous version, so it's possible they just ran out of space. The more sinister possibility is forcing a wave of hardware upgrades ahead of the Next Big Thing.
J-Link is a rather deceptive name. It implies a single product when it was actually been a succession of products, several of which have obsoleted the previous ones for many users.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 327
Re: RISC-V microcontrollers from GigaDevice
« Reply #77 on: November 25, 2019, 06:57:19 pm »
The list of compatible devices list the altera usb blaster, something I also have. I'll try with that and report back. If only this Platformio wouldn't what to install itself every time I run it...
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 327
Re: RISC-V microcontrollers from GigaDevice
« Reply #78 on: December 10, 2019, 06:53:23 pm »
The altera usb blaster didn't work either. In the mean time I ordered two of this sipeed rv debuggers and they showed up today.
After switching the driver from ftdi to winusb using Zadig, the adaptor was recognized and the chip programmed:
Code: [Select]
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.html
PLATFORM: GigaDevice GD32V 1.0.0 > Sipeed Longan Nano
HARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB Flash
DEBUG: Current (sipeed-rv-debugger) External (altera-usb-blaster, gd-link, jlink, sipeed-rv-debugger, um232h)
PACKAGES: framework-gd32vf103-sdk 1.0.0, tool-openocd-gd32v 0.1.1, tool-gd32vflash 0.1.0, toolchain-gd32v 9.2.0
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio\build\sipeed-longan-nano\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
DATA:    [=         ]   7.0% (used 2300 bytes from 32768 bytes)
PROGRAM: [          ]   1.9% (used 2530 bytes from 131072 bytes)
Configuring upload protocol...
AVAILABLE: altera-usb-blaster, gd-link, jlink, serial, sipeed-rv-debugger, um232h
CURRENT: upload_protocol = sipeed-rv-debugger
Uploading .pio\build\sipeed-longan-nano\firmware.elf
GNU MCU Eclipse OpenOCD, 64-bitOpen On-Chip Debugger 0.10.0+dev-00593-g23ad80df4-dirty (2019-06-18-08:21)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Transport "jtag" was already selected
jtag
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"
Warn : Bypassing JTAG setup events due to errors
Info : datacount=4 progbufsize=2
Info : Exposing additional CSR 3040
Info : Exposing additional CSR 3041
Info : Exposing additional CSR 3042
Info : Exposing additional CSR 3043
Info : Exposing additional CSR 3044
Info : Exposing additional CSR 3045
Info : Exposing additional CSR 3046
Info : Exposing additional CSR 3047
Info : Exposing additional CSR 3048
Info : Exposing additional CSR 3049
Info : Exposing additional CSR 3050
Info : Exposing additional CSR 3051
Info : Exposing additional CSR 3052
Info : Exposing additional CSR 3053
Info : Exposing additional CSR 3054
Info : Exposing additional CSR 3055
Info : Exposing additional CSR 3056
Info : Exposing additional CSR 3057
Info : Exposing additional CSR 3058
Info : Exposing additional CSR 3059
Info : Exposing additional CSR 3060
Info : Exposing additional CSR 3061
Info : Exposing additional CSR 3062
Info : Exposing additional CSR 3063
Info : Exposing additional CSR 3064
Info : Exposing additional CSR 3065
Info : Exposing additional CSR 3066
Info : Exposing additional CSR 3067
Info : Exposing additional CSR 3068
Info : Exposing additional CSR 3069
Info : Exposing additional CSR 3070
Info : Exposing additional CSR 3071
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40901105
Info : Listening on port 3333 for gdb connections
Info : device id = 0x19060410
Info : flash_size_in_kb = 0x00000040
Info : flash size = 64kbytes
cleared protection for sectors 0 through 63 on flash bank 0
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
** Programming Started **
auto erase enabled
wrote 3072 bytes from file .pio\build\sipeed-longan-nano\firmware.elf in 1.622513s (1.849 KiB/s)
** Programming Finished **
** Verify Started **
verified 2548 bytes in 0.176993s (14.059 KiB/s)
** Verified OK **
Info : Hart 0 unexpectedly reset!
Info : Note: Hart is halted due to the halt-on-reset bit is set,please continue your  program by appropriate debugger commands or operations!!


The test code doesn't run but at least, it programmed :).
 

Offline wnorcott

  • Regular Contributor
  • *
  • Posts: 98
  • Country: us
  • I like making projects with the ESP32
Re: RISC-V microcontrollers from GigaDevice
« Reply #79 on: December 10, 2019, 09:22:51 pm »
I have one of the Sipeed RV debuggers too.  You can also with a spare Sipeed Longan Nano board, burn the firmware so it becomes a debugger for other Longan Nano boards, using the JTAG header already on the board.  Just need a ribbon cable to connect the two.    That method is supported by PlatformIO too for the Longan Nano board.
On very rare occasions, you might notice an odor or see a puff of smoke or sparks vent from your product.
 

Offline techman-001

  • Frequent Contributor
  • **
  • Posts: 611
  • Country: au
  • Electronics technician for the last 47 years
Re: RISC-V microcontrollers from GigaDevice
« Reply #80 on: January 24, 2020, 03:11:02 am »
here is link of datasheet and SDK
Bumblebee_Core_Doc

GD32VF103_User_Manual_EN_V1.0.pdf 
GD32VF103_Datasheet_Rev1.0.pdf

Literature package for GD32VF103: https://sourceforge.net/projects/mecrisp/files/Target%20literature%20package%20for%20GD32VF103.tar.gz  (25.0 MB)

├── Bumblebee\ Core\ Architecture\ Manual.pdf
├── Bumblebee\ Core\ Brief\ Manual.pdf
├── GD32VF103C-START-V1.0.pdf
├── GD32VF103_Datasheet_Rev\ 1.1.pdf
├── GD32VF103_User_Manual_EN_V1.2.pdf
├── Longan\ Nano\ Pinout.png
├── Longan\ Nano\ Pinout.svg
├── Longan\ nano\ 2663(Assembly\ drawing).pdf
├── Longan\ nano\ 2663(Schematic).pdf
├── RISCVGreenCardv8-20151013.pdf
├── STM32F103\ Reference\ Manual.pdf
├── STM32F103.pdf
├── riscv-privileged-20190608-1.pdf
├── riscv-spec.pdf
└── tool-gd32vflash-v0.1.0-linux.tar.gz

Offline techman-001

  • Frequent Contributor
  • **
  • Posts: 611
  • Country: au
  • Electronics technician for the last 47 years
Re: RISC-V microcontrollers from GigaDevice
« Reply #81 on: January 24, 2020, 04:42:58 am »
https://www.cnx-software.com/2019/08/23/gigadevice-gd32v-risc-v-mcu-development-board/amp/

The new GD32VF103 series RISC-V MCU family features 14 models with the following key specifications:

Core – GD32VF103 RISC-V “Bumblebee Core” @ 108 MHz
Memory – 8KB to 16KB SRAM
Storage  – 16KB to 128KB flash
Peripherals – USB OTG and CAN 2.0B
I/O – 3.3V, 5V tolerant
Supply Voltage – 2.6 to 3.6V
Package – QFN36, LQFP48, LQFP64, and LQFP100 packages

May be pin compatible with STM32F100 series.

As many now know, GD have made their own STM32F10x 'compatible'  peripherals and the pinouts of the 64 pin flatpack are compatible between GD and STM.

I've made up a (ongoing) page comparing the peripherals of two chips and some other details : https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103-vs-gd32vf103.html

One current issue I'm trying to resolve is resetting the peripherals to default with a software command.

I can find no reference to SYSRESETREQ in the GD literature other than the reset-logic pic in the GD32VF103 User Manual V1.2 PDF which I suspect is just  paste from the GD32F103 PDF. What this means is there seems to be no simple way to reset all the GD32VF103 peripherals to power-up-defaults as can be done on STM32.

This is achieved in the GD32VF103 sample factory code using a long list of individual peripheral register resets but I'm after a simple method as with the STM32F10x.

Does anyone have any experience with this issue and the GD32VF103 ?
 
The following users thanked this post: abraxalito, thm_w, edavid

Offline hansd

  • Contributor
  • Posts: 14
  • Country: au
Re: RISC-V microcontrollers from GigaDevice
« Reply #82 on: January 24, 2020, 09:15:46 am »
A system reset
is generated by the following events:
 A power reset (POWER_RSTn).
 An external pin reset (NRST).
 A window watchdog timer reset (WWDGT_RSTn).
 A free watchdog timer reset (FWDGT_RSTn).
 The SYSRESETREQ bit in RISC-V Application Interrupt and Reset Control Register is set (SW_RSTn).
 Reset generated when entering Standby mode when resetting nRST_STDBY bit in User Option Bytes (OB_STDBY_RSTn).
 Reset generated when entering Deep-sleep mode when resetting nRST_DPSLP bit in User Option Bytes (OB_DPSLP_RSTn).
A system reset resets the processor core and peripheral IP components except for the JTAG
controller and the Backup domain.

Page 61 GD32VF103_User_Manual_EN_V1.2 from https://gd32mcu.21ic.com/en/index

I hope this helps.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 327
Re: RISC-V microcontrollers from GigaDevice
« Reply #83 on: February 13, 2020, 07:39:51 pm »
Have someone made any progress on linux, with platformio and a spipeed-rv-debugger ?. I have the latest packages from platform io (1.1.2) fot the gigadevices chips but still no dice regarding programming. Maybe the example code doesn't work. Here what I get in the console after "upload":

Code: [Select]
Processing sipeed-longan-nano (platform: gd32v; framework: gd32vf103-sdk; board: sipeed-longan-nano)
------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: [url]https://docs.platformio.org/page/boards/gd32v/sipeed-longan-nano.html[/url]
PLATFORM: GigaDevice GD32V 1.1.2 > Sipeed Longan Nano
HARDWARE: GD32VF103CBT6 108MHz, 32KB RAM, 128KB Flash
DEBUG: Current (sipeed-rv-debugger) External (altera-usb-blaster, gd-link, jlink, rv-link, sipeed-rv-debugger, um232h)
PACKAGES: framework-gd32vf103-sdk 1.0.0, tool-openocd-gd32v 0.1.1, tool-gd32vflash 0.1.0, toolchain-gd32v 9.2.0
LDF: Library Dependency Finder -> [url]http://bit.ly/configure-pio-ldf[/url]
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 0 compatible libraries
Scanning dependencies...
No dependencies
Building in release mode
Checking size .pio/build/sipeed-longan-nano/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
DATA:    [=         ]   7.0% (used 2310 bytes from 32768 bytes)
PROGRAM: [=         ]   5.0% (used 6572 bytes from 131072 bytes)
Configuring upload protocol...
AVAILABLE: altera-usb-blaster, gd-link, jlink, rv-link, serial, sipeed-rv-debugger, um232h
CURRENT: upload_protocol = sipeed-rv-debugger
Uploading .pio/build/sipeed-longan-nano/firmware.elf
Open On-Chip Debugger 0.10.0+dev-00911-gcfbca74bd (2019-09-12-09:31)
Licensed under GNU GPL v2
For bug reports, read
        [url]http://openocd.org/doc/doxygen/bugs.html[/url]
Warn : Transport "jtag" was already selected
jtag
adapter speed: 1000 kHz

Info : clock speed 1000 kHz
Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Warn : JTAG tap: riscv.cpu       UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Error: JTAG tap: riscv.cpu  expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3"
Warn : Bypassing JTAG setup events due to errors
Info : datacount=4 progbufsize=2
Info : Exposing additional CSR 3040
Info : Exposing additional CSR 3041
Info : Exposing additional CSR 3042
Info : Exposing additional CSR 3043
Info : Exposing additional CSR 3044
Info : Exposing additional CSR 3045
Info : Exposing additional CSR 3046
Info : Exposing additional CSR 3047
Info : Exposing additional CSR 3048
Info : Exposing additional CSR 3049
Info : Exposing additional CSR 3050
Info : Exposing additional CSR 3051
Info : Exposing additional CSR 3052
Info : Exposing additional CSR 3053
Info : Exposing additional CSR 3054
Info : Exposing additional CSR 3055
Info : Exposing additional CSR 3056
Info : Exposing additional CSR 3057
Info : Exposing additional CSR 3058
Info : Exposing additional CSR 3059
Info : Exposing additional CSR 3060
Info : Exposing additional CSR 3061
Info : Exposing additional CSR 3062
Info : Exposing additional CSR 3063
Info : Exposing additional CSR 3064
Info : Exposing additional CSR 3065
Info : Exposing additional CSR 3066
Info : Exposing additional CSR 3067
Info : Exposing additional CSR 3068
Info : Exposing additional CSR 3069
Info : Exposing additional CSR 3070
Info : Exposing additional CSR 3071
Info : Examined RISC-V core; found 1 harts
Info :  hart 0: XLEN=32, misa=0x40901105
Info : Listening on port 3333 for gdb connections
Info : device id = 0x19060410
Info : flash_size_in_kb = 0x00000040
Info : flash size = 64kbytes
Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Warn : JTAG tap: riscv.cpu       UNEXPECTED: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1)
Error: JTAG tap: riscv.cpu  expected 1 of 1: 0x1e200a6d (mfg: 0x536 (Nuclei System Technology Co.,Ltd.), part: 0xe200, ver: 0x1)
Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
** Programming Started **
** Programming Finished **
** Verify Started **
** Verified OK **
Info : Hart 0 unexpectedly reset!

*** [upload] Error 1
============================ [FAILED] Took 3.07 seconds ============================


And the blinky doesn't blink.

(Note: On another computer, with another longan nano, with a jlink 10.1, with embedded studio for RISCV, blinky works).
I'll try my board on segger's IDE with a Jlink 10.1.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 327
Re: RISC-V microcontrollers from GigaDevice
« Reply #84 on: February 14, 2020, 06:30:29 pm »
 :palm: I found the problem(s):

The devices I have have the GD32F103C8T6. Advertised where GD32VF108CBT6. Note the number eight after the C and the letter B. The '8' means 64 kBytes Flash and 20 kBytes RAM. The 'B' means 128 kBytes Flash and 32 kBytes RAM.

With the Segger Studio, changing between the two is not a problem two executable files will be generated with different RAM sizes, each works on the correct device (I got a CB board for testing purposes).

On the PlatformIO side, I can choose the device, compile and upload seem to work but I still get the exception... more digging is necessary.



 

Offline lundmar

  • Frequent Contributor
  • **
  • Posts: 354
  • Country: dk
Re: RISC-V microcontrollers from GigaDevice
« Reply #85 on: February 15, 2020, 11:00:20 am »
Hi guys,

For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo: https://github.com/lundmar/riscv-gd32vf103-demo

This is the first time I get hands on with a RISC-V chip and I was curious to see how it compares to ARM, in particular concerning the required boot code. I've created a demo software that includes the simplest possible boot code to get a single threaded system running including the Newlib C library and the GD32VF103 driver library.

Simply install the appropriate RISC-V toolchain via crosstool-ng and you will be able to compile the demo software.
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple TTY terminal I/O application
http://dc-power-supply.github.io - OSHW DC power supply project
 
The following users thanked this post: ralphrmartin, knapik

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1339
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: RISC-V microcontrollers from GigaDevice
« Reply #86 on: February 15, 2020, 02:05:42 pm »
For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo: https://github.com/lundmar/riscv-gd32vf103-demo

Looks good!

My only quibble is that both your readme and the makefile say rv32ima while the Bumblebee core actually implements rv32imac. That will work fine, but you're missing out on saving typically 25% to 30% in program size (i.e. getting 35% to 40% more program code into a ROM of a given size) by using the optional 16 bit "C" opcodes.

I also dislike overly-abstracted code, so it's great to have this and I'll try it on my Longan Nano soon. But I have an ATtiny85 project to do first :-)
 

Offline lundmar

  • Frequent Contributor
  • **
  • Posts: 354
  • Country: dk
Re: RISC-V microcontrollers from GigaDevice
« Reply #87 on: February 15, 2020, 05:11:50 pm »
For those who want to get started with the GD32VF103 chip in the most simplest way, have a look at my github repo: https://github.com/lundmar/riscv-gd32vf103-demo

Looks good!

My only quibble is that both your readme and the makefile say rv32ima while the Bumblebee core actually implements rv32imac. That will work fine, but you're missing out on saving typically 25% to 30% in program size (i.e. getting 35% to 40% more program code into a ROM of a given size) by using the optional 16 bit "C" opcodes.

I also dislike overly-abstracted code, so it's great to have this and I'll try it on my Longan Nano soon. But I have an ATtiny85 project to do first :-)

My good sir, you are of course correct. I will not tolerate such quibbles on your mind! :)

Let's go full feature and use the compressed ISA instead - I have updated the repository and the binary output file is now precisely 13.8% smaller (.text size went down 14.7%).

The only reason I left it at "ima" was that I wanted the pure 32-bit experience for my first meet with the RISC-V ISA :)

Also, my own quibbles or disappointment with the GD32VF103 aka Bumblebee core is that it does not implement mtvec.mode = 0x3 which allows for the vector table to be implemented in pure C by pointer functions (hw will jump to addresses instead of executing jump instructions), in the same way many cortex-M does it. This is an optional feature of the RISC-V standard and I believe that RISC-V chips such as the SiFive one implements it. You may notice that I have left code implementation for both ways.
« Last Edit: February 15, 2020, 05:21:11 pm by lundmar »
https://lxi-tools.github.io - Open source LXI tools
https://tio.github.io - A simple TTY terminal I/O application
http://dc-power-supply.github.io - OSHW DC power supply project
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1339
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: RISC-V microcontrollers from GigaDevice
« Reply #88 on: February 15, 2020, 08:41:19 pm »
Let's go full feature and use the compressed ISA instead - I have updated the repository and the binary output file is now precisely 13.8% smaller (.text size went down 14.7%).

I'm guessing this program is sooo small it's dominated by the table of interrupt vectors.

Quote
The only reason I left it at "ima" was that I wanted the pure 32-bit experience for my first meet with the RISC-V ISA :)

A perfectly good reason.

Quote
Also, my own quibbles or disappointment with the GD32VF103 aka Bumblebee core is that it does not implement mtvec.mode = 0x3 which allows for the vector table to be implemented in pure C by pointer functions (hw will jump to addresses instead of executing jump instructions), in the same way many cortex-M does it. This is an optional feature of the RISC-V standard and I believe that RISC-V chips such as the SiFive one implements it. You may notice that I have left code implementation for both ways.

Meh. Jump instructions as interrupt/trap vectors saves a fair bit of complexity in the implementation, especially on something that doesn't otherwise have an indirect addressing mode (as RISCs don't). And it works fine as long as you can put all the service routines within 1 MB of the vector table.

I tend to prefer using a single handler function that does the bookkeeping such as saving registers inline and then uses a regular C switch or table of function pointers to choose the handler. You can also preprocess the trap number to avoid having a few dozen pointers to the default "wtf?" handler.

It makes very little difference in speed either way.
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 3125
  • Country: us
Re: RISC-V microcontrollers from GigaDevice
« Reply #89 on: February 16, 2020, 04:40:29 am »
Is the interrupt mechanism considered part of the ISA, or part of the implementation for a RISC-V processor?I guess for ARM Cortex the NVIC is considered part of the core that is external to the CPU, but they seem sometimes-depressingly tightly coupled and non-RISCy.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 1339
  • Country: us
  • Formerly SiFive, Samsung R&D
Re: RISC-V microcontrollers from GigaDevice
« Reply #90 on: February 16, 2020, 07:19:40 am »
Is the interrupt mechanism considered part of the ISA, or part of the implementation for a RISC-V processor?I guess for ARM Cortex the NVIC is considered part of the core that is external to the CPU, but they seem sometimes-depressingly tightly coupled and non-RISCy.

I'll say "part of the ISA, but optional".

The standard privileged architecture specifies a basic interrupt handler that must be present, though it has optional features. Each privilege level that supports handling interrupts (M, S if it exists, U if it exists and the "N" extension is implemented) has a set of interrupt registers including the PC to return to, the exception cause, the exception data, and exception handler base address.

The exception handler base address is constrained to be a multiple of 4, and the bottom two bits indicate the mode. Mode 00 means all exceptions go to a single handler located at baseAddress. Mode 01 means synchronous exceptions (system call, illegal instruction, illegal memory access etc) go to baseAddress while interrupts go to baseAddress plus 4 * interrupt number, where you will normally put a jump instruction to the actual handler. Modes 10 and 11 are reserved.

An implementation can choose to support only mode 00, only mode 01, or both modes. An implementation can choose to use a fixed base address, or allow the user to set it. As usual in RISC-V you find the capabilities by trying to write what you want to the CSR then read it back and see if you get back the same thing you tried to write.

The proposed "Fast interrupts extension" aka CLIC (Core Local Interrupt Controller) uses mode 11. This mode loads a pointer to the handler from baseAddress plus 4 * interrupt number or 8 * interrupt number (64 bit systems). Another mechanism allows to specify (with a bitmap) for each interrupt individually whether it will use its own vector or a common handler at interrupt vector 0.


There is a whole lot more detail, far too much to go into here. If interested then read the specifications on github :-)

Embedded software might be written to expect and need one particular interrupt controller mode. The Linux kernel will I believe work fine as long as at least one of modes 00, 01, or 11 is implemented.

The very simplest implementations can support a single exception handler function at at fixed address (0, for example), and call themselves compatible with the RISC-V Privileged ISA, and things will work. The Linux kernel for example can discover that only mode 00 is supported, and can read back the fixed interrupt handler address from the CSR. Supporting higher modes can require a bit more hardware but provide higher performance.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf