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.

eliminating intermediate delay

Status
Not open for further replies.

win2010

Member level 1
Joined
Sep 30, 2010
Messages
35
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,605
Hello,

Input bits are continuous but I need add Header for each and every time, so only I`m missing input.
I designed this by taking Buffer but this is going Overflow after some time.
Ex:
I had continuous input bits and for each and every 20 bits of input I need to generate 5 bits of Header to 20 bits data.
For 20 input bits i generated 25 bits. while sending to output these 25 bits, i am missing 5 bits of next coming inputs.

I need output should not have any intermediate delay.....

Help me....
Vinayak
 

Your question is not very clear. Where are these bits coming from? where are they going? what packets are you making? can you post any code?
 

It appears you have a rate mismatch between the input and the output of your buffer. (fill rate v.s. drain rate)

a) if the buffer only contains the 20-bit data without the headers (headers are added when reading buffer).
You need to unload the buffer at a faster clock rate so you have time to insert the headers. Assuming serial you need a buffer read clock that is at least 5/4*Freq_in

b) if the buffer contains the 5-bit header and the 20-bit data (headers added when writing to buffer).
You should perform serial to parallel conversion of the data before writing, otherwise you don't have enough clock cycles on the write side to add the 5-bit header (this assumes the buffer write clock is the same as the input data clock). You still need to perform the buffer reads at the higher rate otherwise the buffer will overflow (note: if you need the data to be serial then you have to perform a parallel to serial conversion for each header+data).

c) if the buffer can contain the 5-bit header, make the header a sideband of information.
Make your serial buffer a 2-bit wide buffer that contains {hdr_bit, data_bit}. The header field could simply have a start bit followed by 5-bit header followed by 14 0's (might be helpful to ensure alignment of the serial data stream). In this case the write and read rates are the same.

Perhaps that will give you some ideas of how to approach your problem.

Note: all of these will introduce a fixed latency (per data word in a & b). You are asking the impossible of no intermediate delay, which means to me no extra latency between input and output.


regards
 
Last edited:
My question is simple, I need to send 32208 bits of serial data within the 32128 clock per bit of input.....

How to do this rate change between input and output...?

output has more data than input....
 
Last edited:

I already told you how to do it in post #2.

Maybe instead of using a FIFO like mrfibble stated you need to use brain cells first and read post #2 carefully.
 

Yes first time i did`t get so only i further post new one. Thanks "ads-ee".

Your post clearly says all possibilities.

to "ads-ee" : please little bit elaborate your (c) answer.

How to do two different clock for read and write...? (read is faster than write)
 
Last edited:

to "ads-ee" : please little bit elaborate your (c) answer.

How to do two different clock for read and write...? (read is faster than write)

Alternative plan: how about you summarize what you understood about it so far. And then ask a specific question regarding the specific bit you do not specifically understand. (and no, that thingy "c" does not qualify as specific). Instead of asking "explain me moooooore". Just an idea, to optimize use of time and all that. :)
 

As a picture is worth a thousand words...

You could represent the data in the following manner, with time increasing to the right.
Capture.PNG
 
Thank you.......

But my next block is randomizer(PRBS). Which will start with a Header(5 - bits) first and later 20 bits data. I maintain one extra buffer for 20 bit data also which is overflowing because next header will come when I outputting 20 to 25th datas of previous.



 
Last edited:

Is the 5-bit header part of the data that gets randomized?

You are having a problem with overflow because as I stated before you have to either 1) use different frequency clocks on the write side of the buffer and the read side of the buffer, 2) Find a way to make the design more parallel.

Post #9 was one method of making the data parallel with the header (option 2). If that can't be done then start DESIGNING something that will work in your application.

Or you could start supplying the criteria that makes it impossible to use either option 1 or 2, instead of just telling us about how you have 25-bits of header+data and you can only pull out 20-bits of the 25-bits before overflowing.
 
Last edited:

Yes, randomizer will start with 5 bit header and later 20 bits data....

I am trying to increase the buffer read rate than write, so i can manege these extra bits throughout my program.

- - - Updated - - -

My next difficulty is reading data at 5/4 * clk_frequency.
I can do double clock rate using DCM in Xilinx but generating different READ RATES(like 2013/2008, 676/675) not getting.
 

Yes, randomizer will start with 5 bit header and later 20 bits data....
Okay so you have to either increase the read clock rate or make the randomizer and subsequent block parallel implementations instead of serial.

I am trying to increase the buffer read rate than write, so i can manege these extra bits throughout my program.
My next difficulty is reading data at 5/4 * clk_frequency.
I hope these statements mean you plan on increasing the read side clock rate.

I can do double clock rate using DCM in Xilinx but generating different READ RATES(like 2013/2008, 676/675) not getting.
I'm not quite following what you are saying here about the read rate ratios you're listing.

I'm getting the impression your problems have more to do with not understanding how to develop an architecture (not the VHDL keyword) for a design or multiple architectures and select the most appropriate one that fits the requirements. Basically all of your questions up to this point have been architectural trade offs for your design.

Regards
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top