Picoblaze I/Os

It could be a little confusing when working with the I/Os.
By looking at the KCPSM6 core, the core module doesn't have all the peripherals.



Even for the memory in the top right corner, the instruction memory is generated by the assembler and it's not part of the KCPSM6 core. It's important to be clear on this.

Then you started seeing things like the following from the official user guide. Keep in mind that all the MUX and flip flops are the recommended design, you need to design these in your top module in Verilog.



Examples of these MUX can be found from the official template.
Here is the example for Input. You can see that it only uses 2 bits of the port_id. You can use up to 8 bits depending on the needs.



The 'in_port' is a reg declared at the top of the your top module following the template. 'out_port' and 'port_id' are declared as wires and they are connected to the KCPSM6 core in the instantiation.

The 'input_port_a' to 'input_port_d' are ports to be declared in your own design depending your needs. They are not defined anywhere in the template.



Here is an example for the output ports:



'out_port' is declared as wire in your top, they are directly shorted to the core's 'out_port'. When they are assigned to 'out_port_w' to 'out_port_z', the user can define where the 'out_port_w' to 'out_port_z' are connected to in order to deliver the output data to different places.

In the very simple example in the 'soft core' tutorial, there wasn't really a design for the peripherals. When the core is instantiated, the in_port of the core is directly shorted to the top's 'sw' which are the physical switches on the board.



Then in the top's verilog, out_port is directly shorted to the physical 'leds' on the board.
In the assembly instruction, the 'input' instruction will enable a read operation to load whatever appears at the in_port to register 's0'. Here, the port_id doesn't really do anything in selection, the 'sw' data directly appears at the in_port so the data at the 'sw' will be taken into the core and stored in s0.

Same to the out_port. After the 'output' instruction, a write_strobe signal will be asserted and whatever shows up at the 'out_port' will be directly sent to 'led' since they are physically shorted.



Now, let's take a look at the Square Problem's input/output operations in the top module.
The in_port is either taking in data from the sw or it's checking the button states.



For the out_port, the design has an output decoder to send the out_port byte to ds0_reg - ds3_reg. This is depending on the port_id. ds0_reg - ds3_reg are shorted to the in0 - in3 inside the disp_mux.





Inside the disp_mux module, we see that in0 - in3 are directly sent to sseg which means data at out_port are delivered to sseg without any changes in the middle. In this case, the assembly code must have done all the decoding mechanism for the seven segment display.