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 used for safely transfer of data

Status
Not open for further replies.
In the read clock cycle you will still read word{15:8} and word{7:0} together. So you will read aabb in the first clock cycle.

(changed [ ] to { } to workaround curious forum curiousness)

So what? You read out the entire 16-bit wide word from your fifo on the read end. And then you cleverly name the upper 8-bit part_a, and the lower 8-bits part_b. And then in the module AFTER that you process it byte-wise again. So you do a tic-toc. Handle part_a. handle part_b, handle part_a, etc. Obviously the clock at the read side has to be sufficiently high so there are no fifo overflows. But you know that ofcourse, since you know the data rates in your design.
 

(changed [ ] to { } to workaround curious forum curiousness)

So what? You read out the entire 16-bit wide word from your fifo on the read end. And then you cleverly name the upper 8-bit part_a, and the lower 8-bits part_b. And then in the module AFTER that you process it byte-wise again. So you do a tic-toc. Handle part_a. handle part_b, handle part_a, etc. Obviously the clock at the read side has to be sufficiently high so there are no fifo overflows. But you know that ofcourse, since you know the data rates in your design.

You are more talking of probably how the rtl should be written by saying that the name of the upper part as part_a and lower part as part_b. Is not it? Can you please explain the matter how it will happen with respect to clock and architecture wise if yes?

Main issue to resolve here is that the 16 bit data should be separated into 8 bits each so that in every read clock cycle 8 bit data should be processed. Do you agree? Can you please let me know how it should be taken care?

Regards
 

It is still absolutely unclear why you can't read one byte at a time instead of two if you use the proper fifo. If for some bizarre reason you HAVE TO read two bytes at a time, then you can use a multiplexer to extract one byte at a time. This multiplexer would have to run at twice the clock rate of your read clock.
 

Main issue to resolve here is that the 16 bit data should be separated into 8 bits each so that in every read clock cycle 8 bit data should be processed. Do you agree? Can you please let me know how it should be taken care?

I certainly can! Allow me to repeat myself verbatim!

You read out the entire 16-bit wide word from your fifo on the read end. And then you cleverly name the upper 8-bit part_a, and the lower 8-bits part_b. And then in the module AFTER that you process it byte-wise again. So you do a tic-toc. Handle part_a. handle part_b, handle part_a, etc. Obviously the clock at the read side has to be sufficiently high so there are no fifo overflows. But you know that ofcourse, since you know the data rates in your design.

there we go. And no, I am not kidding.

Would you be happy if you had 1 byte each clock cycle? yes or yes? Yes? Excellent. Then you just insert a magic module that takes your troublesome 16-bit fifo as input, and has an 8-bit wide output. Then you feed this 8-bit output to whatever-it-is.

Would this suddenly solve the problem? If yes, I have some IP I can sell you that will solve this complex design problem. ;-)
 

Would you be happy if you had 1 byte each clock cycle? yes or yes? Yes? Excellent.

Yes, you are right here. This is what wanted and stated again and again.

Would this suddenly solve the problem? If yes, I have some IP I can sell you that will solve this complex design problem.

This is one of the ways the problem can be thought to be solved. Can you please provide me the architecture of that design and the way it will make it 8 bit? Have you ever solved in practice the issue in the way I am describing? Can you please let me know how you take care of it?

Regards

- - - Updated - - -

It is still absolutely unclear why you can't read one byte at a time instead of two if you use the proper fifo. If for some bizarre reason you HAVE TO read two bytes at a time, then you can use a multiplexer to extract one byte at a time. This multiplexer would have to run at twice the clock rate of your read clock.

How will get that clock of twice the frequency barry? Again here will be clock domain crossing issue as mux selection line will have a new clock of frequency twice then that of read clock.
 

You keep refusing to answer a fundamental question: WHY CAN'T YOU USE A FIFO WITH AN 8 BIT WIDE OUTPUT??????
 

just put a flip flop for the bb
and bypass aa so that u will get a 1 cycle difference
hope this helps
In the above posts I mentioned many times that I did not want to pack them. It had to be packed to transfer the data from write domain to read domain. I do not want to use aabb. I want to use aa in first clock cycle and bb in next clock cycle.



Can you provide a way to unpack them?



In the read clock cycle you will still read word[15:8] and word[7:0] together. So you will read aabb in the first clock cycle.


Let me clarify the issue more. Suppose the data that is being written in FIFO is a movie which will consist of many images. The movie is processed in a digital system (named System_A) running at a clock named wr_clk. Now there is a need to process some portions of this movie in another digital system (System_B) which can increase the display capability and this digital system runs at a clock named rd_clk. So we transferred the data from the System_A to System_B by using a FIFO and it resulted in the output being aabb, ccdd instead of aa, bb, cc, dd. Now in write side first data is aa (let it be the image of a finger of the palm) and bb (let it be the image of a leg of a man). So when aabb is being processed in System_B it is processing an unwanted image containing finger and leg together. We want the finger to be processed first and then the leg to be processed next in System_B. This is corrupting the image as per clock cycle you are getting aabb, ccdd and they are being processed in System_B.

Regards
 

Yes, you are right here. This is what wanted and stated again and again.

Good, then at least we are talking about roughly the same thing.

Have you ever solved in practice the issue in the way I am describing?
Dunno, some parts of your problem description are too vague to know for sure. (*) What I can say for certain is that I have solved it in practice in the way I described it.

(*)Yes yes, you may think you have stated things clearly. Judging by the replies in this thread several people beg to differ. Me included.

Anyways, you can use something along these lines.


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
module fix_complex_problem_of_16in_8out(
    input             clock,
    input      [15:0] din,
    output reg  [7:0] dout
);
 
reg byte_sel = 0;
 
always @(posedge clock) begin
    byte_sel <= ~byte_sel;
    dout     <= (byte_sel) ? din[15:8] : din[7:0]; // THIS MUX. This one. This right here is a 2-to-1 MUX. For context, see below. :P
end
endmodule
 
 
// ... and then you instantiate this like so
wire [7:0] new_spiffy_1_byte_result_that_your_following_processing_can_use;
 
fix_complex_problem_of_16in_8out   fix_complex_problem_of_16in_8out  (
    .clock (your_fifo_READ_clock),
    .din   (your_aabb_16_bit_data_OUTPUT_from_your_fifo),
    .dout  (new_spiffy_1_byte_result_that_your_following_processing_can_use)
);
 
// And then feed this 8-bit "new_spiffy_1_byte_result_that_your_following_processing_can_use" signal to
// whatever processing you need.



Obviously there is work required on your part. I only give you some idea on you could approach things. One thing I conveniently and happily ignored due to lack of details provided, is things like fifo being empty/full/whatever. But since you know the specifics of your fifo I am sure you can incorporate that. If you need another MSB/LSB order then you can just change the MUX. What MUX you ask? I'll retro-actively mark it in the code up there.

What you still have to do yourself is read from the fifo on only the even cycles. I'd give you some code for it, but lack of details of your fifo enables my laziness.

Good luck!
 

Good, then at least we are talking about roughly the same thing.


Dunno, some parts of your problem description are too vague to know for sure. (*) What I can say for certain is that I have solved it in practice in the way I described it.

(*)Yes yes, you may think you have stated things clearly. Judging by the replies in this thread several people beg to differ. Me included.

Anyways, you can use something along these lines.


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
module fix_complex_problem_of_16in_8out(
    input             clock,
    input      [15:0] din,
    output reg  [7:0] dout
);
 
reg byte_sel = 0;
 
always @(posedge clock) begin
    byte_sel <= ~byte_sel;
    dout     <= (byte_sel) ? din[15:8] : din[7:0]; // THIS MUX. This one. This right here is a 2-to-1 MUX. For context, see below. :P
end
endmodule
 
 
// ... and then you instantiate this like so
wire [7:0] new_spiffy_1_byte_result_that_your_following_processing_can_use;
 
fix_complex_problem_of_16in_8out   fix_complex_problem_of_16in_8out  (
    .clock (your_fifo_READ_clock),
    .din   (your_aabb_16_bit_data_OUTPUT_from_your_fifo),
    .dout  (new_spiffy_1_byte_result_that_your_following_processing_can_use)
);
 
// And then feed this 8-bit "new_spiffy_1_byte_result_that_your_following_processing_can_use" signal to
// whatever processing you need.



Obviously there is work required on your part. I only give you some idea on you could approach things. One thing I conveniently and happily ignored due to lack of details provided, is things like fifo being empty/full/whatever. But since you know the specifics of your fifo I am sure you can incorporate that. If you need another MSB/LSB order then you can just change the MUX. What MUX you ask? I'll retro-actively mark it in the code up there.

What you still have to do yourself is read from the fifo on only the even cycles. I'd give you some code for it, but lack of details of your fifo enables my laziness.

Good luck!

I got the answer now. So it is clear that my query which has been answered is clear. I did not mention many related issue in this thread like FIFO size etc because I did not have any query related to that. Thanks for the answer and replies.

I have another issue now to look at: The FIFO is 8 bit wide. How can I extract 16 bit out of the FIFO in one read clock cycle?

- - - Updated - - -

You keep refusing to answer a fundamental question: WHY CAN'T YOU USE A FIFO WITH AN 8 BIT WIDE OUTPUT??????

If I am not answering something it means that the is answer is not relevant for the thread. Even your earlier query also of why we need to get 8 bit from 16 bit was not relevant for the thread but still I explained with the help of images. Here the situation is so that you will have to read 16 bit.

Regards
 

I got the answer now. So it is clear that my query which has been answered is clear. I did not mention many related issue in this thread like FIFO size etc because I did not have any query related to that. Thanks for the answer and replies.

I have another issue now to look at: The FIFO is 8 bit wide. How can I extract 16 bit out of the FIFO in one read clock cycle?

And you are sure you are not trolling? :p Anyways, I am sure that with the previous answer you will manage to figure it out. What with your clear query having been answered. In fact the query was so clear it only took 29 posts for you to get an answer to this clear question that some might consider digital design 101.
 

And you are sure you are not trolling? :p Anyways, I am sure that with the previous answer you will manage to figure it out. What with your clear query having been answered. In fact the query was so clear it only took 29 posts for you to get an answer to this clear question that some might consider digital design 101.

We are not supposed to discuss this issue in thread. Anyways, it took 29 posts not because question was unclear. It took more posts to answer each individual's clarity. Someone who has worked on such issue might have answered quickly. I agree that the solution is equivalent to 101 but I wanted to know how it is solved in practice. I wanted to know different ways that exist in reality to handle such issue. So real such issue can only be told by experience persons not by a 1st yr. student. However I agree if I would have asked the question for persons who have not worked in such situation, it would have understood more quickly and easily because then I would have asked the question such a way that even a student can understand.

Regards
 

You are absolutely right. This had nothing to do with your vague descriptions. I am certain it must have been all those other people on a mission to misunderstand things. Well, glad we got that sorted out. You are well on your way to solve your other remaining issue in no time. Looking forward to reading about the solution in post 58!
 

You are absolutely right. This had nothing to do with your vague descriptions. I am certain it must have been all those other people on a mission to misunderstand things. Well, glad we got that sorted out. You are well on your way to solve your other remaining issue in no time. Looking forward to reading about the solution in post 58!

The second issue for which I have enquired today is clearly understood. Is not it? If it is not clear I can clarify for you. Sorry for inconvenience caused to you.
 

No inconvience whatsover, don't worry. I got to practice my sarcasm skills, so that's all good. Apparently I need the practice...

And your second query is tip top crystal clear. I am confident you shall arrive at a solution, possibly even before post 58. Good luck!

What is your answer to my second query? I do not understand why you want the sacasm skills in you. It may spoil your replationship with others. Anyway this is not my business.
 

What is your answer to my second query? I do not understand why you want the sacasm skills in you. It may spoil your replationship with others. Anyway this is not my business.

We are not supposed to discuss this issue in thread.
 

I shouldn't even bother answering anymore because you seem to think that your lack of clarity is everyone else's fault. But:

You can't extract 16 bits of data out of an 8-bit wide fifo in a single clock cycle- that would make it a

16 BIT WIDE FIFO!!!!!!

This just seems to be the reverse of your original problem.
 

I shouldn't even bother answering anymore because you seem to think that your lack of clarity is everyone else's fault. But:

You can't extract 16 bits of data out of an 8-bit wide fifo in a single clock cycle- that would make it a

16 BIT WIDE FIFO!!!!!!

This just seems to be the reverse of your original problem.

I did not write others are faulty. I also do not say that my post is unclear. We are not supposed to discuss this or quarrel here.

Here we need to read 16 bit together in every read clock cycle. How can I do it? Can anybody please reply?
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top