Gowin M3 CPU usage with FPGA fabric

[mon2]

Hi. Still learning but making some progress on the use of the Gowin / Efinix FPGA devices.

Q: How to transfer data to / from the embedded CPU and the FPGA fabric ?

Specifically, enabled the m3 hard CPU inside the Gowin GW1NS-LV4C device to which we enabled 16 GPIO pins during the instantiation. Now this block of 16 GPIO pins are exclusively locked to the M3 CPU (ie. the fpga fabric cannot access the same GPIO pins). Inside the Keil C code for the M3 CPU, we can perform a toggle of the GPIO pins which are binding to the hardware with the constraint file.

This is all working well. Our LEDs are blinking as they should.

Having a mental block on how to now transfer data bytes from the CPU side to the FPGA side (and vice versa) so that the FPGA fabric can assist on some critical timed state machines.

One crude idea is to use the same GPIO pins to output parallel data with sideband handshake lines -> the FPGA fabric state machine then captures this data to process. However, this idea will eat up quite a number of port pins on the FPGA package.

The flexibility of FPGA devices is amazing but with a steep learning curve. Welcome any suggestions. Thanks !

[pcprogrammer]

My guess would be that the IO lines from the MCU are available as internal targets for the FPGA fabric.

The GPIO pins you mention, are these normally available for the FPGA or strictly available for the MCU?

Because if they are normally available for the FPGA one can imagine that the connection from the MCU to the GPIO pins is made via the FPGA fabric, and that it should be possible to route them into the logic to, without having to connect them to a GPIO pin first.

Edit1: I took a look at the manual and I think the ABP2 bus can be used to interface whit the FPGA. http://cdn.gowinsemi.com.cn/DS821E.pdf page 36

Edit2: On the next page there is this diagram, which shows several options on how to connect with the FPGA. The GPIO's can be used as I guessed. But it looks like it is also possible to extend onto the AHB bus. The big question of course is how.

[mon2]

Thank you. On the same level of thinking and found the reference design for the CM1 processor (using that for testing on one kit and using CM3 on another which has a hard M3 micro) -> the reference C code (GMD / Keil) is showing an example of the AHB2_EXI.

So far, little or no documentation but in reviewing the source code, it appears they are chatting with a (fabric based?) custom widget called MULTIPLE. Not sure if we have the FPGA verilog code for this example but will hunt around. Our Gowin FAE is on vacation for another week.

/* -------------------------- Multiple ---------------------------- */
//type definition
typedef struct
{
  __IO   uint32_t  MULTIPLIER;        /* Offset: 0x000 (R/W) [7:0] */
  __IO   uint32_t  MULTIPLICAND;      /* Offset: 0x004 (R/W) [7:0] */
  __IO   uint32_t  CMD;               /* Offset: 0x008 (R/W) [1:0] */
  __I    uint32_t  RESULT;            /* Offset: 0x00C (R/ ) [15:0] */
}MULTIPLE_TypeDef;

//base address
#define MULTIPLE_BASE   AHB_M1

//mapping
#define MULTIPLE        ((MULTIPLE_TypeDef   *) MULTIPLE_BASE)

//bit definition
#define MUL_MULTIPLIER      ((uint32_t) 0x000000FF)
#define MUL_MULTIPLICAND   ((uint32_t) 0x000000FF)
#define CMD_START               ((uint32_t) 0x00000001)
#define STATUS_FINISHED      ((uint32_t) 0x00000010)
#define MUL_RESULT            ((uint32_t) 0x0000FFFF)
/* -------------------------- Multiple ---------------------------- */

So if this AHB extension can chat with this fabric based IP, we should be able to something similar.

There is also some mention of dual port SRAM on the forum but not sure if we have seen sample projects in the Gowin SDK but will search. That should also be ok for our needs.

Thanks again!

[up8051]

Maybe it will be helpful:
https://github.com/verilog-indeed/nano4k_ahb_led

[mon2]

That is an EXCELLENT find ! Thank you. Not comfortable with VHDL but will study and see if we can expand this sample project for our needs.

Can the toolchain allow for a mix of VHDL & VERILOG source files to be used inside the same project ?

[Someone]

This thread repeating the incorrect assertions/understanding from the previous question by the OP:
https://www.eevblog.com/forum/fpga/q-on-verilog-use-of-gpio-pins-on-gowin-ministar-evb/

[mon2]

Thanks for your post.

No, not the same.

1) Original (other) thread was to ask if a single resource (ie. GPIO pin) can be accessed by the hard / soft embedded CPU AND also the FPGA fabric.

ie. GPIO[0] is mated with a LED. Can the CPU blink this LED with C code ? Can this same pin be toggled via verilog inside the same project ?

From the toolchain / verilog rules, apparently not as a default. Once the resource is mapped to the CPU by the IP Wizard, it is for exclusive use by the CPU. The opposite is true if the physical pin on the FPGA is not assigned to the CPU side -> then the FPGA fabric can access the pin.

2) This thread is to understand how to exchange data from the CPU to the fabric and vice-versa. Trying to build a bridge that are operating at 2 different speeds. The fabric side needs to operate on data traffic that cannot exceed 20us and is very restrictive on timing. The CPU side will be used at a different speed (ie. UART) but needs to build a buffer and massage the data flow before passing it forward. It will be easier to implement this side of the bridge using block of code in C.

3) The suggestion from the above posts is great and one solution to use the AHB bus is valid. The code example is with VHDL which currently have no knowledge about but trying to just sample this data with an oscilloscope as it is sent out over the CM1 / CM3 IP. Learning about GAO (Gowin Analyzer Oscilloscope) as well.

Use of dual port RAM will also work but have not explored that thought process.

Gowin has mentioned that they do not have a reference design that uses the AHB for custom widgets. The SDK does offer an example with the AHB enabled logic block for the CPU but they do not show the details on how the FPGA fabric side can communicate with the same enabled AHB port.

The above GITHUB example is great to learn from but after downloading the project -> the project fails to compile as posted.

ERROR (EX4232) : Formal port 'master_exresp' has no actual or default value("C:\Users\kumar\Downloads\nano4k_ahb_led-main\nano4k_ahb_led-main\FPGAProject\CM3_AHB_LED\src\soc_top.vhd":138)
ERROR (EX4716) : Unit 'structural' is ignored due to previous errors("C:\Users\kumar\Downloads\nano4k_ahb_led-main\nano4k_ahb_led-main\FPGAProject\CM3_AHB_LED\src\soc_top.vhd":145)

[dawnclaude]

Your Gowin_EMPU_Top entity has a port called master_exresp , yet you did not assign that port to a signal in your my_cm3 instantiation. Try uncommenting that port assignment or if you are not going to use that port just assign it to open to leave that port unconnected.

[Someone]

This thread repeating the incorrect assertions/understanding from the previous question by the OP:
https://www.eevblog.com/forum/fpga/q-on-verilog-use-of-gpio-pins-on-gowin-ministar-evb/

No, not the same.

1) Original (other) thread was to ask if a single resource (ie. GPIO pin) can be accessed by the hard / soft embedded CPU AND also the FPGA fabric.

ie. GPIO[0] is mated with a LED. Can the CPU blink this LED with C code ? Can this same pin be toggled via verilog inside the same project ?

From the toolchain / verilog rules, apparently not as a default. Once the resource is mapped to the CPU by the IP Wizard, it is for exclusive use by the CPU.

Keep saying that the gpio of the embedded CPU is not accessible from the fabirc, and I'll keep pointing out you are incorrect. Ditch the wrapper generating "wizard" if you need to access lower level details (which will again back you into a corner on this thread).

Gowin has mentioned that they do not have a reference design that uses the AHB for custom widgets. The SDK does offer an example with the AHB enabled logic block for the CPU but they do not show the details on how the FPGA fabric side can communicate with the same enabled AHB port.

AHB (and APB) are standard interfaces, get the documentation and write a peripheral to that specification:
https://developer.arm.com/documentation/ihi0011/a/AMBA-AHB
https://developer.arm.com/documentation/ihi0024/b/Introduction/About-the-AMBA-3-APB

FPGA's are not copy/paste like Arduino, its unlikely there is an open source example out there that already does the (so far completely unexplained) function you need.