Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Multi data size handling

Status
Not open for further replies.

shashankksraj

Newbie
Joined
Nov 17, 2018
Messages
4
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
30
Hi,

I have 32-bit data, 16-bit data, 8-data accompanied by their respective data valid signal. At each clock, any one of the data may arrive into 32-bit memory/buffer. If its 32-bit, I could send across the output. If its any other data, I need wait until the 32-bit is filled after concatenation and send it across the output. Suppose, I get a 16-bit data first, 8-bit data second, 16-bit third. On concatenation, I have 8 bits overflow which I need to send at next clock cycle by concatenating with next arriving data. I can only output 32-bit with help on concatenation and accompanied by valid signal for the output.

How do I achieve the size check and concatenation? Please help.
 

Hi,
I can't think of any useful application where one receives random 8bit, 16bit, 32bit values and send them without framing ...

How can the receiver of the data stream find out which 8bit belong to a 16 bit value or a 32bit value?

I'd say you need (FIFO) buffers for every incoming data format and a useful protocol when you send them out.

But maybe I misunderstood the description. Please clarify. Draw flow charts, overviews, timing diagrams.

Klaus
 

As mentioned above, use intermediate asymmetric FIFOs, where the read side of the FIFOs is 32 bits and the write side is 8 or 16 bits. In this way you always have 32 bits data to be pushed in to the 32-bit memory/buffer.
 

a simple arbiter does the job. check 32 bits. not there? check 16. not there? check 8.
 

Hi,
I can't think of any useful application where one receives random 8bit, 16bit, 32bit values and send them without framing ...

How can the receiver of the data stream find out which 8bit belong to a 16 bit value or a 32bit value?

I'd say you need (FIFO) buffers for every incoming data format and a useful protocol when you send them out.

But maybe I misunderstood the description. Please clarify. Draw flow charts, overviews, timing diagrams.

Klaus

Thanks for response. The final output receiver only cares if the data is 32-bit. Any other data needs to be concatenated to 32-bits and then sent to output receiver. Overflow after concatenation has to come in the next clock cycle, concatenated with next incoming data. The valid signals tells if the incoming data is valid.
 

a simple arbiter does the job. check 32 bits. not there? check 16. not there? check 8.

Any specific Arbiter in mind? Data arrives at every clock cycle, it can be 8-bit, 16-bit or 32-bit. But arrives one at a time, every clock cycle. If its a burst I might consider a depth for the buffer/FIFO/memory
 

As mentioned above, use intermediate asymmetric FIFOs, where the read side of the FIFOs is 32 bits and the write side is 8 or 16 bits. In this way you always have 32 bits data to be pushed in to the 32-bit memory/buffer.

Thanks for reply. I considered the FIFO scenario. Decide a depth based on Data bursts. But thinking how to handle overflow during concatenation, any overflow should be concatenated with next incoming data with loosing. Important to note that any one of the data ( 8/16/32) arrives at each clock cycle. Any insight on this?
 

I see this design as some sort of current/pending write register with an N-byte barrel shift and some logic that flags which bytes are valid for the current/pending registers. The byte valid flags would be used along with the incoming byte valid flags to determine the barrel shift amount to concatenate the byte(s) to the current write data and the rest of the byte(s) to the pending register. Once a write occurs the pending register is transferred to the current register along with the next barrel shift data.

Most of this design seems to involve properly pipelining the transfers of the various byte sizes and determining the decoding of the current bytes valid and the incoming bytes valid and translating that to a barrel shift rotation.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top