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.

Dual Clock FIFO for clock crossing of continuos data

Status
Not open for further replies.

flote21

Advanced Member level 1
Joined
Jan 22, 2014
Messages
411
Helped
1
Reputation
2
Reaction score
3
Trophy points
1,298
Activity points
5,595
Hello guys!

I am wondering if there is any technique to buffering incoming data from 100MHz to 60MHz.

I have been thinking to use a ring memory and a DCfifo to handle this amount of data...but I am not sure how to do it. And I am not which should be the depth of the DCfifo too..

I will describe the scenario:

I have a sensor which sends 14 bits of data at 100MHz continuously with not stop.
I have a FPGA with a 1Gb ETH ip core running at 60MHz.
I need to transfer all the data provided by the sensor at 100MHz to the PC using the FPGA like a interface and make a cross clock of the data from 100MHz to 60MHz.
So basically I have to questions:
1) if the sensor can't stop to send data and I need to send all the data to PC. Is there any technique to buffering the data at ,100MhZ to 60MHz without losses?
2) if in thr best of the situations, we are able to make the cross clocking of the data. The next equation to estimate the Ethernet Data Rate is right?
EthDataRate=14bits x 60MHz =840Mbs < 1Gbs => Ethernet transferring OK!

Regards!!
 

14b * 100MHz = 1.4Mbps. This is too much.

There is probably not a way to send all of the data over a single 1gbps link. If you can make assumptions about the data to allow compression, then you might be ok.

For the fifo you want, you have a width conversion to preserve bandwidth. eg 28b @ 60MHz reading, 14b @ 100MHz writing. However the ethernet link won't allow this. You'll probably end up with 8b samples in the end, or you'll move to link aggregation and get two 1gbps ports (or a 10gbps port).
 

Therefore is it possible to buffer continuos 14bit data at 100 MHz to 60,MHz without pause?? If this is so I guess that you have to use a dual clock FIFO. Which should be the depth of that FIFO?
On the other hand the Ethernet Rate is under the limit because when you buffer the data with the dual clock FIFO you are transferring the data at 60MHz. So 14b x 60Mhz = 840Mbs. I don't get why do you say that I will need a 2 links of 1Gbs or one link of 10Gbs...
 

If the input is constant at 14b at 100 MHz then unless there is a change in data width for the 60 MHz domain (to 28b) the FIFO will overflow, as the input BW is higher than the op BW.
 

But with 28b I am over the limit of the 1gb Ethernet ip core because 28b x 60MHz = 1.68Gbs....so I can't handle this amount of data and I will need to do a pause of the incoming data...right?
 

Hi,

you say the input datastream is "14 bits of data at 100MHz continuously with not stop."

--> it makes 1.4GBits/s.

Try one of the folowing:
* Reduce input data width
* Reduce input data rate
* don´t use continous datastream, but use block datastream with gaps.
* compress data
* increase output data rate

Klaus
 

Hi!
* Reduce input data width
* Reduce input data rate => it is not possible because it is the output of the ADC and we don't want to lose dynamic range..
* don´t use continous datastream, but use block datastream with gaps. => then we will loose information and it is also don't allow..we need a continuous acquisition..
* compress data => if we compress the data we miss pixel information and for material identification with high accuracy application is also not allow...
* increase output data. I don't get this part. Do you mean increase the output data of the sensor? Or do you mean increase the output data of the dual clock FIFO? The first one is not possible because the maximum speed of sensor + ADC is 100MHz. And the second one is also not possible because the maximum working speed of the Ethernet ip core is 60MHz and we need to make the adjustment of the speed with the dual clock FIFO being care of the data rata too.

Regards
 

Hi,

you talk about pixel.. so it is an image processing application.
* maybe it is possible to select an "area of interest"
* 14 bit ADC for image processing is a lot. Is 14 bit for single channel (one color) or combined (RGB)?
* compresion doesn´t necessarily mean you loose pixel information. There are a lot of compression methods without loss of information.
* Do the image processing (or only a part of it) in the FPGA to reduce the ammount of information.


Output rate: I mean the output rate of the FIFO.
* Why 60MHz? Can´t you use a higher rate?
* maybe use multiple ethernet channels. I don´t know if this is possible.
* Select another interface. Maybe some multi channel LVDS. (3GBit/s, 6GBit/s...)

I´m wondering: What hardware is able to process those ammount of data in real time?

Klaus
 

If it outputs a standard video format - then you will have blank regions in the picture on the end of each line and between fields/frames, for about 1/3 of the incoming data stream. These areas dont need to be input to the FIFO.
 

Well it is not exactly video pixels. The sensor is not an image sensor. It is an X-RAY sensor with an analog output which it is able to identify different kind of materials. Therefore the analog output is codified using an external ADC of 14 bits. And we need this resolution to identify materials with similar properties....this resolution is something that we can't reduce because with less resolution we won't be able to identify some materials.
So let's going to assume that i need to compress 14 bits into 8 bits to transfer that data at 60Mhz to the PC through ethernet 1Gb without having eth data rate issues....Can you recommend me any compression algorithm?

The ADC is giving the data to the FPGA at 100 MHz. I can't send data to the PC at 100 MHz because I will have an overload of the ethernet card:

ETH_DATA_RATE = Number of bix X Frequency = 14 bits x 100MHz = 1.4 Gps >>>> 1 Gb (maximum data rate)

Therefore to solve the Ethernet data rate issue I am thinking to reduce the Speed through DC FIFO + compress the number of bit => 60 MHz + 8 bits:

ETH_DATA_RATE = 8 bits x 60 MHz = 480 Mbs << 1Gb

however if you can give me some good compression algorithm to scale 14 bits of data into 8 bits, it will possible to remove the DCFIFO and send the data directly @100MHy because:

ETH_DATA_RATE = 8 bits x 100MHz = 800 Mbs << 1Gb

Can you tell me the name of a good compression algorithm?

thanks!
 

Hi,

you still misunderstand the datarate mismatch.

It is not possible to write a FIFO with 100MHz and read it with 60MHz.
This causes data overflow in the FIFO and you will loose data.

If you feed the FIFO with 100MHz x 14 bits you need to read the FIFO at the 60MHz domain with 2x 14 bits = 28 bits. (preferred)

*****
A simple 14 bit to 8 bit conversion is possible. It just makes the resolution "non linear". In voice tranmission one used a u-law A-law compression.
But this is a single pixel conversion with loss of information. As far as i understand your application you need the resolution down to one LSB with low level signals but with high level signals you don´t need the resolution down to 1 LSB. So most probably you can live with the loss of information with unlinear resolution. But you have to decide.

I´m not sure .. is it a single sensor, a line sensor (with multiple single sensors in a line), or a two dimensional array (image) sensor?

There are different solution for all the sensors.

**
I once developed a sophisticated x-ray measurement tool. A dose meter (dual channel for kV measurement) with huge input range of 1: 100.000.000.
No need for manual range setup. Not missing a single sample. No overflow on a single sample. But much lower sample rate.
So maybe i can give you some hints..

Klaus
 

Did you look to use another transmission link like Camera Link or CoaXpress instead of Ethernet? They offer more bandwidth but you need a frame grabber to get the image on the computer.
 

Did you look to use another transmission link like Camera Link or CoaXpress instead of Ethernet? They offer more bandwidth but you need a frame grabber to get the image on the computer.

Or more generally, where is the requirement for using Ethernet actually coming from and can that be changed?

To follow up on Tricky's line of thought, even though your X-ray is not 'video', it is highly unlikely that the sensor is really transmitting valid data at an exactly 100 MHz rate. That rate is probably the peak rate that one must still be able to handle, but it would not be the overall data rate.

By the way, you do realize that Ethernet, if it is actually required, will not guarantee you the bandwidth that you need. Unless you have a point-to-point connection, there will be others on the network as well using bandwidth. If it is a point-to-point connection, then you should really question the need for Ethernet. If a dedicated connection is needed, why would any specific interface then be a requirement? Why not USB 3 (as an example)?

The dual clock fifo is the least of your worries at this point.

Kevin Jennings
 

@KlausST

I know that i will have an overflow problem if i write at 100 MHZ and I read at 60MHz. But if i can compress the data from 14 bits to 8 bits I can transfer "2 pixels" of 16 bits at 60MHZ and I won't have the overflow problem because I can package 2 incomming pixels at 100 MHZ in 2 system clocks => 1 package of two pixels at 50MHz => No overflow of FIFO.

The main problem under my eyes is to find the proper compression algorithm to adapt 14 bits to 8 bits without too much looses...I am very open mind to listen your ideas...

The sensor is just one output. It is not an array or something like that. So it is giving to you a normal analog output for every exposure shot.

Your prjject with X-RAY looks very interested. I will come to you for some questions when I have my project in further steps.

@Tetik and K-J

It is not possible to change the interface. It is a point to point connection and the lenght between the sensor and the PC is around 30-50 metres...So ETH is the best soulution for this application. But if you have any other suggestion I can listen to that...

Thanks!
 

Hi,

can you tell how you process the data in your PC?

*****

Do you really need that 100MS/s in your PC? (10ns of timing resolution, 50MHz analog bandwidth?)
What is the analog bandwidth of your input signal?

I can think of downsampling the data in your FPGA:
* Input with 100MS/s
* filter
* output with 25MS/s (or sth else)

So you loose timing information, but no resolution. Is this a way to go?

Klaus
 

two 1gbe links using port aggregation or 1 10gbe link are both options. These also allow 16b samples to be sent, making it easier for software to handle the data.

Without research on the actual requirements, it is hard to suggest anything but default compression algorithms. delta encodings and custom floating point are two choices.
 

It is not possible to change the interface. It is a point to point connection and the lenght between the sensor and the PC is around 30-50 metres...So ETH is the best soulution for this application. But if you have any other suggestion I can listen to that...

CoaXpress supports 2.5Gbps over 55m with a coax cable.
**broken link removed**
 

If you want to "compress" 14-bits to 8-bits you need to rethink what you are doing. You won't be able to find a compression algorithm that can compress 14-bits to 8-bits unless it's called truncation. You can possibly compress the entire image before sending it over the Ethernet link, but you'll need to capture the entire image first then compress then send, which means you'll need to store possibly as much as four times the image size.
1. the first image buffer to compress, using something like LZW
2. the compression output buffer for the first image
3. the next input buffer being captured while the first is getting compressed.
4. the compression output buffer for the second image
You would have to ping-pong between the buffers, while one pair of input and output buffers is getting loaded/sending the other is pair is reading and compressing. I know there are other methods of compressing data using some run length type algorithms (sequences of 1s or 0s), but most of those have such variability in compression that you may have issues with buffer overruns depending on the images captured.
 

Hi,

The PC is getting the pixels and it has to “draw” the amplitude of the X-ray pulses along the time. The PC is stupid. Just organize the pixels and it displays them on the screen.

I don’t need 100mbs in the PC side. What I need is to send all the pixels on real time without losing anyone. A down-sampling is not a solution because I will lose pixels and this is not ok. The minimum working frequency of the Eth ip core is 35MHz.

It is not possible to change the WTH interface of 1Gb, it is something that it is mandatory. So the development of this project should with the ETH 1Gbs.

On the other hand compressing an image, storing the complete image in a DDR memory is not also any solution, because this sensor is not giving to you exactly video information. The truncation of the pixels could be a solution to test if the sensor is sending right data or not. And I would say that I am gonna try to do it like that in the beginning. In the future I will think some kind of pixel processing on real time in the FPGA to send only the important information of the data captured.

Thank you everybody for the answers!

I will keep you informed!
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top