GHz Microcontrollers? You Bet! - Page 1
Forum section: electronics / general

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 03, 2019, 01:00:04 am
content: I never thought I'd see this happen so soon:https://media.nxp.com/news-releases/news-release-details/nxp-launches-ghz-microcontroller-eraThis beast has a Cortex-M7 core running at 1 GHz and a Cortex-M4 core running at 400 MHz.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 03, 2019, 02:46:17 am
content: It looks likePJRC will create a Teensy based on the i.MX RT1170 chipsomething like in the late 2020 timeframe. (Teensy 4.0 already uses i.MX RT1062 chip running at 600 MHz, which NXP itself lists as a similar product; because of this, I assume the plan is realistic.)

author: ataradov
author_rank: Super Contributor
timestamp: October 03, 2019, 02:56:06 am
content: This blends the line between MCUs and MPUs and not in a good way. It makes no sense to me. Programming and hardware design for something like this is not at all like for typical MCUs. So why not just put Cortex-A5 at that point?I guess NXP sees some market for this, but I just don't get it. There is no need for the clock frequency race in the MCU world, I'd rather see companies put out better peripherals.

author: KE5FX
author_rank: Super Contributor
timestamp: October 03, 2019, 04:18:53 am
content: Quote from: ataradov on October 03, 2019, 02:56:06 amHow so?

author: ataradov
author_rank: Super Contributor
timestamp: October 03, 2019, 04:24:36 am
content: Quote from: KE5FX on October 03, 2019, 04:18:53 amOn a board side, you will have to really pay attention to how you layout memories and power supplies. I doubt you could make this thing work reliably on less than 6 layer board.On a software side you will have to deal with caches, internal bus interconnects and stuff like this to get real performance out of it. It all gets abstracted away with real OSes, like Linux, but with things like FreeRTOS you will have to deal with all of that, and it is not trivial.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: October 03, 2019, 04:36:45 am
content: Quote from: ataradov on October 03, 2019, 02:56:06 amOf course they see a market, or it would not be built.So what if it is not a 'typical MCU' ?Quote from: ataradov on October 03, 2019, 04:24:36 amYup, but some customers will consider the performance worth the effort.eg They may have mocked up on a raspPi, and want a higher volumem lower power intermediate solution.

author: Marco
author_rank: Super Contributor
timestamp: October 03, 2019, 04:39:34 am
content: Why would it need 6 layers? It needs only a fraction of the power and ground pins of a MPU and you're not trying to escape 100s of high speed IO in between ... it still only supports 32 bit SDRAM.PS. is LPDDRx support really too much to ask for? Even if it could only work at low speed at least you're not paying a ridiculous premium for ancient tech with far higher power consumption.PPS. oops I missed it was a 298 pin package, that is getting up there a bit.

author: ataradov
author_rank: Super Contributor
timestamp: October 03, 2019, 04:42:04 am
content: Quote from: Marco on October 03, 2019, 04:39:34 amJust a gut feeling based on having to support people trying to use existing Cortex-M7 devices running at 300 MHz. I may be totally wrong, of course and this device may easily work on 4 layers.

author: ogden
author_rank: Super Contributor
timestamp: October 03, 2019, 04:46:54 am
content: Quote from: ataradov on October 03, 2019, 02:56:06 amFor IoT buzzword it isThere's always some number crunching application that could benefit from computing performance. Today you just toss MCU in where 10years ago only solution would be FPGA or "worse" - ASIC. Press release pretty much sums it up:Quote

author: rjp
author_rank: Regular Contributor
timestamp: October 03, 2019, 05:56:29 am
content: Quote from: ataradov on October 03, 2019, 02:56:06 amcpu's running operating systems dont boot instantly - that blurry line makes perfect sense for specialist task specific audio and imaging gear which is expected to boot nearly instantly from power on.

author: ehughes
author_rank: Frequent Contributor
timestamp: October 03, 2019, 02:06:43 pm
content: Now that it is public, I can talk a bit more. This series has been in development for awhile now and there are some high end customers demanding it.There are some very nice use case for high speed MCUs. I am working with a customer right now with a very special real-time supplication where an A5 and its interrupt latency would simply not work. The RT series is attractive as it is low cost and *really* fast for certain applications. There are some weird signal processing applications that benefit from a very fast micro controller that is low cost. In my particular case, we needed something with a reasonably fast ADC and the ability to crunch numbers real-time while not consuming a ton of power. A FPGA could work but the closest Xilinx part was still $35 (5x the price), was harder to develop with (30 minute synthesis times) and in a much larger package.Everyone talks up Linux for these high end applications but it comes with a huge amount of development burden just getting Yocto setup so you can end up with a small, tight binary that just boots and runs.

author: nctnico
author_rank: Super Contributor
timestamp: October 03, 2019, 02:42:00 pm
content: Quote from: ehughes on October 03, 2019, 02:06:43 pmThat is more a problem with Yocto being a convoluted mess rather than Linux itself. Using buildroot (which is 100 times more simple compared to Yocto) or even a standard Linux distribution makes more sense nowadays. With the current SoC projects I'm working on I develop on the target using a regular Linux distribution. This saves a ton of time compared to setting up a cross compilation environment.Another option is to use a bootloader as the OS. For example: U-boot has become like an OS on it's own with all the features it has nowadays.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 03, 2019, 03:40:17 pm
content: Quote from: ataradov on October 03, 2019, 04:24:36 amIt doesn't need to be so. The same was said on the new STM32H7 (Cortex M7 @ 400MHz, complex internal bus and caches), and I have very succesfully programmed it as any plain old microcontroller.Yes, the complex bus system and clock tree causes some headaches, but it certainly did not force me to go for an OS. Everything was solvable with the reference manual as usual, given maybe a few extra days compared to a simpler device.The ability to do calculations for software defined power converters at 400MHz actually is meaningful. For example, in my case, I'm running 30% CPU time in these interrupts. So it couldn't be done with, say, Cortex M4 at 120MHz (at least without thinking it again in a very different way). And it also cannot be done on an application processor. Hence I do see the appeal to these microcontrollers.I think the most important thing is to create a consistent and simple set of headers and simplistic HAL, and give enough examples. And write proper documentation, which is the key to succesful bare metal programming.My use case does a lot of image processing (3D time-of-flight processing, point cloud processing) and is a tightly integrated solution controlling the motors, etc, for safe maneuvering a mobile robot. Having a combination of no-OS bare metal simplicity and robustness, very low interrupt latency, large number of integrated peripherals (such as motor control timers, ADCs...), and still have "the oomph" for doing image processing was appealing. And yes, I could pay an extra few dollars to upgrade it to run at 1000MHz. 400MHz barely does it without extensive and tedious optimization.And I don't want nor need caches. I run them disabled. A large number of RAM sections, and the fast core-coupled special sections for instructions and data, are what I want. For simplicity and robustness, again.

author: Jan Audio
author_rank: Frequent Contributor
timestamp: October 03, 2019, 03:51:44 pm
content: QuoteNice.

author: Jan Audio
author_rank: Frequent Contributor
timestamp: October 03, 2019, 03:54:04 pm
content: Quote from: ataradov on October 03, 2019, 02:56:06 amMore then before is always better.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 03, 2019, 04:15:13 pm
content: Of course. It almost sounds like the famous "640K ought to be enough for anybody".20 or 25 years ago, the mere thought of a 100MHz MCU would probably have looked ridiculous. Now they have become almost entry-level.MCUs have specific benefits compared to more all-purpose CPUs/SoCs. MCU architectures, like ARM Cortex, have specific advantages. The fact the MCUs embed enough RAM, Flash and peripherals to be useful with very little to almost no external parts except bypass caps is also ultra-useful.I see no reason why 1GHz would be a specific barrier for usefulness. There are already 500MHz+ MCUs on the market. Is 1GHz suddenly a magic limit?I actually think the opposite: having more fast and dedicated "CPUs" on the market is interesting, rather than having to rely only on general-purpose ones.It's been often discussed, but actually using a typical ARM SoC as an MCU is a huge PITA, with many pitfalls, limitations, unreasonable power draw for the task, very hard to program bare metal, and the list goes on...

author: Siwastaja
author_rank: Super Contributor
timestamp: October 03, 2019, 04:27:16 pm
content: And, do note that the higher clock speeds come "for free" (until a certain limit, not 1GHz of course.)Smallest process nodes are always expensive, but so are the larger (because of more die required), in mass market. The sweet spot is somewhere in the middle. So, 20 years ago, the MCU "had" to be, say, max 20MHz to use the cheapest process. Nowadays, the cheapest process can support, say, 200MHz. Producing a "slower" microcontroller would mean slowing it down quite arbitrarily. (Either by actually limiting it way below its capabilities, or using an architecture which lacks fairly trivial delay path optimizations.)1GHz is, naturally, over that sweet spot so it's more expensive to produce, but yet it's going in that direction.Multicore MCUs are something I really look forward to see more in the future - after all, it can help when dealing with concurrency, and most MCU embedded systems do (except for the very simplest).And, in bare metal, definitely.I think that multi-coreism can be leveragedmuch mucheasier on an MCU, than on a classical workstation. Parallelism and multithreading is notoriously hard, but on an MCU, you can simply allocate different cores to run completely different programs, from different instruction memories, using different peripherals. Suddenly your interrupt-driven complex state machines just go away and you can write simple blocking programs to do things, especially relevant for bit-banging. (A bit like parallel VHDL processes,exceptthat youcanuse non-synthesizable behavioral things like "wait until...")Simple cores are small (compared to the flash & ram area), and the "difficult concurrent" issues demand very small sub-programs (often less than 1Kbytes), so not much RAM. So why not have one stronger "main" CPU, and a several smaller (preferably more than just 1) IO cores.Yes, all of this is already being done, but it's still very novel and niche. I'm waiting to see where this goes. Doing it in a simple and robust manner is what is needed.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 03, 2019, 04:28:03 pm
content: Quote from: ataradov on October 03, 2019, 02:56:06 amI see this as primarily a marketing gimmick. Sure, some people need this kind of performance, but most don't, but having a part with this potential in your product line will help sell the more common lower speed parts.I also see this the same way I see cars that are capable of 150 MPH+ in a country where the speed limits are generally around 65 MPH.

author: dietert1
author_rank: Super Contributor
timestamp: October 03, 2019, 04:37:23 pm
content: Yes, i also think this development is a continuous process. The difference between the Raspberry Pi processor and any of these high power Cortexes isn't that huge. I also remember the surprise when running some double precision tests on the STM32H7. Emphasis on the GHz limit is no more than a NXP marketing idea.Working with ARM processors, once you have done one or two Cortex projects, you won't have difficulties to setup a bare metal environment for the bigger machines. It's just a lot of work because those machines are complex and have lots of options to setup properly. Manuals are 1000 pages upwards, not really suitable for a single person project. And a multiprocessor is yet another level.Regards, Dieter

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 03, 2019, 04:53:43 pm
content: Quote from: Siwastaja on October 03, 2019, 04:27:16 pmYep, agreed. This is one approach I suggested when we were discussing "alternatives" to the XMOS xCore thing.There are already Cortex-M7 MCUs with an additional M4 core, but it's still limited in that direction. Many more smaller cores in addition to one "big" one would be indeed interesting, and easier to program.As to the sweet spot you were talking about - of course, there are the technical factors, and then the financial ones. But very small and very fast cores could typically be very cost effective using finer process nodes. Now a big problem with the finer nodes is that a given die quickly becomes more pad-limited than limited by the logics it contains... so, except with very large CPUs, a big concern is the number of IOs. But you could certainly design a very fast, and very simple MCU with a small number of IOs on say a 14nm process, and still yield pretty cheap ICs (it's all in the numbers of course).The Kendryte K210 MCU, for instance, which is on a 28nm process IIRC, even though it's dual-core and has a significant amount of embedded SRAM, still has a relatively small number of IOs. No wonder about that...

author: tggzzz
author_rank: Super Contributor
timestamp: October 03, 2019, 05:15:37 pm
content: Quote from: Siwastaja on October 03, 2019, 04:27:16 pmI agree that multicore is the future, but to coin a phrase "the future is already here, it is just that it isn't evenly distributed".History has repeatedly demonstrated that programming will be a conceptual bottleneck holding back the technology.QuoteExactly. A core's while (1) {...} mainloop can also include "USB comms" or "ethernet comms" or wait until this i/o || that i/o || message received || message consumed || timeout ||...Ob caveat: asymmetric processors have had a rocky past. It isn't unknown for the "big fast core" to get hung up waiting for the "slow small core" to finish doing its job.QuoteSuch MCU hardware has been available for a decade (currently xCORE is at 32 core/4000MIPS extendable), and simple/robust software concepts and languages since the 1980s (CSP/Occam and now xC). Hence itoughtnot to be novel, but...Niche? Yes -currently

author: Marco
author_rank: Super Contributor
timestamp: October 03, 2019, 05:48:43 pm
content: Quote from: ehughes on October 03, 2019, 02:06:43 pmOn the other hand, you get real memory. I don't understand why these faster MCUs don't get LPDDR3/4 support ... why only support SDRAM? It's 3 decades old, are they taking the piss?STM32MP1 with a single A7 core is 5 euro in volume and ST says you can put it on a 4 layer board without blind vias. How hard is RTX to use on the Cortex A7?

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 03, 2019, 05:59:11 pm
content: You can make the case that this part isn't a true MCU because it doesn't have internal flash memory. I guess that's why NXP calls it a "Cross-Over" MCU. I suppose this is driven more by the process technology in this case, however (it's difficult to implement flash below 40nm and this part uses a 28nm process).

author: coppice
author_rank: Super Contributor
timestamp: October 03, 2019, 06:01:56 pm
content: If you want a flash based MCU the flash brings severe speed constraints, even if paired with a reasonable amount of cache. Use ROM or RAM for the code and gigahertz MCUs are not a problem. A lot more MCUs are likely to run from RAM in the next few years, many booted from a local serial flash die in an MCM. While most MCU applications only need the MCU to run at a few megahertz, a lot of potential applications open up if you can get cheap MCUs that will compute fast enough to do some serious signal processing.

author: mac.6
author_rank: Regular Contributor
timestamp: October 03, 2019, 06:37:55 pm
content: internal flash is a big bottleneck for MCU. 40nm is already problematic for flash, not mentioning speed issues (128 or 256bit memory bus width is common).Future is MRAM but it comes with its own problems too (like magnetic sensibility).

author: mark03
author_rank: Frequent Contributor
timestamp: October 03, 2019, 07:43:55 pm
content: Quote from: imo on October 03, 2019, 04:37:14 pmThe pattern that I have seen thus far is newer processors which run at faster speeds, can be under-clocked to run at the same speed as the old tech, with lower power. Hopefully that remains the case. I know that there are leakage issues at the smaller process nodes. NXP was talking up FD-SOI a while back, but that seems to have been delayed...Edit: press release says this chip *is* built on FD-SOI. So I would expect the power numbers to be significantly better than STM32F7/H7 and the prior iterations of iMX RT. Will be interesting to see when it actually ships in quantity (at Digikey).A shame about the high-pin-count package though. Hopefully they will migrate the 28nm FDSOI stuff into the more mainstream parts eventually.

author: Marco
author_rank: Super Contributor
timestamp: October 03, 2019, 08:10:33 pm
content: The I.mx7ulp seems finally in production, so they seem to be getting fdsoi in grip ... 2 years behind schedule.

author: lucazader
author_rank: Regular Contributor
timestamp: October 03, 2019, 08:36:01 pm
content: I am really liking the trend towards flashless MCU's.They are much cheaper than the flash based ones, and then you can use off the shelf QSPI memory that is a fraction of the cost per KB that the on hip flash costs.It allows manufacturers to produce smaller higher yield dies, which results in cheaper processors.Or it allows them to switch to smaller more power efficient production nodes.Or put that die area towards on chip dcdc subsystems instead of the LDO's traditionally used to scale 3v3 down to the core voltage. Which again improves power consumption.I very much like the idea of this chip.Ability to run a few motors in a dedicated M4 core with low interrupt latency, and then have HMI, USB and WiFi/Ethernet comms on the other processor, all while maintaining low power consumption sounds like a great idea to me.

author: radioactive
author_rank: Regular Contributor
timestamp: October 03, 2019, 08:51:39 pm
content: What do they have for A/D converters on the new NXP parts? I'm impressed with the 16-bit converters on the stm32h743 as well as the dsp capabilities.

author: lucazader
author_rank: Regular Contributor
timestamp: October 03, 2019, 09:50:41 pm
content: From what I can see they have only specified the sample rate of the ADC's in the literature released so far for this new chip (2MSPS).This is faster than previous chips in the same line which are 12-bit 1MSPS units.However i couldn't see any spec for the bit depth of the ADC ont he new processor.

author: nctnico
author_rank: Super Contributor
timestamp: October 03, 2019, 10:45:13 pm
content: Quote from: Marco on October 03, 2019, 05:48:43 pmI think these kind of MCUs are designed to put on a 4 layer board. An LPDDR4 design needs 8 layers at the very least.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: October 03, 2019, 11:14:30 pm
content: Quote from: coppice on October 03, 2019, 06:01:56 pmWouldn't that bestealing intellectual property from China?

author: Marco
author_rank: Super Contributor
timestamp: October 03, 2019, 11:32:07 pm
content: ST maintains you can use the stm32mp1 with lpddr3 on a 4 layer PCB, without blind vias even. See their routing application note.

author: thm_w
author_rank: Super Contributor
timestamp: October 04, 2019, 12:29:03 am
content: Let me know when a 1GHz beast is available in QFN or QFP48Quote from: lucazader on October 03, 2019, 08:36:01 pmGood point, 1MB of flash is ~50c digikey, whereas moving from 256kB to 2MB for an STM32 is a massive $5-10 increase in price. The question is, how much of that is profit margin and how much is actual inherent cost of the chip? We know with other consumer goods the margin is much higher on the larger parts, and that the low end parts are often remarks/bins of the high end ones.So many manufacturers may be reluctant to do this.

author: lucazader
author_rank: Regular Contributor
timestamp: October 04, 2019, 12:35:07 am
content: Quote from: thm_w on October 04, 2019, 12:29:03 amIt also allows you to more freely pick the MCU performance, and or package/pin count that fits your application, and then decide on the amount of flash your application will need (and potentially up or down size this amount as needed before or during production).This would be an ideal world scenario of course. But to some extent we have used this in some of our products allowing us to get the correct amount of flash in a product rather than paying for 1MB of internal flash, and then also 4MB of external (which has happend previously) when we could and should have just used the external 4MB.

author: coppice
author_rank: Super Contributor
timestamp: October 04, 2019, 12:37:11 am
content: Quote from: thm_w on October 04, 2019, 12:29:03 amThis is market pricing. Adding 2MB of flash doesn't blow up an MCU's cost by several dollars. Adding 2MB of RAM costs more than 2MB of flash, at least down to 40nm. So, a RAM based MCU that boots from serial flash will be more expensive than a flash MCU. The main argument for using RAM is to allow faster execution. At 28nm and below flash can be problematic, so a different set of constraints will apply.

author: westfw
author_rank: Super Contributor
timestamp: October 04, 2019, 02:14:48 am
content: QuoteNo. "Obvious" and also "Prior Art" (FPGAs loading from serial EEPROM.)

author: OwO
author_rank: Super Contributor
timestamp: October 04, 2019, 03:49:38 am
content: I think most applications that use a 1GHz MCU are really better served by an FPGA. For example high speed concurrent I/O, realtime DSP, or anything requiring low latency. Microprocessors can NOT multitask no matter how you dress it up, so they are no good for I/O. They also suck at DSP. I had an application that needed to demodulate a certain signal, and the most optimized NEON implementation on a cortex-A9 took a few hundred clock cycles per sample to do it. In contrast a half decent hardware implementation using very few FPGA resources (only one multiplier) would take no more than 30 cycles per sample.The sad state of affairs is simply because most people can't be bothered to learn hardware design, and even when they do they stick to software -ism like "processes" or behavioral logic design. IMO FPGA design should be like designing a circuit - you describe the circuit elements at a high level (for example in terms of adders, multipliers, and sub-modules), but in the end you are still wiring up a circuit and not describing "operations" to be performed.

author: mark03
author_rank: Frequent Contributor
timestamp: October 04, 2019, 04:05:40 am
content: Quote from: OwO on October 04, 2019, 03:49:38 amThe big players in FPGA-land are making this worse, in a way, by going all-in on tools and wizards which try to make engineers productive without knowing any HDL at all (see the recent Xilinx Vitis announcement). This may well be the future, but in the meantime, it tends to obfuscate the lower-level tricks and techniques for those just starting out. E.g. years ago Xilinx had app notes on topics like how to optimize FIR filtering or DDC/DUC; now they just tell you to use the closed-source wizard instead. Great (?) for productivity and time to market, not so good for actual understanding. Also, just try finding a good text on DSP design in Verilog/VHDL.

author: mark03
author_rank: Frequent Contributor
timestamp: October 04, 2019, 04:10:49 am
content: Quote from: thm_w on October 04, 2019, 12:29:03 amThere is a *lot* more to this than price per MB. On-chip flash is way faster than external QSPI. Even if you go for the latest and greatest Octo- or Hyper-flash or whatever, AFAIK the basic on-chip flash in something like an STM32 is still faster. (Isn't the flash 128 bits wide in STM32?) And of course you are also paying a significant power penalty when the flash moves off-chip.I don't see much point in running code from flash on an iMXRT. All of the applications I have in mind would treat the part more like an FPGA: Load the program into internal RAM at boot time, and run from there.

author: techman-001
author_rank: Frequent Contributor
timestamp: October 04, 2019, 05:32:17 am
content: Quote from: Sal Ammoniac on October 03, 2019, 01:00:04 amDo they have a low power version, you know, one that only draws 5 Amps at 1.8 volts ?Actually, forget it .... I'm waiting for the new STM32 with the 50 qubit quantum core so I factor my Primes in 100 seconds instead of having to wait 28 Billion years with a NXP Cortex-M7.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: October 04, 2019, 05:53:35 am
content: Quote from: westfw on October 04, 2019, 02:14:48 amFPGAs, and the EZ-USB FX, too. But there are major details to attend to when the flash is inside a multi-chip package, such useful, patentable details as loading the application code into the flash, copying the application from the flash to the program RAM on startup, and controlling application read/write access according to lock bits and control signals. GigaDevice implemented a serial flash translator emulating the ST embedded flash controller including memory-mapped writes, and got a Chinese patent issued August 2016 on it. I guess other vendors can still use the system ROM.Quote from: mark03 on October 04, 2019, 04:05:40 amGreat for lock-in, too. Xilinx can't seem to say no to a walled garden.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 07:09:11 am
content: Quote from: thm_w on October 04, 2019, 12:29:03 am1000MIPS, 64 pin tqfp. Other packaging available. Other memory, interface, and i/o options available.https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103If you want more horsepower...2000MIPS, 128 pin tqfp. Other packaging available. Other memory, interface and i/o options available.https://www.digikey.co.uk/product-detail/en/xmos/XLF216-512-TQ128-I20/XLF216-512-TQ128-I20-ND/51487154000MIPS, 374 pin fpga. Other packaging available. Other memory, interface and i/o options available.https://www.digikey.co.uk/product-detail/en/xmos/XEF232-1024-FB374-C40/880-1107-ND/5358020

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 07:12:46 am
content: Quote from: coppice on October 03, 2019, 06:01:56 pm1MByte flash 1000MIPS, no cache to get in your way, nowhere near the top of the range.https://www.digikey.co.uk/product-detail/en/xmos/XUF208-256-TQ64-I10/XUF208-256-TQ64-I10-ND/5401103When you hit a brick wall, change direction!

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: October 04, 2019, 12:50:31 pm
content: Quote from: tggzzz on October 04, 2019, 07:12:46 amNot sure it's a direction many people will want to go:Quote

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 04, 2019, 02:58:06 pm
content: Quote from: donotdespisethesnake on October 04, 2019, 12:50:31 pmThey seem to be focused on audio applications, which fits well with their architecture. Higher data rates, such as SDR applications, are probably better served by FPGAs.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 03:07:40 pm
content: Quote from: donotdespisethesnake on October 04, 2019, 12:50:31 pmYoungsters will have to change direction during their career. The xCORE devices are currently the best starting point in a solid different direction. They won't be the end word, but I've yet to see better.I'm looking for alternatives, but haven't seen anything interesting.QuoteThe point of the post was to illustrate that coppice's contention wasn't strictly correct.TheIDEcalculates the maximum number of processor cycles to get fromheretotherein your application. That includes the effects of compiler optimisation and the number of cores in use. It doesn't need to take account of variations due to caches and interrupts, because there aren't any.All other MCUs I've seen require max time to be measured, while keeping your fingers crossed that you have blundered across the worst case.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 03:26:24 pm
content: Quote from: Sal Ammoniac on October 04, 2019, 02:58:06 pmI'd use an FPGA for SDR applications too!There will always be applications that are outside any processor's computational capabilities; boringThere will always be the tension embodied in Amdhal's law.However, the xCORE devices are halfway between conventional MCUs and FPGAs:very FPGA-like IO structures, e.g. 250Mb/s SERDES, strobed interfacesvery FPGA-like control flow, e.g. wait for any of N conditions (e.g. timeout, i/o complete, message tx/rx) and resume computation on the next clock cyclevery FPGA-like timing guarantees. Each i/o port contains a timer, allowing output to be setup to occur on a specific clock cycle, or the capture the clock cycle when input arrivedvery FPGA-like clocking: multiple clocks at different frequenciesvery FPGA-like solution composition: multiple simultaneous non-interfering processing, communicating results where necessaryAs a demonstration of "kicking the tyres" I was able to count usesoftware alonetoguaranteecounting all the transitions on two 62.5Mb/s input streams. That's not impossible in a standard MCU, but I'd like to see someone guarantee that when front panel-i/o and USB comms is occurring at the same time.The whole process was delightfully simple; the hardware and software manuals were short and accurate - with neither errata nor gotchas.

author: nctnico
author_rank: Super Contributor
timestamp: October 04, 2019, 03:38:48 pm
content: Quote from: Sal Ammoniac on October 04, 2019, 02:58:06 pmI'd like to add that controllers like these are another nail in the coffin of typical DSPs.

author: MT
author_rank: Super Contributor
timestamp: October 04, 2019, 04:00:11 pm
content: Quote from: ataradov on October 03, 2019, 02:56:06 amThere are a big and multiple markets for speed, audio is one, images another. I look forward to even more speed, more cores and smaller pin packages and for ST they really have to fix their pin mapping mess!

author: Marco
author_rank: Super Contributor
timestamp: October 04, 2019, 04:07:46 pm
content: xCORE managed to score a couple of niches because of its USB audio software, but for price/performance or power consumption it's not really in the same range as RT1170 or STM32MP1 AFAICS.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 04:17:35 pm
content: Quote from: Marco on October 04, 2019, 04:07:46 pmAs per the topic title, xCORE demonstrates that GHz MCUs (and above) aren't new and have been around for a while.I regard xCORE as anexampleof thekindof radical thinking thatwillbe required in the future. I certainly don't regard it as the last word on the subject; I hope it isn't.Since the 80s the principal MCU speed improvement has been due to improved semiconductor processes. That's rapidly running out of steam due to heat flux, numbers of atoms/electrons in junctions, leakage, and even the speed of light in silicon.Parallelism will have to happen, and that requires different ways of designing/constructing software. The old techniques won't cut it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 04, 2019, 04:19:23 pm
content: IMHO, although they are pretty nice and potentially versatile, XMOS products are still niche products, and will probably remain for a sizeable amount of time.Conventional single- and multi-core architectures are still going to be pretty useful for a large number of applications. The paradigm shift is all nice with xCore, but it's not completely without inherent limits, and its departure from conventional architectures requires the use of a specific language (xC). The language itself is not half bad; problem is, it's just a niche language at the moment. Getting teams to use it is not necessarily a picnic; and then, if you have any regulatory requirements, it may even just be a strict no-no. Maybe that sucks, but just how things are...I also wouldn't be comfortable basing a whole development on something that has simply no equivalent on the market, tieing myself to just ONE vendor. Very risky. Whereas decently written C can be ported relatively easily, xC can't be ported easily to anything else much at the moment. Another issue, at least IMO. Not fair, but just the way it is. And I don't know enough about xC to know if the situation can even be corrected - is xC open, and can other vendors actually use it for their own products? If not, then it's not a fairness problem; it's a deliberate choice from XMOS. If it's possible, then, it becomes interesting.A quick thought... to me, CPUs REQUIRING external RAM to run do not really qualify for the term "MCU" anymore. Of course the term is going to be twisted in all kind of ways in the future for marketing reasons. But one of the typical benefits of MCUs is the low part count/high level of integration. Of course, you'd get the same amount of integration as far as the user is concerned if the external RAM (/Flash/...) is provided as a separate die inside the same package. But an MCU requiring DDR4 RAM? Damn. No thanks. I know SRAM is expensive, but I think it would be interesting to invest more research on it than strictly relying on dynamic RAM for some applications.As to FPGAs, they can do a lot of things, but are certainly not a viable alternative in a large number of cases. They are very good for some, ultra parallel algorithms, but otherwise, they can't compete with an optimized CPU for running sequential code, from a speed, power draw(++) and cost POV. And integration. Large FPGAs tend to have a very large number of IOs, which you may not need at all, and require a large number of bypass caps. So, no, they are not a replacement for everything, not even in all applications where you need very fast processing.

author: nctnico
author_rank: Super Contributor
timestamp: October 04, 2019, 04:27:03 pm
content: Quote from: tggzzz on October 04, 2019, 04:17:35 pmSorry but parallism has been around for ages and it isn't new. The reason why it is not often used is because parallel processes which are asynchronous by nature make it very harder to predict whether a program runs correctly or not.You keep pushing the XMOS processors but to me these seem more like a software defined FPGA rather than a general purpose microcontroller.Quote from: SiliconWizard on October 04, 2019, 04:19:23 pmIn a not so distant past microcontrollers didn't have internal memory either. Take the 8051 for example. I recall a design I did about 20 years ago which used a 40MHz 8051. This device started at half clock speed, copied the flash to the SRAM and then switched to full speed and execution from SRAM.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 04, 2019, 04:38:19 pm
content: Quote from: nctnico on October 04, 2019, 04:27:03 pmOh, I know. Note that back then, they were not even called microcontrollers, but, IIRC, "microcomputers", until the first chips with embedded RAM and EPROM appeared. And, did the 8051 not have a small amount of embedded RAM anyway? Like 256 bytes? (If memory serves... not completely sure.) So for some very simple things, you didn't necessarily need an external RAM chip?As to "not so distant"... 8051 chips can still be found. That doesn't make them current. 20 years ago, MCUs with a sizeable amount of embedded RAM and Flash were certainly already pretty common, and pure 8051 stuff, mostly used for cost or legacy reasons.Then the term "microcomputer" got replaced in all datasheets, sometime in the late 80s. But again that's just a matter of definition, and use cases. These days, you're expecting an MCU to provide a high level of integration. Going backwards in terms of integration, would, IMO, be a mistake, and, as much as I said pure "MCUs" still can't be replaced with more general-purpose CPUs in a lot of cases, if you're going, OTOH, to use an "MCU" that requires external RAM, Flash, and possibly other external stuff to run, you can as well go for a more general-purpose CPU in many cases, and that's the cases where I would agree that the line between the two is being crossed. So to me, that's not the clock rate that makes the line crossed at all, but more the integration factors, and the overall complexity of the architecture.

author: coppice
author_rank: Super Contributor
timestamp: October 04, 2019, 05:10:28 pm
content: Quote from: tggzzz on October 04, 2019, 04:17:35 pmThis is accurate, but not in the way I think tggzzz meant. MCUs have gotten faster because they just naturally do as the process is scaled down for economy. Most MCUs in use today are running well below their rated speed, because that's all the application demands, and the power consumption is a bit lower at the lower speed. Many faster MCUs, designed for control applications, like the TI C2000, Motorola 56800 and Mcirochip DSPIC are/were not even marketed as MCUs, but as digital signal controllers, because these faster performers represented a different market from MCUs.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 05:10:57 pm
content: Quote from: SiliconWizard on October 04, 2019, 04:19:23 pmApart from minor points, we are in violent agreementConventional programming paradigms and tools have their inherent limits too. They are more familiar limits, so they aren't as noticable and are just part of the scenery. My contention is that future progress requires travelling into different "scenery", so different limitations will become pain points. Might as well start now, particularly with youngsters with a career ahead of them.Apart from that, xC is merely one (reasonably pure) embodiment of CSP. There are other less pure embodiments incorporated into other modern languages.CSP is a fundamentally different paradigm, just as procedural/function/OO/FSM/etc paradigms are different. I'm more than happy to jump from one paradigm to another when it makes it easier to create a high quality solution to a problem, (e.g. C to Java).

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 04, 2019, 05:22:40 pm
content: Quote from: tggzzz on October 04, 2019, 05:10:57 pmOh I know, and I know. I was just merely saying that using xCORE at the moment was implying using xC, and that wasn't portable to anything else. If xC was open (which I still don't know, if you do, please tell me), that could actually "boost" the use of XMOS products significantly, lowering the mentioned barriers. And maybe pushing some companies to actually leverage it and develop CPUs with alternate architectures... while still maintaining some amount of "portability".Not to say that the concept itself is not interesting, or that it can't be implemented in other ways. I think diversity of solutions is a nice thing anyway. Not every task needs a hammer.Maybe I see your point though, as far as education goes; students are still mainly exposed to very mainstream tools and architectures, in a purely utilitarian approach, whereas education is a good period to take time to open your horizons and prepare for the future.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 05:30:54 pm
content: Quote from: nctnico on October 04, 2019, 04:27:03 pmAgreed. I first looked at Occam and Transputers in the early 80s, but they weren't a fit for my applications. CSP was from the 70s.Unfortunately too many people don't recognise the history, and repeat bits of it badly. I want to remove "badly" from that observation!QuoteAsynchrony iseverywhere, from the internal implementation of processors and processor/memory systems, FPGAs where the cross-chip wire delay limits the clock speed, to any application that cannot fit in an SMP machine, to distribnuted processing. That's inevitable given that a 1GHz/1ns clock signal repeats every ~20cm.There are techniques for dealing with asynchrony, but they haven't crept into the traditional software paradigms. That will have to change in the future, if progress is to be maintained.QuoteI don't push them, but I do compare and contrast their significant advantages with plain-vanilla MCUs. Sometimes people benefit from having their thinking jolted out of the standard rut.There is, aswerecognise but many don't, a continuum between FPGAs and ordinary MCUs. The same designs can often be implemented in either technology, and it is fun to push/pull functions from one to the other as appropriate. Hence xCORE does indeed occupy a middle ground between ordinary MCUs and FPGAs; good.However, theyaregeneral purpose processors, and can be used as general purpose processors using conventional tools. Doing that loses some of their advantages, of course.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 05:44:15 pm
content: Quote from: SiliconWizard on October 04, 2019, 05:22:40 pmI presume xC is a single-vendor solution. Openness only really realises its benefits with "me too" products and tools. If "me too" tools (e.g. screws/nails/bolts and other fasteners) can do your job, fine - but sometimes unique fasteners make improved joints faster and cheaper.QuoteToo true. Too frequently not recognised. Sheep stay inside their penQuoteI chose a university and course that taught me things I didn't think I needed to know. It educated me and hinted at many ways of thinking and solving problems, and to look at better ways of doing things in the future.In the UK 50% of kids go to university whereas in my time only ~8% did. I get the feeling that many "universities" are actually "trade schools", teaching people how to make mortar of the right consistency and how thick to put it between the bricks. Now that is just fine and necessary, but it islimiting.Isaac Asimov's novella "Profession" significantly influenced my thinking when I was a teenager. I wish more youngsters would read it now:https://www.abelard.org/asimov.phpIt remains valid.

author: Yansi
author_rank: Super Contributor
timestamp: October 04, 2019, 06:13:45 pm
content: Quote from: ataradov on October 03, 2019, 04:42:04 amAtaradov, your insight into stuff and your opinions are mostly great, however this time you are off.You deal with the very EXACT SAME caches and MPU (=Memory Protection Unit) once and every time you use a Cortex M7. If one does not know how to deal with them, one should probably not program Cortex M7, regardless of its CPU clock speed. External memory chips are typically transparently accessible within the internal linear 32bit memory space, via the means of the memory controller peripherals.Fast MCUs are pretty easy to deal with on 4 layers, even MPUs with DDR memories. (Ever heard about Allwinner Cortex A chips in a LQFP?).Also, GHz CPU does not mean GHz memory interface. Not at all.//EDIT: The main awesome advantage of a fast MCU is practically Z E R O boot time, if nothing else. Also, very good for safety critical applications, as the code is way more easily auditable and available for analysis, rather then a piece of broken linux.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 04, 2019, 06:44:26 pm
content: Quote from: tggzzz on October 04, 2019, 05:44:15 pmI don't completely agree with that, and I'm not sure you completely got my point here, so here it is.I don't agree with "Openness only really realises its benefits with "me too" products and tools". That is certainly not true. Openness has several benefits, one of the most important being perennity, and this is the one I specifically was on about here.If some vendor tool is open, I know my developments are potentially perennial. If the vendor ever shuts down, or I want to have opportunities to go see elsewhere, and if no solution exists, even devise my own - then I can. If the tool isn't open, I can't. I'm stuck. If you want your developments to be perennial/reusable, that's an important key factor, and I'm saying this is a major criterion why I never used XMOS products personally, and I'm certain it is also for many other potential customers.Being able not to rely on a single source IS often important. It's not just as caricatural as "me too" products. If you want not to be tied to a single source, it's just vital.If your developments are, OTOH, just one-shot and non-critical stuff, it doesn't matter.

author: tggzzz
author_rank: Super Contributor
timestamp: October 04, 2019, 08:31:28 pm
content: Quote from: SiliconWizard on October 04, 2019, 06:44:26 pmIt is Friday, so I completely believe those statements.The perennity concept is valuable, but it has significant limitations. Consider, for example, that you use version x.y.z of a C compiler. Later on you come back and use version x.y+3.z-1. The compiler flags and optimisations may very well result in a significantly different binary. The only solution is to have your completed environment in a VM and hope that the third party libraries don't require yet another versionAnd then we can consider all the various versons of the language itself.

author: maginnovision
author_rank: Super Contributor
timestamp: October 04, 2019, 08:56:59 pm
content: Also you should cut in half the mips for all of the xcore 200 mcus unless you plan on writing dual issue code exclusively and all in assembly. The compiler only does it in a few cases and sometimes it runs slower with dual issue produced code due to poor optimization.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 04, 2019, 08:57:40 pm
content: Well, maybe I'm just not making my point completely clear, or maybe you're just tired. Or possibly both.The "binaries" point doesn't seem really relevant here. I'm not expecting "open" to the extreme of being able to reuse binaries plug-and-play. That rarely even happens in the computing world.So, I'll take a couple examples to illustrate what I mean, and hopefully that'll make things clearer.If I design a device around an MCU and program it in C in a reasonable way (most code portable, the only non-portable stuff clearly defined and well isolated), switching to a different MCU from a different vendor IS possible, and may not take much time. I'll have some porting to do for the non-portable parts, but that's mostly straightforward if I did things right in the first place. If the MCUs are on a similar architecture, that's even more straightforward, but even when they aren't, that's usually not a huge deal (unless I really used very specific features ALL over the place... which I avoid doing, or if I do, that'll be on a very small design needing a lot of optimization, and if it's small, rewriting it would take a lot less time anyway.)If I design for an FPGA in VHDL, and again structure my code properly, porting it to a different FPGA is not that big a deal. If I used some specific IPs from one FPGA, I'll just port those parts to use equivalent IPs for the other. Done. I also usually write VHDL so that it can even be synthesized trouble-free on an ASIC if needed, and again, modulo just replacing specific IPs with corresponding ones, or implementing them.In both cases, that's what I call perennial. Language versions don't matter much if what I used was defined from the start. If I develop C99-compliant code, all I'll need is a C99-compliant compiler for other targets. If I develop VHDL-2008 code, all I'll need is a VHDL-2008 compliant tool... (and that said, I tend to stick to VHDL-2002 most of the time, to avoid having potential problems running into tools that are not yet fully 2008-compliant.)It's not "plug and play", but most of the work is reusable.As I said above, I don't know exactly what license(s) apply to xC. If the language reference is free to use, and if third parties have a right to develop xC compilers, I'll consider xC "open". The XMOS xC compiler itself doesn't necessarily have to be open source. Now if XMOS doesn't allow any third party to use/implement xC, I'll consider it "closed", and my developments in xC would be forever tied to XMOS products. I'll really have to check about that!

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 04, 2019, 11:16:59 pm
content: For what it is worth, I like heterogenous multiprocessing, and find it in some ways even more useful than symmetric multiprocessing.The Odroid HC1 single-board computer I have uses a Samsung Exynos 5422 eight-core big.LITTLE processor, with four 2 GHz Cortex A15 cores, and four 1.4 GHz Cortex A7 cores. I don't have a Beaglebone, but the TI AM335x Sitara processors have a Cortex A8 processor, with two PRUs (programmable real-time units). Both have been on the market for years. So, it's definitely not new.The things I tinker with, tend to consist of a Linux host running UI and/or service daemons, and a microcontroller (or microcontrollers) with native USB doing the real-time work. I've mentioned I have thought about using a separate microcontroller as a blitter (or 2D GPU of sorts, optimized for 2D vector graphics and pixmap blitting); with memory, really, being the limiting factor. (The i.MX 1062 on the Teensy 4.0 has enough RAM to use 512 KiB for a framebuffer and temporary pixmaps (it has 1024 KiB, but some of it is used for code and stack too, and half of it is tightly coupled), say 480×320 with 16-bit color, with additional 217088 or 329×329 for offscreen pixmaps. Or, for a tiled/sprite graphics display, you can have about a thousand 16×16 tiles; at 600 MHz, it should be fast enough to support several tile layers and even partial transparency at reasonable frame rates. At $20/22€ retail, it makes for an interesting option for Arduino hobbyists.)For a very fast microcontroller, I would really love to have a slower helper core doing USB interrupts and DMA setup/ack stuff, so I could dedicate the faster core to signal/data computation. Or, have the faster core do computation and interrupts, with the slower core doing strict realtime output. I can think of uses for both.

author: Yansi
author_rank: Super Contributor
timestamp: October 04, 2019, 11:46:38 pm
content: Quote from: Nominal Animal on October 04, 2019, 11:16:59 pmI think that may already be quite common. How about STM32MP1? A dualcore 600MHz A7 plus a M4 at 200MHz.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 05, 2019, 12:11:23 am
content: Quote from: Yansi on October 04, 2019, 11:46:38 pmIsn't that a proper microprocessor, like Exynos 5422 or Sitara AM355x, requiring external RAM? Heterogenous configurations are not rare in embedded systems, but I haven't seen any microcontrollers yet; anything that one could use to build a development board under 2"×2" for under $30 retail price?

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 05, 2019, 01:29:45 am
content: https://www.st.com/en/microcontrollers-microprocessors/stm32h745-755.html

author: mark03
author_rank: Frequent Contributor
timestamp: October 05, 2019, 02:08:18 am
content: Also lots of M4+M0 examples, if that counts. See NXP's LPC4xxx series for example.

author: mark03
author_rank: Frequent Contributor
timestamp: October 05, 2019, 02:11:41 am
content: Coming back to the i.MX RT1170 which started the thread, after some more googling, the best information I could find on availability was "second half 2020." I will take this to be somewhat optimistic; call it Christmas 2020. The RT600 was announced well over a year ago and there is still nothing on the product page but a "fact sheet" now in its third revision (from October 2018).There is also talk here and there of an RT1070 to be announced next year. Hopefully that is the slightly stripped-down 1-GHz MCU in the 196-ball package.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 05, 2019, 02:14:41 am
content: Ah, thanks. It looks like even the microcontroller ones are not that new. For example, LPC4350/4330/4320/4310 has a Cortex-M4 and a Cortex-M0, and even high-speed USB (two, actually), but is not new. Also costs just 7.65€ in singles at Mouser. There does not seem to be affordable development boards available, though; LPC4330 Xplorer seems to be > $50, the STM32H745I-DISCO > $80. My SBCs are cheaper than that.

author: radioactive
author_rank: Regular Contributor
timestamp: October 05, 2019, 02:55:24 am
content: QuoteYou might take a look at the stm32h743 nucleo board ($27usd) :https://www.digikey.com/product-detail/en/stmicroelectronics/NUCLEO-H743ZI2/497-19452-ND/10130892

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 05, 2019, 03:34:59 am
content: Quote from: radioactive on October 05, 2019, 02:55:24 amSTM32H743 seems to be a single-core microcontroller, not a dual-core one.

author: radioactive
author_rank: Regular Contributor
timestamp: October 05, 2019, 04:22:18 am
content: QuoteOh, I didn't realize that stm32h745 was dual core, so suggested cheaper board. Now, I'm going to have to take a closer look at the pinout on that stm32h745 and see if it is compatible with the 743.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 05, 2019, 07:15:28 am
content: I knew it! NXP would F**k ST, finally, If they manage to produce some 0.8mm BGA tough!

author: tggzzz
author_rank: Super Contributor
timestamp: October 05, 2019, 08:13:29 am
content: We pretty much agree; I'm concentrating on some of the imperfections that plague us and make porting unpleasant.Quote from: SiliconWizard on October 04, 2019, 08:57:40 pmIn both those cases there is a practical limitation which makes porting more difficult: the specific peripherals in MCUs, and the specific CLBs and primitive blocks in FPGAs (e.g. SERDES or multiport RAM). If you can write in pure HDL and not make use of specialised features on a specific family, then that problem isn't serious.In addition, with FPGAs the toolset is very much a key part of the manufacturer's competitive advantage.QuoteI doubt xC is free in any sense other than beer.I haven't seen it for any other manufacturer's products, but that goes with the territory of being a pioneer. It is an important commercial consideration.XMOS did at one stage have a device which was (IIRC) seven xCORE plus one ARM core, all of which could be programmed in xC. Since xC is C underneath, I guess they were opening the door to having conventional libraries executing in the ARM core.

author: Marco
author_rank: Super Contributor
timestamp: October 05, 2019, 10:07:47 am
content: Quote from: Nominal Animal on October 05, 2019, 12:11:23 amA 16 bit wide ddr3l ic isn't going to prevent you from meeting those requirements.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: October 05, 2019, 10:19:46 am
content: Quote from: tggzzz on October 04, 2019, 07:12:46 amOnly 2 of 40 "XUF..." parts in stock .

author: tggzzz
author_rank: Super Contributor
timestamp: October 05, 2019, 10:23:44 am
content: Quote from: mikeselectricstuff on October 05, 2019, 10:19:46 amMy post merely offered a specific counter-example to coppice's general contention.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 05, 2019, 06:37:28 pm
content: Quote from: radioactive on October 05, 2019, 02:55:24 amThe H755 has a Nucleo board, and it's $29.https://www.st.com/en/evaluation-tools/nucleo-h755zi-q.html#sample-and-buy

author: nctnico
author_rank: Super Contributor
timestamp: October 05, 2019, 06:44:21 pm
content: IMHO having cheap evaluation boards is just a non-issue. I happily pay more for an evaluation board if that means getting more features and the design files. Starting out with a low cost part is the wrong path anyway.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 05, 2019, 09:55:45 pm
content: Quote from: SiliconWizard on October 05, 2019, 06:37:28 pmThe only distributor,Arrow, tells me "This product is currently not available for order on arrow.com".Quote from: nctnico on October 05, 2019, 06:44:21 pmOh, but our use cases are completely different. With these things, I make experimental stuff that I hope other hobbyists can replicate, as there may not be an actual market for a finished product.The actual use case I have in mind, is a dual-core microcontroller that could control three or four TMC2209 stepper drivers. The faster core would take care of USB and interrupts, including end-stop state changes, and trace Bézier curves to produce the correct step order sequence, as well as the approximate velocity along that axis at each step. The slower core would run hard realtime, and emit the steps at the correct intervals per the interstep velocity. For Cartesian configurations, it'd allow true curve paths with very quiet operation. The order (and direction) of each step determines the actual path, the intervals the velocity, acceleration, and jerk. Right now, I can implement the faster core on a Linux machine, and transfer the step-velocity data via USB no problem, but the interrupts cause timing jitter I'd rather avoid. Obviously, this is just a slow-burn hobbyist research project, so I want to use cheap existing development modules to find out if it works well enough in practice.

author: nctnico
author_rank: Super Contributor
timestamp: October 05, 2019, 10:04:06 pm
content: The interrupt jitter can be avoided by making the stepper driver interrupt a higher priority one. The ARM Cortex M cores support nested interrupts so you can interrupt an interrupt routine. The only limit is the total number of CPU cycles you have available.

author: tggzzz
author_rank: Super Contributor
timestamp: October 05, 2019, 11:34:24 pm
content: Quote from: nctnico on October 05, 2019, 10:04:06 pmThat might work for one interrupt source, but what if you have several "high prioriry" sources.So, rather than "avoided", don't you mean "reduced"? Optionally with "to an acceptable degree"?

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 05, 2019, 11:42:52 pm
content: Quote from: Nominal Animal on October 05, 2019, 09:55:45 pmDamn. AVNET had like 5 boards available a couple hours ago:https://www.avnet.com/shop/emea/products/stmicroelectronics/nucleo-h755zi-q-3074457345641678914/looks like the online store is currently having a problem though...ST is playing tease with those new boards it seems.

author: nctnico
author_rank: Super Contributor
timestamp: October 06, 2019, 12:08:06 am
content: Quote from: tggzzz on October 05, 2019, 11:34:24 pmNo. I mean avoided. In the end you have a limited number of X cycles you can divide over Y processes. By design you assign an amount of resources to each process. So if you have various high priority tasks you make sure that -by design- each task can be handled in time. This design process doesn't involve any 'what if' fiction. I have various projects/products which do exactly this (multiple realtime tasks).

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 06, 2019, 02:46:03 am
content: Quote from: nctnico on October 05, 2019, 10:04:06 pmInteresting! I haven't checked yet which of the microcontrollers I already have allow a timer interrupt to have a higher priority than some of the hardware-related interrupts, but if they do, this is an excellent option. I admit, in my stupidity/newbieness, I kind of assumed the interrupt priorities were fixed, not adjustable.(Trinamic TMS2209 have the nice feature that the STEP/DIR interface supports level change as the STEP trigger, meaning that the STEP output pin only needs to change state once per step. For typical stepper drivers, you need two state changes.)The microcontroller I'm most comfortable with is an NXP Kinetis K20 (Teensy 3.2, 72 MHz Cortex-M4), which seems to support 16 priority levels without any restrictions I can immediately find.I recently got a couple of NXP i.MX RT1062 (Teensy 4, 600 MHz Cortex-M7), but like the i.MX RT1170 on the topic at hand, RT1062 is a "crossover processor" with lots of peripherals, and the complexity of a full computer processor. It too seems to support 16 priority levels, according to the datasheets nested vectored interrupt controller description, but I am not sure what kind of latencies the other subsystems may cause; it is a complex beast. The higher clock rate does mean that even if there are some unavoidably higher-priority interrupt sources or other sources of unexpected latencies, they should be short enough to not matter much.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: October 06, 2019, 03:42:23 am
content: Quote from: Nominal Animal on October 05, 2019, 09:55:45 pmIsn't that what timer/counter hardware is for?I know that many STM32 timer registers can be reloaded by DMA on request of several selectable timer events, which is great if you have enough lead time to buffer them up. Maybe the Kinetis has similar capabilities?

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2019, 07:09:36 am
content: Interrupt jitter is a total non-issue for motor control, on any modern ARM Cortex anything, I would dare to sayeven including Cortex-M0, maybe excluding some very special high-tech micromachining applications. Maximum current change rate defined by motor inductance, and physical inertia are orders of magnitude more.Interrupt priorization is trivial, and we are talking about tens of nanoseconds of jitter, in systems which need to be controlled at ~ tens to hundreds of microseconds intervals.A typical case is that the timer hardware controls PWM, handles sudden overcurrent events, and the interrupt is triggered once per PWM cycle, or say, 20 kHz.I have actually never seen a problem with interrupt latency nor jitter, even when designing software-defined DC/DC converters, with 10-20x higher switching frequency. That's why the dedicated peripherals exist - you won't bit-bang control signals in an interrupt.I do see the theoretical appeal of the XMOS systems, but I have never encountered an actual use case, yet. When I do, I'll be happy to try them out.My latest large project is something that the XMOS architecture would handle quite poorly. A lot of theoretical combined MIPS, but I would hit the classical problems of parallelization, trying to force such homogenous architecture, where every single core is relatively low-performance.A single-core Cortex-M7 MCU seems to be a good match for such a heterogenous project:* 1st priority interrupt, pre-empting everything else, safety shutdowns everything from multiple peripheral trigger sources,* 2nd priority interrupt runs a 250kHz software DC/DC dual-phase buck converter feedback control loop* 3rd priority interrupts run two separate 20kHz 3-phase BLDC motor control loops* 4rd priority interrupts control the state machine to configure DMA and control readout of 18 (!) MEMS inertial measurement devices, in a matrix of three shared SPI buses and six shared chip select lines, each producing data at 1kHz.* Said 4rd priority interrupt demotes its priority by calling a software interrupt whenever the inertial data has been collected to run a 250Hz motion estimation control loop* Finally, 3D time-of-flight cameras are triggered by free-running code, their data is compensated with sensor calibration data, lens blur and flare compensation model (basically combinations of small convolution kernel, box blur, and some lookup tables) is ran, and data is converted to point clouds for motion planning.All the interrupts take about 5% of the CPU, or about 30% when the buck converter is running. The last item is computationally expensive, and requires the "oomph" of 400MHz M7, with all the algorithms running from the core-coupled RAM. And this is something which is difficult to parallelize properly, but having enough single-core performance to run the heavy algorithm from bog standard C implementation (without too much optimization tricks) shortens the development time.I run caches disabled. All even remotely timing critical code easily fits the ITCM memory.

author: tggzzz
author_rank: Super Contributor
timestamp: October 06, 2019, 07:44:08 am
content: Quote from: nctnico on October 06, 2019, 12:08:06 amThat looks like "reduced to an acceptable degree", which is a perfectly acceptable engineered design. I've done that too

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2019, 07:48:11 am
content: Your XMOS will have measurable jitter as well. Maybe in picoseconds, but it exists, if from nothing else, from analog domain.So there is no fundamental difference whether something is reduced 10x or 1000x below acceptable limit. The result is the same.

author: tggzzz
author_rank: Super Contributor
timestamp: October 06, 2019, 07:53:29 am
content: Quote from: Siwastaja on October 06, 2019, 07:09:36 amI'm sure you are right about it not being a problem in this case.The higher priority interrupt will cause jitter in completion of the lower priority interrupt. That may well be acceptable; fineQuoteAmdahl's law is still validA theoretical advantage, if any, doesn't preclude other perfectly acceptable solutions. Use a good enough tool for the job at hand.There's still value of knowing about the advantage, so that you can make use of it where beneficial. The right tool for the job, and all that.QuoteI'm pleased to learn disabling caches is possible; it hasn't been on some of the processors I've seen in the past

author: tggzzz
author_rank: Super Contributor
timestamp: October 06, 2019, 07:58:52 am
content: Quote from: Siwastaja on October 06, 2019, 07:48:11 amDrat. Got me thereThe jitter cannot be less than one clock cycle; 10ns for a core, 4ns for i/o at maximum clock rate. I/O will also take some time to cross the internal interconnect fabric, but if you use the per-port timer that can be discounted.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2019, 09:31:10 am
content: Quote from: tggzzz on October 06, 2019, 07:53:29 amAFAIK at least all STM32 MCUs - I would guess all Cortex M7 MCUs in general, as well, since the cache subsystem is from ARM, not ST - all boot with cache disabled. You have to specifically enable it. I just never do that. I sometimes do enable MMU to protect from accidental write to the instruction RAM areas.AFAIK all relevant M7 MCUs have significant amounts of core-coupled memory as well, so I find very little use for cache. Maybe for some super massive programs that won't fit the ITCM, yet require improvement inaverageruntime, especially compared to running out of an external (Q)SPI flash. A large UI using a crappy, bloated UI library would likely be a good example. And quite frankly, if the program is so huge (say, 100K) that it won't fit ITCM, the average performance would be what matters, not worst case latency. If it has a timing-critical part, that would be, again, placed in the ITCM.

author: tggzzz
author_rank: Super Contributor
timestamp: October 06, 2019, 11:20:18 am
content: Quote from: Siwastaja on October 06, 2019, 09:31:10 amCan you specify that certain parts of the code and data are nailed down in ITCM/DTCM? The last processor I looked at with that ability was the i960, and that mechanism was crude!Since 1986 there have been so many significantly different classes of ARM processor, that I've lost track of the details

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2019, 12:26:42 pm
content: Quote from: tggzzz on October 06, 2019, 11:20:18 amOf course. GNU tools have no issue, and they've been the same for decades I think, and should work the same for any vendor, any CPU.I define the ram sections in the linker script:Code:...ram_itcm (rwx) : ORIGIN = 0x00000000, LENGTH = 63Kram_vectors(rwx) : ORIGIN = 0x0000FC00, LENGTH = 1K /* last 1K of ITCM dedicated for relocated vector table*/...rom_b1s0 (rx) : ORIGIN = 0x08000000, LENGTH = 128K.... = ALIGN(8);_TEXT_ITCM_I_BEGIN = LOADADDR(.text_itcm);.text_itcm :{_TEXT_ITCM_BEGIN = .;*(.text_itcm)_TEXT_ITCM_END = .;} >ram_itcm AT>rom_b1s0Then in C runtime initialization, before main():Code:uint32_t* text_itcm_begin = (uint32_t*)&_TEXT_ITCM_BEGIN;uint32_t* text_itcm_end = (uint32_t*)&_TEXT_ITCM_END;uint32_t* text_itcm_i_begin = (uint32_t*)&_TEXT_ITCM_I_BEGIN;while(text_itcm_begin < text_itcm_end){*text_itcm_begin = *text_itcm_i_begin;text_itcm_begin++;text_itcm_i_begin++;}Then the function definitions:Code:void __attribute__((section(".text_itcm"))) delay_us(uint32_t us){...}I'm sure you can get the compiler to generate the startup code, and so on, but I write it myself since it's trivial. It leaves some options open, for example, if I want to boot something up really quickly, and initialize the RAM from flash later.I think that having full control of your tools and what goes where is... easy. Easier than having to guess. Yes, need to learn the linker script syntax, but OTOH you can just copy-paste from a previous project, mostly.

author: tggzzz
author_rank: Super Contributor
timestamp: October 06, 2019, 12:44:07 pm
content: Quote from: Siwastaja on October 06, 2019, 12:26:42 pmAs with many things, it is "what you gain on the swings you lose on the roundabouts".Once you are over the learning curve, being explicit isverycomfortingI will say that the xCORE/xC learning curve wasmuchshorter and sweeter than I was expecting. The datasheets and tutorials wereshortsimple, explicit and I foundzero"gotchas". Some of the ARM and GCC documentation isn't quite like thatMaybe people not used to "thinking parallel" and in terms of "events" and "messages" would find it more difficult to get started. The only stumbles I made were due to my sloppy thinking and to when it is beneficial to use the xC asynchronous message interface. Can't blame the tools for those: PEBCAK!

author: coppice
author_rank: Super Contributor
timestamp: October 06, 2019, 02:08:47 pm
content: Quote from: tggzzz on October 06, 2019, 12:44:07 pmMost people who really struggle with parallel thinking on day one never seem to get very good at it. Its something that really seems to divide people into capable and non-capable groups.

author: tggzzz
author_rank: Super Contributor
timestamp: October 06, 2019, 02:16:02 pm
content: Quote from: coppice on October 06, 2019, 02:08:47 pmWith hardware, both analogue and digital, it isn't even a question as to whether you "think parallel" from the start. Thinking sequentially only comes later, after clocks and registers are introduced.I wonder if future software courses will gradually move over to introducting concepts that way. I'll probably be dead by then!

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 06, 2019, 02:36:43 pm
content: Quote from: Siwastaja on October 06, 2019, 07:09:36 amAgree.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 06, 2019, 02:44:22 pm
content: Quote from: coppice on October 06, 2019, 02:08:47 pmYes. Actually, thinking "parallel" is not very natural for most people. Although a myriad of things are happening in parallel in our brain, they are happening completely unconsciously. We have a very hard time *consciously* thinking about several different things at the same time. When we think of a number of steps to accomplish (again, on a conscious level), we are mostly single-task.Parallel processing is thus hard to grasp fo those that have a hard time abstracting things. I think it needs good abstraction capabilities, and would venture that both are strongly related.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 07, 2019, 05:37:02 am
content: FWIW, the Teensy 4.0 microcontrollercan be overclocked to 1008/996 MHz, but cooling is a problem; that thread shows a setup with a smallish heatsink (~ 1" cubed) where it seems to run fine at 960 MHz. This has the i.MX RT1062 "crossover processor".

author: Siwastaja
author_rank: Super Contributor
timestamp: October 07, 2019, 06:42:14 am
content: Don't know about Teensy, but at least for STM32H743, the issue isn't the core power dissipation at all - it's the fact that people tend want to default to using the integrated linear Vcore regulator, to minimize part count. With Vcore=1.2V and Vin=3.3V, this increases the consumption by 2.75x. The integrated linear regulator heats up the whole chip!IIRC (and don't quote me on this), STM32H743 is specified for a typical consumption of about 400mA running most peripherals and CPU at 400MHz (the current draw is almost exclusively by the Vcore domains). This means, the consumption (and thus, heating) is 0.48W when ran from an external 1.2V source, or 1.32W from a 3V3 source. Quite a difference!So if you are looking for power savings, or running it cool, or overclock it, do what I did and supply Vcore from a separate switch-mode 1V2 converter.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 07, 2019, 07:50:43 am
content: Quote from: Siwastaja on October 07, 2019, 06:42:14 amTeensy 4.0 has a TLV75733P for the 3.3V rail. i.MX RT1062 does have four LDOs (3.0V, 2.5V and two 1.1V). However, looking at theTeensy 4.0 schematicand thereference manual(page 1064, 12.4.2.4 Examples of External Power Supply Interface), the 2.5V LDO and one of the 1.1V LDOs are only used for the PLLs and crystal; a DC-DC converter (internal to i.MX RT1062) with external inductor and capacitors is used to provide the main 1.1V rail (from the 3.3V rail). The 3.0V LDO is only used for USB, and the final 1.1V LDO for 32 kHz RTC and possibly watchdog timer.They say in that thread that higher clock frequencies work, but only for a while, so it looks like overall heat dissipation is the first limiting factor for Teensy 4.0. I could be utterly wrong, of course; I'm not an EE.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 07, 2019, 12:41:40 pm
content: At such elevated clock frequencies, I wouldn't be too troubled having to use some kind of heatsink for the MCU.Oh, and of course, regarding internal LDOs... using them really depends on the application. Note that some MCUs don't give you access to the Vcore supply from an external pin, in which case, you obviously don't have a choice. But if you have a choice, and can "afford" a buck converter (in terms of cost/area/part count/...), this is often a much better choice regarding power consumption (and of course, dissipation), as long as you select it properly. One downside (apart from the above) is that it will take longer to stabilize than a typical LDO. May or may not matter. Depends!

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 08, 2019, 10:03:55 pm
content: Quote from: coppice on October 06, 2019, 02:08:47 pmHave them take an FPGA class. That'll either straighten them out in a hurry, or weed them out.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 09, 2019, 06:00:56 am
content: From my days using Macromedia Director (late nineties), and a course on Shockwave I held in 1999, I know that event-based approach works well for learning purposes. Technically, the programming language used,Lingo, is single-threaded, but the way scripts could be attached to objects, makes the object-oriented paradigm easy to understand. It also works well for introducing parallelism, as it appears that multiple of those scripts are run in parallel in Shockwave (even though they are really run sequentially in a specific order).I don't think parallel processing is hard to understand, since many things happen in parallel in real life. You do need some good analogs to explain how scripts and machine code is executed, to give the learners a good intuitive grasp, first.It is asynchronous multiprocessing that people struggle with, in my experience. (You know, like queues in front of several cashiers. Or multiple lanes in a traffic jam. Some people weave, as they do not understand how far the interference patterns reach.)For example, I basically never use OpenMP, because it is really only useful for synchronous parallelism. It is too restrictive/inefficient for my use cases.In distributed computing,MPIis used for passing information between threads and processes. It has excellent features for asynchronous communication, but the majority of "MPI experts" recommend not using them, because they cannot grok the asynchronicity themselves! I suppose that is like suggesting all FPGA designs should have exactly one global master clock, with no asynchronous clock zones? And no full-duplex transfers, because it's too complex for us humans to handle; such designs may deadlock.I use exclusively asynchronous I/O between distributed processes, because that is the only way to do both communication and computation in parallel. As I've mentioned before, I really hate how all current distributed molecular dynamics simulators switch between the two sequentially, wasting time, rather than doing the communications in parallel with computation. Sure, it is a bit harder, because you need to split the computation into parts you can do without the transferred information and do those first. Or even keep the information transfers one step ahead of the computation, which is harder still. But, ifIcan do that, it can't be that hard.

author: GeorgeOfTheJungle
author_rank: Super Contributor
timestamp: October 09, 2019, 07:10:11 am
content: This reminds me of...

author: tggzzz
author_rank: Super Contributor
timestamp: October 09, 2019, 07:23:26 am
content: Quote from: Nominal Animal on October 09, 2019, 06:00:56 amThat all rings true, but I haven't use OpenMP nor MPI because it wasn't relevant to my application domains.The deadlock/livelock issue is always going to be a problem, especially where no one individual comprehends the entire system.The only resolution (not solution) to that is liberal use of timeouts when a reply is required or a transmit queue might become full. Other techniques welcome

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 09, 2019, 08:28:38 am
content: Quote from: tggzzz on October 09, 2019, 07:23:26 amKinda sorta yeah. For humans, precedence/priority rules work, but they're too complex to implement for computing hardware.OpenMPI, MPICH, and MVAPICH all have a separate I/O/management thread per parallel process per machine, which handles the sending and receiving of asynchronous messages. Each message is specific to acommunicator(handle specifying a group of processes), and has a data type and a tag. If you use the tags properly, all messages a process sends, and all messages it receives, via a specific communicator, are handled in parallel. There is no risk of deadlock or livelock, since there is no lock, nor any expectation or assumptions about the order the messages arrive/are sent. (In fact, they can very well be sent in parallel too, if they are larger than a single packet on packet-switched networks like IB or IP.)It really does boil down to proper use of those tags, and getting a grip on how it really works when it works right. Not at all that complex. Which makes it that more infuriating how some "experts" decry it is "dangerous", just because they don't grasp it right themselves.Quote from: tggzzz on October 09, 2019, 07:23:26 amWell, you need those to detect unexpected problems, which can always occur in real life. I consider them complementary to a robust design; a "but if a situation occurs where these assumptions do not hold" -catch clause.

author: tggzzz
author_rank: Super Contributor
timestamp: October 09, 2019, 10:06:36 am
content: Quote from: Nominal Animal on October 09, 2019, 08:28:38 amAlso consider deadlock/livelock that isn't related to the messaging mechanism, but to the applications themselves. That is a user design error, but if different companies produce different parts of the application, then no one person can comprehend the entire system.QuoteAgreed. That machine I didn't know existed in a company I've never heard of just died or became very slow...

author: coppice
author_rank: Super Contributor
timestamp: October 09, 2019, 11:11:54 am
content: Quote from: Nominal Animal on October 09, 2019, 08:28:38 amDid you really mean complementary? Dealing with the unexpected is at the very heart of creating robust designs.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 09, 2019, 11:46:35 am
content: Quote from: tggzzz on October 09, 2019, 10:06:36 amYes; I skipped that in an effort to keep my responses from being so darn long. I know some people hate my walls of text. Sorry!Deadlock and livelock situations inherently involve more than one lock, with the same sets of users (the code doing the locking). It is an interesting topic, and very important in practical parallel applications and services, but not directly related to or associated with asynchrony. "Grab", "try", "hold", and "release" are clear and easily understood concepts when dealing with mutexes; others are needed for rwlocks, semaphores, and condition variables. But, as a whole, nontrivial locking is a subject that can be handled separately.For example, when writing multi-threaded Python code -- and you will want to if you use Gtk+ or Qt, and do any kind of communication or significant computation in the same process, without freezing the user interface --, you can use Queue, a synchronous queue class between threads. Now, the most common Python interpreters only execute one thread at a time, but it does not mean threads have no benefits in Python. Using blocking I/O with Python threads (Threading, or GTK+ or Qt threads) makes a lot of sense, for both code simplicity, and efficiency, as the Python threads release the interpreter lock for the duration of the blocking call; essentially, such code works as if multiple Python threads did execute at the same time. For heavy computation, you'll want to use a separate processes -- the multiprocessing module -- to make use of more than one core for concurrent computation. With this approach, your code may not have any explicit locks, and introducing locking issues is a matter of not requiring a specific message order in Queues. (Combining Arduino and Python to create an user interface for an USB-connected microcontroller is one of my long-term projects; I'd like to write a tutorial about it.)I personally do not have experience in teaching how to avoid deadlock/livelock in multi-lock, multi-party systems. I'm stupid enough to distrust locking schemes that I don't understand, so I tend to rework the structure to avoid the problem entirely. I am aware of the locking issues in the Linux kernel, and how they evolved (from the time when there was just one Big Kernel Lock), but other than how to analyze such schemes with the help of tools like Graphviz graphs, and how to simplify such locking schemes, I don't know much. (I know nothing about current CS research about locking schemes, for example; and haven't used an FPGA yet.)A dual-core (heterogenous crossover) processor like the i.MX RT1170 is not something I'd consider so complex that locking would be particularly susceptible to deadlock/livelock, especially since their tasks would be rather separated. In particular, I believe most use cases would involve atomics instead; and that one of the cores would in most use cases never hold more than one lock at a time, which is one of the cases where lock analysis and avoiding deadlock/livelock is easy.Quote from: coppice on October 09, 2019, 11:11:54 amI was referring toliberaltimeouts, the ones that do not have an immediately obvious purpose. (Remember, the context is avoiding deadlock/livelock, things that should not happen if the system is working as designed.)Timeouts and checking whether a buffer has enough space, are an integral, low-level part of all robust designs, yes.Even a robust design makes assumptions about the context, and what should happen in what order. Typically, this is reflected in how some problems can be worked around, and how some problems are fatal. These assumptions are inherent in the design. Remember, a computer program cannot really deal with anything truly unexpected: all you can do, is check whether each operation succeeds or fails, and be prepared for their failure. (And, obviously, one has to remember that just because a send() succeeded, does not mean the data has reached the other end, or is even on the wire yet; and so on.)As an analog for liberal timeouts, consider a C function checking if a pointer is NULL, even when calling that function with a NULL pointer makes absolutely no sense, and you're sure your code never calls it with a NULL pointer. Similarly, a networked service might have a timeout for the entire handshake-and-authorization process, so that if it does not happen within say half a minute, the connection is dropped (or moved to a tar bucket as hostile), even though no error has occurred.The "complementary" bit I mentioned, is writingdefensivecode, that has extra checks and liberal timeouts, with the purpose of catching errors in the assumptions inherent in the design. Typically, they catch programming errors, and design errors like a deadlock/livelock-susceptible locking scheme. (Unfortunately, POSIX pthreads does not have a function to check if the current thread is already holding a mutex, without affecting the state of that mutex. If there was, sprinkling such checks to code that is not supposed to be called with certain locks held, would belong to this category too.) For example, the most commonly used code path might check twice that the connection handle is still valid, and many programmers feel that the second check is unnecessary. However, I may have put it there deliberately, because I believe it likely that an addition is made in the future that adds a secondary code path that shares the latter check, and I want to catch the most likely errors the implementors of that secondary code path writers will do. (A typical reason for such is that I've seen similar cases leading to that sort of a bug.)Others call it paranoia, but I've found it a very useful approach in security-sensitive situations.

author: coppice
author_rank: Super Contributor
timestamp: October 09, 2019, 12:05:36 pm
content: Quote from: Nominal Animal on October 09, 2019, 11:46:35 amYou seem to have a less robust notion of robust design than me.

author: Nominal Animal
author_rank: Super Contributor
timestamp: October 09, 2019, 12:20:18 pm
content: Quote from: coppice on October 09, 2019, 12:05:36 pmI tend to use "robust" for any check/workaround/expectation I can immediately show a causal chain for, and "paranoid"/"defensive" for the ones I cannot.I use "robust design" for designs that cater to all known causal chains. A design that does not consider known causal chains is "fragile", and a design that does not consider all practical causal chains is "buggy".

author: tggzzz
author_rank: Super Contributor
timestamp: October 09, 2019, 04:05:25 pm
content: Quote from: Nominal Animal on October 09, 2019, 11:46:35 amI can deal with that; your responses are consise and relevantQuoteYes indeed.QuoteMy attitude too. Unfortunatelyon its ownit doesn't always scale; consider the telecoms system or the financial system (shudder!).QuoteI agree, and that's even without considering two other points:you can get deadlock/livelock without having mutexes. Merely one example: different nodes on a token ring network have to agree that there is exactly one token circulating - easy to get wrong. Merely another example: the "split brain problem" where a distributed high availability system accidentally partitioned, and subsequently the partitions have to re-merge. (Come to think about it, those two have many similarities!)POSIX threads couldn't be written in C, until very recently

author: Harjit
author_rank: Regular Contributor
timestamp: October 27, 2019, 06:05:40 pm
content: Anyone here using the iMXRT in a 0.65mm BGA package? If so, how are you soldering it?From looking at the Evaluation board design files, the iMXRT10xx in the BGA package is routed on four layers. Compared to the STM32H743, one thing not going for the iMXRT10xx based on the hardware design kit is that it needs 33+ decoupling capacitors! That is a lot of real estate.FWIW, there is a 0.8mm pitch BGA for the iMXRT1064. Look for the part with the industrial version of the part - iMXRT1064IEC.

author: NorthGuy
author_rank: Super Contributor
timestamp: October 27, 2019, 11:39:11 pm
content: If there were no restrictions, I would do everything in FPGA. You build a module you like and you just use it - you don't have to live with vendor's idiosyncrasies, you don't need to interrupt other modules, and other modules don't interrupt you. You can run at any speed. It's easy to scale - if you can control 1 motor, you immediately can control 50 of them, or 100. It's easy to reuse - you just connect wires or FIFOs between modules. Unfortunately, high price and slow synthesis firmly stand on the way. May be it gets there in the future, as it's really much easier to develop stuff on FPGA both for professionals and housewives alike.But right now people are crazy about 32-bit processors. They use them to do stuff which can easily be done by PIC16. When they get FPGA, they start by bringing a 32-bit core into their design, while there's no need for any core at all. But this is something historical. The mark of our time. While this persists, FPGAs don't have much chance. Eventually, the time will pass and people will get crazy about something else (may be this will be FPGAs, but I'm afraid 64-bit CPUs will have their hay day first). But at this point of time, it's not wise to stand on the way of GHz MCUs.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: October 30, 2019, 05:00:03 pm
content: Quote from: NorthGuy on October 27, 2019, 11:39:11 pmI can understand FPGAs with hard CPU cores on-chip might have some utility, but have a difficult time accepting why anyone would use a soft-core CPU on an FPGA. Seems like a waste of (expensive) resources.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 30, 2019, 05:09:30 pm
content: Quote from: Sal Ammoniac on October 30, 2019, 05:00:03 pmFor many sequential control and configuration tasks, doing it in software is trivial (say, 100 lines of code written in 2 hours), while doing it as a pure hardware state machine might be resource-hungry and/or tedious - say 1000 lines of VHDL written over a week, and the solution possibly uses more LUTs than a small core. In this is the case, synthesizing a small, maybe just a 8-bit core makes a lot of sense.For a practical example, supplyinginitial configurationto an external Ethernet MAC+PHY chip was, by far, the biggest part - in work time, and also in LUTs - in a system I had to do once. The part that streamed UDP packets was, of course, trivial. Since existing C code to do the damn configuration, including all workarounds for the broken-by-design-chip, would have been available, it is very likely that synthesizing a small 8-bitter would have made the task easier. But we did it as a VHDL state machine, and it wasn't nice to write and debug. No simulation possible with an external chip with poor documentation.Of course, synthesizing a "powerful" DSP core to handle a lot of data won't make a lot of sense (you have the FPGA logic fabric and multiplier and RAM blocks to do that!); but in this case, having it as a hard block, doesn't make much more sense either.A hard, say, Cortex-M4 core or similar, may end up wasted most of the time. With soft cores, you have at least a lot of flexibility (including the option of not synthesizing any CPU).

author: nctnico
author_rank: Super Contributor
timestamp: October 30, 2019, 05:14:20 pm
content: Quote from: Sal Ammoniac on October 30, 2019, 05:00:03 pmIt is much easier / quicker to use software than hardware. FPGAs need a lot of time to simulate / 'compile' (an hour isn't excessive for a reasonably complex design) where software is compiled & uploaded in seconds. I have used soft cores / programmable state machines in most of my FPGA designs because they reduce development time and made some of the functionality software upgradable.

author: dietert1
author_rank: Super Contributor
timestamp: October 30, 2019, 09:39:22 pm
content: I think one advantage of the sequential mantra is that you already have it in your workstation. You can write some code and check your idea. If a workstation had some user accessible FPGA fabric inside, always connected and ready to use, that would make a difference. Those FPGAs with embedded arm processors are a fantastic environment.In the end i think that projects doing something meaningful with GHz multiprocessors are as complex as any FPGA project, there is no difference. Those projects are not for inventors and hobbyists, but require sound organisation.Regards, Dieter

author: ejeffrey
author_rank: Super Contributor
timestamp: October 31, 2019, 05:04:18 am
content: Quote from: Sal Ammoniac on October 30, 2019, 05:00:03 pmSoft cores can actually be quite small. For complex sequential operations with relaxed timing requirements a soft core can easily take up less resources than trying to implement the same thing in standard state machines. They are frequently used for gruntwork / bookkeeping / IO. I have a system with an FPGA talking to a bunch of high speed DACs. But the DACs have an API register file that needs to be programmed in a certain sequence to configure properly and run checksum tests to adjust the clock timing. The person who originally designed it did it all in logic. It is incredibly annoying it would be far simpler if a small CPU and C program handled the initialization, and probably take the same or smaller resources.

author: tggzzz
author_rank: Super Contributor
timestamp: October 31, 2019, 09:45:29 am
content: Quote from: nctnico on October 30, 2019, 05:14:20 pmWhen I was young software turnaround times were half a day. That had the benefit that youthoughtand hand executed your program before submitting it.It will be interesting to see how well the new Xilinx Vitis platforms works in the real world.

author: ehughes
author_rank: Frequent Contributor
timestamp: November 01, 2019, 01:41:19 am
content: Sorry to be Off topic, but I always like some FPGA in an MCU.The LPC55S69 has a small programmable logic unit on the bus of the Cortex M33. There are 26 5 input LUTs and 4 FF's. Not much but enough to be useful! There is a basic tool to work from verilog, schematic or direct LUT mapping.

author: ogden
author_rank: Super Contributor
timestamp: November 01, 2019, 07:28:03 am
content: Cypress have whole series (Psoc4, Psoc5, Psoc6) of various ARM core MCU's with programmable logic and switched-capacitor programmable analog blocks inside.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 01, 2019, 02:37:44 pm
content: Quote from: nctnico on October 30, 2019, 05:14:20 pmA also use programmable state machines. I get a BRAM block where each position produces some sort of action. Wires coming out of the BRAM may do things directly (such as output a signal, enable/disable something), or get decoded producing some actions. The address is usually changed sequentially, but may jump as a result of state machine action, same as in CPU. Then, by changing BRAM contents, I can install different "programs", each program containing several "subroutines". I usually write software on PC which generates such programs and then they can be loaded onto BRAM (possibly in run time). Then other parts of the design can force execution of certain "subroutines" from the BRAM space by simply changing the BRAM fetching address.In my eyes, this is different from "Let's install my favourite core, and then I can write everything in C" approach.

author: nctnico
author_rank: Super Contributor
timestamp: November 01, 2019, 07:55:34 pm
content: Quote from: NorthGuy on November 01, 2019, 02:37:44 pmThat is different and I have used that too but many problems are just more suitable to solve using a CPU rather than logic. Having a soft-core at hand just makes life easier; it gets you the best of both worlds. And due to the FPGA you can add/create whatever peripheral you want.

author: dietert1
author_rank: Super Contributor
timestamp: November 01, 2019, 07:58:11 pm
content: I remember making a digital audio application many years ago. For the user interface it included an 8-bit softcore (predefined XILINX IP), for audio processing a DSP, then some IP units like SPDIF interface with PLL, I2S output, IR remote receiver and the like. Everything in one Spartan 200 FPGA. For the DSP channel programm i used a very simple controller without conditional jumps, similar to the solution proposed by ntnico.An interesting project. Of course, nowadays one would use a ZYNQ that is probably a hundred times more powerful. I mean the speed of softcores used to be limited. As fas as i remember even the simplest Zynq parts have Arm cores running at several hundred MHz.I remember that debugging the PLL was something tricky since i couldn't do it in the simulator. Speaking in general, any solution with parallelism is more difficult to debug than a sequential process.Regards, Dieter

author: tggzzz
author_rank: Super Contributor
timestamp: November 01, 2019, 09:38:02 pm
content: Quote from: dietert1 on November 01, 2019, 07:58:11 pmI know what you mean, but...I've seen sequential processes that were difficult to debug, and parallel processes that were easy to debug.What matters is choosing the appropriate abstractions, and implementing them cleanly. but such good taste has always been in short supply

author: NorthGuy
author_rank: Super Contributor
timestamp: November 01, 2019, 10:19:23 pm
content: Quote from: nctnico on November 01, 2019, 07:55:34 pmYes, making an MCU out of FPGA, and it's, of course, will be a very good one, exactly tailored to your needs.But you can do more than that. CPU usually handles lots of things. That's why people like RTOSes so much - it help them run lots of things simultaneously. You don't need this in FPGA - you can create as many cores as you wish, and you can make them into "programmable state machines" tailored exactly to the task being executed. This is much more progressive and flexible architecture. But! It is not time for this yet. People largely prefer dealing with familiar things. So, they put a CPU into their FPGA and run RTOS.

author: ogden
author_rank: Super Contributor
timestamp: November 01, 2019, 10:53:41 pm
content: Soft-core CPU's and coded programmable state machines are slower, yet much more resource-efficient than FPGA "hard logic". As simple as that.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 02, 2019, 12:08:25 am
content: Quote from: ogden on November 01, 2019, 10:53:41 pmIt depends on what you're doing. If you do something hardware friendly, for example calculate CRC (or AES for that matter), the softcore will use much more resources than logic and will be many times slower.As for the programmable state machines, I don't see any reason why they would be slower (or faster) than non-programmable state machines. If the state machine is programmable at bitstream level, then it's likely to be physically identical to the equivalent non-programmable state machine. If the state machine is programmable in run time, you must spend some resources to do the programming, so it will use more logic resources compared to the non-programmable equivalent. But, since you can arbitrarily change its program, it'll give you flexibility you wouldn't otherwise have. And it'll save you memory because it lets you use the same memory for different things.

author: ogden
author_rank: Super Contributor
timestamp: November 02, 2019, 12:34:51 am
content: Quote from: NorthGuy on November 02, 2019, 12:08:25 amYes. CPU is slow, FPGA fabric is fast. You assign jobs accordingly. Kinda obvious, huh?QuoteHardcoded (logic-based) state machine do not have instruction fetch cycle.

author: nctnico
author_rank: Super Contributor
timestamp: November 02, 2019, 12:47:28 am
content: Quote from: NorthGuy on November 01, 2019, 10:19:23 pmWell there is another good reason to run everything in one CPU: you only need to maintain 1 piece of software. Imagine needing 10 different pieces of software and keep track on how they are compatible (or not). Much more work and more places where things can go wrong. This is one of the reasons why I always advise to use 1 fast processor instead of several (slower/smaller) ones. The logistic overhead is much less.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 02, 2019, 01:36:02 am
content: Quote from: ogden on November 02, 2019, 12:34:51 amState machine is a map (array if you will) which maps the state to the outputs and to the next state. Except some trivial cases, the array is typically implemented a memory (LUT memory, or BRAM). In Mealy machines, inputs are involved too (conditional jumps if you speak in terms of CPU), which complicates things, but doesn't change the general principle.To make it programmable, you simply add an ability to dynamically change the memory in the array. Once the memory is changed, everything works the same as before, nothing extra is added. Programming simply changes the map.

author: NorthGuy
author_rank: Super Contributor
timestamp: November 02, 2019, 01:39:17 am
content: Quote from: nctnico on November 02, 2019, 12:47:28 amI also think that one (big?) CPU is much better than many small ones. Programming several MCUd on the board is certainly very bad idea.

author: coppice
author_rank: Super Contributor
timestamp: November 02, 2019, 03:02:17 am
content: Quote from: nctnico on November 02, 2019, 12:47:28 amAlways? I agree than in most situations a single fast processor is the fastest, most reliable, and most managable route to a solution. However, there are several common requirements where multiple processors win hands down. If you have a section of your system requiring strict certification (e.g. a legal metrology function) its far better to box that away in its own processor, so every minor change to the applications code doesn't trigger a major recertification. Security partitioning is another area where isolating functions in separate processors can really harden the system.

author: tggzzz
author_rank: Super Contributor
timestamp: November 02, 2019, 08:32:57 am
content: Quote from: ogden on November 02, 2019, 12:34:51 amFPGA latency isshort,predictableandfixedat design time - which is beneficial forhardrealtime systems.FSMs in software are (with rare exceptions) at the mercy of whatever else is happening in the software (tasks, interrupts, caches).

author: nctnico
author_rank: Super Contributor
timestamp: November 02, 2019, 03:52:42 pm
content: Quote from: coppice on November 02, 2019, 03:02:17 amThese are some of the few exceptions where you can't avoid the extra effort. Currently I'm working on such a project where there is an embedded controller and a user interface. The extra communication layer (software + hardware) in between does take extra work.However the processor I'm using for the user interface also has virtualisation and a seperate microcontroller for doing realtime tasks (the target market is automotive and you can run the dashboard and infotainment from the same device). So in the end you can do things which need a hard seperation from a single device as well.Quote from: tggzzz on November 02, 2019, 08:32:57 amWell you should define the time constraints first. Otherwise your statement doesn't make sense. The project I described above is hard realtime and uses software floating point calculations in the interrupts routines. There is more than enough time to do all this and yet the ADCs / DACs are updated at precise (nanosecond) intervals.

author: ogden
author_rank: Super Contributor
timestamp: November 02, 2019, 03:53:44 pm
content: Quote from: tggzzz on November 02, 2019, 08:32:57 amIf you code FSM in software using CPU running OS, then yes indeed. Thou we were talking about purpose-built programmable state machines which are kinda very, very crippled CPU. Those are cycle-by-cycle predictable. Even Picoblaze which is more RISC CPU than FSM, is predictable, unless you screw-up yourself with interrupts.Speaking of FPGA logic versus CPU controversy here will be reasoning of Xilinx:Quotehttps://www.xilinx.com/support/documentation/ip_documentation/ug129.pdf

author: tggzzz
author_rank: Super Contributor
timestamp: November 02, 2019, 06:20:09 pm
content: Quote from: ogden on November 02, 2019, 03:53:44 pmAh, youngsters"Crippled" processors like that were sufficient for CPM, MSDOS, UNIXen, Smalltalk (just!), Apple Macintosh machines, and many RTOSs? Caches were "in the future", but the "crippled" processors still had interrupts and operating systems.But perhaps I misunderstood what you were saying.QuoteYou don't need interrupts to have non-predictability. Other variability comes with multple competing tasks/threads.

author: tggzzz
author_rank: Super Contributor
timestamp: November 02, 2019, 06:27:27 pm
content: Quote from: nctnico on November 02, 2019, 03:52:42 pmNot true.Just because those statements are true for FPGAs and are beneficial for hard realtime systems doesn't mean FPGAs are the only way of implementing a hard realtime system.I've been professionally implementing such systems since 1979QuoteSure. Hard realtime != fast, but hard realtime == predictable and hence fixed. But we both know that.

author: ogden
author_rank: Super Contributor
timestamp: November 02, 2019, 08:39:42 pm
content: Quote from: tggzzz on November 02, 2019, 06:20:09 pmYou are missing by a mile. I tried to explain programmable state machines using "CPU analogy" you supposedly understand, but seems it did not work at allQuoteTasks, threads? LOL. Please at least check what is actual subject of conversation you are jumping in. In typical implementations PicoBlaze uses block RAM for code storage which meansmaximum 1024 instructions. You may start here:https://en.wikipedia.org/wiki/PicoBlaze. Quote:Quote

author: NorthGuy
author_rank: Super Contributor
timestamp: November 02, 2019, 08:52:40 pm
content: When it comes to real-time, Xilinx 7-series FPGAs can go down to about 50 ps. With entry-level S7 at $15 this is very impressive.

author: nctnico
author_rank: Super Contributor
timestamp: November 02, 2019, 08:58:39 pm
content: Quote from: tggzzz on November 02, 2019, 06:27:27 pmAnd now you are contradicting yourself. Again, without a time constraint there is no requirement to use an FPGA for a hard realtime system. If I need to read an ADC value, do some calculations and update a DAC every second +/-100ms then a very slow microcontroller can likely do the job. The requirement should drive the solution and not the other way around otherwise you'd looking for a problem for a solution. IMHO your statements are very confusing to people who are trying to learn something from this forum.

author: jhpadjustable
author_rank: Frequent Contributor
timestamp: November 02, 2019, 10:22:30 pm
content: Quote from: tggzzz on November 02, 2019, 06:20:09 pmCalling M68000 "crippled" and putting it into the same class as the 8086? Come on, now.If you were a greybeard, surely you remember the 4-bit micros that were the workhorses of the 1970s and 1980s? That is the level of complexity a picoBlaze core is intended to service.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: November 02, 2019, 10:45:25 pm
content: Quote from: nctnico on November 02, 2019, 12:47:28 amThat's generally true formicro-processorlevel designs,but at the micro-controllerlevel, things are getting much more blurred. More MCUs can be a better choice.Nowadays, we look to (eg) replace DIP SW with MCU and reduce cables with MCU, because the MCU prices are so low, they actually cost less than the physical things they replace.We also use MCUs to give more choice on sensors, again with a view to removing hardware/physical side costs.In all these cases, the 'software' the runs on those MCUs is quite specific and is often lifetime stable. No firmware updates are needed.

author: coppice
author_rank: Super Contributor
timestamp: November 02, 2019, 10:52:37 pm
content: Quote from: PCB.Wiz on November 02, 2019, 10:45:25 pmWell, that's what you hope on the day you begin mass production of a design where the code can't be updated.

author: MT
author_rank: Super Contributor
timestamp: November 29, 2019, 02:30:26 pm
content: Quote from: tggzzz on November 02, 2019, 06:20:09 pmYes and squids are on of the few lifeforms thats naturally multitasking, one central brain and one brain per arm.

author: aix
author_rank: Regular Contributor
timestamp: November 29, 2019, 06:12:14 pm
content: Quote from: MT on November 29, 2019, 02:30:26 pmYou're probably thinking of octopuses.P.S. Now that I've opened that can of worms,https://english.stackexchange.com/a/271/2518

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 29, 2019, 10:30:18 pm
content: Quote from: aix on November 29, 2019, 06:12:14 pmSince it has such a tangled etymology, perhaps a middle ground, sayoctopusi, would work better?Obviously, my English is on par with my telepathic skills. Which, to be honest, should probably be called telepathetic. Or, if you are close enough, just pathetic.

author: brucehoult
author_rank: Super Contributor
timestamp: November 30, 2019, 03:00:11 am
content: Quote from: Nominal Animal on October 03, 2019, 02:46:17 amSadly I missed this thread starting as it happened at the start of a longish vacation in October and then it's been inactive since November 2.My Teensy 4.0 seems to run ok at 1 GHz. It gets rather hot with no heatsink, but it seems to throttle itself. Running my primes benchmark (http://hoult.org/primes.txt) it takes the identical same number of clock cycles at anything from 600 MHz to 960 MHz, but at 1 GHz it takes more cycles to complete.Impressive that at 960 MHz it slightly beats the FU-540 single-issue RISC-V "Rocket" design in the HiFive Unleashed running at 1.45 GHz (it's slower than the HiFive at 1.50 GHz). The Teensy uses *exactly* the same number of clock cycles as the dual-issue RISC-V U74. 1.5x - 1.6x real world performance increase is typical for dual-issue over single-issue (at about 15% area increase, so it's a good trade-off).The Teensy 4.0 absolutely *thrashes* the Cortex A7 RPi2. It's 60% faster at the same MHz. I don't know but I'd have thought the A7 and M7 would have very similar pipelines. Is the L1 cache in the A7 really so bad? It's got an MMU in the way, of course. This benchmark uses only 8 KB of RAM (and just over 200 bytes of code).At SiFive we're seeing big demand for GHz speed simple controller cores (no MMU, no cache, no FPU) in both 32 bit and 64 bit. They are being used in things such as disk/SSD or network controllers. There is a lot of data being moved quickly. The code is relatively small and simple, but still measured in at least kilobytes and far beyond what you can implement directly in an FPGA.

author: splin
author_rank: Frequent Contributor
timestamp: November 30, 2019, 06:12:18 am
content: Quote from: brucehoult on November 30, 2019, 03:00:11 amHow can it take more cycles at 1GHz, unless it is is waiting for some external asynchronous signal?

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: November 30, 2019, 06:47:33 am
content: Sadly NXP has not revealed anything yet! Just a news page and a 2 page flyer,Maybe the sad news is it would be like i.MX RT600, which they had announced it like more than a year ago! if this is the case, who cares, my company has made a 2.5GHz MCU, but we would not tell the public any more info

author: brucehoult
author_rank: Super Contributor
timestamp: November 30, 2019, 06:51:38 am
content: Quote from: splin on November 30, 2019, 06:12:18 amSorry .. I meant more time than you'd expect if it was the same number of cycles, all actually at 1 GHz. Specifically, the Arduino library millis() function reports 26213 ms at the 1.008 GHz preset, which implies 26.4 billion clock cycles to complete the task, vs 26.1 billion clock cycles at every other commanded speed, including 960 MHz (27196 ms)Conversely, one could calculate the other way and conclude that it is throttling back to around 996 MHz, or that the PLL or whatever isn't all that accurate in its setting at such speeds, or that the millis() function suddenly doesn't work the same as it does at 960 MHz and below.My attempt to time it with a stopwatch just now gave 26.4 sec at the 1.008 GHz setting vs the 26.213 it self-reports, which I'd say is within my reaction time variation. If it was running at a true 1008 MHz then you'd expect 25.90 seconds for the same number of clock cycles.I could of course have it set and reset a GPIO and have another board (running at constant speed) do the time measurement, but I can't be bothered with that right now.

author: Nominal Animal
author_rank: Super Contributor
timestamp: November 30, 2019, 01:44:22 pm
content: Quote from: brucehoult on November 30, 2019, 06:51:38 amPerthis threadat PJRC forums, they've seen various issues above 960 MHz, so it could be anything from signal integrity issue inside the chip onwards. That beta test thread is very informative, if you're interested in the details.

author: brucehoult
author_rank: Super Contributor
timestamp: November 30, 2019, 03:41:51 pm
content: Quote from: Nominal Animal on November 30, 2019, 01:44:22 pmHmm."The IDE setting of 1008 actuals codes to 996 through the TD 1.48 setup. It can be changed there."So my benchmark is running in exactly the expected amount of time after all.Which prompts the question of why the menu item is 1.008, not 996...

author: Miyuki
author_rank: Frequent Contributor
timestamp: December 01, 2019, 05:50:43 pm
content: Quote from: brucehoult on November 30, 2019, 03:00:11 amM7 isbeastcompared to other cores, even smaller A onesM7 have 2.14-3.23 DMIPS/MHzA7 have just 1.9Bigger A9 have still "just" 2.5You will need something like A15 with 3.5 to 4 to be faster