From: Luke Kenneth Casson Leighton Date: Tue, 8 Jan 2019 15:50:57 +0000 (+0000) Subject: clarify requirements X-Git-Tag: convert-csv-opcode-to-binary~4754 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=a7d60884417b1e88d366395b558209fbca4e7791;p=libreriscv.git clarify requirements --- diff --git a/3d_gpu/requirements_specification.mdwn b/3d_gpu/requirements_specification.mdwn index bfc5f34fb..4340a4cf5 100644 --- a/3d_gpu/requirements_specification.mdwn +++ b/3d_gpu/requirements_specification.mdwn @@ -28,6 +28,7 @@ An overview of the design is as follows: to a separate "tile buffer" (SRAM), not to the integer register file. The instruction will be scalar and will inherently and automatically parallelised by SV, just like all other scalar opcodes. +* xBitManip opcodes will be required to deal with VPU workloads * The register files will be stratified into 4-way 2R1W banks, with *separate* and distinct byte-level write-enable lines on all four bytes of all four banks. @@ -53,7 +54,9 @@ An overview of the design is as follows: Unit (in instruction issue order) that is to write its result to that register, shall be augmented with "history" capability that aids and assists in "rollback" of "nameless" registers, should an exception - or interrupt occur. + or interrupt occur. "History" is simply a (short) queue (stack) + that preserves, in instruction-issue order, a record of the previous + Function Unit(s) that targetted each register as a destination. * Function Units will have both src and destination Reservation Stations (latches) in order to buffer incoming and outgoing data. This to make best use of (limited) inter-Function-Unit bus bandwidth.