early results with a 16-bit instruction space

[biosbob]

relevant to #629, i made a first-pass at compressing all instruction addresses to 16-bits within the CPU complex.... all internal registers that hold some sort of PC are now half as wide....

starting with a baseline design that consumed ~4360 LUTs on my IceBreaker, i've reduced that number by almost 200 LUTs; and now that i have a "feel" for where this optimization saves space, there are still plenty of other places where 32-bit address registers/buses can be compressed to at least 17 bits....

again, this is all very preliminary -- though it represents the first real savings in space i've been able to obtain....

[stnolting]

Interesting! How did you constrain all those registers? Just a global mask or did you actually reduce the width of all of them?

by almost 200 LUTs

That is quite a lot as this is just the address logic. With a more efficient address decoding in all the modules the resource requirements might further drop.

Btw, I have started reworking the processor's bus system / address map in #647. Would be interesting to see if the (upcoming) changes make an difference for you setup.

[biosbob]

more results....

all bus addresses are now 17-bits in width; and in cases where i know i'm dealing with an instruction address (eg, the pc) this is further reduced to 16 bits....

i've also replaced use of the XIP module with SPI in my bootloader, which simply copies the executable image from FLASH to IMEM; i currently do not execute directly from FLASH....

starting with ~4360 LUTs with 32-bit addresses (plus XIP), i'm now at 3761 LUTs!!!!

once i clean up my code, i'll merge in the #648 changes which should (hopefully!!!) make things even better....

[stnolting]

Wow, that is a lot! I was not expecting that... Which parts of the rtl code did you modify?

I am thinking about adding two mask constants - one for the instruction fetch address logic and another one for the data access address logic. When placed correctly all over the CPU core the synthesis tool should be able to trim the entire addressing logic... 🤔

[biosbob]

looking a little closer at #648, there is still some work to be done to enable the compact addressing scheme to be implemented by simply adjusting some generic parameters.... my current prototype implementation can be see here.... note that this branch is based on an older version of the neorv32 main branch, and cannot be merged into the latest; just use this code as a "proof-of-concept"....

as you can imagine, there are LOTS of places where we declare signals/ports/constants as std_ulogic_vector(31 downto 0) -- whether these are different sorts of addresses or different sorts of data values.... as a starting point, i would recommend creating various subtypes that denote more specific intent -- an instruction address, an IO index/offset, a register data value, etc....

at present, i have a 32-bit data_t subtype, a 17-bit caddr_t subtype, and a 16-bit iaddr_t subtype.... the addr field of my bus_req_t record is now declared as a caddr_t; the various signals (registers) representing the current/next/etc PC in the CPU complex are of type iaddr_t as are various CSRs that hold instruction addresses....

as i proceed further, i would expect subtypes to emerge reflecting IO index/offset vectors with fewer than 16 bits.... each of these subtypes is defined using a constant not unlike today's XLEN.... in general, there would be a number of "width" constants that could ideally be specified through generic parameters (passed to neorv32_package if possible)....

a set of functions for converting between the sub-types (expanding or shrinking the vector as needed) also makes the code more readable.... and since these functions are explicit in the sub-types of their argument and result, my VHDL-aware editor can flag semantic errors....

the new address map proposed in #648 is somewhat at odds with a more general solution to compressed addressing.... in the full 32-bit case, the 0x80000000 mark should truly separate instruction from data accesses; said another way, the high-order bit of the address discriminates between these spaces.... to be consistent, the ROM should be moved into the lower-half of memory, as should any XIP page; DMEM and the IO space can remain where they are.....

the generalization comes from realizing that this partition yields a pair of 31-bit spaces anchored around address 0x0..... in my case, i have a pair of 16-bit spaces similarly anchored around 0x0..... by compressing the instruction space DOWN towards 0x0 while compressing the data space UPWARDS towards 0x0, i can effectively eliminate high-order address bits that are no long needed....

somehow, someway i need to specify the width of my compressed address (==17).... note that the entire instruction/data spaces needed not be fully populated.... i've further divided my address space into quarters, designated by the two high-order bits in the 17-bit address; this enables separation of IMEM from ROM and DMEM from IO.... as a rule, internal calculations of address values using general 32-bit ALU registers can simply have their high-order 15-bits truncated when output on some bus....

we might want to take a step back and review #648 in light of my recent experiments....

[stnolting]

my current prototype implementation can be see here

Seems like you made a LOT of modifications here... 🙈

as you can imagine, there are LOTS of places where we declare signals/ports/constants as std_ulogic_vector(31 downto 0) [...] at present, i have a 32-bit data_t subtype, a 17-bit caddr_t subtype [...]

in general, there would be a number of "width" constants that could ideally be specified through generic parameters (passed to neorv32_package if possible)....

Right, but I would not change this. Instead, a simple 32-bit mask - inserted into the according address bus-driving logic - should be able to constrain the effective bus width. The synthesis tool should be smart enough to trim those "masked" bus bits.

the generalization comes from realizing that this partition yields a pair of 31-bit spaces anchored around address 0x0

Could we use such an address mask to shrink the entire addressable space down to 16-bit only?

An example: if we have 0x0000_FFFF as address mask (that is applied to all address decoding logic) we could easily setup an address space layout that uses bits 15:14 to select one out of four regions (IMEM, DMEM, IO, BOOTROM).

[biosbob]

so as an example, there is the curr_pc signal inside the cpu module -- which i've declared as iaddr_t.... this signal of course is passed in/out of various other modules; the actual assignment to this signal occurs in places that were not always obvious (to me)....

but because i specifically constrained the signal at its point of declaration, the compiler informed me where there were inconsistent modifications and/or port bindings; this also extended to constant declarations as well....

while tedious, the renaming DID enable me to assert whether a particular signal/port/constant was indeed an address (which could or could not have the same width as something declared as data_t).... without these declarations, finding the actual site of address manipulation seemed impossible (to me).... relying on the optimizer is only as strong as our ability to find ALL places where the mask needs to be applied; miss just one and the address bus won't be narrowed....

ultimately, i guess the answer is to add an "addressing mask" into the current design and see what happens 😉