It seems that OnSemi will do the job. While the processes are often called "compatible" at different foundries, they also provide design rules very specific to their exact manufacturing method. These rules can be 50 pages in length. Chip designed for OnSemi's rules.
Hey, that's right near my place. I go by that fab on a regular basis.
Trivia: in the 00's, I did a full CAD construction lay out of a fab in 3D. When one looks at site drawings, it's amazing the builders and fitters get anything done! Its a rats best of colors and overlapping 2d wire frame squished down onto the paper.
When I got the model done, I had an amazing few days design review. They would just shout stuff out, and I moved, added, modified, until it was buildable and code compliant.
Then I surprised them with CDs that could boot on many laptops. Stripped down a Linux and had it render the data in this nice viewer the CAD company made. They could walk out to the job site and position the camera to see what it would look like.
Turns out tolerances are roughly an inch grid. That is what fitters are for!
Got feedback later. That FAB went up quick, few problems. Just seeing it mattered. The viewer had a measure function they used some, but just by eye scaling and their skill at construction did the trick.
Was for Intel. And a one off. Another guy was the expert, but something happened and he dropped my name to finish it. He was making a name by doing it this way and was just leaving a fully equipped computer on site rather than a ton of drawings. I had helped him get going a few years prior.
So I jumped on the thing, grabbed one of the veterans at this stuff and we went at it. FABS are complex.
Again, back to the original question and regarding robotics and education.
Who is teaching REAL robotics?
Kuka, Fanuc, Motoman, et-al. The producers of the robots that are used in industry, don't utilise open-loop stepper-motors. They use closed-loop servos and surprisingly few "robot technicians" understand how they work.
The last time I checked, the most that any PIC (DSP) could handle is 2 quadrature encoders. A single P2 could handle a 6/7/8 axis REAL robot.
Apologies for this post's lack of structure or coming across as a rant but am working all hours right now and seriously need to hit the sack
FWIW a new micro on the block is the ATTiny1614/6/7. It has 16KB Flash, 2KB SRAM, 256B EEPROM, some Fuses, Internal 16/20MHz RC and 32.768KHz RC, up to 22 I/O in up to QFN24. Price $0.93/1 $0.782/100 from Mouser.
For <<$1, Flash+SRAM+EEPROM+Fuses and internal oscillators !!!
Another thread was complaining about some cheap micros not having internal oscillators.
P2 is going to require external Flash to boot, and maybe external xtal. IMHO big mistake nowadays!!!
I don't think those little MCU are comparable to the P2, or even the P1. Totally different beasts with very different design goals and capabilities.
I have always imagined the P1/2 as alternatives to FPGA. For those applications where you need to do some twisty custom logic, with lots of I/O and deterministic timing. Cases where MCU's don't cut it but FPGA is too big, too expensive and too damn complex and cumbersome to work with.
This is similar to the goals of the XMOS devices.
Problem is the FPGA route is getting more attractive every day. What with the availability of small cheap FPGA chips and boards. And in particular the arrival of Free and Open Source tools that make using FPGA a lot less hassle. For example Icarus Verilog, Verilator, IceStorm and now SpinalHDL. One day someone will wrap those tools up in a drop-dead simple to install and easy to use IDE, Arduino style. With RISCV cores thrown in. Then novices can build their own custon logic with ease.
The Prop still shines as about the only device that supports plug-and-play dropping in of other peoples software components with out having to tackle analyzing how they will impact each other timing wise. Or mess with integrating them into ones interrupt hierarchy or operating system.
FWIW a new micro on the block is the ATTiny1614/6/7. It has 16KB Flash, 2KB SRAM, 256B EEPROM, some Fuses, Internal 16/20MHz RC and 32.768KHz RC, up to 22 I/O in up to QFN24. Price $0.93/1 $0.782/100 from Mouser.
For <<$1, Flash+SRAM+EEPROM+Fuses and internal oscillators !!!
You can get MCUs for well under 50c, with all that - eg N76E003AT20 1000+ $0.40 18KF, 1KR, 12b ADC.PWM.2xUART.SPI.i2c
This is one part I'm looking at P2 Boot from.
Another thread was complaining about some cheap micros not having internal oscillators.
Are you sure ? I have seen cheap micros that lack Xtal Oscillators, and the ATtiny1616 is one of those.
Pretty much every small MCU these days has a RC osc on board.
That means if the on-board RC osc is not good enough, you have to bump to an external Oscillator, there is no middle-step left.
These days, that external Oscillator, even tho cheaper than ever, is still much more costly than the << $1 MCU you connect it to !
P2 is going to require external Flash to boot, and maybe external xtal. IMHO big mistake nowadays!!!
I don't think it requires an external xtal, but certainly most P2 uses will use a Xtal or Osc, as it does not have a calibrated RC Osc.
There are other parts that have external code, ESP32, ESP8266 for example, and they seem to sell well enough.
I don't think those little MCU are comparable to the P2, or even the P1. Totally different beasts with very different design goals and capabilities.
I agree with this sentiment. I may be a tiny minority, but I've never used the RC oscillator of the P1 (except as the PropTool may use it for programming, or the Propeller for booting). About half of my permanent Propeller projects sport OCXOs or TCXOs. For me, the Propeller is what gets used when I need to do a whole lot of complicated things at the same time and yet I need them all to be done perfectly. :-)
I wasn't meaning the ATTiny or others as comparible to the P2. It's just that they are producing these chips with these sections on board for such low prices, surely these extras (Flash, EEPROM, Fuses, 1% RC Oscillators) cannot be costing much per die/dice.
The P1 RC oscillator isn't any good for much. It is way too inaccurate.
All the new micros I see include a 1% trimmable oscillator. And yes, if that is not accurate enough, an external oscillator is required but tht only takes 1 pin. A lot of companies never mastered putting the xtal caps inside the chip like the P1. But still the prices for oscillators are coming down. While the HC49U/S are really cheap, they now take up a lot of space. The 3225 (3.2x2.5mm) or smaller crystals/oscillators are becomming the norm on boards. I am talking volume production here. No point in producing P2 if there aren't going to be any volume customers. Hobbyists will not keep Parallax going in the P2 market.
@jmg
The bigger ARM and similar chips have external memory because they are using large blocks of it. There are various builds where the external memories vary in size, and therefore cost. This is definately a different market to the P2.
That Nuviton chip is cheap. I will look at its specs.
@heater
I am quite OK with using the suppliers FPGA software if it is free. Their software is extremely complex. Xilinx started to charge ridiculous prices for their software in the very late80's and early 90's. Both Altera and Xilinx still do for the biggest FPGA's. But then again, so do they charge for those big FPGA's. For companies that have big margins, those prices don't matter. I would love to be able to get my hands on one of the latest and largest FPGA's - just in a TQFP100/144. Don't need all those I/O, fast lane I/O's. But sure would love all those LUT's and memory to play with.
But for me, I am now onto the FPGA's again. I designed some into products in the late 80's, using Xilinx software to hand route the design from I/O thru the LUTs and out again. One of them interfaced to the internal Bus on an ICL Mini Computer. I should dig out a photo.
Those Lattice parts are nice for the price. Internal oscillators, some have reasonable SRAM (P1 equiv). Some have OTP but also can boot from external spi flash.
@jmg
The bigger ARM and similar chips have external memory because they are using large blocks of it. There are various builds where the external memories vary in size, and therefore cost. This is definately a different market to the P2.
I was quoting MCU parts with External Serial Flash, running from on-chip RAM, exactly the same setup as P2.
RAM execute has definite speed advantages.
Analog Devices DSPs are all RAM based, & code loads at boot.
Their BlackFin parts start from $1.99/1k for 400MHz, 68KR
I also notice a pair of parts : these can boot from SPI memory, but have another option
ADSP-BF504F Blackfin 1 400M 800 68 KBR + 32MbF $7.48
ADSP-BF504 Blackfin 1 400M 800 68 KBR $5.18
For the added $2.30, you get a stacked die 32MbF, 70ns Tacc, or 50MHz burst, so much slower than RAM, but in-package and faster than SPI.
RaspPi type ARMs, are Microprocessors, not Microcontrollers - they either have stacked die, or flip-pcb BGA DDR memory.
The P1 shines because it has 32KB SRAM plus 8*2KB SRAM COGS.
Likewise the P2 will have a market where 512KB SRAM plus 16*4KB SRAM COGS.
The egg-beater will really help the big programs.
So the point I make is the program is soft-loadable, plus multi-cores. There is plenty of fast micros running from flash out there. But most (excluding ARM) don't have large SRAM making them unsuitable for softloading. There is a PIC that has 512B SRAM and 2MB FLASH IIRC (PIC32MZ???).
But this market is being eroded all the time by other micros. And requiring external SPI Flash and an external crystal (plus 2+voltage regulators) are going to quickly date the P2. Don't expect to see it within 12 months either.
I am quite OK with using the suppliers FPGA software if it is free. Their software is extremely complex.
My concern above was nothing to do with vendors software not being free. Monetarily. I'm very sure it has taken a lot of development effort over many years and vendors have every right to try and recoup their investment.
My observation is that those vendor tools, like Quartus, are vastly complicated beasts for users to get their heads around. It takes a significant investment of time and effort on the users part to even get started. Then when you do get going with it the development cycle, edit, test, repeat, is horribly slow and frustrating. One has to seriously need to use an FPGA to be bothered with all that. It's not for the casual user.
But now we have Free and Open Source tools coming along. Like Icarus Verilog, SpinalHDL, IceStrorm.
Icarus for example already makes the development iteration cycle massively quicker. Just write code and run it. Like writing BASIC, Python or Javascript. This turns HDL development from a chore into a joy.
Now I find SpinalHDL which makes the actual source code you have to write an awful lot simpler. Approachable by anyone who can handle Spin or C or whatever regular programming language.
It's early days yet, these Free tools are a chore to get installed and running. But soon we can imagine they will come in packages for your operating system of choice and just work. Or they will be integrated into simple IDEs like MS Visual Studio Code, Atom, etc. Which is already happening.
All of a sudden the casual makers and tinkerers of the world be be able to get on with FPGAs with ease.
Anyway, I'm going to have some fun exploring all this and checking that what I'm saying actually true. Assuming pressure of work ever eases up a bit....
Heater,
The major part I find difficult is examples of defining simple things such as fixed pin placement. For example in IceCube2 verilog, some ice40 parts have high current outputs. When not used in this fashion you can use the pins as Open Drain. But how do you define the constraints to use these pins? Cannot find an example of actual use. I found the verilog instantiation but I don't know how to use it. Unfortunately there is no Lattice forum so no where to ask specific ice40 questions. It's my lack of understanding, but where does one find answers?
I realise these compilers take a long time to run, but they are extremely complex, and have taken many years to get where they are. However I understand the request for a simpler to use and faster to compile software.
...
But this market is being eroded all the time by other micros. And requiring external SPI Flash and an external crystal (plus 2+voltage regulators) are going to quickly date the P2. Don't expect to see it within 12 months either.
*external SPI Flash*
These parts are cheap and small. Sure, it is nice to have one less BOM item, but it's not a deal breaker at P2 prices/pin counts.
I would like Parallax to explore supporting Stacked Die on the P2 layout, so they keep the option of a internal SPI. (aka NUC505)
*an external crystal*
External Crystal or Osc is also not a big issue, as I doubt many P2 apps expect to be minimal RC-Osc based.
Chip has improved the PVT nature of the RC Oscs, so it is possible for Parallax to include a CAL byte/word in the OTP/Fuse area.
That would make it similar ex-factory precision to most others, but the added market footprint from this is not large.
Improved fail-safe operation is maybe a result, but I think P2 lacks any OSC fail/ OSC OK detection, so it is already weak there.
ie if you Start on RC osc and then flip to external, and it's not actually there....
Personally, I'd rank Osc fail safes, above Osc Cal.
*plus 2+voltage regulators*
This is a bit more valid, multiple rails are a pain, but at the powers FPGAs and P2 uses, there is little choice.
On chip linear regulators are not really an option.
SMPS parts are getting cheaper. Cheapest BUCK parts are now ~14c/3k, DUAL parts are ~27c/3k
As a linear option, I like the look of the new LDL1117S18R, LDL1117S33R (sub 10c, SOT223) but stocks are 'coming'.
I will agree, that all of the above does combine to make a compact P2 module more important. One that includes SPI+Osc+VREGs
Not sure what that part was exampling, but it is a useful point :
Yes, it is 72MHz, but 72MHz is modest to slow, in P2 space.
That 72MHz FLASH is actually 2 wait states, 00 wait states is only 25MHz, so you see direct Flash execute is actually significantly slower
I have no idea about FPGA forums. But then I have never looked. I presume the vendors have forums. I suspect most FPGA users are in industry and get their support via expensive training sessions provided by the vendors. Or perhaps they picked it up during their EE degree studies.
Most of what I know about actually using FPGA, Altera Cyclone and Quartus in my case, has come from this forum Chips has been very helpful.
That and the occasional scans through Altera docs and google searches. Oh and the Icarus Verilog site.
Certainly the compilers/synthesizers take a while to run. The magic thing I found is that for a lot of development you don't need those huge slow Quartus and other tools. While starting out on a new component/module one can run it under Icarus with a very quick edit/fix development cycle. When it looks like it is working as you want then you can go to Quartus and try it on a real FPGA.
I have yet to find the time to get into any Lattice parts. Soon I hope.
@jmg,
Perhaps you have naever produced a volume product. Otherwise you would well know that every part carries an overhead well in excess than the odd ~20c the part costs.
To a hobbyist this doesn't matter.
@heater,
Lattice have discontinued their forum. Shame
@jmg,
Perhaps you have naever produced a volume product. Otherwise you would well know that every part carries an overhead well in excess than the odd ~20c the part costs.
To a hobbyist this doesn't matter.
I've no idea what you imagine "well in excess than" to mean, in real dollars, but best not tell Raspberry Pi, lest they might discover it is impossible to make a Pi Zero for $5 !!
Don't worry, They already have noticed that it was impossible since the first boards were out of stock. So for several months it was impossible to find the Zero even on their four distributors. Nowadays they have found the trick to do it: they limit their RPIZero sales to 1 per person. While at the same time they have on sale the 'kit' RPIzero that is nothing more than a zero + SD + adapter that cost cents for them (on volume) but they sell at 7-10x times the price of RPIzero just to make up the loss on bare boards. Nice lesson to learn about how to playing to sell on loss mixed with sales statistics.
In fact they already knew that it was impossible since the first minute they planned the design. Zero was just a marketing campaign to get press media attention. 'Lowest cost computer ever made $5'. Now, just to not let people angry about their tactics, it has limited production and limited availability but full availability for the 'kit' version at 7-10x the original price for worthless extras that can recoup benefits for the sale at loss on the $5 boards.
BTW, following Cluso discussion: have you calculated the the BOM cost for that cheap 14c buck converter? What happens if it does require a big smd inductor whose price is ten times the IC? I can tell you this first hand.
I'd use it as a better documented alternative to XMOS XS-1. We already have products that use XMOS but their lackluster continued approach to documentation is such a turn-off that we're considering dumping them. I had to do a lot of reverse engineering. Our designs will fit into a P2 no problem. We do hard-realtime data acquisition and processing. We used to use SX48 20 years ago, first with hand-written assembly, then I wrote a time-triggered LISP compiler for it (I was young and crazy). I might revive that project for P2 since it allows to write high-level code and automatically enforces timing constraints (e.g. this must take no longer than X, or that must happen exactly at Y).
BTW, following Cluso discussion: have you calculated the the BOM cost for that cheap 14c buck converter? What happens if it does require a big smd inductor whose price is ten times the IC? I can tell you this first hand.
Inductors vary depending on the current, and losses you want. Some quick examples :
47µH 220mA are 6.5c/3k, 47µH 390mA(sat) are 9.1c/3k, 47µH 950mA(sat) are 12.5c/3k, 47µH 1.3A(sat) is 13.4c/3k, 47µH 2A(sat) is 16c/3k
- yes, there is a price curve there, but I'm not seeing 'price is ten times the IC' ?
That's also why I included a linear option, in a low cost, easily cooled, largish package ( not those 1.x mm XFNs/BGAs )
If your design is not pulling hundreds of mA, that's another choice.
I'd use it as a better documented alternative to XMOS XS-1. We already have products that use XMOS but their lackluster continued approach to documentation is such a turn-off that we're considering dumping them. I had to do a lot of reverse engineering. Our designs will fit into a P2 no problem. We do hard-realtime data acquisition and processing. We used to use SX48 20 years ago, first with hand-written assembly, then I wrote a time-triggered LISP compiler for it (I was young and crazy). I might revive that project for P2 since it allows to write high-level code and automatically enforces timing constraints (e.g. this must take no longer than X, or that must happen exactly at Y).
Sounds an ideal fit for P2. Which parts of XMOS needed 'a lot of reverse engineering' ?
Sounds an ideal fit for P2. Which parts of XMOS needed 'a lot of reverse engineering'
Internal registers are mostly undocumented and only wrapped up in a C API, going funky with the channels requires way more information than the documentation gives, and the built-in USB accelerator is completely undocumented but there was a need to understand exactly what it does. Heck, even some rather uncontroversial properties of the implementation of the abstract architecture were undocumented, like the number of available resources of various types (!).
One thing P2 won't do is select a.k.a. on-the-fly interrupt setup that allows no-latency response to events. That's a really helpful feature of XMOS. Only because of it the communication channels make some sense. Without this feature, memory-mapped communications a.k.a. HUB memory is the more straightforward approach.
One thing P2 won't do is select a.k.a. on-the-fly interrupt setup that allows no-latency response to events. That's a really helpful feature of XMOS. Only because of it the communication channels make some sense. Without this feature, memory-mapped communications a.k.a. HUB memory is the more straightforward approach.
Can you elaborate ?
The P2 does have interrupts, but there is no such thing as 'no-latency response to events', in any system, as some SysCLKs are always needed to sample and test any event.
The event dispatch system in XS-1 assigns an optional handler to each event. After awaiting an event, the code execution will continue in the handler for the highest priority event that occurred. Thus the no-latency effect - the next instruction executed is that of the event response code, there's no context saving/restoring etc. Propeller has 3 interrupts and they're not event-specific, so if you routinely handle responses to more than 3 events, the handlers have to multiplex and check which event occurred and react appropriately. To implement XS-1 like event handling, we'd need 32 register pairs instead of just 6. Or 16 registers for handler addresses, and a return address memory separate from register space. Perhaps it could be in the lookup ram at the very least.
As a separate matter, I wonder if bytecode interrupt handlers would be a useful idea. Those could be marked e.g. by setting the highest bit of the handler address to 1.
I presume you mean "After completing an event handler, the code execution will continue in the handler for the highest priority..."
It's not clear to me how that is much different than a normal prioritized interrupt system. Except there may be extra program counters and registers, per event, to remove context
switching overhead.
But presumably an XMOS core already has a set of regs per thread so that it can run them all in the instruction interleaved manner that it does. 8 such threads per core.
The event dispatch system in XS-1 assigns an optional handler to each event. After awaiting an event, the code execution will continue in the handler for the highest priority event that occurred. Thus the no-latency effect - the next instruction executed is that of the event response code, there's no context saving/restoring etc.
So that's equivalent to the P2 WAIT design ?
If you want paused code like that, you need one COG for each possibly simultaneous Event.
Comments
Exciting!
Going with the Parallax moto
"Made in USA"
Trivia: in the 00's, I did a full CAD construction lay out of a fab in 3D. When one looks at site drawings, it's amazing the builders and fitters get anything done! Its a rats best of colors and overlapping 2d wire frame squished down onto the paper.
When I got the model done, I had an amazing few days design review. They would just shout stuff out, and I moved, added, modified, until it was buildable and code compliant.
Then I surprised them with CDs that could boot on many laptops. Stripped down a Linux and had it render the data in this nice viewer the CAD company made. They could walk out to the job site and position the camera to see what it would look like.
Turns out tolerances are roughly an inch grid. That is what fitters are for!
Got feedback later. That FAB went up quick, few problems. Just seeing it mattered. The viewer had a measure function they used some, but just by eye scaling and their skill at construction did the trick.
Was for Intel. And a one off. Another guy was the expert, but something happened and he dropped my name to finish it. He was making a name by doing it this way and was just leaving a fully equipped computer on site rather than a ton of drawings. I had helped him get going a few years prior.
So I jumped on the thing, grabbed one of the veterans at this stuff and we went at it. FABS are complex.
Who is teaching REAL robotics?
Kuka, Fanuc, Motoman, et-al. The producers of the robots that are used in industry, don't utilise open-loop stepper-motors. They use closed-loop servos and surprisingly few "robot technicians" understand how they work.
The last time I checked, the most that any PIC (DSP) could handle is 2 quadrature encoders. A single P2 could handle a 6/7/8 axis REAL robot.
Apologies for this post's lack of structure or coming across as a rant but am working all hours right now and seriously need to hit the sack
For <<$1, Flash+SRAM+EEPROM+Fuses and internal oscillators !!!
Another thread was complaining about some cheap micros not having internal oscillators.
P2 is going to require external Flash to boot, and maybe external xtal. IMHO big mistake nowadays!!!
I have always imagined the P1/2 as alternatives to FPGA. For those applications where you need to do some twisty custom logic, with lots of I/O and deterministic timing. Cases where MCU's don't cut it but FPGA is too big, too expensive and too damn complex and cumbersome to work with.
This is similar to the goals of the XMOS devices.
Problem is the FPGA route is getting more attractive every day. What with the availability of small cheap FPGA chips and boards. And in particular the arrival of Free and Open Source tools that make using FPGA a lot less hassle. For example Icarus Verilog, Verilator, IceStorm and now SpinalHDL. One day someone will wrap those tools up in a drop-dead simple to install and easy to use IDE, Arduino style. With RISCV cores thrown in. Then novices can build their own custon logic with ease.
The Prop still shines as about the only device that supports plug-and-play dropping in of other peoples software components with out having to tackle analyzing how they will impact each other timing wise. Or mess with integrating them into ones interrupt hierarchy or operating system.
This is one part I'm looking at P2 Boot from.
Are you sure ? I have seen cheap micros that lack Xtal Oscillators, and the ATtiny1616 is one of those.
Pretty much every small MCU these days has a RC osc on board.
That means if the on-board RC osc is not good enough, you have to bump to an external Oscillator, there is no middle-step left.
These days, that external Oscillator, even tho cheaper than ever, is still much more costly than the << $1 MCU you connect it to !
I don't think it requires an external xtal, but certainly most P2 uses will use a Xtal or Osc, as it does not have a calibrated RC Osc.
There are other parts that have external code, ESP32, ESP8266 for example, and they seem to sell well enough.
On the topic of P2 memory candidates, I did see this ReRAM in the news...
https://www.crossbar-inc.com/en/products/p-series/
However, that ReRAM is qualified only for 40nm and below, so not yet on OnSemi process...
I agree with this sentiment. I may be a tiny minority, but I've never used the RC oscillator of the P1 (except as the PropTool may use it for programming, or the Propeller for booting). About half of my permanent Propeller projects sport OCXOs or TCXOs. For me, the Propeller is what gets used when I need to do a whole lot of complicated things at the same time and yet I need them all to be done perfectly. :-)
The P1 RC oscillator isn't any good for much. It is way too inaccurate.
All the new micros I see include a 1% trimmable oscillator. And yes, if that is not accurate enough, an external oscillator is required but tht only takes 1 pin. A lot of companies never mastered putting the xtal caps inside the chip like the P1. But still the prices for oscillators are coming down. While the HC49U/S are really cheap, they now take up a lot of space. The 3225 (3.2x2.5mm) or smaller crystals/oscillators are becomming the norm on boards. I am talking volume production here. No point in producing P2 if there aren't going to be any volume customers. Hobbyists will not keep Parallax going in the P2 market.
@jmg
The bigger ARM and similar chips have external memory because they are using large blocks of it. There are various builds where the external memories vary in size, and therefore cost. This is definately a different market to the P2.
That Nuviton chip is cheap. I will look at its specs.
@heater
I am quite OK with using the suppliers FPGA software if it is free. Their software is extremely complex. Xilinx started to charge ridiculous prices for their software in the very late80's and early 90's. Both Altera and Xilinx still do for the biggest FPGA's. But then again, so do they charge for those big FPGA's. For companies that have big margins, those prices don't matter. I would love to be able to get my hands on one of the latest and largest FPGA's - just in a TQFP100/144. Don't need all those I/O, fast lane I/O's. But sure would love all those LUT's and memory to play with.
But for me, I am now onto the FPGA's again. I designed some into products in the late 80's, using Xilinx software to hand route the design from I/O thru the LUTs and out again. One of them interfaced to the internal Bus on an ICL Mini Computer. I should dig out a photo.
Those Lattice parts are nice for the price. Internal oscillators, some have reasonable SRAM (P1 equiv). Some have OTP but also can boot from external spi flash.
RAM execute has definite speed advantages.
Analog Devices DSPs are all RAM based, & code loads at boot.
Their BlackFin parts start from $1.99/1k for 400MHz, 68KR
I also notice a pair of parts : these can boot from SPI memory, but have another option
ADSP-BF504F Blackfin 1 400M 800 68 KBR + 32MbF $7.48
ADSP-BF504 Blackfin 1 400M 800 68 KBR $5.18
For the added $2.30, you get a stacked die 32MbF, 70ns Tacc, or 50MHz burst, so much slower than RAM, but in-package and faster than SPI.
RaspPi type ARMs, are Microprocessors, not Microcontrollers - they either have stacked die, or flip-pcb BGA DDR memory.
Likewise the P2 will have a market where 512KB SRAM plus 16*4KB SRAM COGS.
The egg-beater will really help the big programs.
So the point I make is the program is soft-loadable, plus multi-cores. There is plenty of fast micros running from flash out there. But most (excluding ARM) don't have large SRAM making them unsuitable for softloading. There is a PIC that has 512B SRAM and 2MB FLASH IIRC (PIC32MZ???).
But this market is being eroded all the time by other micros. And requiring external SPI Flash and an external crystal (plus 2+voltage regulators) are going to quickly date the P2. Don't expect to see it within 12 months either.
@jmg
EFM8LB12F64EB in QFN24 & QFN32 64KB Flash 4KB SRAM 72MHz $1.24/1K
My observation is that those vendor tools, like Quartus, are vastly complicated beasts for users to get their heads around. It takes a significant investment of time and effort on the users part to even get started. Then when you do get going with it the development cycle, edit, test, repeat, is horribly slow and frustrating. One has to seriously need to use an FPGA to be bothered with all that. It's not for the casual user.
But now we have Free and Open Source tools coming along. Like Icarus Verilog, SpinalHDL, IceStrorm.
Icarus for example already makes the development iteration cycle massively quicker. Just write code and run it. Like writing BASIC, Python or Javascript. This turns HDL development from a chore into a joy.
Now I find SpinalHDL which makes the actual source code you have to write an awful lot simpler. Approachable by anyone who can handle Spin or C or whatever regular programming language.
It's early days yet, these Free tools are a chore to get installed and running. But soon we can imagine they will come in packages for your operating system of choice and just work. Or they will be integrated into simple IDEs like MS Visual Studio Code, Atom, etc. Which is already happening.
All of a sudden the casual makers and tinkerers of the world be be able to get on with FPGAs with ease.
Anyway, I'm going to have some fun exploring all this and checking that what I'm saying actually true. Assuming pressure of work ever eases up a bit....
The major part I find difficult is examples of defining simple things such as fixed pin placement. For example in IceCube2 verilog, some ice40 parts have high current outputs. When not used in this fashion you can use the pins as Open Drain. But how do you define the constraints to use these pins? Cannot find an example of actual use. I found the verilog instantiation but I don't know how to use it. Unfortunately there is no Lattice forum so no where to ask specific ice40 questions. It's my lack of understanding, but where does one find answers?
I realise these compilers take a long time to run, but they are extremely complex, and have taken many years to get where they are. However I understand the request for a simpler to use and faster to compile software.
Have you found any good FPGA forums?
*external SPI Flash*
These parts are cheap and small. Sure, it is nice to have one less BOM item, but it's not a deal breaker at P2 prices/pin counts.
I would like Parallax to explore supporting Stacked Die on the P2 layout, so they keep the option of a internal SPI. (aka NUC505)
*an external crystal*
External Crystal or Osc is also not a big issue, as I doubt many P2 apps expect to be minimal RC-Osc based.
Chip has improved the PVT nature of the RC Oscs, so it is possible for Parallax to include a CAL byte/word in the OTP/Fuse area.
That would make it similar ex-factory precision to most others, but the added market footprint from this is not large.
Improved fail-safe operation is maybe a result, but I think P2 lacks any OSC fail/ OSC OK detection, so it is already weak there.
ie if you Start on RC osc and then flip to external, and it's not actually there....
Personally, I'd rank Osc fail safes, above Osc Cal.
*plus 2+voltage regulators*
This is a bit more valid, multiple rails are a pain, but at the powers FPGAs and P2 uses, there is little choice.
On chip linear regulators are not really an option.
SMPS parts are getting cheaper. Cheapest BUCK parts are now ~14c/3k, DUAL parts are ~27c/3k
As a linear option, I like the look of the new LDL1117S18R, LDL1117S33R (sub 10c, SOT223) but stocks are 'coming'.
I will agree, that all of the above does combine to make a compact P2 module more important. One that includes SPI+Osc+VREGs
Not sure what that part was exampling, but it is a useful point :
Yes, it is 72MHz, but 72MHz is modest to slow, in P2 space.
That 72MHz FLASH is actually 2 wait states, 00 wait states is only 25MHz, so you see direct Flash execute is actually significantly slower
Most of what I know about actually using FPGA, Altera Cyclone and Quartus in my case, has come from this forum
That and the occasional scans through Altera docs and google searches. Oh and the Icarus Verilog site.
Certainly the compilers/synthesizers take a while to run. The magic thing I found is that for a lot of development you don't need those huge slow Quartus and other tools. While starting out on a new component/module one can run it under Icarus with a very quick edit/fix development cycle. When it looks like it is working as you want then you can go to Quartus and try it on a real FPGA.
I have yet to find the time to get into any Lattice parts. Soon I hope.
Perhaps you have naever produced a volume product. Otherwise you would well know that every part carries an overhead well in excess than the odd ~20c the part costs.
To a hobbyist this doesn't matter.
@heater,
Lattice have discontinued their forum. Shame
BTW, following Cluso discussion: have you calculated the the BOM cost for that cheap 14c buck converter? What happens if it does require a big smd inductor whose price is ten times the IC? I can tell you this first hand.
Inductors vary depending on the current, and losses you want. Some quick examples :
47µH 220mA are 6.5c/3k, 47µH 390mA(sat) are 9.1c/3k, 47µH 950mA(sat) are 12.5c/3k, 47µH 1.3A(sat) is 13.4c/3k, 47µH 2A(sat) is 16c/3k
- yes, there is a price curve there, but I'm not seeing 'price is ten times the IC' ?
That's also why I included a linear option, in a low cost, easily cooled, largish package ( not those 1.x mm XFNs/BGAs )
If your design is not pulling hundreds of mA, that's another choice.
Sounds an ideal fit for P2. Which parts of XMOS needed 'a lot of reverse engineering' ?
Internal registers are mostly undocumented and only wrapped up in a C API, going funky with the channels requires way more information than the documentation gives, and the built-in USB accelerator is completely undocumented but there was a need to understand exactly what it does. Heck, even some rather uncontroversial properties of the implementation of the abstract architecture were undocumented, like the number of available resources of various types (!).
One thing P2 won't do is select a.k.a. on-the-fly interrupt setup that allows no-latency response to events. That's a really helpful feature of XMOS. Only because of it the communication channels make some sense. Without this feature, memory-mapped communications a.k.a. HUB memory is the more straightforward approach.
Can you elaborate ?
The P2 does have interrupts, but there is no such thing as 'no-latency response to events', in any system, as some SysCLKs are always needed to sample and test any event.
As a separate matter, I wonder if bytecode interrupt handlers would be a useful idea. Those could be marked e.g. by setting the highest bit of the handler address to 1.
I presume you mean "After completing an event handler, the code execution will continue in the handler for the highest priority..."
It's not clear to me how that is much different than a normal prioritized interrupt system. Except there may be extra program counters and registers, per event, to remove context
switching overhead.
But presumably an XMOS core already has a set of regs per thread so that it can run them all in the instruction interleaved manner that it does. 8 such threads per core.
So that's equivalent to the P2 WAIT design ?
If you want paused code like that, you need one COG for each possibly simultaneous Event.