i.MX RT 600 - Page 1
Forum section: electronics / general

author: ehughes
author_rank: Frequent Contributor
timestamp: October 16, 2018, 04:58:59 pm
content: Cortex M33 + Tensilica DSP + 4.5MB SRAMhttps://www.nxp.com/products/processors-and-microcontrollers/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-rt-series/arm-cortex-m33-based-family-of-crossover-processors:i.MX-RT600

author: mark03
author_rank: Frequent Contributor
timestamp: October 16, 2018, 05:17:13 pm
content: Looks interesting! Can someone who's used the Tensilica DSP comment on how open it is? Are there free tools? Is there an optimized FFT for it that you can access without signing away your firstborn?

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 05:36:45 pm
content: I wonder if they will revise their i.MX 8 to replace the M4F's with M33F's...

author: Berni
author_rank: Super Contributor
timestamp: October 16, 2018, 05:38:12 pm
content: Interesting chip there.The DSP part of it is not that hugely impressive, it is pretty beefy as far as audio DSPs go but in the end it can only do 4 per cycle 32x32 integer MAC or 8 per cycle 16x16 integer MAC. Running that at 600MHz makes for some pretty speedy math compared to any ARM Cortex M7 out there. Yet a lot of bigger ARM chips have NEON instructions and this gives them 4 per cycle 32x32 float or integer MACs or even 16 per cycle 8x8 integer MACs(Not useful for audio but for graphics certanly). Additionally these bigger ARMs tend to run at around 1 GHz and often have more than 1 core.So i guess this chip better be resonably cheap or low power to make it worth it. And yes hopefully you can get your hands on the C compiler for it, but seeing the compiler is made by Cadecence i have a feeling its not going to run you cheap for a license.

author: ataradov
author_rank: Super Contributor
timestamp: October 16, 2018, 05:49:11 pm
content: Quote from: blueskull on October 16, 2018, 05:47:09 pmDoes Tensilica DSP have a free compiler? I too wonder how open it actually is.

author: technix
author_rank: Super Contributor
timestamp: October 16, 2018, 05:58:51 pm
content: Quote from: ataradov on October 16, 2018, 05:49:11 pmIt appeared to me that those DSP cores uses the same compiler as the Xtensa cores, as found in ESP8266... So hijack that?

author: mark03
author_rank: Frequent Contributor
timestamp: October 16, 2018, 06:02:24 pm
content: Not just the compiler, but a freely-available library of basic DSP functions. For all its warts, CMSIS-DSP at least exists and is free, so the barriers to entry for M4F/M7 DSP are low. If the same is not true for the Tensilica DSP, it won't be of much interest to smaller players.

author: djacobow
author_rank: Super Contributor
timestamp: October 16, 2018, 06:21:09 pm
content: [ Disclosure: I worked for Tensilica 2000-2005 before it was aquired by Cadence. By far, the best company I ever worked for. ]The way Tensilica Xtensa Processor Generator works is that licensees use a GUI to select among a bunch of "canned" processor features: multipliers, MMU, cache size/type/none, special instructions for this or that. Additionally, using a special language called "TIE", fully custom instructions can be created that use custom IO, custom register files, etc. When the user clicks "go" the processor RTL is created on the fly, along with a verification suite, scripts for synthesis and layout, etc, along with a full suite of GCC-based software tools that understand all the customizations including the new instructions.Regarding the compiler, at a minimum, instrinsics are created so that you can instantiate variables matching the register file entries and call the instructions directly on them without dropping to assembler. But when the register and instruction types created result in vector operations on "normal" types (float, int32, uint32, etc), the compiler is generally smart enough to use them on its own, unrolling loops and such.It's really an incredible platform, and was far ahead of its time. It was basically everything RISC-V claims to be regarding extensibility, except better and more automatic, but, of course, not free or open.Anyway, the Xtensa HiFi engine 4 is essentially a fully canned audio DSP where all these choices have been made in advance by Tensilica, but conceptually works the same as any Xtensa processor. Tensilica definitely provided NXP with a compiler and all the regular tools.Is there an optimized FFT? I am absolutely sure there is and it is part of the basic support for the DSP.Will NXP be providing these tools to users for free? Don't know. Will they provide the FFT library to users? Don't know.Someone asked whether the ESP32 tools could be used to build binaries for this machine. The answer is a definite maybe, if the ESP32 is a strict subset of instructions to whatever is in this processor. Probably things like the linker map would have to be adjusted, and of course, the compiler would not use the DSP instructions, but you could create intrinsics for them. But a better path by far would be to use the compiler that was generated for the DSP.-- dave j

author: Berni
author_rank: Super Contributor
timestamp: October 17, 2018, 05:26:37 am
content: That sounds pretty jazzy. I never even seen a FPGA softcore generator that is this automated.Oh and how is the software support for the i.MX RT family in general?Everyone quite likes the STM32 chips here and the new Attolic true studio IDE works well and the CubeMX tool for generating a project and initialization code is a great idea. Yet in the end these so called HAL drivers that ST provides are at times simply garbage. Quite a few times i ended up using the driver to initialize the peripheral and then ignoring the HAL driver away and using direct register access to run it afterwards. That is because the driver simply was not capable of doing what i needed (Such as having UART continuously receive or generate a I2C restart rather than sending a stop followed by a start) or sometimes i had to fix a bug in the driver myself (Like the ethernet driver had a broken transmit function). On top of it all the source code is a convoluted mess of #defines and #includes where you have to dig down 4 function calls and 6 macro expressions deep before you find the actual hardware register its writing to (Even for simple things like I2C or ADC).Are the drivers provided by NXP for the RT family better than this?

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 17, 2018, 09:04:34 am
content: RT is the way to go for Future Cortex M designs, if they could make something better than STMCUBE for them, it would be like heaven

author: ogden
author_rank: Super Contributor
timestamp: October 17, 2018, 09:40:00 am
content: Quote from: Berni on October 17, 2018, 05:26:37 amYes they are and it's ok. CubeMX and ST HAL libraries are good for beginners/students to quickly get "hello world" and ST code examples running. Professionals shall not rely on "free for all" libraries that does not even have proper support.

author: mac.6
author_rank: Regular Contributor
timestamp: October 17, 2018, 11:05:52 am
content: Quote from: Berni on October 17, 2018, 05:26:37 amSome differences, IDE is MCUXpresso (Eclipse based IDE) which support most debug probes (jlink, opensda, pemicro etc...).You have config tool for pinmux and clock, much like CubeMX, which spit out C code compatible with SDK. You can even do peripheral code but I haven't used it.Software is into SDK, with drivers, middleware (rtos, tcpip stack, usb stack) and a lot of examples. One SDK per part.All SDK share the same structure, the same drivers API (where possible), so moving through parts is easy, given the parts support the same SDK family (not always the case, especially with old and deprecated parts).

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 17, 2018, 03:24:21 pm
content: How does RT600 compares to XMOS parts? any Ideas?

author: Berni
author_rank: Super Contributor
timestamp: October 18, 2018, 05:32:04 am
content: The problem with XMOS is that its hard to find suitable applications for it. They market them as being 32 core microcontrollers but its actually a 4 core microcontroller with 8 threads on each core (And you need to use at least 4 threads per core to get the full MIPS speed on that core). Additionally each core lives in its own memory space with its 256KB of RAM (This used to be only 64K). That sounds like a decent amount of on chip memory right? Well... there is no flash so this RAM has to hold all of your program code too, and there are no external memory interfaces so expanding this memory is not possible. The impressive MIPS number and single cycle execution does give it significantly more processing grunt than ARM MCUs, but there is no hardware floating point and because you have no peripherals you often have to dedicate cores for bitbanging (using serdes on pins) of things like UART, SPI, I2S etc so a few 100s of MIPS will be lost to IO tasks.So in the end the XMOS chip is in an awkward position standing on the border where the lands of MCUs, DSPs and FPGAs intersect. Its a fast MCU with limited memory size, its a DSP with no float and a not hugely impressive MMACs spec, its a FPGA that can run weird exotic interfaces but only at speeds under about 50MHz and limited complexity. XMOS has a lot of cool things that nobody else does, but ends up being limiting in annoying ways.So for most applications in think the RT600 makes more sense.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 18, 2018, 09:57:50 am
content: ThanksI think the main i.MX RT 600 draw back is the lack of Ethernet Controller, and maybe the LCD controller and External Memory controller.

author: technix
author_rank: Super Contributor
timestamp: October 18, 2018, 04:42:26 pm
content: Quote from: blueskull on October 18, 2018, 03:35:38 pmI was a bit confused at people shoehorning LCD and Ethernet into a MCU, be it i.MX RT or STM32F7. I always thought at that price point it is cheaper and easier to develop with V3s + 64MB SPI NOR/256MB SPI NAND/16GB eMMC or something. V3s is even cheaper than iMX6ULL, and comes with built-in 64MB DDR2. Or if 64MB wasn't enough (which you really shouldn't have used those Cortex-M7 by this point) a slight step up to A13 which can go up to 512MB DDR3 while still cheaper.

author: Berni
author_rank: Super Contributor
timestamp: October 18, 2018, 06:18:02 pm
content: We use STM32 MCUs with LCD and external memory a lot at work so i don't see why that would be a Linux thing.External memory is pretty easy to use on a MCU. Just set up the memory controller for the kind of RAM chip you have and suddenly the RAM is part of your memory map. The LCD controller is also very useful because a lot of displays that are QVGA(320x240) resolution and up have a RGB interface, you just set up the LCD controller and give it a pointer to your framebuffer in RAM and wouala its showing it on the display without any CPU intervention. We have a STM32F7 running a 640x480 display just fine (it does have hardware bitblt DMA too), sure you don't have the horsepower to do fancy smooth animated menus at such a resolutions (Especially since the rest of your app also needs some CPU time and RAM bandwith), but it can still draw a nice looking UI at a decent speed once things are optimized enough. All of it running in C without a real Linux like OS while sipping so little power it can run for an entire day continuously(Including the LCD) from a smartphone battery.I also dealt with some Ethernet on a STM32H7. Once you get lwip running on it you got most things taken care of. Also due to the pretty optimized "zero copy" nature of lwip combined with a DMA shoveling traffic trough the ethernet controller you can saturate a full duplex 100 Mbit ethernet link with ease(It doesn't support gigabit PHYs). Okay you sure as heck won't be running a PHP webserver on this, but you can certainly fetch webpages, send emails, stream audio or just generally send large amounts of data to something on a network.Linux is not always the right tool for the job. It certainly is great for any kind of complex device, but a god damn multimeter really does not need Windows CE and a 1 minute boot time!

author: technix
author_rank: Super Contributor
timestamp: October 19, 2018, 05:43:16 am
content: Quote from: blueskull on October 18, 2018, 06:17:21 pmThat was my point investigating Linux on PIC32MZ DA, as it is also a TQFP chip with built-in DDR DRAM. For me the Octavo parts seem like unobtanium and expensive, and the equivalent would be V3s, PIC32MZ2064DAG176 and ATSAMA5D27C-D1G-CU.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 20, 2018, 03:09:56 pm
content: Ethernet is an industrial Port! we use it every where, since 50+MHz MCU's we have it! I have done very nice and cool things with LPC1768@100Mhz including some Impress JS and JSON, Also Smaller size LCD's can be very beneficial,So why not! they are every where and At least in our company most of us hate Linux to play with.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: October 22, 2018, 09:02:26 pm
content: Is there any Price info available?

author: mark03
author_rank: Frequent Contributor
timestamp: February 25, 2020, 09:50:01 pm
content: More info and availability announced yesterday:https://media.nxp.com/news-releases/news-release-details/nxp-announces-availability-imx-rt600-crossover-familyRegarding compiler and library access for the Tensilica DSP, they sayQuoteI guess "complementary" means free? At least to some customers, anyway.I had a brief scan through the user's guide. A description of the DSP core is reserved for chapter 50, which is four pages long. It says "Information about additional HiFi4 documentation can be found in Section 51.2 References" and if you go there it says "references to additional information about the HiFi4, TBD"! So it is still possible/likely, I think, that they are going to keep the DSP locked down pretty tight and treat it like most application-processor vendors treat their GPUs, with little in the way of technical documentation and access only through approved "free" libraries. We'll see.Interestingly, the bits of user guide that I read through seemed quite well written. This is in stark contrast to the user's guide for the RT1060, which I recently gave up in favor of a slower STM32H7. The RT1060 documentation was so bad that I decided the pain was likely not worth the trouble. (Everything you need is there. Probably. It just hurts to access it.) Anyway, I thought this was a good sign that NXP may up their documentation game in the next, FDSOI, spins of the RT series. One can hope.

author: ali_asadzadeh
author_rank: Super Contributor
timestamp: February 26, 2020, 06:35:16 am
content: That's a good news, I hope their 1070 also came out soon.