I was curious too to know what is new for the 'Lite' version.
At first I thought it was just a version to let us know that It's Intel Quartus (not Altera). Later, when reading the release notes, I found that they added things for new Cyclone 10 and Arria 10 (like timing and power estimator) . And finally I read the list of service request that were fixed ... (shock) they have one custumer using Quartus 11 and they fixed their service request (/shock) (but no details given).
I'm making lots of progress tuning the Verilog. I found simple ways to speed up the CORDIC and the colorspace converter. Also, the S and D mux's have been redesigned to good effect. I'm getting single-cog compiles at 101MHz Fmax. Four cogs are coming in at around 91MHz. That's getting better by the hour, though. I hold off on the 16-cog compiles because they take almost two hours. They used to take three, though. Cleaning up the critical paths has allowed Quartus to get the job done faster.
I'm making lots of progress tuning the Verilog. I found simple ways to speed up the CORDIC and the colorspace converter. Also, the S and D mux's have been redesigned to good effect. I'm getting single-cog compiles at 101MHz Fmax. Four cogs are coming in at around 91MHz. That's getting better by the hour, though. I hold off on the 16-cog compiles because they take almost two hours. They used to take three, though. Cleaning up the critical paths has allowed Quartus to get the job done faster.
Excellent news Chip!
That's a double whammy. Increasing clock speed while reducing compile speed
It's also casting another look over the code for bugs at the same time, although I guess there is a lower possibility of introducing bugs too.
It's been taking me a while to get v19 out. I've got everything going at 100MHz now ....
So 96MHz will be fine, but 108 MHz is just too far ?
Will the builds set the FPGA PLL for 96MHz, or 100MHz ?
They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?
The 16-cog compiles are coming in at around 80MHz now. They used to be around 66MHz. So, we are overclocking proportionally the same as before. 108MHz might work, but I'm not very confident it wouldn't be flakey. What do you think?
The 16-cog compiles are coming in at around 80MHz now. They used to be around 66MHz. So, we are overclocking proportionally the same as before. 108MHz might work, but I'm not very confident it wouldn't be flakey. What do you think?
First builds of a new verilog, I would err on conservative.
They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?
80MHz was 6.6667, and that seems to have communicated at least. Not sure if it meets any USB specs.
It's hard to be certain, so ideally both need to be tested.
If HOST code was debugged at 6.667 ok, it seems 8.33 should also be ok.
The devices I know that lock to USB, do so using the 1ms frame rate, but maybe some try to lock to edges and are more jitter sensitive ?
Did you look at the thread on Smart Pins, Up/Down Counting aka CLK , DIRN position encode variant support ?
I saw the thread, but need to re-read it carefully to understand what's being talked about. I understood there's some need for automatic resetting or position reporting when a 'home' signal is encountered during operation.
I saw the thread, but need to re-read it carefully to understand what's being talked about. I understood there's some need for automatic resetting or position reporting when a 'home' signal is encountered during operation.
That is less important, than supporting AB signals for CLK and DIRECTION, which is really a variant of Quad Encode.
Rotary encoders commonly use Quad counting, but if you want to 'clip onto' a stepper motor system, CLK and DIRN are more common.
I'm not sure there are enough signal paths to support Quadrature Counting plus HW reset, and that infers 3 hardware pin connected ?
I think 3 is quite a jump on Smart pin structure ?
Some time spec for the Software alternative of Pin -> Interrupt -> SW Zero (either capture, or clear) would be useful to know.
They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?
I find this in a TI pdf 10. What is the jitter requirement for the 48-MHz signal (pin 27) for the TUSB2046B?
The clock must meet the USB 2.0 full-speed jitter specification as outlined in Table 7-9 of the full-speed specification (available at http://www.usb.org/developers/docs/).
The source jitter tolerance TDJ1 has to be between –3.5 ns (min) to 3.5 ns (max).
TDJ2 has to be between –4 ns to 4 ns.
That indicates 96 or 108MHz will be needed to get inside those formal limits, but a 160MHz+ part just might be able to use any SysCLK ?.
The smart pin has a real quadrature encoding mode, and that occupies the two input signals. It might be easy to bring in a 3rd signal, though. We'll see.
Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
The smart pin has a real quadrature encoding mode, and that occupies the two input signals. It might be easy to bring in a 3rd signal, though. We'll see.
How many SysCLKs does the interrupt path need, and how much variance does that path have ?
eg suppose a rough guess of 10 sysclks at 100MHz, which is 100ns - and I'm not sure anyone needs to live-zero, at a speed of > 10MHz ?
I have seen quad encoders needing to count above 10MHz
Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
96MHz will meet the USB jitter spec numbers above, so it seems to me a better place to start thorough USB testing from.
Then, when USB is looking solid and stable, 100MHz can be checked (along with 108MHz)
The smart pin has a real quadrature encoding mode, and that occupies the two input signals. It might be easy to bring in a 3rd signal, though. We'll see.
Save that one for Prop3 thoughts. However a CLK+DIR mode would fit the existing two inputs available. Most of the discussion around this was whether it could be merged into an existing mode.
There was also a possible CLK+DIR solution with mode %10111 = For periods in X+ clock cycles, count periods using two Smartpin cells. Although I'm not sure on how this mode really works.
The idea is one Smartpin counts up on A rises with B low say, and the other Smartpin counts up on A rises with B high. Then software subtracts one Z from the other Z to get the total count.
Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
The idea is one Smartpin counts up on A rises with B low say, and the other Smartpin counts up on A rises with B high. Then software subtracts one Z from the other Z to get the total count.
That's a CLK + Enable and CLK + !Enable mode , also known as gated counter, and that's another missing mode..
Quad Counting is really a super-set of these that adds a Quad to CLK + Direction precursor, so it just needs a logic bit to bypass/disable that to get CLK+DIRN.
CLK+Enable may need to map to another counting mode ?
ie needed in addition to Quad, are the simpler variants of CLK + Direction, & CLK + Enable
1) CLK + UP_DN, where the counter is incremented or decremented on each CLK rise, depending on the state of UP_DN.
2) CLK + ENA, where the counter is incremented on each CLK rise when ENA is high.
Pin polarity is settable, of course.
Is that right?
Those are two very common cases in instruments for frequency measurement and motion control.
I've been looking at the smart pin section that does periodic and continuous measurements. To add these modes is very trivial. We just need to use WYPIN to set sub-modes. It's almost nothing, at all.
We actually have THREE slots that can do something new.
Aside from CLK+UP_DN and CLK+ENA, is there one other mode that would be helpful to have that follows the same general scheme?
Would CLK+RESET be of any use?
..... Maybe if it would capture on reset, but that's still not useful, it seems.
I think there is already an external Capture, but what I'd call a higher precision model ?
Those high-precision, whole period ones, may be harder to explain and use, than a simple Capture & Reset, so yes, CLK+RESET(capture) sounds useful to me, as a 'spare mode filler'
With Capture & reset, you need only one edge, whilst the higher precision modes need at least two edges.
Addit : examples of simple one-edge echo style uses would be any sonar system, from the low precision Ping units (air), and there are linear probes that use speed of sound in metals & Magnetostrictive pulses.
Those are ~ 5.8mm/us or 17.24ns/0.1mm each way so a 2 metre probe is ~689us echo and a 29MHz SysCLK is 0.1mm LSB, that's right in P2 territory.
I'm compiling for 120MHz. I'll see how well it works for the 16-cog implementation on the -A9. The only apparent problems at higher speeds that I've noticed were the DACs, but I've since constrained their output delays, along with the DAC clock's, so that there are no setup/hold-time issues. 120MHz will get rid of jitter for USB stuff, as there will be ten full clocks per USB bit.
Comments
At first I thought it was just a version to let us know that It's Intel Quartus (not Altera). Later, when reading the release notes, I found that they added things for new Cyclone 10 and Arria 10 (like timing and power estimator) . And finally I read the list of service request that were fixed ... (shock) they have one custumer using Quartus 11 and they fixed their service request (/shock) (but no details given).
Excellent news Chip!
That's a double whammy. Increasing clock speed while reducing compile speed
It's also casting another look over the code for bugs at the same time, although I guess there is a lower possibility of introducing bugs too.
I've got the new instruction sheet done:
https://docs.google.com/spreadsheets/d/12LZ9KPEy5FEz8aVAG1DBVur36MB2eTVNT4QZ7wgpc-c/edit?usp=sharing
I think I'll have the rest of this out tomorrow.
So 96MHz will be fine, but 108 MHz is just too far ?
Will the builds set the FPGA PLL for 96MHz, or 100MHz ?
They are at 100MHz. That gives ~8.33 clocks per 12MHz USB bit. I know 96MHz is a clean 8x of 12MHz, but does it really do anything other than make USB signals look better on a scope? Is any hardware out there sensitive to 1/8th bit of jitter?
First builds of a new verilog, I would err on conservative.
80MHz was 6.6667, and that seems to have communicated at least. Not sure if it meets any USB specs.
It's hard to be certain, so ideally both need to be tested.
If HOST code was debugged at 6.667 ok, it seems 8.33 should also be ok.
The devices I know that lock to USB, do so using the 1ms frame rate, but maybe some try to lock to edges and are more jitter sensitive ?
Did you look at the thread on Smart Pins, Up/Down Counting aka CLK , DIRN position encode variant support ?
Rotary encoders commonly use Quad counting, but if you want to 'clip onto' a stepper motor system, CLK and DIRN are more common.
I'm not sure there are enough signal paths to support Quadrature Counting plus HW reset, and that infers 3 hardware pin connected ?
I think 3 is quite a jump on Smart pin structure ?
Some time spec for the Software alternative of Pin -> Interrupt -> SW Zero (either capture, or clear) would be useful to know.
I find this in a TI pdf
10. What is the jitter requirement for the 48-MHz signal (pin 27) for the TUSB2046B?
The clock must meet the USB 2.0 full-speed jitter specification as outlined in Table 7-9 of the full-speed specification (available at http://www.usb.org/developers/docs/).
The source jitter tolerance TDJ1 has to be between –3.5 ns (min) to 3.5 ns (max).
TDJ2 has to be between –4 ns to 4 ns.
That indicates 96 or 108MHz will be needed to get inside those formal limits, but a 160MHz+ part just might be able to use any SysCLK ?.
Maybe I shoulld recompile for 96 MHz. It's possible that our jitter was causing some connection issues, right?
eg suppose a rough guess of 10 sysclks at 100MHz, which is 100ns - and I'm not sure anyone needs to live-zero, at a speed of > 10MHz ?
I have seen quad encoders needing to count above 10MHz
96MHz will meet the USB jitter spec numbers above, so it seems to me a better place to start thorough USB testing from.
Then, when USB is looking solid and stable, 100MHz can be checked (along with 108MHz)
Is there any testing that needs 100MHz to prove ?
There was also a possible CLK+DIR solution with mode %10111 = For periods in X+ clock cycles, count periods using two Smartpin cells. Although I'm not sure on how this mode really works.
The idea is one Smartpin counts up on A rises with B low say, and the other Smartpin counts up on A rises with B high. Then software subtracts one Z from the other Z to get the total count.
Some USB 3.0 capable devices were giving grief, although no one knew why. I was just reading that thread the other day, now that I can do some testing too. http://forums.parallax.com/discussion/comment/1402661/#Comment_1402661
Quad Counting is really a super-set of these that adds a Quad to CLK + Direction precursor, so it just needs a logic bit to bypass/disable that to get CLK+DIRN.
CLK+Enable may need to map to another counting mode ?
ie needed in addition to Quad, are the simpler variants of CLK + Direction, & CLK + Enable
CLK+DIR can be built from two CLK+ENA's, hence why I'm listing it as a possibility.
The option is edge-to-edge, not edge with enable. I'm sure Chip will clarify.
1) CLK + UP_DN, where the counter is incremented or decremented on each CLK rise, depending on the state of UP_DN.
2) CLK + ENA, where the counter is incremented on each CLK rise when ENA is high.
Pin polarity is settable, of course.
Is that right?
Those are two very common cases in instruments for frequency measurement and motion control.
I've been looking at the smart pin section that does periodic and continuous measurements. To add these modes is very trivial. We just need to use WYPIN to set sub-modes. It's almost nothing, at all.
We actually have THREE slots that can do something new.
Aside from CLK+UP_DN and CLK+ENA, is there one other mode that would be helpful to have that follows the same general scheme?
The third one is free, though. So, what should it be? Sad to waste it.
This leaves gaps for future in case of no need for architecture change.
As in "reset clocked counter to zero on reset pulse"?
That's what I was thinking, but it really doesn't seem useful, does it? Maybe if it would capture on reset, but that's still not useful, it seems.
That's good to hear, I was hoping it was minor.
I think there is already an external Capture, but what I'd call a higher precision model ?
Those high-precision, whole period ones, may be harder to explain and use, than a simple Capture & Reset, so yes, CLK+RESET(capture) sounds useful to me, as a 'spare mode filler'
With Capture & reset, you need only one edge, whilst the higher precision modes need at least two edges.
Addit : examples of simple one-edge echo style uses would be any sonar system, from the low precision Ping units (air), and there are linear probes that use speed of sound in metals & Magnetostrictive pulses.
Those are ~ 5.8mm/us or 17.24ns/0.1mm each way so a 2 metre probe is ~689us echo and a 29MHz SysCLK is 0.1mm LSB, that's right in P2 territory.
I'm recompiling the FPGA images now.