[generatebits] Instruction decompressor not reusable

[alekob]

Tried to reuse an already existing processor with (instruction dictionary) decompressor for different software images. It seems that the switch "-ensure_programmability" has no effect as the decompressor is generated differently depending on the tpef.

In order to reproduce, please do a "make diff" on the attached test case. It will generate .tpef files and decompressor files on different source code using the same processor description (.adf, .bem, .idf)

test_compress.zip

[pjaaskel]

I think you've bumped into a non-existing feature. The instruction dictionary mechanism at its current state is meant for FPGA softcores where the dictionary and the program image always go hand in hand. There is no proper "reprogramming" support in the sense of utilizing the old dictionary for new programs yet.

During the years of TCE we have discussed two directions a) programmable dictionaries in the decoder so it's possible to update the dictionary with the program in the processor or b) import the dictionary as an additional scheduling constraint to the compiler which then forces the compiler to use only instructions available in the dictionary. Neither has been implemented so far.

[alekob]

Too bad, but what's then the meaning of "-ensure_programmability"?

Well, solution a) can make sense for FPGA project but I doubt the benefit because modern FPGA compiler will map the decompressor lookup table into block RAM's anyways.

For ASIC designs the decompressor will be fixed in hardware, only the programm will be located in ROM or RAM. My intention for using the decompressor is to reduce the width of the programm memory in order to reduce the overall power consumption of the device.

So, option b) would be highly appreciated from my side, but I guess this feature is not planned in the next future!?

[pjaaskel]

Ensure programmability currently just adds all src-dst pairs to the dictionary, thus helps in case there was a compiler that inputs the dictionary to ensure that all src-dst pairs can be reached. Thus, not very useful at the current state for ASIC impementations as it ruins the compression ratio and there is no instruction scheduler utilizing the dictionary anyways.

The current dictionary compression feature does make sense in some cases for FPGAs, but it requires that the program uses a subset of the target's connections and/or immediate capabilities etc. This can result in block ram requirements for dict + compressed image that are less than the uncompressed image due to narrower instruction.

I do understand what ASIC implementations need for the reprogrammability with dictionary compression; both a) and b) options I mentioned were meant for improving dictionary compression on ASIC, not FPGA.

Like you guessed, our group has our own feature needs which come from the funded projects' targets which we will work on primarily. We do not need ASIC reprogrammability with dict compression in the current project targets, unfortunately.

However, we will check if there is a simple enough way to add more programmability to the dict compression feature to see if we can fit this feature in our list of activities funded by the current projects regardless, but it's unlikely a day or a two task so I'd not hold my breath.

Fortunately the source code is open for just this reason - you are not tied to a single vendor for improving the tools?!

[pjaaskel]

Yup, we looked into it, and it looks like at minimum a few weeks of work and we have more important features in pile for us, so cannot promise it will appear soon to the code base from our side. Sorry!