5
\$\begingroup\$

Hey guys I was referred here from another site and was hoping that someone could help me out.

Some Background Information:

I'm a 4th year EE student at Georgia Tech. A research team with the AE department came around to some of our classes and asked for help with their project for some of their more electronic stuff. I signed up and ended up on the FPGA team which has deteriorated to myself and one other guy, so we're really busy. My current task is to set up a camera to take and store pictures using the FPGA & DSP on this board.

I'm stuck using firewire due to the limitations of the camera and the restrictions on the number of pins that has been allocated to me, so in the last month or so I've been trying to build a link + host layer for a firewire interface with this thing arbitrating for me. I also have to use system verilog. Anyways, I've never used the language before and am having a hard time trying to create one from scratch. The firewire interface seems super complex and I've basically been told "hurry up" by the guys in charge of the project.

Originally I had planned to use this project from opencores.com but it's missing files and I gave up trying to repair it since I don't really know the language all that well, but it looks like I'm probably going to need to either figure out how to fix it or find something else that will work or else I won't be finished in time.

In the top level file it includes a file called fw_link_defines.vh, which I don't have and doesn't seem to be anywhere else on the internet. It looks like it defines(?) three things, if that's what the ` is actually doing in statements like "pkt_type = `SELF_ID_PKT;", which wouldn't be too hard to fix, but there's also some weird thing called phy_ctrl which I thought was a structure or something but after looking on the internet it appears to be an "instantiation". I can't figure out what the heck that actually does. I've looked at a few tutorials but can't seem to find any good ones on them, all I've found is large tutorials with one paragraph that says "this is an instantiation, they are a real pain to work with" and don't really explain much.

(Start here for TL;DR)

Basically what I'm asking is that if anyone knows any other open FPGA projects that use firewire to talk to a device, or if anyone knows a good source to learn how to use instantiations. I've been having a real hard time with this and would be very grateful for any help you could give. Thanks guys.

\$\endgroup\$
1
\$\begingroup\$

Ouch, well i've never worked with firewire at this level before but here are some maybe helpful thoughts:

I read through the TI PHY datasheet that you linked, it looks like its designed to work with the TI Link Layer Controllers. Have you considered just using such a part rather than trying to implement its functionality from scratch?

Also the PHY <-> LLC link runs at full firewire speed, which for 400mbps and an 8bit link is ~50Mhz, the camera may let you get away with running the link much slower, maybe not. Point being you can't just take the pins of that PHY, blue wire them into the FPGA pins and expect a remotely functional or stable connection. You'll very likely have major signal integrity issues.

It looks like the LLC's from TI come in various configurations, some with rather simple, generic 8/16 bit microcontroller style interfaces which should be easy to implement. You can probably find verilog blocks for such an interface freely available. These links would still need to be fast, ~50Mhz so you'll still have the signal integrity issue. You could run it slower i guess but if the data feed overruns the FIFO in the LLC your SOL.

Once your done with the physical interface you still have an entire firewire driver stack to implement, i guess you'd have to do this in the DSP? Or put a small soft core into the FPGA to handle this work?

What I would really do is tell them they are crazy for forcing a firewire interface for something of this size/capabilities. Its going to take a significant amount of resources to build the firewire interface for no gain since you'll never use anywhere near its bandwidth.

If that fails, I'd try something like this which is a single part with the firewire PHY.LLC and an ARM7 core in a single chip. It offers a parallel data bus to get the information into the FPGA. This way you write the firewire driver to support communications to the camera and plunk it in the ARM7 core and all that has to get transfered to the FPGA are the raw images, no overhead work in the FPGA. You still need to carefully design a PCB for this, your still dealing with a very high speed firewire bus.

EDIT:

At 100MBit/s the firewire bus runs at 100MHZ so you have to deal with moving 100MHZ differential signals from the PHY to the firewire connector. On the PHY<->LLC<->FPGA side: I wouldn't personally try to breadboard a 13MHZ parallel data bus, it may be possible if your careful.

The critical issue for signal integrity is the rise/fall time of the signal, not its clock rate. High clock rate usually means faster rise/fall times but sometimes if you use a transceiver thats designed to run at high frequency at lower frequencies it doesn't actually slow down the rise/fall times.

If the wire carrying the signal is longer than:

Tr/(2*Td) with

Tr = the signal rise time at the source and

Td = the propagation delay per unit length of the wire/cable you are using.

Then you need to consider transmission line effects. You'll have to deal with reflections in the wire which will cause all sorts of junk on the line.

You also need to be careful to make sure all the wires of a parallel bus are the same length with the tolerance for variation depending on the clock frequency of the bus.

Is this thing really going to end up in an UAV/RC aircraft? If so you've got to deal with vibrations and G forces as well.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ Thanks for your reply. The camera datasheet they gave me says that it has transmission rates of "100, 200, 400, 800 Mbit/s". Do you think 100Mbit/s (~13 MHz?) would be okay, or is that still too high? >You can probably find verilog blocks for such an interface freely available. That would be amazing. Is there a specific site I would find them, or should they just be on TI's or Altera's sites? Google searches just seem to be finding datasheets. If that doesn't work I'll suggest the LLC chip, though I'm not sure what our power limitations are. Once again, thanks so much for your help! \$\endgroup\$ – PsychoMedic Jun 27 '10 at 9:02
  • \$\begingroup\$ Oh wow sorry for the formatting on that, I didn't realize comments didn't have the normal formatting of regular posts. \$\endgroup\$ – PsychoMedic Jun 27 '10 at 9:03
  • \$\begingroup\$ No worries, the site does alot well, comments is not one of them. \$\endgroup\$ – Kortuk Jun 27 '10 at 15:22
  • \$\begingroup\$ @psychomedic check my edit \$\endgroup\$ – Mark Jun 27 '10 at 17:42
  • \$\begingroup\$ It's supposed to plug right into the header on the board, so hopefully we can get away with it or find some other solution. I think it's supposed to turn on quite a while after it reaches proper altitude, but I'm not sure how the conditions will be up there for vibrations and whatnot. I'll bring it up with them and see what they have to say. Thanks so much for your help. \$\endgroup\$ – PsychoMedic Jun 27 '10 at 21:13
2
\$\begingroup\$

To be honest, if your goal is to get video/pictures from a camera onto a FPGA-based device, a firewire camera is the wrong starting point. You probably should find a camera more suited to your purpose with an easier interface to use. This probably also has the advantage of being much smaller than an off-the-shelf camcorder.

Wait, am I misunderstanding something? I just looked a bit at the link describing the board that has your FPGA on it, and it says it already has a camera built into it? (Omnivision OV5610 5.17 megapixel color CMOS image sensor array). Are you saying it's using Firewire for the on-board connection between the FPGA and the built in camera?

| improve this answer | |
\$\endgroup\$
  • 1
    \$\begingroup\$ Unfortunately I am not in charge of choosing the components, or I would most certainly choose... pretty much anything else. This is the camera we are using: ptgrey.com/products/grasshopper/index.asp It has a general purpose IO but you can't get the pictures off the camera with it and it has volatile memory. As for the onboard camera, I'm pretty sure ours doesn't have that, so I guess I may have used the wrong link, but all the other components are the same, sorry. \$\endgroup\$ – PsychoMedic Jun 29 '10 at 21:23
  • 1
    \$\begingroup\$ You have NO influence on the hardware at all? That's a pretty f**ked up project, since it seems that the capabilities of the firmware is largely determining the feasibility. It might be a good time to basically take a little while to think through what you have to do, and decide if you think it's feasible based on what you know (and it sure sounds like it's not), and if you don't think so, go to the project manager and let them know that it won't work. \$\endgroup\$ – Connor Wolf Aug 11 '10 at 10:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy