Now, I'm not sure if waitpxx would miss a pulse between 1 and 4 clock cycles wide unless the pulse starts at almost exactly the same time as waitpxx.
Not entirely sure what we are after here but if you sample data afterwaitpxx has recovered than there is a small gap which we can't observe. After the match cycle waitpxx needs 2 more cycles to get out and the data line has to remain stable to be seen by the following sample op (e-phase).
Hanno, that's what I thought. I understood how multiple cogs could be synchronized to read or write at the rate of one r/w per clock cycle, but could not see any way to do that using a pin and waitxx to indicate data was ready before reading it.
Still sometimes falling into old habits of thought when inputting data as my first post in this thread shows.
Excellent ... because I still don't understand how it is done. Could Hanno please help me understand.
This thread is getting a bit confusing. Some are talking about maximum sampling rates where the goal is to take several samples in quick succession. Some others are talking about minimizing the time between a trigger event and the first sample. Lanterfish- what are you interested in?
Hanno
"What would be the fastest sampling speed under the following circumstances:
Assembler: detect sample ready pulse, read 24-bits on port(s) and storing in HUB ram?
Assume 100MHz clock."
Cheers
Based on his first post I think he is talking about minimizing the time between a sample ready pulse, reading 24 data bits on the port pins, and storing it in hub ram.
Under ideal conditions (see the attached .jpg) I believe the data could be read in as little as 8 clock cycles, but in reality it could take 10 to 12 cycles to allow for jitter and other effects. Using multiple synchronized cogs, very tight code, and a 100MHz clock that could result in .833 to 1.25 million samples per second.
True, it is getting a bit confusing and as kwinn states my first question was based around "minimizing the time between a sample ready pulse, reading 24 data bits on the port pins, and storing it in hub ram".
With the AD9985A the trigger for the prop is output fromthe ADC at the pixel clock rate. And this pulse asserts after the data has settled (so shift the data ready pulse to the last 4 clocks in kwinn's post).
Closer reading of the AD9985A's datasheet reveals a (programmable length) Hsync out pulse that is referenced to the sample clock. This pulse asserts approx 2 sample clocks before the first valid data block. So ...
Using this as the trigger (rather than the pixel clock) and using 4 cogs I am assuming that the first cog could sample the first data block, 2nd cog running similar code but padded with NOP or MOV commands so that it should read and store next data block, and so on for other cogs.
Some padding code before looping n times back to sample loop. Once n times samples taken, loop back to WAITXX at start of program.
Will try and find some time tomorrow to draw a timing diagram that may better explain the above. This PC has no drawing software.
Still trying to get my head around the hardware & assembler for the prop so some of this discussion is stretching my current knowledge. Fantastic!!!!
I took a look at the AD9985A data sheet, and that is a pretty impressive chip. I take it you want to synchronize the start of the data acquisition using the horizontal sync signal and then acquire data at the pixel clock rate. If that is the case then multiple synchronized cogs can acquire the data much faster than my earlier estimates.
Here's a somewhat offbeat approach. It's likely to work only if the dot clock bursts between scan lines stay in phase with each other (like the color bursts at the beginning of a video signal). Let's say you have an external PLL which, absent one of its phase comparator inputs (the dot clock), does not change frequency. It won't need a wide capture range, so a VCXO should work as the frequency generator part. Now the VCXO provides the master clock drive for the Prop, instead of an external crystal. That way, the Prop's instructions will always be synchronized to the dot clock, so there's no need for a WAITxxx instruction to monitor it. You just monitor HYSYNC and begin sampling a fixed number of instructions afterwards.
As an example of the kind of PLL I have in mind, take a look at the MC44144 color burst synchronizer.
@ kwinn. Pretty much what I am wanting to achieve. It is the syncronisation of cogs that I am having trouble getting my head around.
@ Phil. Interesting thought. Haven't received the AD9958A yet but should scope it to check the pixel clock output with active video. If constant then could be usable for clocking prop. Is that what you are suggesting?
Haven't received the AD9958A yet but should scope it to check the pixel clock output with active video. If constant then could be usable for clocking prop. Is that what you are suggesting?
Yes. But, if I understand your timing values correctly, you will want to double its frequency from 40 MHz to 80 MHz, which entails an external PLL. Or you could just divide it down to 5 MHz and use the Prop's internal PLL.
I have a suspicion that an external PLL with a gated phase comparator will be necessary if the clocks are absent during the sync intervals.
Yes. But, if I understand your timing values correctly, you will want to double its frequency from 40 MHz to 80 MHz, which entails an external PLL. Or you could just divide it down to 5 MHz and use the Prop's internal PLL.
I have a suspicion that an external PLL with a gated phase comparator will be necessary if the clocks are absent during the sync intervals.
-Phil
From what I understand I can feed 40MHz pixel clock to X1 input and use _CLKMODE = XINPUT + PLL2X command to double.
EDIT: The AD9985A has a mode where in the absence of Hsync in the onboard OSC/PLL will continue to provide pixel clock for up to several lines before starting to lose sync. Must read more about this!
I like Phil's idea- here's another thought in the off-beat direction...
It sounds like your device may not have a 1 to 1 mapping from input pixels to ouput pixels- are you ok with losing one line? If yes- and the jitter between successive lines is low- then you can use the trigger from the first line to start sampling the second line and so forth. What are the resolution of your input/output devices? How quickly do you need to update both?
Hanno
@lanternfish, I took a closer look at the data sheet as well and can see uses for this chip beyond the video applications. I see what you mean regarding the 2 sample clock delay after Hsync. That might be useful for synchronization, but you may have to do something along the lines of what Phil suggested for a reliable sync lock. Can you disclose the pixel clock rate(s) you are going to use and how many pixels you want to transfer to hub ram at one time?
all timings are given in integer numbers of dot clocks. That's good, because it means that the dot clocks from one scan line to the next will always be in phase with each other, which prevents cogging or hunting of the PLL from one scan line to the next.
@lanternfish, I think the mode you are thinking of is the Coast Timing. This locks the PLL frequency for several horizontal lines in those cases where the vertical refresh signal disrupts the hsync.
PS - Most video meant for a computer monitor always has the sync signals present and on separate pins (ie. sync is not on the green signal).
If you are inputting an SVGA signal to the 9985 and want to use the pixel clock for the prop you could double the frequency with a couple of gates and input it directly, or divide it by 8 and use pll16x.
Input will be 800 x 600 60Hz SVGA. Output will 400 (effective) x 300 60Hz. Latency between source & output that won't matter. And at some point input will overtake output and image tearing will occur. will deal with that later.
I had looked at decimating input by only sampling 400 pixels of each subsequent line. May still have to look at that approach as a starting point.
Mind you this could be extended to do 200 sample of each line and outputting an interleave of odd/even lines making one line i.e. sample1 of line 1, sample1 of line 2 .... x 200 = strangely decimated output line 1.
EDIT: input image will look like low-res (colour) cctv images with a lot of noise.
So external hardware could be used to divide pixel clock to whatever rate needed for sample trigger.
As for a 40 MHz pixel clock straight into the prop (#43), the manual (pg. 68 - 71) would indicate that it is a valid solution. Or am I missing something?
As for a 40 MHz pixel clock straight into the prop (#43), the manual (pg. 68 - 71) would indicate that it is a valid solution. Or am I missing something?
The manual is correct. You can drive the XTAL input with 40 MHz. The catch is that it also has to be your system clock frequency, since it's too high to drive the PLL, which requires a base frequency between 4 and 8 Mhz. If you have 40 Mhz and want an 80 MHz system clock, you have to divide the 40 Mhz down to 5 Mhz first, to accommodate the PLL's capture range.
Comments
Not entirely sure what we are after here but if you sample data after waitpxx has recovered than there is a small gap which we can't observe. After the match cycle waitpxx needs 2 more cycles to get out and the data line has to remain stable to be seen by the following sample op (e-phase).
Excellent ... because I still don't understand how it is done. Could Hanno please help me understand.
Thanks
Hanno
Based on his first post I think he is talking about minimizing the time between a sample ready pulse, reading 24 data bits on the port pins, and storing it in hub ram.
Under ideal conditions (see the attached .jpg) I believe the data could be read in as little as 8 clock cycles, but in reality it could take 10 to 12 cycles to allow for jitter and other effects. Using multiple synchronized cogs, very tight code, and a 100MHz clock that could result in .833 to 1.25 million samples per second.
According to the spec sheets, WAITXX consumes a minimum of 5 clocks, not 4 as per your drawing.
Cheers,
Peter (pjv)
True, it is getting a bit confusing and as kwinn states my first question was based around "minimizing the time between a sample ready pulse, reading 24 data bits on the port pins, and storing it in hub ram".
With the AD9985A the trigger for the prop is output fromthe ADC at the pixel clock rate. And this pulse asserts after the data has settled (so shift the data ready pulse to the last 4 clocks in kwinn's post).
Closer reading of the AD9985A's datasheet reveals a (programmable length) Hsync out pulse that is referenced to the sample clock. This pulse asserts approx 2 sample clocks before the first valid data block. So ...
Using this as the trigger (rather than the pixel clock) and using 4 cogs I am assuming that the first cog could sample the first data block, 2nd cog running similar code but padded with NOP or MOV commands so that it should read and store next data block, and so on for other cogs.
Some padding code before looping n times back to sample loop. Once n times samples taken, loop back to WAITXX at start of program.
Will try and find some time tomorrow to draw a timing diagram that may better explain the above. This PC has no drawing software.
Still trying to get my head around the hardware & assembler for the prop so some of this discussion is stretching my current knowledge. Fantastic!!!!
As an example of the kind of PLL I have in mind, take a look at the MC44144 color burst synchronizer.
-Phil
@ Phil. Interesting thought. Haven't received the AD9958A yet but should scope it to check the pixel clock output with active video. If constant then could be usable for clocking prop. Is that what you are suggesting?
I have a suspicion that an external PLL with a gated phase comparator will be necessary if the clocks are absent during the sync intervals.
-Phil
From what I understand I can feed 40MHz pixel clock to X1 input and use _CLKMODE = XINPUT + PLL2X command to double.
EDIT: The AD9985A has a mode where in the absence of Hsync in the onboard OSC/PLL will continue to provide pixel clock for up to several lines before starting to lose sync. Must read more about this!
It sounds like your device may not have a 1 to 1 mapping from input pixels to ouput pixels- are you ok with losing one line? If yes- and the jitter between successive lines is low- then you can use the trigger from the first line to start sampling the second line and so forth. What are the resolution of your input/output devices? How quickly do you need to update both?
Hanno
-Phil
all timings are given in integer numbers of dot clocks. That's good, because it means that the dot clocks from one scan line to the next will always be in phase with each other, which prevents cogging or hunting of the PLL from one scan line to the next.
-Phil
PS - Most video meant for a computer monitor always has the sync signals present and on separate pins (ie. sync is not on the green signal).
-Phil
Input will be 800 x 600 60Hz SVGA. Output will 400 (effective) x 300 60Hz. Latency between source & output that won't matter. And at some point input will overtake output and image tearing will occur. will deal with that later.
I had looked at decimating input by only sampling 400 pixels of each subsequent line. May still have to look at that approach as a starting point.
Mind you this could be extended to do 200 sample of each line and outputting an interleave of odd/even lines making one line i.e. sample1 of line 1, sample1 of line 2 .... x 200 = strangely decimated output line 1.
EDIT: input image will look like low-res (colour) cctv images with a lot of noise.
So external hardware could be used to divide pixel clock to whatever rate needed for sample trigger.
As for a 40 MHz pixel clock straight into the prop (#43), the manual (pg. 68 - 71) would indicate that it is a valid solution. Or am I missing something?
Cheers
-Phil