Do these 2-cog and 8-cog images correspond to what your thinking of in terms of "family" members?
Or, is it just the most you could fit?
Would all the real ones have smart pins on every pin?
Each board has the biggest family member that will fit.
On 64 I/O pin chips, there is some advantage to making every other set of four pins not smart, as it decreases the die edge dimension greatly. On 32 I/O pins, or less, chips, there is probably room enough for all smart pins.
Any chance of a P2 running on MAX10m25SC? 25k LE. DEO Nano is 22k LE
Is there a cheap board that can be acquired?
That's a good question. There's a $150 demo board with a 10M50, available right now. But the one that looks most interesting is the HyperMAX, which has a 10M25, HyperRAM, and HyperFlash. Unfortunately, it also doesn't seem to be available yet (price unknown). While it would be nice to play with a MAX10 variant in the future, I suggest leaving it off the table for the immediate goal of testing. If/Once the HyperMAX comes out, it would probably be worthwhile spending some time at that point, so that we can test out the feasibility of using Hyperbus tech with the P2.
Rjo__, I tried out your code and just realized that the CORDIC was excluded in the A9 compile, since I did it after the DE0-Nano, and forgot to turn it back on. I'm recompiling right now.
Chip, the MAX10 is not something to be concerned with, there is not a 10M25 that I see available, there is a 10m08 with the same io for 50 bucks. I am building a Max10m25 SC with the HyperRam attached for P1V, one day it would nice to see if it would run some minimum P2.
PINSETM renamed back to WRPIN
PINSETX renamed back to WXPIN
PINSETY renamed back to WYPIN
GETPINZ renamed back to RDPIN
I'm less sure about this change.
There are existing Boolean opcodes like SETB, CLRB etc that I think have direct pin (not smart) access now, so it needs to be clear that Opcodes access the Pin Cell Control area, not the physical pin.
To me, WRPIN/RDPIN is going to look to a new user, like a way to access the physical pin ?
Better to have Smart Pin Cell opcodes more clearly named, PINSETu or even PINCELu or WRCELL or WxPCELL/RDPCELL ??
- ie carefully avoid using just 'pin' in the mnemonic.
PINSETM renamed back to WRPIN
PINSETX renamed back to WXPIN
PINSETY renamed back to WYPIN
GETPINZ renamed back to RDPIN
I'm less sure about this change.
There are existing Boolean opcodes like SETB, CLRB etc that I think have direct pin (not smart) access now, so it needs to be clear that Opcodes access the Pin Cell Control area, not the physical pin.
To me, WRPIN/RDPIN is going to look to a new user, like a way to access the physical pin ?
Better to have Smart Pin Cell opcodes more clearly named, PINSETu or even PINCELu or WRCELL or WxPCELL/RDPCELL ??
- ie carefully avoid using just 'pin' in the mnemonic.
I'm not too satisfied with the current names, and I like your idea of 'cell' or something that doesn't look too much like the plain pin.
Re the 16 debug ISR addresses. Could they be set/get from a 16 long memory/registers parallel to HUB ram, by dedicated instruction? When the debug ISR is set it vectors via the parallel area.
If going with smart/smartx/smarty what about smartrd (smart read) instead of getsmart (BTW its 8 chars and IIRC we are limited to 7).
smart/smartx/smarty could also be smartwr/smartwx/smartwy too.
Instead of smart, perhaps spin (oops??) or ipin (oops??)
RD and WR make sense as prefix, but 'smart' is just too long to fit.
Pin is too close to Physical Pin, so I think that only leaves Cell, from the destination name of Smart Pin Cell
Well, if the marketing department has the guts to use the playful but meaningful name "pinheads" for the pin logic (a name that could resonate with students, teachers and engineers alike), then configuration of such pin logic could be done with the names "rdhead" and "wrhead" (both 7 characters) to be consistent (a "head" or "head-end" being roughly equivalent to a "cell" in this context, though "cell" sounds rather larger in scope).
I'm guessing we lost some more smart pins to get Cordic back
Lut sharing must take a lot more logic than I thought...
Can you make only half the cogs have lut sharing to free up space?
To compile for DE0-Nano (and now BeMicro-A2), I have to turn off the CORDIC. When I went back to compile for the Prop123-A9, I forgot to turn it back on.
The LUT write sharing is not much logic. The problem is that when you get into the 90%+ utilization range on these FPGAs, compilation times stretch way out and the Fmax falls.
Comments
I'm guessing you mean the P123-A7 version?
All four images locked and loaded Ok.
It's Pnut time.
Or, is it just the most you could fit?
Would all the real ones have smart pins on every pin?
Is there a cheap board that can be acquired?
Each board has the biggest family member that will fit.
On 64 I/O pin chips, there is some advantage to making every other set of four pins not smart, as it decreases the die edge dimension greatly. On 32 I/O pins, or less, chips, there is probably room enough for all smart pins.
I'll work on that today. I hope I still have all my old A2 files, with pin-outs and pictures.
That's a good question. There's a $150 demo board with a 10M50, available right now. But the one that looks most interesting is the HyperMAX, which has a 10M25, HyperRAM, and HyperFlash. Unfortunately, it also doesn't seem to be available yet (price unknown). While it would be nice to play with a MAX10 variant in the future, I suggest leaving it off the table for the immediate goal of testing. If/Once the HyperMAX comes out, it would probably be worthwhile spending some time at that point, so that we can test out the feasibility of using Hyperbus tech with the P2.
Except:
This nco for my camera clock. The only change I made from v8 is to substitute the new names.
The docs look the same in v9, but I'm missing something.
PropCamStart_Xclk WRPIN #%1_00110_0,#_PROPCAM_MCLK WXPIN #1,#_PROPCAM_MCLK qfrac ##10_000_000,##sys_clk getqx adra WYPIN adra,#_PROPCAM_MCLK setb dira,#_PROPCAM_MCLK retRjo__, I tried out your code and just realized that the CORDIC was excluded in the A9 compile, since I did it after the DE0-Nano, and forgot to turn it back on. I'm recompiling right now.
The Prop123-A9 compile doesn't have the CORDIC, so I'm recompiling right now and will post it as soon as it's available.
The 'Chip's Document' link embedded in the second link, points to an older V8 DOC, not the newest v9 ?
I'm less sure about this change.
There are existing Boolean opcodes like SETB, CLRB etc that I think have direct pin (not smart) access now, so it needs to be clear that Opcodes access the Pin Cell Control area, not the physical pin.
To me, WRPIN/RDPIN is going to look to a new user, like a way to access the physical pin ?
Better to have Smart Pin Cell opcodes more clearly named, PINSETu or even PINCELu or WRCELL or WxPCELL/RDPCELL ??
- ie carefully avoid using just 'pin' in the mnemonic.
I'm not too satisfied with the current names, and I like your idea of 'cell' or something that doesn't look too much like the plain pin.
There is also a new $125 price point for a 10M50 Eval, so the 10M25 should be (well?) under that.
https://www.altera.com/products/boards_and_kits/dev-kits/altera/kit-max-10m50-evaluation.html
[/quote]
I'm not too satisfied with the current names, and I like your idea of 'cell' or something that doesn't look too much like the plain pin.[/quote]
smart
smartx
smarty
getsmart
https://youtube.com/watch?v=HWtPPWi6OMQ
My code stopped working on my A9 but was Ok on a DE2-115.
Nice work on the DE0 Nano. 2 cogs and 4 smart pins is perfect
Sounds great !
Thanks a lot !
It can't get better, but not that they say later something like "he missed for just that..."
If going with smart/smartx/smarty what about smartrd (smart read) instead of getsmart (BTW its 8 chars and IIRC we are limited to 7).
smart/smartx/smarty could also be smartwr/smartwx/smartwy too.
Instead of smart, perhaps spin (oops??) or ipin (oops??)
RD and WR make sense as prefix, but 'smart' is just too long to fit.
Pin is too close to Physical Pin, so I think that only leaves Cell, from the destination name of Smart Pin Cell
Lut sharing must take a lot more logic than I thought...
Can you make only half the cogs have lut sharing to free up space?
To compile for DE0-Nano (and now BeMicro-A2), I have to turn off the CORDIC. When I went back to compile for the Prop123-A9, I forgot to turn it back on.
The LUT write sharing is not much logic. The problem is that when you get into the 90%+ utilization range on these FPGAs, compilation times stretch way out and the Fmax falls.