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

0 Members and 1 Guest are viewing this topic.

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #75 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 #76 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: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: RISC-V microcontrollers from GigaDevice
« Reply #77 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
 
The following users thanked this post: I wanted a rude username

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: RISC-V microcontrollers from GigaDevice
« Reply #78 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: 32
  • Country: au
Re: RISC-V microcontrollers from GigaDevice
« Reply #79 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: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #80 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: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #81 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: 436
  • Country: dk
Re: RISC-V microcontrollers from GigaDevice
« Reply #82 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 serial device I/O tool
 
The following users thanked this post: ralphrmartin, knapik

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #83 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: 436
  • Country: dk
Re: RISC-V microcontrollers from GigaDevice
« Reply #84 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 serial device I/O tool
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #85 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.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: RISC-V microcontrollers from GigaDevice
« Reply #86 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: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #87 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.
 
The following users thanked this post: chickenHeadKnob, I wanted a rude username

Online Noopy

  • Super Contributor
  • ***
  • Posts: 1739
  • Country: de
    • Richis-Lab
Re: RISC-V microcontrollers from GigaDevice
« Reply #88 on: April 21, 2020, 05:23:59 pm »

Hi all,


I have die pictures of the GD32VF103 for you:


https://richis-lab.de/STM32_10.htm






There also is a flash die on top of the controller.
It´s similar but smaller than the flash in the GD32F103:
https://richis-lab.de/STM32_06.htm
I assume they put the kind of flash die in the package they have around at this time.




"CHICAGO"?  :-//




POWER!  MORE POWER!  ;D

 :popcorn:
 
The following users thanked this post: thm_w, iMo, techman-001, I wanted a rude username

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #89 on: April 22, 2020, 04:49:57 am »
I was wondering about this. That means that executes from RAM the same way the GS32F103 does. Now we need some benchmarks !! And a way to unlock the extra SRAM.

Danke Noopy !
 

Offline GromBeestje

  • Frequent Contributor
  • **
  • Posts: 280
  • Country: nl
Re: RISC-V microcontrollers from GigaDevice
« Reply #90 on: April 22, 2020, 07:47:43 am »
Has anyone ever succeeded unlocking any RAM in the GD32F10x? Back in the day there was some speculation, but I've never seen a continuation of this.
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #91 on: April 26, 2020, 08:08:13 am »
I have been wondering a while about this flash/sram concept that the GD32VF103 seems to use. Starting with the blinky test created by platformio, I modified the code to test the throughput of the processor.

At least for code around ~1024 bytes, there seems to be no penalties, what makes me think that maybe the code is really loaded into SRAM, I mean, the whole code. That could only be tested with a larger function. I saw in one of the threads about the GD32F103 that the flash is loaded into a cache. So you see the load process when a new cache line has to be filled. I do not see this here, yeah, the code is a bit simple. In a x86, similar code exposes the memory architecture thus I tried a similar approach here...

Code: [Select]
RiscV GD32VF103 Instruction throughput tests:

GPIOC 13 LED, test pin
CPU Clock 108 MHz (default setting). 9.52 ns/clock

Code

static void __attribute__((noinline, naked)) main_loop_15MHz( void )
{
    asm volatile(
        "   lui     a5, 0x40011 \n\t" // GPIOC
        "   addi    a3, a5, 16  \n\t"
        "   lui     a4, 0x2     \n\t"
        "1:                     \n\t"
        "   sw      a4, 20(a5)  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   sw      a4, 16(a5)  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   j       1b          \n\t"
   
    );
}
Tek0000.csv

Signal freqnecy 15.49 MHz
High width 47.20 ns - 2 opcodes + jump
Low width 17.68 ns - 2 opcodes

trying to match the jump width
------------------------------

30 ns ~ 3 clocks at 108 Mhz

static void __attribute__((noinline, naked)) main_loop_10MHz( void )
{
    asm volatile(
        "   lui     a5, 0x40011 \n\t" // GPIOC
        "   addi    a3, a5, 16  \n\t"
        "   lui     a4, 0x2     \n\t"
        "1:                     \n\t"
        "   sw      a4, 20(a5)  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   sw      a4, 16(a5)  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   j       1b          \n\t"
   
    );
}

Match !
Tek0001.csv

Signal freqnecy 10.89 MHz
High width 46.9 ns - 2 opcodes + jump
Low width 45.8 ns - 2 opcodes

The low pulse is consistently 1 ns shorter as the high pulse
The addi opcodes are 32 bit opcodes, it seems that there is no
difference between the width of the opcodes and the execution
time. Using the same target register seems to not impose
any penalties.

Check for chache line size, go for > 64 byte code
-------------------------------------------------

static void __attribute__((noinline, naked)) main_loop( void )
{
    asm volatile(
        "   lui     a5, 0x40011 \n\t" // GPIOC
        "   addi    a3, a5, 16  \n\t"
        "   lui     a4, 0x2     \n\t"
        "1:                     \n\t"
        "   sw      a4, 20(a5)  \n\t" // low
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   sw      a4, 16(a5)  \n\t" // high
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   j       1b          \n\t"
   
    );
}

Tek0002.csv

Signal freqnecy 4.156 MHz
High width 121.2 ns - 11 opcodes + jump (+2) // 9.32 ns/opcode
Low width 120.7 ns - 13 opcodes = ~ 9.28 ns/opcode

No cache line fill detected

Try longer code > 128 bytes
---------------------------

static void __attribute__((noinline, naked)) main_loop( void )
{
    asm volatile(
        "   lui     a5, 0x40011 \n\t" // GPIOC
        "   addi    a3, a5, 16  \n\t"
        "   lui     a4, 0x2     \n\t"
        "1:                     \n\t"
        "   sw      a4, 20(a5)  \n\t" // low
        "   addi    a3, a5, 16  \n\t" // 44 times !
        "   sw      a4, 16(a5)  \n\t" // high
        "   addi    a3, a5, 16  \n\t" // 42 times
        "   j       1b          \n\t"
   
    );
}

Tek0003.csv
44e - 2f6 = 344 bytes
Signal freqnecy 1.200 MHz
High width 417.6 ns - 43 opcodes + jump (+2) // 9.28 ns/opcode
Low width 415.8 ns - 45 opcodes = ~ 9,24 ns/opcode


Try longer code > 1024 bytes
---------------------------

static void __attribute__((noinline, naked)) main_loop( void )
{
    asm volatile(
        "   lui     a5, 0x40011 \n\t" // GPIOC
        "   addi    a3, a5, 16  \n\t"
        "   lui     a4, 0x2     \n\t"
        "1:                     \n\t"
        "   sw      a4, 20(a5)  \n\t" // low

        "   addi    a3, a5, 16  \n\t" // ** 172 times !
       
        "   sw      a4, 16(a5)  \n\t" // high
       
        "   addi    a3, a5, 16  \n\t" // ** 170 times
       
        "   j       1b          \n\t"
   
    );
}

Tek0004.csv
84e - 2f6 = 1368 bytes
Signal freqnecy 312.2 kHz
High width 1602 ns - 171 opcodes + jump (+2) // 9.28 ns/opcode
Low width  1601 ns - 173 opcodes = ~ 9,25 ns/opcode



The Binky code is then:

Code: [Select]
/*!
    \file  main.c
    \brief running led
   
    \version 2019-6-5, V1.0.0, firmware for GD32VF103
*/

/*
    Copyright (c) 2019, GigaDevice Semiconductor Inc.

    Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

    1. Redistributions of source code must retain the above copyright notice, this
       list of conditions and the following disclaimer.
    2. Redistributions in binary form must reproduce the above copyright notice,
       this list of conditions and the following disclaimer in the documentation
       and/or other materials provided with the distribution.
    3. Neither the name of the copyright holder nor the names of its contributors
       may be used to endorse or promote products derived from this software without
       specific prior written permission.

    THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE.
*/

#include "gd32vf103.h"
#include "systick.h"
#include <stdio.h>

/* BUILTIN LED OF LONGAN BOARDS IS PIN PC13 */
#define LED_PIN GPIO_PIN_13
#define LED_GPIO_PORT GPIOC
#define LED_GPIO_CLK RCU_GPIOC

static void main_loop( void );

void longan_led_init()
{
    /* enable the led clock */
    rcu_periph_clock_enable(RCU_GPIOA);
    /* configure led GPIO port */
    gpio_init(GPIOA, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_1);

    GPIO_BC(GPIOA) = GPIO_PIN_1;
    gpio_init(GPIOA, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, GPIO_PIN_2);

    GPIO_BC(GPIOA) = GPIO_PIN_2;
    /* enable the led clock */
    rcu_periph_clock_enable(LED_GPIO_CLK);
    /* configure led GPIO port */
    gpio_init(LED_GPIO_PORT, GPIO_MODE_OUT_PP, GPIO_OSPEED_50MHZ, LED_PIN);

    GPIO_BC(LED_GPIO_PORT) = LED_PIN;

}

void longan_led_on()
{
    GPIO_BOP(LED_GPIO_PORT) = LED_PIN;
}

void longan_led_off()
{
    GPIO_BC(LED_GPIO_PORT) = LED_PIN;
}
/*!
    \brief      main function
    \param[in]  none
    \param[out] none
    \retval     none
*/
int main(void)
{
    longan_led_init();
    main_loop();
}

// and here paste one of the main_loop functions
[code]
« Last Edit: April 26, 2020, 08:11:35 am by ale500 »
 
The following users thanked this post: thm_w

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #92 on: April 26, 2020, 08:38:14 am »
Interesting investigation, thanks!

I've got a few Longan Nano boards (at $4.90 each plus $50 shipping might as well get more than one) but didn't find a chance to play with them yet.

You're never going to detect cache lines by making the code bigger than a cache line -- you have to make it bigger than the entire cache.

However, the datasheet...

https://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_Datasheet_Rev1.0.pdf

... says it read program code directly from flash with no wait states.

That's probably what limits it to 108 MHz. I'm sure the rest of it could go faster.

Interesting that it seems every taken branch uses 3 clock cycles i.e. a pipeline flush.

So, no cache, no branch prediction.

Sadly there is no information about instruction timing in the datasheet.

If would be interesting to see if a conditional branch for the loop takes the same time as the Jump. The timing on JALR (e.g. function return) would also be interesting. Are shift all single-cycle regardless of the shift count?
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #93 on: April 26, 2020, 08:55:35 am »
May be the wording on my part was poorly selected.  You are right, of course.

What the datasheet says, regarding the flash can be ignored. We know it is being serially loaded. The question I wanted answered was if the whole flash gets mirrored or not. And if not how big is the "cache". It seems to be bigger than 8 kBytes. The code crosses now the first 4 kbytes boundary and doesn't seem to expose any loading latency (I extended the function to ~ 3.4 kBytes and crosses the 4 kbytes boundary. Most probably it is loaded completely. That means that there are some "hidden" registers that make the mirror SRAM writable. And some hidden ROM too. It would have been nice to see to which pins the flash was connected to guess on the interface type, the EXTI doesn't support serial memories. Now that I think of it, it doesn't support QPI either, so it is probably just SPI.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #94 on: April 26, 2020, 09:16:26 am »
What the datasheet says, regarding the flash can be ignored. We know it is being serially loaded.

How do we know it is being serially loaded?

The datasheet says there is an AHB bus to the flash. In fact it says there are two AHB ports to the flash, one for the address, one for the data. All the other peripherals, including the main SRAM memory are on a 3rd "system" AHB bus.

Why do you think they are lying?
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #95 on: April 26, 2020, 09:58:56 am »
I suggest you read up on "Parallel NOR Flash". For example https://www.cypress.com/file/202491/download

I see the sequential access time there is 9 ns. What's the clock cycle time on the GD32VF103? 9 ns. Interesting.

Note that the main business of GigaDevice is making and selling flash memory. Microcontrollers are somewhat of a side-line. I'm sure they can make flash as well as Cypress can.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #96 on: April 26, 2020, 10:24:13 am »
So, there is 128k of program memory, right? That's 1 M bits. Likely arranged in a 1024x1024 array, with a 1024 bit (128 byte) row buffer. Say it takes 18 ns to read a row into the buffer but then 9 ns to read something else from the same row. And the bus back to the CPU is 32 bits wide.

If you're running code sequentially, or even jumping around in the same 128 bytes then you get 9 ns access.

When you cross or jump to a new row (whether random or sequential) you get a 18 ns access instead of 9 ns.

So your test with 345 instructions and 1376 bytes in the loop is going to cross row boundaries 10 times, plus the jump. So 334 instructions will take 9 ns and 11 instructions will take 18 ns. Total 3204 ns or 9.287 ns per instruction on average.

3204 ns per loop is 1e9/3204 = 312.11kHz.

Is that compatible with what you're seeing?

YES
 

Offline ale500

  • Frequent Contributor
  • **
  • Posts: 415
Re: RISC-V microcontrollers from GigaDevice
« Reply #97 on: April 26, 2020, 12:22:01 pm »
I understand what you mean, but, if you look at the picture Noopy posted, most likely a flash, like in the GD32F103, is in an extra die that only has 10 pins. Meaning, even with a hyperbus or similar you are several clocks away from 32 bits of data.
If they had flash on die then what you say would apply, no discussion. Before Noopy posted the picture I thought we had a flash on die.
Let's say I'm mistaken, I have another idea: the RiscV core used has instructions and cycle counters.

Let's extend the test and use these counters. This is getting very interesting !

Edit:

Something with the counters doesn't seem to work, I read the same values before and after some instructions:
I get 0x00003171 for the cycles counter and 0x000021B0 for the instret counter, both times.

Code: [Select]
static void __attribute__((noinline, naked)) main_loop( uint32_t *countersptr )
{
    asm volatile(
        "   rdcycle a5          \n\t"
        "   sw      a5, 0(a0)   \n\t"
        "   rdinstret a5        \n\t"
        "   sw      a5, 4(a0)   \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   rdcycle a5          \n\t"
        "   sw      a5, 20(a0)   \n\t"
        "   rdinstret a5        \n\t"
        "   sw      a5, 24(a0)   \n\t"

        "   lui     a5, 0x40011 \n\t" // GPIOC
        "   addi    a3, a5, 16  \n\t"
        "   lui     a4, 0x2     \n\t"
        "1:                     \n\t"
        "   sw      a4, 20(a5)  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   sw      a4, 16(a5)  \n\t"
        "   addi    a3, a5, 16  \n\t"
        "   j       1b          \n\t"
    );
}


Edit: The simple solution seems to fail. The counters are disabled.

After enabling the counters I get:
There are 35 instructions between both rdcycle and rdinstret.

Cycles before 0x4769, after 0x478e, diff : 37
Intructions retired before 0x32ba, after 0x32de, diff : 36

The last store word doesn't get count.

I think that it executes from some very fast memory without any wait states. (unless they do not count as cycles, what seems improbable given previous tests).

@brucehoult: What do you think ?
« Last Edit: April 26, 2020, 01:23:01 pm by ale500 »
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 4040
  • Country: nz
Re: RISC-V microcontrollers from GigaDevice
« Reply #98 on: April 26, 2020, 01:52:29 pm »
Hmm .. ok I've found some better pics of GD32F103 with ARM and it really does look like it's got 128k of SRAM to copy the flash into and 20k of SRAM for the program to use.

Nuts!

I guess technically the "Flash Memory Controller" box could contain 128k of SRAM.

The DG32VF103 start up time from reset is 132 ms, and 118.8 ms to wake from 7 uA standby mode. Wake from "deep sleep" 400 uA mode is 6 us. So that's almost 15000 times longer from standby mode. And 60x lower power consumption. Only "backup registers" are retained in standby mode, CPU registers and SRAM contents are lost.

That 118.8 ms to wake is enough time to copy 128k of flash to SRAM at 1.11 MB/sec, 8.8 Mbps. One byte every 900 ns. One bit every 112.5 ns. Even stupidly cheap flash is faster than that. The external SPI flash on the HiFive1 can run at 133 MHz doing 4 bits per cycle (QSPI), or 66 MB/sec.

For comparison, an STM32F103 wakes up from stop 13 uA mode in 5 us, and from standby 2 uA mode in 50 us. So it comes out of the lowest power consumption mode over 2000 times faster.

I seem to recall AVRs have similar wakeup times to the STM chip.

So yeah, ok, call me convinced.
 
The following users thanked this post: thm_w

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 14490
  • Country: fr
Re: RISC-V microcontrollers from GigaDevice
« Reply #99 on: April 26, 2020, 02:59:14 pm »
Yup, those were some of my points as well. Crazy start up and wake up times, not that great in terms of power consumption either.

But yeah this flash chip+SRAM solution is likely considerably cheaper. They just stack a very low cost flash chip (hence why it's likely so slow) die on their MCU die. It's likely not even QSPI. Integrating flash memory directly on the same die, and being able to run from it at a reasonable speed would be a lot more expensive.

All in all, it seems there aren't any RISC-V-based MCUs on the market yet that can really compete with existing ARM-based MCUs, at least for a number of key factors such as power consumption/efficiency of low-power modes/etc.

That's too bad, since due to the simplicity of RISC-V, there's clear potential to design MCUs that are even lower power (possibly by a large margin) than their ARM "counterparts". But I haven't seen such an MCU yet on the market.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf