Sorry to be so dense but could someone point me to the instructions for flashing the FPGA image? I had thought I knew how to run the Quartus Programmer but I can't even get it to see the USB2serial chip on the 1-2-3 board. It could be that my problem is having recently "upgraded" from Windows 7 to Windows 10. Is there a trick needed to get the programmer working on Win10?
Edit: I'm using Quartus II 32-bit Programmer 12.1.
You don't need Quartus. Use the px.exe program in the .zip.
You'd type...
px Prop123_A9_Prop2_v7.rbf /# /p
...where # is the com port.
Uhhhh... Duh! I guess I've been away from this too long!! Thanks, Chip.
I had to think about it for a few seconds, myself, as I was visualizing Quartus and trying to envision what needed to be done. Then, I remembered!
I think there's been some attrition over the last eleven weeks without any updates.
I still need to get Quartus working at some point because I'd like to try this on my DE0-Nano and DE2-115 as well as the 1-2-3 A9 board. I'd also really like to find the time to play with P1v as well.
No, I want the whole toolchain. The main reason I want to play with P1v is to try modifying it. After playing with the ESP8266 a while, I'm wondering how feasible it would be to add a TLB to P1v to allow code execution from external SPI flash or SRAM.
I still need to get Quartus working at some point because I'd like to try this on my DE0-Nano and DE2-115 as well as the 1-2-3 A9 board. I'd also really like to find the time to play with P1v as well.
@David
Quartus includes a separate app (Latest version on Win10 in my case) "Quartus Prime 15.1 Device Installer" that will load the devices you need.
or look for "Quartus II 15.0 Device Installer".
It's strange that Altera have a menu item (Tools - Install Devies ..) that refers to this app but can't launch it from within Quartus. ???
Cheers
Brian
P.S. IIRC You will need Quartus version 15.0 or later (64 bit) for Cyclone V-A9 support.
Maybe some attrition. In my case, I've just been building something a piece at a time. Gonna have to break away and play with the new smart pins. Fun times.
I haven't attrited yet. Smart pins are just too smart for me so far!! Plus I still have trouble with dumb pins.
I also don't have a scope, so I need to slow things down to human speeds and find examples that work in my world.
I'm kind of spoiled here with a 16-channel logic analyzer.
The Prop2 can make a nice logic analyzer, as it can capture 8, 16, or 32 bits per clock using the streamer, and then have pin pattern matching act as a trigger. VGA output for display. Once this hardware is deemed final, we'll get the tools going and it will be easy to put something like that together.
Honestly, this design offers a lot of potential. I'm hoping we get it produced and can make systems that offer a lot of bench capability. Someone gets it, puts the necessary circuits together, and runs, writes, shares little programs to do these things, capture data, play it back, transform it, visualize, make sounds (auralize? Is that a word?).
It obviously won't be pro grade, but at modest speeds and signal levels and complexity, a P2 chip could offer up a powerful suite of tools that one can really use.
Many of us have used the P1 this way. I did the logic analyzer to compliment my scope.
All these DACS, COGS, PIPS, and the various modes as well as the streamer are going to combine in ways we aren't even thinking yet.
Pretty exciting stuff. I know I am going to learn a lot.
OK, my brain says this should work and it does if I take the smart pin instructions (I get marching bits on the LEDS)
It is Chip's serial example but I added the 'mov dirb,mask32' to set up the ouput for the LEDs and changed the setnib to a mov so I just pick up y and shove it into outb.
I got rusty over winter break, so it's probably something dumb but I'm missing it. I've tried it with the wait and tried it at different bit rates. I've even physically connected pin0 and pin1.
dat org
pinsetm pm_tx, #0 'set asynchronous tx mode in smart pin 0
pinsetx bitper, #0 'set tx bit period
pinsetm pm_rx, #1 'set asynchronous rx mode in smart pin 1
pinsetx bitper, #1 'set rx bit period
mov dira,#3 ' enable smart pins 1..0
mov dirb,mask32 ' enable pins 8...0
setedg #%01_000001 'trigger on smart pin 1
pinsety x,#0 'stuff initial tx value (starts full-duplex timing)
.loop ' waitx ##10000 'remove ' for delay
pinsety x,#0 'set next tx value
add x,#1 'increment value to send
waitedg 'wait for smart pin 1 to signal rx data received
pinack #1 'acknowledge smart pin 1
pingetz y,#1 'get rx data from smart pin 1
mov outb,y
jmp #.loop 'loop
pm_tx long %1_11_11101_0000_0000_00_0_0000000000000 'async tx long mode, dir high
pm_rx long %1_10_11111_0000_0111_00_0_0000000000000 'async rx long mode, dir low, inputs pin 0
bitper long 3 'number of clocks per bit period, 3..65536
mask32 long $FFFF
x long 0
y long 0
Oh god, forgive me. This just popped into my head:
Let's call 'em POGS! They are like little COGS, only for the pins.
There is the physical pin, and then there is the POG, and the combination is the Smart Pin, but really the little compute unit can access more than just one pin, sooo?
Wondering if I understand the A/B selector options...
I see things like this: "relative +3 pin’s read state"
Does this mean that both A and B inputs could be three pins away?
Does this mean several smart pins could operate on the same 2 input A/B pins?
See the earlier example, where on pin cell (A) connects to A&B for Quadrature, and the pin Cell available at (B) can also connect to extract period of the pulses.
Still unclear, is if those paired readings can be triggered, so you know they have captured related to same edges.
Trying to decipher the capture modes especially.
Quite a bit seem inferred, not clearly stated, and certain ratios seem to be assumed.
eg taking Count A-input highs
- Sounds like A = Count_Enable, but getting a result seems to require a measurement period, and what happens when A is similar to that Period ?
This also seems to 'chop off' based on Period, so quite high jitters will result, where A is of modest cycles.
Does this line
'If 0 is used, the count operation will not be periodic, but continuous, like a totalizer.'
infer that Clear-On-Capture is done ?
Time A-input positive edges
I think is saying this is a Saturating Counter, stops at 50% of possible full scale ?
It claims Z[31] will always be 0., but I think means Z.31 is the overflow/saturate bit, and can read 1.
I think this also has Clear-On-Capture ?
Sometimes you want to capture the Pulse Width, and know how many cycles that was over.
(A single pulse may be too coarse, so 16, 100, 1024 etc may be required)
That seems to have slipped thru the cracks in the modes ?
I thought there was something about smart pins triggering an "event" in cogs... Was that my imagination? Don't see it in the cog docs...
I noted that too. My best guess is you'd set the Cog in the same manner as an ordinary pin input, ie: SETEDG with POLLEDG/WAITEDG or the related IRQ. Not that I know how that is done either.
Thinking some more about Clear-On-Capture.
I think this needs to be a user-choice via config flag.
Sometimes, it is useful to Clear-On-Capture, and sometimes it is best avoided.
eg Useful in cases like period check, where you may not be sure your SW will read inside a period, and Clear-On-Capture is one HW way to ensure you get just one period of time.
As above, being able to use N-periods (not just time) is useful for dynamic range control.
Clear-On-Capture is not so useful in polling cases, where count may represent distance/totals, and when counting external events, any clear has aperture issues where it may coincide with a INC edge, which is then lost. In these cases a SW difference avoids this.
Thinking some more about Clear-On-Capture.
I think this needs to be a user-choice via config flag.
Sometimes, it is useful to Clear-On-Capture, and sometimes it is best avoided.
eg Useful in cases like period check, where you may not be sure your SW will read inside a period, and Clear-On-Capture is one HW way to ensure you get just one period of time.
As above, being able to use N-periods (not just time) is useful for dynamic range control.
Clear-On-Capture is not so useful in polling cases, where count may represent distance/totals, and when counting external events, any clear has aperture issues where it may coincide with a INC edge, which is then lost. In these cases a SW difference avoids this.
There are no losses. The accumulator can be masked to zero going into an end-of period addition, but the value to be added, 0/-1/1, is still added. So, if the accumulator had 1000 in it and it was end of period and 1 was going to be added, 1000 would be reported to the Z result register and the accumulator would be set to 1.
I thought there was something about smart pins triggering an "event" in cogs... Was that my imagination? Don't see it in the cog docs...
I noted that too. My best guess is you'd set the Cog in the same manner as an ordinary pin input, ie: SETEDG with POLLEDG/WAITEDG or the related IRQ. Not that I know how that is done either.
That's correct. Remember that INA/INB flags when a pin operation completes. One of the smart pin examples in the latest zip uses WAITEDG this way, if I recall correctly.
I thought there was something about smart pins triggering an "event" in cogs... Was that my imagination? Don't see it in the cog docs...
I noted that too. My best guess is you'd set the Cog in the same manner as an ordinary pin input, ie: SETEDG with POLLEDG/WAITEDG or the related IRQ. Not that I know how that is done either.
That's correct. Remember that INA/INB flags when a pin operation completes. One of the smart pin examples in the latest zip uses WAITEDG this way, if I recall correctly.
I used WAITEDG to get around jitter that polling would have caused in the scope trigger signal. You could just poll it, instead, if you don't need exactness. Polling would allow interrupts, too. And by polling, I mean just doing a TESTB and looping back. No need to waste the SETEDG resource. The IN feedback from the pin just needs to be tested for a high, not an edge. PINACK will cause the smart pin to drop IN back to a low state.
There are no losses. The accumulator can be masked to zero going into an end-of period addition, but the value to be added, 0/-1/1, is still added. So, if the accumulator had 1000 in it and it was end of period and 1 was going to be added, 1000 would be reported to the Z result register and the accumulator would be set to 1.
Sounds good - are you saying that "accumulator can be masked to zero" is user configurable, I did not see that in the DOCs ?
There are no losses. The accumulator can be masked to zero going into an end-of period addition, but the value to be added, 0/-1/1, is still added. So, if the accumulator had 1000 in it and it was end of period and 1 was going to be added, 1000 would be reported to the Z result register and the accumulator would be set to 1.
Sounds good - are you saying that "accumulator can be masked to zero" is user configurable, I did not see that in the DOCs ?
In the case of the periodic/continuous measurement modes, a period of 0 will inhibit accumulator clearing. Otherwise, the accumulator will be cleared to the current adder value on each period completion.
In the case of the periodic/continuous measurement modes, a period of 0 will inhibit accumulator clearing.
Current DOCs suggest that periodic is time-window only, but it could be useful to (optionally) clock that measurement frame counter from the Fin, to allow N-Cycles-count as well ? Useful for higher Freq in, where a single capture may lack resolution.
In those cases, using Zero as a mode switch may be too restrictive ?
Comments
I had to think about it for a few seconds, myself, as I was visualizing Quartus and trying to envision what needed to be done. Then, I remembered!
I think there's been some attrition over the last eleven weeks without any updates.
@David
Quartus includes a separate app (Latest version on Win10 in my case) "Quartus Prime 15.1 Device Installer" that will load the devices you need.
or look for "Quartus II 15.0 Device Installer".
It's strange that Altera have a menu item (Tools - Install Devies ..) that refers to this app but can't launch it from within Quartus. ???
Cheers
Brian
P.S. IIRC You will need Quartus version 15.0 or later (64 bit) for Cyclone V-A9 support.
"
This design feels good Chip.
I'm working on the smart pin docs right now.
I also don't have a scope, so I need to slow things down to human speeds and find examples that work in my world.
I'm kind of spoiled here with a 16-channel logic analyzer.
The Prop2 can make a nice logic analyzer, as it can capture 8, 16, or 32 bits per clock using the streamer, and then have pin pattern matching act as a trigger. VGA output for display. Once this hardware is deemed final, we'll get the tools going and it will be easy to put something like that together.
Honestly, this design offers a lot of potential. I'm hoping we get it produced and can make systems that offer a lot of bench capability. Someone gets it, puts the necessary circuits together, and runs, writes, shares little programs to do these things, capture data, play it back, transform it, visualize, make sounds (auralize? Is that a word?).
It obviously won't be pro grade, but at modest speeds and signal levels and complexity, a P2 chip could offer up a powerful suite of tools that one can really use.
Many of us have used the P1 this way. I did the logic analyzer to compliment my scope.
All these DACS, COGS, PIPS, and the various modes as well as the streamer are going to combine in ways we aren't even thinking yet.
Pretty exciting stuff. I know I am going to learn a lot.
It is Chip's serial example but I added the 'mov dirb,mask32' to set up the ouput for the LEDs and changed the setnib to a mov so I just pick up y and shove it into outb.
I got rusty over winter break, so it's probably something dumb but I'm missing it. I've tried it with the wait and tried it at different bit rates. I've even physically connected pin0 and pin1.
I see things like this: "relative +3 pin’s read state"
Does this mean that both A and B inputs could be three pins away?
Does this mean several smart pins could operate on the same 2 input A/B pins?
Let's call 'em POGS! They are like little COGS, only for the pins.
There is the physical pin, and then there is the POG, and the combination is the Smart Pin, but really the little compute unit can access more than just one pin, sooo?
We would have HUB, COG, POG, PIN!
Ok, I'll leave now.
**A POG is these silly collectable kid toy: https://en.wikipedia.org/wiki/Pogs
So you have HUB, LUB, COG, POG, PIN!
I'll leave too, now!
I thought the smart pins were tied to their pin and adjacent pin.
This is definitely more flexible...
BTW: I think "0xxx = true (default)" is more clear as "0xxx = non-inverted (default)"
but, maybe I should make suggestions in the docs...
See the earlier example, where on pin cell (A) connects to A&B for Quadrature, and the pin Cell available at (B) can also connect to extract period of the pulses.
Still unclear, is if those paired readings can be triggered, so you know they have captured related to same edges.
Trying to decipher the capture modes especially.
Quite a bit seem inferred, not clearly stated, and certain ratios seem to be assumed.
eg taking Count A-input highs
- Sounds like A = Count_Enable, but getting a result seems to require a measurement period, and what happens when A is similar to that Period ?
This also seems to 'chop off' based on Period, so quite high jitters will result, where A is of modest cycles.
Does this line
'If 0 is used, the count operation will not be periodic, but continuous, like a totalizer.'
infer that Clear-On-Capture is done ?
Time A-input positive edges
I think is saying this is a Saturating Counter, stops at 50% of possible full scale ?
It claims Z[31] will always be 0., but I think means Z.31 is the overflow/saturate bit, and can read 1.
I think this also has Clear-On-Capture ?
Sometimes you want to capture the Pulse Width, and know how many cycles that was over.
(A single pulse may be too coarse, so 16, 100, 1024 etc may be required)
That seems to have slipped thru the cracks in the modes ?
I noted that too. My best guess is you'd set the Cog in the same manner as an ordinary pin input, ie: SETEDG with POLLEDG/WAITEDG or the related IRQ. Not that I know how that is done either.
I think this needs to be a user-choice via config flag.
Sometimes, it is useful to Clear-On-Capture, and sometimes it is best avoided.
eg Useful in cases like period check, where you may not be sure your SW will read inside a period, and Clear-On-Capture is one HW way to ensure you get just one period of time.
As above, being able to use N-periods (not just time) is useful for dynamic range control.
Clear-On-Capture is not so useful in polling cases, where count may represent distance/totals, and when counting external events, any clear has aperture issues where it may coincide with a INC edge, which is then lost. In these cases a SW difference avoids this.
There are no losses. The accumulator can be masked to zero going into an end-of period addition, but the value to be added, 0/-1/1, is still added. So, if the accumulator had 1000 in it and it was end of period and 1 was going to be added, 1000 would be reported to the Z result register and the accumulator would be set to 1.
That's correct. Remember that INA/INB flags when a pin operation completes. One of the smart pin examples in the latest zip uses WAITEDG this way, if I recall correctly.
I used WAITEDG to get around jitter that polling would have caused in the scope trigger signal. You could just poll it, instead, if you don't need exactness. Polling would allow interrupts, too. And by polling, I mean just doing a TESTB and looping back. No need to waste the SETEDG resource. The IN feedback from the pin just needs to be tested for a high, not an edge. PINACK will cause the smart pin to drop IN back to a low state.
In the case of the periodic/continuous measurement modes, a period of 0 will inhibit accumulator clearing. Otherwise, the accumulator will be cleared to the current adder value on each period completion.
I'll add to the doc's about this.
Current DOCs suggest that periodic is time-window only, but it could be useful to (optionally) clock that measurement frame counter from the Fin, to allow N-Cycles-count as well ? Useful for higher Freq in, where a single capture may lack resolution.
In those cases, using Zero as a mode switch may be too restrictive ?
Good idea, and include the note about carry-forward of INC/DEC.
Other parts have Clear-On-Capture but, I'm not sure they cover the dual case.