Welcome to HDL Express, the personal webpages of Kirk Weedman
HDL stands for Hardware Description Language.
This website also contains information on various Verilog/FPGA tutorials, Alternative Energy projects, and the progress of a new CPU architecture that I'm designing.
I'm an electronic design engineer specializing in contract Verilog RTL FPGA design, functional verification, testbench creation, simulation and debug. I have a varied background in other disciplines too.
Currently available for new FPGA design contract work.
Oct. 28, 2016: Current Status of the new Out of Order CPU Architecture.
This architecture is not like the typical OoO architectures being used today and the goal is to improve OoO IPC.
I'm looking for possible help. Read my OFFER to join in helping me progress faster on this new architecture.
See CPU History for more information about the progress on this architecture
See Branch Prediction Elimination for more info about the progress on this method.
1. Current simplified block diagram of new Out of Order Microarchitecture
2. Debugging instructions & flow through all stages
3. Adding more instructions to armv7_disasm.v and decode.v
More details on specific modules:
top_tb1.v - Top level test bench #1. There's enough written to start the debug process. Currently debugging 360+ different instructions
KPU_OoOe.ppt - PowerPoint presentation: overview and details about how this new microarchitecture works.90% written
cpu_params.h - written. Additions/changes as needed.
armv7_disasm.v - 85% written. Currently debugging.
kpu_oooe.v - top level module 70% written. Currently debugging
fetch.v - 75% written (missing code for branch prediction elimination related logic)
decode.v - Most instructions decoded. Currently debugging. Coprocessor & Supervisor call instructions not yet implemented
arm_micro.v - Logic & data for ROM/RAM microcode table. Currently debugging.
dependency_control.v - 100% written. Seems to be working well.
llrs.v - Linked List Reservation Stations (not similar to any known RS) 100% written. This is a linked list type queue. This module keeps track of all instructions and whether they are ready to start execution. The oldest instruction that's ready to be executed is offered to the appropriate functional unit in the Issue/Execute stage. Seems to be working well.
sll.v - 100% written. Contains the core logic for a Singly Linked List queue and is instantiated in llrs.v. The queue list is linked from newest to oldest instruction.
gpr.v - 90% written. Contains CPU architectural registers and read/write logic connected to them. This is not shown in the above diagram, but commit.v writes to gpr.v (the architectural register set).
commit.v - 90% written. This commits/retires instructions (multiple per clock if available) In Order.
Pool of Functional Units - This is actually a collection of the modules below with controlling logic. In the current simulations, there are 5 alu_functional_units, 1 br_functional_unit, and 5 ls_functional_units in the "pool". Each type proceses certain types of instructions. The number of alu, branch, load/store functional, etc. units are determined by individual parameters. This allows the design to be varied between simulations to see the effects of different numbers of functional units. In general the design has been parameterized for many areas of the design allowing different simulations to determine which are optimal parameters for a given target CPU.
alu_functional_unit.v - ARMv7 ALU logic. 75% written. Contains Logical functions, add, subtract, 16x16, and 32x32 integer multipliers. Using vedic type integer multipiers for now.
br_functional_unit.v - 30% written - enough to just pass instructions on to commit.v so they don't hold up the data processing instructions I'm currently debugging.
fm_functional_unit.v - floating point multiply functional unit. not written
fa_functional_unit.v - floating point addition functional unit. not written
cop_functional_unit.v - coprocessor functional unit. Created, but not finished.
ls_functional_unit.v - Load/Store functional unit. Determines Load/Store addres. 90% written. Not debugged yet.
ls_cam_cache.v - Content Addressable Memory used as a cache to store N Load/Store addresses. See CPU History for more information. 80% written. Not debugged yet.
ls_dependency_control.v Similar to Dependency Control - not yet written
lsrs.v - Load/Store Reservation Station. Similar to llrs.v - not yet written.
start_ls.v - start a Load or Store memory transfer. - not yet written.
unique visitors since Mar. 3, 2016