That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.
Guess what? The Prop2 has no equivalent mode!
Here's a commented snippet: (Inputs A and B are the same pin in James's test code)
mov i, looplength
mov j, looplength
mov frqb, #1 ' start rectangular (flat +1 increment) for input B
uploop add frqa, #1 ' start triangular (ramp the increment up and down) for input A
djnz i, #uploop ' ramp up
downloop sub frqa, #1
djnz j, #downloop ' ramp down
mov frqb, #0 ' stop rectangular for input B
mov frqa, #0 ' stop triangular for input A
wrlong phsa, adcp_tri ' post triangular sample
wrlong phsb, adcp_rect ' post rectangular sample
So, you are thinking there should be some time-varying weighted windowing mode?
So, you are thinking there should be some time-varying weighted windowing mode?
I was thinking, partly because this technique has made me think some backwards compatibility might be a good idea, more about providing a mode with the same frqa (Y) and phsa (Z) arrangement as the Prop1. Everything else from the Prop1 counters already exists in the input config I think.
Of course, as is often the case with the Prop1, this technique requires a cog to be 100% on the job to make it work. That's a put off for most people when thinking about the Prop2.
Of course, as is often the case with the Prop1, this technique requires a cog to be 100% on the job to make it work. That's a put off for most people when thinking about the Prop2.
That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.
Guess what? The Prop2 has no equivalent mode!
Evan, before you edited your post you said: "That's a whole new trick for the Prop1 - performing a sinc2 function." I think the P1 code applies separate rectangular and triangular windows, which are Sinc1 and Sinc2, respectively. Convolving M identical rectangular window functions together produces SincM.
I mentioned implementing Sinc2 are few days ago and this was the response:
The Sinc3 logic could also do Sinc1 and Sinc2 if half the adder inputs are held low, so that acc3=acc2=acc1 or acc3=acc2.
Does SINC2 have any special appeal?
Don't think so, initial responses to reset are identical.
So, we will provide a third-order filter, but there's really no reason to bother with a second-order filter, right? If we have a third-order, who cares about a second-order? Any second-order implementation would rather have been a third-order, given the resources were available. That's how I see it.
I've done quite a lot reading in the last couple of weeks and a sigma-delta modulator of order N requires a filter of order N+1. This fact has been mentioned on the forum before and it explains why a triangular window gives so much better results than a rectangular.
If a future P2 has a second-order modulator then Sinc3 will be able to cope with it, but as the current P2 has a first-order modulator why have a Sinc1 mode when it will never produce good results?
TonyB_, I just downloaded Logic Friday. Pretty neat!
I'm seeing about making counter-adder values for each bit in the Tukey.
Creating a truth table for it is easy. Shame about the annoying equation syntax, though. Minimize jointly could be the best option in this case. Always select exact.
Here is the new scope code that does the 29-tap Hann and 45-tap Tukey filtering. This filter change only added two ALM's. We are now at 84.
Could we use an existing up/down counter for the plateau bits? Count enable = plateau in bit XOR plateau out bit and up/!down = plateau in. Add ramp and plateau values to get output. To detect overflow, if plateau count > 0 and output = 0, then output = FF.
You've already implemented the overflow detection. The plateau counter must be zeroed whenever there is a mode change, including Tukey to Hann-like and vice-versa.
If a future P2 has a second-order modulator then Sinc3 will be able to cope with it, but as the current P2 has a first-order modulator why have a Sinc1 mode when it will never produce good results?
Don't forget this mode also needs to work with external modulators, many of which are available in isolated, and/or better ENOB than P2.
Also, given the high sysclks in P2, I'm not sure anything can be called strictly first-order.
I'm seeing about making counter-adder values for each bit in the Tukey.
An up/down saturating counter can reduce (halve) the ROM size, and if 1-step-triangle is 'good enough', there is no ROM needed at all.
This is for your scope-mode, right ? - so you target speed over bits in this case ?
My preference is to prefer Flipflops over ROMs as I know the tools will properly optimize FF, and there is no hidden routing cost.
I'm seeing about making counter-adder values for each bit in the Tukey.
An up/down saturating counter can reduce (halve) the ROM size, and if 1-step-triangle is 'good enough', there is no ROM needed at all.
This is for your scope-mode, right ? - so you target speed over bits in this case ?
My preference is to prefer Flipflops over ROMs as I know the tools will properly optimize FF, and there is no hidden routing cost.
It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:
1. New addx3 logic for (t1+t3)*3, (t7+t10)*3,(t8+t12)*3, (t5+t11)*3
2. A counter for 16* terms as these bits are sequential, in similar way to plateau.
It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:
If I code that for drive from a U/D counter, the skirts portion alone packs to a 4i ROM, of PT 1,3,4,4,4,4
If I then support the flat ( clean flat assumed, no 1f ) via a larger U/D counter, it becomes 5i ROM, PT of 3,3,4,4,4
The U/D+DIRN counter(6 bits) then counts up to half way, then flips and counts down. Ctr Values >= 0xe generate 0x20 flat output.
The ROM is smaller in width because the DIRN bit is outside the ROM, and the generated terms are less, as skirts naturally mirror by direction.
1. New addx3 logic for (t1+t3)*3, (t7+t10)*3,(t8+t12)*3, (t5+t11)*3
2. A counter for 16* terms as these bits are sequential, in similar way to plateau.
I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.
Nice, but does it need to be that comprehensive ?
7 or even 6 bit trigger levels would save logic - even 5 bits is a 3% increment in LSB ?
I think you need to be brutal about added logic, and pare things to minimal on anything that multiplies by 64x.
Here's the test code that runs on the FPGA with the SINC3 smart pin and two real I/O pins on the pad ring test chip:
....
Okay! I just wired in a quiet 3.3V regulator and things are looking WAY better:
I think that means 250MHz sysclk gives 8b at 15.625 Msps, right ? Which is above the ADC roll-off ?
If you can get those silicon results using sinc3, I'm still unclear why a separate (logic costly) scope-mode filter is needed ?
Here's the test code that runs on the FPGA with the SINC3 smart pin and two real I/O pins on the pad ring test chip:
....
Okay! I just wired in a quiet 3.3V regulator and things are looking WAY better:
I think that means 250MHz sysclk gives 8b at 15.625 Msps, right ? Which is above the ADC roll-off ?
If you can get those silicon results using sinc3, I'm still unclear why a separate (logic costly) scope-mode filter is needed ?
It's automated and very simple to use. I'm hoping the logic size comes way down. Waiting to hear from ON Semi on the latest compile.
I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.
Very nice. I can imagine that a scope mode could become very useful in a pinch and could potentially save dragging out and connecting up a real scope at times for some lower frequency work. I can ultimately imagine code for VGA+scope debug COGs in the OBEX2 as well as logic analyser stuff. Hopefully it (and other changes) can still all fit...
I got the trigger working in the scope smart pin. You can set two 8-bit levels and a 1-bit slope.
For positive slope, it must go below the X[7:0] value to arm and then above the X[15:8] value to trigger and disarm:
Another thought here - What about using the Threshold DAC and comparator, I think are already there ? How fast are those ?
You could have a sticky output and an ARMED approach, to make it more tolerant of whatever low hysteresis the threshold detector has ?
At even less logic cost ?
That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.
Guess what? The Prop2 has no equivalent mode!
Here's a commented snippet: (Inputs A and B are the same pin in James's test code)
mov i, looplength
mov j, looplength
mov frqb, #1 ' start rectangular (flat +1 increment) for input B
uploop add frqa, #1 ' start triangular (ramp the increment up and down) for input A
djnz i, #uploop ' ramp up
downloop sub frqa, #1
djnz j, #downloop ' ramp down
mov frqb, #0 ' stop rectangular for input B
mov frqa, #0 ' stop triangular for input A
wrlong phsa, adcp_tri ' post triangular sample
wrlong phsb, adcp_rect ' post rectangular sample
CAUTION If actually implementing this, the last two lines write the PHSx shadow registers to hubram. Which were previously set to zero. Consider it PASM pseudo-code.
The rectangular window measurement is merely for comparison purposes.
That's a whole new trick for the Prop1. The ramping isn't every sysclock but maybe that isn't so terrible. Certainly his results look great. And, in theory, the shape can be more complex.
Guess what? The Prop2 has no equivalent mode!
Here's a commented snippet: (Inputs A and B are the same pin in James's test code)
mov i, looplength
mov j, looplength
mov frqb, #1 ' start rectangular (flat +1 increment) for input B
uploop add frqa, #1 ' start triangular (ramp the increment up and down) for input A
djnz i, #uploop ' ramp up
downloop sub frqa, #1
djnz j, #downloop ' ramp down
mov frqb, #0 ' stop rectangular for input B
mov frqa, #0 ' stop triangular for input A
wrlong phsa, adcp_tri ' post triangular sample
wrlong phsb, adcp_rect ' post rectangular sample
CAUTION If actually implementing this, the last two lines write the PHSx shadow registers to hubram. Which were previously set to zero. Consider it PASM pseudo-code.
The rectangular window measurement is merely for comparison purposes.
Chip,
I haven't been properly following the ADC saga, so this may be way off base...
There is some noise problem that shows up every 7-8 bits???
Could this possibly be some sort of sign extension bug???
I am not convinced you have got to the root cause of the ADC problems. To me, it seems that you/others are trying to solve a problem that is not sufficiently understood by throwing all sorts of software solutions to the problem and then trying to make the hardware implement them.
IMHO weeks have been wasted that could have been better spent on testing the P2, and/or writing things that really matter much more such as SPIN2 etc.
Comments
Does that cost money each time? Or is there a certain amount of testing covered in the standard fee?
It's all part of the program.
So, you are thinking there should be some time-varying weighted windowing mode?
I was thinking, partly because this technique has made me think some backwards compatibility might be a good idea, more about providing a mode with the same frqa (Y) and phsa (Z) arrangement as the Prop1. Everything else from the Prop1 counters already exists in the input config I think.
I was thinking the same thing.
Evan, before you edited your post you said: "That's a whole new trick for the Prop1 - performing a sinc2 function." I think the P1 code applies separate rectangular and triangular windows, which are Sinc1 and Sinc2, respectively. Convolving M identical rectangular window functions together produces SincM.
I mentioned implementing Sinc2 are few days ago and this was the response:
I've done quite a lot reading in the last couple of weeks and a sigma-delta modulator of order N requires a filter of order N+1. This fact has been mentioned on the forum before and it explains why a triangular window gives so much better results than a rectangular.
If a future P2 has a second-order modulator then Sinc3 will be able to cope with it, but as the current P2 has a first-order modulator why have a Sinc1 mode when it will never produce good results?
I'm seeing about making counter-adder values for each bit in the Tukey.
Creating a truth table for it is easy. Shame about the annoying equation syntax, though. Minimize jointly could be the best option in this case. Always select exact.
I've found my post about plateau counting:
You've already implemented the overflow detection. The plateau counter must be zeroed whenever there is a mode change, including Tukey to Hann-like and vice-versa.
Don't forget this mode also needs to work with external modulators, many of which are available in isolated, and/or better ENOB than P2.
Also, given the high sysclks in P2, I'm not sure anything can be called strictly first-order.
This is for your scope-mode, right ? - so you target speed over bits in this case ?
My preference is to prefer Flipflops over ROMs as I know the tools will properly optimize FF, and there is no hidden routing cost.
It counts up bits for each bitN in the tap weights and then sums the sums at offsets to get the sample:
up ramp taps and coefficients: t0, t1, t2, t3, t4, t5, t6, t7, t8, t9,t10,t11,t12 1, 3, 5, 7, 10, 13, 16, 19, 22, 25, 27, 29, 31 up ramp sum = 1*(t0 +t1 +t2 +t3 +t5 +t7 +t9+t10+t11+t12) + 2*( t1 +t3 +t4 +t7 +t8 +t10 +t12) + 4*( t2 +t3 +t5 +t8 +t11+t12) + 8*( t4 +t5 t9+t10+t11+t12) + 16*( t6 +t7 +t8 +t9+t10+t11+t12) Separating 3*, 6* and 12* terms, up ramp sum = 1*(t0 +t2 +t5 +t9 +t11+t12) + 2*( t4 ) + 3*( t1 +t3 +t7 +t10 ) + 4*( t2 +t3 ) + 6*( t8 +t12) + 8*( t4 t9+t10 +t12) + 12*( t5 +t11 ) + 16*( t6 +t7 +t8 +t9+t10+t11+t12)Two changes that might minimize the logic:1. New addx3 logic for (t1+t3)*3, (t7+t10)*3,(t8+t12)*3, (t5+t11)*3
2. A counter for 16* terms as these bits are sequential, in similar way to plateau.
Why the h1F in the middle ?
That seems to be generating a 45 line ROM, 6 bits wide, and that will logic reduce inside to tools.
It was to stop the max value exceeding 255, however all plateau bits are now 32 with 8-bit overflow detection, as mentioned in a recent post.
If I code that for drive from a U/D counter, the skirts portion alone packs to a 4i ROM, of PT 1,3,4,4,4,4
If I then support the flat ( clean flat assumed, no 1f ) via a larger U/D counter, it becomes 5i ROM, PT of 3,3,4,4,4
The U/D+DIRN counter(6 bits) then counts up to half way, then flips and counts down. Ctr Values >= 0xe generate 0x20 flat output.
The ROM is smaller in width because the DIRN bit is outside the ROM, and the generated terms are less, as skirts naturally mirror by direction.
Nice way to break it down. I will try this.
For positive slope, it must go below the X[7:0] value to arm and then above the X[15:8] value to trigger and disarm:
Here is the code:
7 or even 6 bit trigger levels would save logic - even 5 bits is a 3% increment in LSB ?
I think you need to be brutal about added logic, and pare things to minimal on anything that multiplies by 64x.
I think that means 250MHz sysclk gives 8b at 15.625 Msps, right ? Which is above the ADC roll-off ?
If you can get those silicon results using sinc3, I'm still unclear why a separate (logic costly) scope-mode filter is needed ?
It's automated and very simple to use. I'm hoping the logic size comes way down. Waiting to hear from ON Semi on the latest compile.
Another thought here - What about using the Threshold DAC and comparator, I think are already there ? How fast are those ?
You could have a sticky output and an ARMED approach, to make it more tolerant of whatever low hysteresis the threshold detector has ?
At even less logic cost ?
---Mike R,
You could say Chip answered that when I was coaching to have the clock and data sources matching between sinc1 clocked and sinc3 clocked - https://forums.parallax.com/discussion/comment/1456147/#Comment_1456147
The two sinc1 modes were not intended for this purpose, nor were they even considered a pair.
Great Chip. I'm curious to see how we would use it?
The rectangular window measurement is merely for comparison purposes.
Can the Goertzel hardware not do this?
Oh, yeah. it actually can. It uses signed numbers, though. So, you would be limited to positive values up to 127.
It never occurred to me, but one slow cycle of the Goertzel would be like a 512-tap FIR filter. You could make any kind of window you'd like.
I haven't been properly following the ADC saga, so this may be way off base...
There is some noise problem that shows up every 7-8 bits???
Could this possibly be some sort of sign extension bug???
I am not convinced you have got to the root cause of the ADC problems. To me, it seems that you/others are trying to solve a problem that is not sufficiently understood by throwing all sorts of software solutions to the problem and then trying to make the hardware implement them.
IMHO weeks have been wasted that could have been better spent on testing the P2, and/or writing things that really matter much more such as SPIN2 etc.