Lets say I would like to slow down DVI signal by a factor of 2, basicly elongate every signal variation by 2.

All logic, syncs, clock (obviously)...

Is there an IC that can do this, or I have a long FPGA puzzle ahead of me ?

I was wondering, what is the correct electronics term of ''elongating'' signal variation time by factors of 2/4/8 etc... I am looking for a fancy name.

 

Think about what you are asking your system to do. You data comes in at a rate of R and you want to send that same data out at a rate of R/2. That means that it will take twice as long for your data to leave as it took to arrive. So if you are feeding this think data for an hour, the box has to have the last half hour of that data buffered so that it can finish sending it out. And that just keeps getting worse and worse.

 

I forgot to mention, yes this will be sampled not too often.

4-5 times a second, rest will all be discarded, this will not be viewed or watched or used.

 

In that case, just buffer the frame you are sampling and read it out at the slower rate.

I actually designed a frequency converting buffer that did this automatically. It had three buffers that ran around in a ring. The input wrote to a new buffer if one was available otherwise it just overwrote the data in the existing write buffer. The output read from a new buffer is one was available otherwise is just read the same buffer again. This worked very nicely for converting between the frame rate of the focal plane array and the NTSC output to the monitor.

 

your process, what is it called ?? I'm having a problem of actually writing the data at 100 mhz thats the problem.

frequency buffering ? Basicly nothing of the above brings me to an google leads that make sense, a buffer to me is a high impedance repeater.

I need, the ''official name''... googling purposes.

No slang plz.

 

Believe it or not I'm having trouble finding a cheap solution to write data @ 100 mhz clock without running into problems with interrupt latency and without building an actual computer. I cannot even get to the point of writing down data so fast to then re transmit it, if I could store it I would simply process everything I need. I need basicly a faster xmos.

I need basicly a hardwired logic solution genius flip flop circuit, I know theres a solution but the mental effort will be huge. I need something like an xmos, but faster.

Unless somebody here knows something I dont.

Wbahn, that actually makes sense, I see what you mean now, good idea but no my idea for getting a single chip solution is gone, simply writing the info without any instruction or work to do is fast. But I need 2.4 million pixels x 3 bytes of memory I thought this was gonna be easier than this.

You see ghz on every box of every product I have to do karate to just process a measly 100 mhz operation

 

If your data is coming in at 100MHz, then no matter what you do you are going to have to process it, to some degree at least, at 100MHz.

I think the buzz phrase you are looking for is "frame capture" or "frame grabber". A number of years ago I was looking for a flexible capture card that could capture data off of our chips and thought it would be easy to find one and it wasn't. But I think there are a lot more options (not necessarily cheap) out there now. I would also think that a solution for something as widespread as DVI would be easier to find.

But while a frame grabber will allow you to capture frames of data and perhaps to selectively retransmit them, I doubt any would allow you to put out the signal with a clock rate that was different that what the DVI standard calls for.

Why do you need the slower clock rate?

 

I'm trying to build an automaton, wich directly reads pixel data from a 1024x1280 or a 768x1024 display, wich reads color ''conditions'' and then decides what actions it will take based coordinates. But this is like troubles x 1000 since everything goes so fast there is no time to even do anything with device clock speed so close to process.

I think I'm stupid here you were right Wbahn, there is no FPGA solution, basicly the first few pulses can be followed but then theres just a massive overflow of information... There is no pattern for my mind to wrap around, Ive found pretty complex solutions before but that was a long time ago, I thought there could be but really its an empty desert if you pause and think.

Only solution is to have a very fast processor who can directly process the logic or a write fast/re-transmit slow type of device.

 

Is your automaton running on a PC or other processor? If so, then just use a frame grabber to capture every Nth frame where N is big enough to give you time to process the image.

 

its based on external hardware, whatever that may turn out to be, everything must be totally external , there already exists such software, but I find those lacking in many ways.

 

It's sounding increasingly like you are headed for a custom solution. But there are FPGA development boards that are tailored toward image processing, so you might look to see if one of those can eat a DVI data stream and give you access to the data for your own custom processing blocks.

 

http://www.newelectronics.co.uk/electronics-news/renesas-unveils-cortex-a9-base-mpu-range/45699/

This looks like an interresting chip, with 10Mb of SRAM, this will give me the chance to hold down a frame.

Just hope it doesnt take any fancy compilers like KEIL and that the microE or crosswork for 150-300$ range will support it soon.

I'm gonna ask them .

 

It does, indeed, look interesting. I tend to work in the weeds, but I really should (and would like to) become more familiar with working a bit higher in the stack.

 

Yeha those chips are a pain to work with I know.

Its just so expensive, you cant just try things out.

But a chip like that, if it has some good flash memory like 3 MB+ , its pretty much ultimate level performance, its like basicly a computer in a chip I dont think you can ask for more.

I wonder how ashamed those PLC companies feel when these things come out ? Thay'll argue that its rugged thats what they'll do...

 

Expensive, but amazingly easy to get free samples of some really spendy parts (I have no idea if these chips fall in that mix). But even if you get a $300 part free (and I have on a few occasions), anymore it means high density BGA or similar and it costs a huge amount of time and fab to get a board that will let you do something (unless a decent development board is available and you are able to get THAT for free -- harder, but sometimes still doable).

 

I think I'm just gonna use this FIFO thin g, this company is jewing me out on a ready made chip, because they have features I dont even need...

http://www.latticesemi.com/products/...ramebuffer.cfm

http://www.ti.com/product/sn74v3640

And I think I'll just use an PIC @ 70 mhz, I wished to try and learn ARM, but I dont think ill ever finish anything if every time I need the debud myself via the net to understand the chip....

DVI cable splitted to TMDS 10b/8b receiver deserializer to FIFO to PIC.

Now I just hope a cable splitter doesnt cause me reflections and problems with signal if I keep the wire real short...

http://www.connectworld.net/41215.html

Because an actual screen will be plugged in parallel, to see whats going on when I developp the automaton.