Q on Verilog use of GPIO pins on Gowin Ministar EVB

[mon2]

Hi. Experimenting (learning about verilog) with the Gowin Ministar EVB which has multiple 7-segment LED displays and is confirmed working with the demo FPGA & Keil C code to produce a counter. Working as advertised.

In reviewing how it works, the FPGA IP has a CST (constraint) file that maps out an array of GPIO pins that are 3v3 CMOS style.

The FPGA top.v file exposes this block of GPIO pins and the Keil compiler makes use of the same block of pins to produce the counter using the hard Cortex CPU.

Is it possible to access the SAME GPIO pins inside the FPGA Verilog code ? If yes, how ?

That is, to perhaps just blink a single LED segment that is also used by the CPU Keil code ? I believe we can map a different LED / GPIO pin to perform a dedicated task that will be independent of the Cortex C code run but this is more to understand the procedure to access same I/O block with verilog.

ie. to force ON for example gpio_io[6] in verilog (same pin is available to the Keil C code)

gpio_io[6] = 1'b1; // example

Thanks.

https://github.com/magicjellybeanfpga/MiniStar/tree/main/projects/Tutorials

Project is the Digital Tube Demo.

[langwadt]

you can (probably) connect the mcu pins to wires and then some logic before connecting to the pins, instead of directly to the pins

[mon2]

Thanks for your feedback. Perhaps I am not clear on my explanation - please see below on my recent attempt and raised error code.

Code: [Select]

module top(
    inout [15:0] gpio_io,
    input reset_n   
);


wire m3_clk;

    Gowin_OSC U_Gowin_OSC(
        .oscout  (m3_clk),
        .oscen   (1)
    );

        // enables use of the hard Cortex CPU inside the Gowin FPGA
Gowin_EMPU_Top your_instance_name(
.sys_clk (m3_clk),  //input sys_clk
.gpio    (gpio_io), //inout [15:0] gpio
.reset_n (reset_n)  //input reset_n
);

  // my attempt to access the GPIO_IO[6] pin from the FPGA side
  blink my_blinky(
        .clk (m3_clk),
        .LED (gpio_io[6])
    );


endmodule

then contents of blink.v are:

Code: [Select]

module blink (clk, LED);

input clk;
output LED;

reg [31:0] counter;
reg LED_status;

initial begin
counter <= 32'b0;
LED_status <= 1'b0;
end

always @ (posedge clk)
begin
counter <= counter + 1'b1;
if (counter > 50000000)
begin
LED_status <= !LED_status;
counter <= 32'b0;
end

end

assign LED = LED_status;

endmodule


raised error code is:

GowinSynthesis start
Running parser ...
Analyzing Verilog file 'C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v'
Analyzing Verilog file 'C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_osc\gowin_osc.v'
Analyzing Verilog file 'C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\top.v'
Analyzing Verilog file 'C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\blink.v'
Compiling module 'top'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\top.v":3)
Compiling module 'Gowin_OSC'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_osc\gowin_osc.v":9)
WARN  (EX3670) : Actual bit length 32 differs from formal bit length 1 for port 'oscen'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\top.v":13)
Compiling module 'Gowin_EMPU_Top'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":1035)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module '**'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\gowin_empu\gowin_empu.v":0)
Compiling module 'blink'("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\blink.v":1)
NOTE  (EX0101) : Current top module is "top"
[5%] Running netlist conversion ...
ERROR (CV0013) : Pin(gpio_io[6]) of 'LED'(IOBUF) does not connect to port("C:\Users\kumar\Downloads\MiniStar-main\MiniStar-main\projects\Tutorials\Digital Tube Demo\seg_run\fpga_led\src\blink.v":26)
GowinSynthesis finish

[mon2]

Project fileset:

https://we.tl/t-WpAhA21rn6

[up8051]

But in this way you are trying to control one pin from two sources / processes and this is not allowed.
Is it really what you want?

[tom66]

Perhaps the problem is that the MCU port is an inout, so it has an inherent tristate associated with it.  (The bus can be 1, 0, or Z.  This is fundamentally implemented as a 'output' bit, a 'tristate' bit and an 'input' bit.)

That tristate may or may not be accessible, depending on the hardware.

Not that familiar with Gowin architecture, but you can try to see if the MCU module exposes e.g. a gpio_in and gpio_out and gpio_tri set of ports (instead of the 'easier' gpio one which does that for you.)  It might then be possible to get your signal into the port that way.

Another way would be to use a range select, so if you do, e.g.:

Code: [Select]

Gowin_EMPU_Top your_instance_name(
.sys_clk (m3_clk),  //input sys_clk
.gpio    (gpio_io), //inout [15:0] gpio
.reset_n (reset_n)  //input reset_n
);

wire LED_gpio = <some toggling signal>;
wire [15:0] my_gpio = {gpio_io[15:7], LED_gpio, gpio_io[5:0]};

This may not synthesise if the FPGA resources do not exist to connect into that port.  For instance, on Xilinx Zynq most of the MIO are bonded directly to pads. There is no way to redirect these even if they exist as ports on the Verilog toplevel for the ARM, because there is no FPGA resource there.  You will usually fail at place and route stage if you have done something wrong here.

[BrianHG]

Perhaps the problem is that the MCU port is an inout, so it has an inherent tristate associated with it.  (The bus can be 1, 0, or Z.  This is fundamentally implemented as a 'output' bit, a 'tristate' bit and an 'input' bit.)

That tristate may or may not be accessible, depending on the hardware.

Not that familiar with Gowin architecture, but you can try to see if the MCU module exposes e.g. a gpio_in and gpio_out and gpio_tri set of ports (instead of the 'easier' gpio one which does that for you.)  It might then be possible to get your signal into the port that way.

Another way would be to use a range select, so if you do, e.g.:

Code: [Select]

Gowin_EMPU_Top your_instance_name(
.sys_clk (m3_clk),  //input sys_clk
.gpio    (gpio_io), //inout [15:0] gpio
.reset_n (reset_n)  //input reset_n
);

wire LED_gpio = <some toggling signal>;
wire [15:0] my_gpio = {gpio_io[15:7], LED_gpio, gpio_io[5:0]};

This may not synthesise if the FPGA resources do not exist to connect into that port.  For instance, on Xilinx Zynq most of the MIO are bonded directly to pads. There is no way to redirect these even if they exist as ports on the Verilog toplevel for the ARM, because there is no FPGA resource there.  You will usually fail at place and route stage if you have done something wrong here.

^*&(#$*(#^$*#^*)%&#$)*#*$&%^^#  I was just typing the same thing at the same time....

Only difference:

wire [15:0] my_gpio = {gpio_io[15:7], (LED_gpio  || / ^ / &&  gpio_io[6]), gpio_io[5:0]};

The optional or / xor / and allows the Gowin MPU software to effect the led blinking.

[mon2]

Thank you all for your comments.

@up8051 - Believe that we validated the same today. That is, from our assorted attempts, it appears that if the GPIO block is assigned to the CPU IP, then this same GPIO block is exclusive to the CPU. With our limited knowledge, we could not access any of the GPIO pins with verilog for the array of [15:0] port pins.

However, we did add an additional GPIO single bit port (GPIO_28) which is bonded out to a 2.54mm male pin header -> had no issues to write '0' or '1' to suit with verilog. This result was expected.

We 'assumed' that any constraint GPIO pin is available to BOTH the FPGA fabric or the CPU side IP.

If we understand the other posts, it is possible to segregate the GPIO port pins into chunks and then the (excluded but) isolated port pin (as per the shared code) can then be accessed through Verilog ? Is this correct ? Very good to know this as well.

On this note, IF verilog code is used to say toggle this single bit port -> can the Keil C code also access the same ? Again, just wanting to learn if the access is exclusive to one side or the other.

I believe we can squeeze our code to perform the task either way but like the idea of using the FPGA for a state machine to initialize some hardware very quickly upon power up -> then skip to the Keil side to spit out data. It was only one of many ideas to access the hardware. It should be ok to consider using only the M3 CPU to do it but we need to test against our pending PCBA.

Thank you again for the great posts. So much for us to learn ahead...

[tom66]

Does the Gowin toolchain expose a viewer where you can see the result of place and route?  On the Xilinx tools you can use this to explore where a net was routed.  You will be able to see if resources exist to allow that net to be routed into the fabric.  I think that it may not support it just because it is a tristate bus and that isn't usually routed inside an FPGA.

[Someone]

You have the empu inside a convenience wrapper? The 16 bits of "hard" GPIO are separate input output tristate/en ports on the primitive:
http://cdn.gowinsemi.com.cn/SUG283E.pdf

Your posts are jumping between electrical world (bidirectional io) and the software without thinking how the FPGA works.  There is no tristate or bidirectional io inside modern FPGAs, its implemented as separate wires. Synthesis support for interconnecting inout is very sparse, if you don't want to dig into the details and learn your specific device/toolchain the safe/default solution is to only have inout at the top level and immediately connect that to the matching device IO primitive (which is probably what's hidden inside your wrapper).

[langwadt]

It looks like you can get in/out/en instead of io

https://github.com/verilog-indeed/nano_4k_empu/blob/dev/gowin_empu/src/gowin_empu/gowin_empu.v