With its tiny size the ZPU would seem an ideal candidate for a multi-core design.\u00a0 Unfortunately, instantiating more than one of the traditional zpu_small cores in a single project is complicated by the ROM \/ Stack RAM entity being instantiated within the CPU core itself.\u00a0 If you want multiple ZPUs, doing different jobs, then their ROMs must differ!\u00a0 To solve this, I’ve removed the internal ROM and defined a new interface (using VHDL techniques I’ve picked up from the PACE project) for connecting the ZPU to a separate ROM \/ Stack RAM entity. The biggest advantage of this is that it makes it much simpler to swap between different firmwares.<\/p>\n
The signals required for the ZPU’s ROM \/ Stack RAM entity are as follows:<\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0 memAWriteEnable : in\u00a0 std_logic;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memAAddr\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : in\u00a0 std_logic_vector(maxAddrBitBRAM downto minAddrBit);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memAWrite\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : in\u00a0 std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memARead\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : out std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memBWriteEnable : in\u00a0 std_logic;\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memBAddr\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : in\u00a0 std_logic_vector(maxAddrBitBRAM downto minAddrBit);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memBWrite\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : in\u00a0 std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0\u00a0\u00a0\u00a0 memBRead\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 : out std_logic_vector(wordSize-1 downto 0);<\/pre>\nIn order to avoid having to connect all these individually, and to create signals for them in the toplevel, I’ve defined some new types in zpupkg.vhd:<\/p>\n
\u00a0\u00a0\u00a0 type ZPU_ToROM is record\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memAWriteEnable : std_logic;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memAAddr : std_logic_vector(maxAddrBitBRAM downto minAddrBit);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memAWrite : std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memBWriteEnable : std_logic;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memBAddr : std_logic_vector(maxAddrBitBRAM downto minAddrBit);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memBWrite : std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0 \u00a0end record;\r\n\r\n\u00a0\u00a0 \u00a0type ZPU_FromROM is record\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memARead : std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0memBRead : std_logic_vector(wordSize-1 downto 0);\r\n\u00a0\u00a0 \u00a0end record;<\/pre>\nThis means the relevant part of the ZPU’s interface can be reduced to:<\/p>\n
\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0 from_rom : in ZPU_FromROM;\r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0to_rom : out ZPU_ToROM<\/pre>\nand the toplevel merely has to do this:<\/p>\n
signal zpu_to_rom : ZPU_ToROM; \r\nsignal zpu_from_rom : ZPU_FromROM; \r\n...\r\nmyrom : entity work.SDBootstrap_ROM \r\n\u00a0\u00a0 \u00a0port map ( \r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0clk => clk, \r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0from_zpu => zpu_to_rom, \r\n\u00a0\u00a0 \u00a0\u00a0\u00a0 \u00a0to_zpu => zpu_from_rom \r\n\u00a0\u00a0 \u00a0);<\/pre>\nTo simplify creating the ROM entities from compiled code, I’m doing some Makefile magic.\u00a0 (Previously I’ve been using the 2-port RAM megafunction wizard to generate the ROMs – and using srec_cat to generate the required .mif files.)<\/p>\n
Luckily the ZPU project includes a ROM generating program, which takes a raw binary file as input and outputs VHDL code like so:<\/p>\n
\u00a0\u00a0\u00a0\u00a0 0 => x\"a08087fe\",\r\n\u00a0\u00a0\u00a0\u00a0 1 => x\"04000000\",\r\n\u00a0\u00a0\u00a0\u00a0 2 => x\"800b810b\",\r\n\u00a0\u00a0\u00a0\u00a0 3 => x\"ff8c0c04\",\r\n\u00a0\u00a0\u00a0\u00a0 4 => x\"0b0b0ba0\",\r\n\u00a0\u00a0\u00a0\u00a0 5 => x\"80809d0b\",\r\n ...<\/pre>\nWith a bit of shell scripting and redirection it’s easy enough to combine this with a VHDL prologue and epilogue to build a complete VHDL file defining the ROM.\u00a0 My prologue and epilogue use the name dualportram, and the makefile uses sed to change this to something more suitable, like so:<\/p>\n
\u00a0\u00a0 make -C SDBootstrap\/\r\n\u00a0\u00a0 sed 's\/dualportram\/sdbootstrap_rom\/' >sdbootstrap_rom.vhd <rom_prologue\r\n\u00a0\u00a0 .\/zpuromgen SDBootstrap\/boot.bin >>sdbootstrap_rom.vhd\r\n\u00a0\u00a0 cat >>sdbootstrap_rom.vhd rom_epilogue<\/pre>\nIf the directories, files and entities are named carefully, we can generalize this even further, and my toplevel firmware makefile now looks like this:<\/p>\n
all: zpuromgen Dhrystone.gen SDBootstrap.gen RS232Bootstrap.gen\r\n\r\nclean:\r\n make -C SDBootstrap clean\r\n make -C RS232Bootstrap clean\r\n make -C Dhrystone clean\r\n rm *.vhd\r\n\r\nzpuromgen: zpuromgen.c\r\n gcc -o zpuromgen zpuromgen.c\r\n\r\n%.gen:\r\n make -C $*\/\r\n sed 's\/dualportram\/$*_ROM\/' >$*_ROM.vhd <rom_prologue\r\n .\/zpuromgen $*\/$*.bin >>$*_ROM.vhd\r\n cat >>$*_ROM.vhd rom_epilogue<\/pre>\n","protected":false},"excerpt":{"rendered":"With its tiny size the ZPU would seem an ideal candidate for a multi-core design.\u00a0 Unfortunately, instantiating more than one of the traditional zpu_small cores in a single project is complicated by the ROM \/ Stack RAM entity being instantiated … Continue reading