--- Quote Start ---
I guess it would have been helpful to include a screenshot of the block diagram for people without Quartus. See attached.
--- Quote End ---
A block diagram at the system-level would also be useful, i.e., showing the ADCs, where their clocks come from, cables between boards and the protocols over those cables.
--- Quote Start ---
As to the interface, I'm not actually using GPIO for any heavy lifting. The FPGA PCB connects via the BBxMs camera header which exposes the OMAP CCDC camera interface which we plan to use in 8-bit parallel mode. This interface goes through the silicon on the OMAP which supports resizing memory mapping, etc. and is already integrated into vidoe4linux as the omap3isp. The header also includes an i2c bus, which goes to an SX1503 16 line IO expander. We did because IP cores for i2c were absurdly expensive and we really don't need much other than: reset, on/off, mode, go, test, and fault. Also, we are already on rev 2 & 3 of some of the PCBs in the system, and already have an alpha version of the kernel driver written so I'd like to avoid changing interfaces if possible. The BBxM doesn't expose the GPMC interface due to the POP memory and I wanted to leave the main expansion header open just in case.
--- Quote End ---
Ok, that makes sense. It wasn't clear whether you were using the BeagleBoard-xM just because it sounded like fun, or whether it had interfaces you could use. You have clearly selected it for its features.
--- Quote Start ---
Regarding your comments about modelsim. That seems like really sound advice and is certainly consistent with all I've been reading.
I've already been studying the datasheets timing diagrams quite carefully. Is there a good example of what you are suggesting regarding the interface? I'm unclear as to what I would actually create. Are you referring to a testbench for the modules, by which I mean a verilog file that uses always blocks with timing delays to generate signals which are in turn inputs to my modules? That seems simple enough (I think) for the inputs, but not applicable to the outputs insofar that there are timing requirements on them as well.
--- Quote End ---
Take an ADC as an example. I haven't looked at the part number you mentioned, but some are SPI, some are parallel output, some are non-standard serial output. To design the interface to an ADC, I create a VHDL model of the ADC digital output, and create a simple data source, eg., a static ADC value, read ADC samples from a file, or a real valued port that the testbench drives. I then create the FPGA-side of the ADC interface and create a testbench that checks the value read from the ADC. As I build a larger system, I incorporate more of these models, and the testbench evolves to check every component in the system.
--- Quote Start ---
As an aside, small world. I'm actually over at Carnegie Observatories working on this system and the instrument (a multi-fiber optical spectrograph for the Magellan Clay Telescope) all week.
--- Quote End ---
I'm about 5 hours north of Pasadena (at the Owens Valley Radio Observatory), so we won't get a chance to catch up, sorry! :)
--- Quote Start ---
Also, I forgot to mention: I'm very open to good books anyone knows. I've read through basic tutorials online, but I'm essentially trying to bootstrap myself to the level of "build your own high-speed webcam system from scratch" and most guides I've run across just don't seem to go into enough depth.
--- Quote End ---
I've never found a good book on design; there's too many things you can design, so I suspect its a hard book to write :)
Personally, I buy evaluation kits, reverse-engineer the parts that are not well documented, break things, and learn from the experience.
Cheers,
Dave
Honored Contributor
