[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [f-cpu] Status quo



Hi Yann,

On 04/01/2015 01:32 PM, whygee@xxxxxxxxx wrote:
Le 2015-04-01 12:24, Nikolay Dimitrov a Ãcrit :
Here, you're just mixing address lines. Nothing crazy. CÃdric's
example seems to work at the byte level with a more complicated
pattern, that's where SIMD is helpful to shuffle the bytes.

If we put a big LUT (4K entries) on the address lines, we can have
arbitrary conversion of any tile addressing scheme, that should answer
the needs which Cedric explained. The price to pay for this "tiling
linearisation" is the LUT propagation time (not sure how big it's for
Actel BRAMs, but a wild guess is that it's around 2-4ns).

Of course, this LUT shouldn't be used while accessing non-tiled memory
:D.

Kind regards,
Nikolay

That thing is not ok.

* 2 or 4ns is an eternity in a pipeline.
* what would your LUT do ?
* how do you specify that the addresses
  are translated through the LUT (for graphics)
  and not ? (for "normal data") ?

As a reminded, the F-CPU instruction set contains
byteswap (for endianness conversion) and bitreverse
(for DSP / FFT addressing). An instruction could be added
to do the bit mixing. Even a parallel LUT instruction,
why not (quite handy for many other things) but the
address bus is really timing-critical...

Well, I personally don't like the idea of having such CPU instructions in the first place, so didn't intended to put this LUT on the CPU data path at all.

I think it can be implemented like MMU extension module, to handle the address-conversion only for the tiled pages (for graphics purposes, if/when needed).

Regards,
Nikolay
*************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxx with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/