The Dhrystone_fast project demonstrates increasing the ZPU’s speed by enabling optional hardware instructions, at the cost of increasing the CPU’s footprint. The firmware is identical to that used by the Dhrystone_min project, except for some CFLAGS.\u00a0 Because we have hardware implementations of some instructions available, for performance reasons it’s useful to tell the compiler to prefer those instructions and avoid the ones that are still emualted.<\/p>\n
The ZPU is configured like so:<\/p>\n
generic map (\r\n\tIMPL_MULTIPLY => true,\r\n\tIMPL_COMPARISON_SUB => true,\r\n\tIMPL_EQBRANCH => true,\r\n\tIMPL_STOREBH => false,\r\n\tIMPL_LOADBH => false,\r\n\tIMPL_CALL => true,\r\n\tIMPL_SHIFT => true,\r\n\tIMPL_XOR => true,\r\n\tREMAP_STACK => false,\r\n\tEXECUTE_RAM => false,\r\n\tmaxAddrBitBRAM => 13\r\n)<\/pre>\nNotice that we leave STOREBH and LOADBH set to false. The reason for this is simply that those instructions aren’t yet fully implemented in my ZPUFlex variant of the ZPU processor. While they work for external RAM access, they don’t currently do anything for Block RAM access. It’s possible to specify compiler flags in the Makefile (-mno-byteop -mno-shortop) which will make the compiler emit load\/shift\/mask\/store code to replace those instructions – this allows, for example, a Boot ROM to load a program into SDRAM, and the bootstrapped program to benefit from hardware loadb\/storeb without breaking the Boot ROM.<\/p>\n
Even with emulated loadb\/storeb, the fast version of the project turns in 5.6 DMIPS, the whole project being 1135 logic elements on the DE1, and the ZPU itself taking up 926.<\/p>\n","protected":false},"excerpt":{"rendered":"
The Dhrystone_fast project demonstrates increasing the ZPU’s speed by enabling optional hardware instructions, at the cost of increasing the CPU’s footprint. The firmware is identical to that used by the Dhrystone_min project, except for some CFLAGS.\u00a0 Because we have hardware … Continue reading