Astronomer requesting Developemnt Feedback/Guidance (CycIII, Verilog)

[Altera_Forum]

Hi All,  

First off: I'm an astronomer way out of my comfort zone! Second: I'm essentially asking for people to look at what I'm working on, talk about it with me, point out how I've screwed it up, and offer design advice and pointers. I'm not looking for someone to solve my problems (that said, if you are interested in freelancing, let's talk). I realize I've not asked any specific questions nor made any request beyond "Please read and share your thoughts". Admins, if there is a more suitable location for this post, please let me know or move it.   I'm building a custom, high-speed imager for a structured light application in a new astronomical spectrograph. We've got a laser video projector, eight linear CMOS imager chips (Hamamatsu S10453), two 4 channel 8-bit ADCs (AD9289), a Cyclone III (EP3C40F324C8), and a Beagleboard xM (an ARM7 single-board-computer with high speed parallel interface for smartphone cameras and such). The general idea is that the FPGA is controlled via GPIO lines from the BBxM and horizontal (~25kHz, both edges used) and vertical synchronization (~60Hz) signals from the projector. It generates the clock and control signals needed by the imagers and ADCs, receives (and slightly processes) the data from the ADCs, and finally sends it to the BBxM via an 8-bit parallel camera interface.   The analog front end is relatively simple: the FPGA provides a clock (10MHz) and a start signal to the imagers, when start is high they collect the light and when low they clock out the analog pixel data. The ADCs convert all 4 channels simultaneously on the clock, serialize each channel, and send the data out over 4 LVDS DDR channels along with a data clock and a frame clock (80, 40, and 10 MHz, respectively).   The imager has a low-speed and a high-speed mode. In the low-speed mode we expose for an entire projected frame (1 projected frame = 1 4kB frame sent to BBxM). In the high-speed mode we expose for a single horizontal line, readout (roughly 2 lines time), then repeat, capturing lines 1,4,7,… of the first projected frame, dither in time by one horizontal line and capture lines 2,5,8… on the second frame, etc (5 projected frames = 1 ~2.4MB frame sent to BBxM). The logic behind these operating modes is complex and I won't get into it unless someone asks.  I've made a first pass at a schematic top level with verilog modules (readme.rtf in archive). It compiles, but I've not done an SDC file yet, nor have I done logic simulation. I'm sure it would fail on both counts though. ;) I think this pretty much covers it. I'll keep working on the design. I'm about ready to start figuring out how to do my timing constraints and try doing functional logic simulations of some of the blocks. I don't really understand how to do either, but I've watched all the altera training videos and know that is basically my next step. I've attached the Quartus 12 project.  Finally, I realize this is a large request and hope that this isn't violating the social conventions here. Anyway, regardless, thanks for reading.   tl;dr: I'm an astronomer who just started working with FPGAs and verilog. I'm making a custom imager for a spectrograph destined for a observatory in Chile. I would appreciate help with development. Code is attached.

[Altera_Forum]

I realize you have provided an overview of the system, but it would be easier to comment on individual interfaces. Could you please draw a block diagram (or several block diagrams). Show the signals or buses going between devices (or question marks if you haven't figured it out yet). 

 Why use GPIO on the BeagleBoard xM, can't you just connect to the processor's local bus and have your FPGA memory mapped? I know you can do this with the BeagleBone, but I have not looked at the BeagleBoard, so cannot comment on that.  Regarding the comments in the readme.rtf - I can help you figure out how to correctly synchronize your ADCs.  Before you even start to worry about creating the synthesizeable code, you should be creating a Modelsim simulation of each piece of hardware you are interfacing to, and then write the Verilog to implement that interface. A model of each piece of hardware can usually be constructed by implementing its timing diagrams in Verilog. The model does not have to be a perfect copy of the real hardware, but it should reproduce the functions that you are using. Yeah, it sounds like twice as much code, but its not twice as much work, since you will save yourself debug time, and you are also forced to read the data sheet in detail, so you gain a better understanding of the devices.  Cheers, Dave (radio astronomy)

[Altera_Forum]

Hi Dave, 

 I guess it would have been helpful to include a screenshot of the block diagram for people without Quartus. See attached.  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.  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.  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.  --EDIT-- 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.

[Altera_Forum]

--- 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