Open drom opened 7 years ago
This would force to use it in several cycles... I don't like it, this would earn some transistors but I find it better to use one decoder the width of the biggest one you are going to receive and decode it in just one cycle. I find yours useful, but it's complicating the interface, so maybe it would be a good idea to have in the project a collection of decoders instead?
What is your use case? How do you get your input stream? How do alight data before unpacking?
actually if you tie ai
pointer to 0, and make input data bus di
wider then output do
, then you can guarantee that you will have 1 cycle execution.
gluon
in this case is the error (or carry) flag, that you have more data outside of input window.
That reminds me that we may need another flag overflow
that indicates, that input stream data sequence is longer then fits into output word format.
What is your use case?
As I told you, I'm doing an implementation of WebAssembly on FPGA, so I know in advance varint numbers will not be greater than 5 or 9 bytes for 32 and 64 bits.
How do you get your input stream?
I don't have an input stream... just read the bytes from a ROM and wire them directly to the decoder.
How do alight data before unpacking?
My ROM implementation does that for me :-P
@piranna I was thinking about useful Verilog interface for the unpack modules.
Most probably the byteStream would be located in some sort of memory with word access. Practical word width
WDI
can be 4, 8, 16, 32 Bytes.The stream would have some sort of initial pointer
ai
ofWA
width 2, 3, 4, 5 will point to the first byte in the LEB encoded number.The module would produce single word of fixed width
WDO
and the updated pointerao
.Here is proposed Verilog interface:
exampe 1 (unpack_36_64_u32):
exampe 2 (unpack_36_64_u32):
two cycle unpack operation because of missalighnment.