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.

FIFO output is as a Data Packet? Is that possible?

Status
Not open for further replies.

ram11

Newbie level 4
Joined
Mar 10, 2018
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1
Activity points
57
Hi,

I have been asked to design an system where the system receives a constant data stream from a FIFO. The output from the system should be in the form :-

Length (binary integer 0 to 65535) Type (ASCII A, B, C, D) Data(No restriction of type)

where :-
Length(2 Bytes) : Total length of the packet including length.
Type (1 Byte) : 'A'( fix length = 4), 'B'(Fixed length=28), 'C'(Fixed Length = 51), 'D'(Variable length = 4 to 64)
Data could be anything

The question is that I am getting the data on the input bus and I have to delimitate it as one of the above 4 messages.

I having trouble understanding the question because my assumption of FIFO is that:- the output of a FIFO are just plain data and there are no bits so represent length type etc. May I know if FIFO can output a data packet as shown above.

I thank everyone in advance for your help.

With Regards,
Ram
 

A FIFO can output whatever the you put into it. If it's got some predetermined format, so what? You get 8-bit, or 16-bit, or whatever data out and then parse it as required. What's your problem?
 

Thank you for your response. Ok, so the output of the FIFO can be anything, agreed. In my design problem, I have been told that a 64 bit input stream containing a continuous stream of packets is coming into a black box. The packet format is defined as follows:
Length | Type (ASCII A, B, C, D) | Data(No restriction of type)

where :-

Length(2 Bytes) : Total length of the packet including length.
Type (1 Byte) : 'A'( fix length = 4), 'B'(Fixed length=28), 'C'(Fixed Length = 51), 'D'(Variable length = 4 to 64)
Data could be anything.

The problem is to delimitate the input as one of the above 4 messages.

I was reading about encoding techniques and I learnt that the above format is a TLV encoding technique where length gives the size of the data field Type indicates the kind of field that this part of the message represents and the rest is data. I am having trouble understanding what does the Type in this question represent. For eg. consider a 64bit input, the first 16 bits represent the length and the next 8 bits represent the type. So from my understanding a data packet of type C should have its data divided between two packets. The first packet will have the first 40 bits and the next packet will have the remaining 11 bits of data. May I know if my understanding is correct.
 

The answer is beyond the discussed data structure.

Either if the data packets are aligned with 64 bit boundary (by using fill bytes) or can start somewhere in the middle of it, there must be some kind of framing in the data stream. Robustness requirements demand that the receiver should be able to resync to the packet start even in case of data loss or corruption, thus just counting data length isn't an option.

Framing can be either made by using unique patterns in the data stream, involving escape sequences or encoding with additional bits in case of binary data. Or by signaling start of frame in an additional channel, e.g. extra bits in the FIFO output.

Thank you for your reply but in my design question, this is all the information that I have been provided. Apart from this I have a list of input and output signals to and from the black box. There is a Input Bus Enable which is basically DATA WIDTH/8 and is a byte enable for bytes are that are valid. The question also says I can have the start of one packet and the end of an other packet on the same Input Bus Data.
 

The answer is beyond the discussed data structure.

Either if the data packets are aligned with 64 bit boundary (by using fill bytes) or can start somewhere in the middle of it, there must be some kind of framing in the data stream. Robustness requirements demand that the receiver should be able to resync to the packet start even in case of data loss or corruption, thus just counting data length isn't an option.

Framing can be either made by using unique patterns in the data stream, involving escape sequences or encoding with additional bits in case of binary data. Or by signaling start of frame in an additional channel, e.g. extra bits in the FIFO output.

- - - Updated - - -

As said, a framing signal e.g. SOP (start of packet) is required to decode the stream. If you review popular streaming interface specifications, you'll see that they always provide some information of this kind.

The question also says I can have the start of one packet and the end of an other packet on the same Input Bus Data.
Means SOP must be a multi-bit signal, able to mark any byte in 64 bit word (or none), at least 4 bit required.

There is a Input Bus Enable which is basically DATA WIDTH/8 and is a byte enable for bytes are that are valid.
Doesn't seem related to packet framing, unless you are misunderstanding the point.
 

Thank you for your inputs. In the question I have not been given any framing bit information. I have a list of signals and there is a InBus_Enable pin which is DATA_WIDTH/8 and it is a Byte Enable pin which says which bits are valid. Also the questions states that - You can have start of one packet and end of another or 2 messages on the same InBus_Data. This is not optional feature to implement. E.g. back to back A messages. This is all the information that I have for the design problem.
 

The answer is beyond the discussed data structure.

Either if the data packets are aligned with 64 bit boundary (by using fill bytes) or can start somewhere in the middle of it, there must be some kind of framing in the data stream. Robustness requirements demand that the receiver should be able to resync to the packet start even in case of data loss or corruption, thus just counting data length isn't an option.

Framing can be either made by using unique patterns in the data stream, involving escape sequences or encoding with additional bits in case of binary data. Or by signaling start of frame in an additional channel, e.g. extra bits in the FIFO output.

- - - Updated - - -

As said, a framing signal e.g. SOP (start of packet) is required to decode the stream. If you review popular streaming interface specifications, you'll see that they always provide some information of this kind.


Means SOP must be a multi-bit signal, able to mark any byte in 64 bit word (or none), at least 4 bit required.

Doesn't seem related to packet framing, unless you are misunderstanding the point.

May I share the question with you privately. I dont wanna post the question on the public thread.
 

Forum rules say
Don't make requests for help in private using personal messages, create a thread in the forum so that other members can benefit from the posted answers.
The emphasis is on benefit of other members.

I think there are three possible explanations.
- The framing method is specified in the project, but you didn't understand it yet.
- Framing has been forgotten in the project specification.
- A framing mechanism is taken as granted. For the scope of your project, it's assumed that the first valid data byte after reset is a SOP, from this point you have to track packet length to know where the packet ends and the next packet starts.

In any case it should be possible to ask your supervisor for a clarification.
 

This is an interview question for a high frequency trading job. You got the more annoying version where you can get multiple packets per cycle.

As long as you answer questions without detail you'll be fine. Seriously, this was the only time I've been told I was too detail oriented to be an engineer.
 

This is an interview question for a high frequency trading job. You got the more annoying version where you can get multiple packets per cycle.

As long as you answer questions without detail you'll be fine. Seriously, this was the only time I've been told I was too detail oriented to be an engineer.

:) I think I understand what you mean. Thank you for your help.
 

for interview questions you need to either:

1.) ask questions for clarity.
2.) make an assumption and explain why it is reasonable and what the implications are.

Ideally, you would be able to place your design task within the context of a larger design and determine which assumptions make sense. And to be able to explain why your assumptions make sense. And then to make a reasonably good design.

But don't go into detail because apparently that isn't HFT culture.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top