VGA framegrabber

[saigai]

Hello forum!

I've just managed to write a big chunk of text about a long time project of mine - a VGA framegrabber.

http://www.rpg.fi/desaster/blog/2013/04/19/vga-framegrabbing-with-tvp7002/

This is a project where I've taken my first steps into FPGA development, and high(er) speed signals in general.

I'm eagerly looking for some thoughts and feedback on this. Up until now, I've been keeping it a secret, to not embarrass myself with overly ambitious tasks

Anything completely ridiculous about the design? Something I should explain in more detail? Any tips on what might be the next logical step in terms of improving the hardware?

(The online demo will not be updating during my sleep hours, since the mini-itx vga source is whining it's stupid fan right in my bedroom.)

[marshallh]

58 views and no replies, crime against humanity.

Nice work there. At some point you will want to move to a dedicated 4layer pcb with a more flexible FPGA like a cyclone III (best combo of bang/buck imo). For higher resolutions I would buffer frames in SDRAM. Your flakiness is probably related to your poor grounding on that one sided pcb you have.

[saigai]

Nice work there. At some point you will want to move to a dedicated 4layer pcb with a more flexible FPGA like a cyclone III (best combo of bang/buck imo). For higher resolutions I would buffer frames in SDRAM. Your flakiness is probably related to your poor grounding on that one sided pcb you have.

Thanks! The board is in fact 2-sided, with bottom side being mostly ground. However it has some silly routing, and I do hope to make a new one. 4-layers would be nice, and is also recommended by TI as the minimum for good thermal performance. However, manufactured boards like that are not the cheapest for prototyping..

Right now I'm happy to have moved from FPGA to CPLD for this. However, as the project moves forward (with things like SDRAM), it may indeed be a good idea to go back to FPGA.

I've been fighting with the ENC28J60 problems again, and the amount of Errata workarounds they have for it makes me thing there may still be something wrong with the driver. I'm just having problems wrapping my head around the whole thing.

[McMonster]

That's a great thing! I worked as a systems admin for some time and in general I often tinker with many different PCs, often old and headless. I don't even have a working display capable of interfacing with VGA/HDMI or anything, when I was setting up my home server I had to borrow LCD monitor from work.

So I had the idea of building a device that could connect to standard PC interfaces (VGA, USB for mouse/keyboard, serial port etc.) and create virtual console on a laptop (which I used to carry anywhere until I switched jobs) over a single USB cable. So basically almost the same thing as your project.

[saigai]

That's a great thing! I worked as a systems admin for some time and in general I often tinker with many different PCs, often old and headless. I don't even have a working display capable of interfacing with VGA/HDMI or anything, when I was setting up my home server I had to borrow LCD monitor from work.

So I had the idea of building a device that could connect to standard PC interfaces (VGA, USB for mouse/keyboard, serial port etc.) and create virtual console on a laptop (which I used to carry anywhere until I switched jobs) over a single USB cable. So basically almost the same thing as your project.

I've also worked as a sysadmin, managing several headless servers. For this kind of stuff a network based KVM is a necessity.

The KVM's that I worked with were quite expensive, and had ugly/clumsy user interfaces. Although my project can't match their performance yet, I do see several ways of making the user experience better Never had a chance to teardown one of those the inspect their inner workings..

Did your device develop beyond idea? I haven't really found any "prior art" to look into, so I'm interested in hearing about similar projects

[hans]

Nice work there. At some point you will want to move to a dedicated 4layer pcb with a more flexible FPGA like a cyclone III (best combo of bang/buck imo). For higher resolutions I would buffer frames in SDRAM. Your flakiness is probably related to your poor grounding on that one sided pcb you have.

Thanks! The board is in fact 2-sided, with bottom side being mostly ground. However it has some silly routing, and I do hope to make a new one. 4-layers would be nice, and is also recommended by TI as the minimum for good thermal performance. However, manufactured boards like that are not the cheapest for prototyping..

Right now I'm happy to have moved from FPGA to CPLD for this. However, as the project moves forward (with things like SDRAM), it may indeed be a good idea to go back to FPGA.

I've been fighting with the ENC28J60 problems again, and the amount of Errata workarounds they have for it makes me thing there may still be something wrong with the driver. I'm just having problems wrapping my head around the whole thing.

I've also been writing my own Mac/IP stack code for the ENC28j60, and I agree.. the errata is quite a list of things gone wrong..
Did you check out the errata for the new enc424/624j600 chips? The datasheet boasts "Hardware AES encryption core"
Read the errata. "Encryption core not working" -> "At room temperature it works, but outside it doesn't. Workaround: use software AES, Microchip AES libraries provided" - argh!

Anyway, what exact problems are you having? Also, what chip revision?

Nice project by the way. As I see you're having lots of parallel busses, you could make use of the parallel feature on the newer ENC624j600 chips though. It's 100Mbit instead of 10Mbit, and it can be addressed basically like a SRAM chip of 32kB size (24kB data buffer). Maybe that way you can copy data from SRAM to the ethernet packet buffer with the CLPD/FPGA and possibly have the CPU handle the TCP/IP stack story (with some protocol in between to command data copying).
Although, that doesn't hugely complicated and maybe a Phy chip for the LPC1768 is an option too if you want to get rid of the ENC28j60.

[McMonster]

I've also worked as a sysadmin, managing several headless servers. For this kind of stuff a network based KVM is a necessity.

Fortunately there's a lot of professional, complex hardware for that. Managing IBM Blade servers for example is really simple. What I really missed is a small, semi-professional tool I could carry around.

Did your device develop beyond idea? I haven't really found any "prior art" to look into, so I'm interested in hearing about similar projects

Unfortunately not, I experience chronic free time shortage (full time job, master thesis, delayed already...). But I did google for a device like that and found something more or less what I wanted, but was painfully expensive. Can't remember where it was.

[saigai]

I've also been writing my own Mac/IP stack code for the ENC28j60, and I agree.. the errata is quite a list of things gone wrong..
Did you check out the errata for the new enc424/624j600 chips? The datasheet boasts "Hardware AES encryption core"
Read the errata. "Encryption core not working" -> "At room temperature it works, but outside it doesn't. Workaround: use software AES, Microchip AES libraries provided" - argh!

Anyway, what exact problems are you having? Also, what chip revision?

Nice project by the way. As I see you're having lots of parallel busses, you could make use of the parallel feature on the newer ENC624j600 chips though. It's 100Mbit instead of 10Mbit, and it can be addressed basically like a SRAM chip of 32kB size (24kB data buffer). Maybe that way you can copy data from SRAM to the ethernet packet buffer with the CLPD/FPGA and possibly have the CPU handle the TCP/IP stack story (with some protocol in between to command data copying).
Although, that doesn't hugely complicated and maybe a Phy chip for the LPC1768 is an option too if you want to get rid of the ENC28j60.

The problem is hard to describe, at some point the chip may simply stop receiving packets (which I'm looking into now, it's probably the interrupt flag), or transmitted/received packets may start getting all sorts of random error statuses - and the MAC address may reset back to zeroes.

I'm still trying to figure out what exactly is happening, but it's a difficult thing to debug; sometimes it can work for a long time! Maybe due to changes in room temperature 

Right now I've noticed that I have overlooked this errata entry (my REVID is 0x06, so B7)

The Receive Packet Pending Interrupt Flag
(EIR.PKTIF) does not reliably/accurately report
the status of pending packets.

I've fixed this, but having seen different types of failure, I don't have high hopes of this fixing everything..

The reason why I'm having such a hard time with this, is of course the fact that I haven't actually started from ground up. I've started by using someone else's driver (probably for another revision), and trying to figure out things as I go. I've read code snippets more than the actual datasheet.

For this project, I want to eventually look at another PHY chip, but the enc28j60 is still a very interesting chip, because I could use it for all sorts of projects involving smaller microcontrollers.

[saigai]

But I did google for a device like that and found something more or less what I wanted, but was painfully expensive. Can't remember where it was.

This is one device I found when researching this stuff:

http://www.epiphan.com/products/frame-grabbers/vga2usb/

A bit expensive for non-professional use... but looks shiny