Initial Impressions of the THEJAS32 SoC
An impractical microcontroller, for most purposes
THEJAS32 is based on the ET1031 processor, a 32-bit single-core, in-order, 3 stage pipeline processor. The SoC is designed by Center for Development of Advanced Computing (CDAC), as part of the Digital India RISC-V (DIR-V) program, by the Ministry of Electronics and Information Technology (MeitY). Government of India.
This SoC includes 256KB of internal SRAM. Peripheral interfaces include three UART, four SPI, three I2C, eight PWM pins and 32 GPIOs. It operates at a nominal frequency of 100 MHz. The SoC is manufactured on a 130 nm process1.
I am writing this review based on the material available online, and a few days of experimentation with the ARIES MICRO v1.0 development board. There is not much material available online about the THEJAS32 and its ecosystem. To plug this gap, I intend to publish more information, as time permits.
My initial impression is that the THEJAS32 is an impractical SoC for most applications. It doesn’t integrate a variety of features that customers would look for in a product of this class. For instance, it doesn’t include essential features like the ability to use a crystal oscillator as a clock source. Critical features to ensure reliable operation, such as a watchdog timer, and even brown out reset (BOR) circuitry are given a miss. The specified operating temperature range (0 to 85 degrees C) is not suitable for typical industrial applications. The ESD rating is not even mentioned, which would surely make any hardware designer think twice before even considering it for any commercial project. Finally, the lack of a DMA engine will make it very difficult to use the peripherals simultaneously at high speeds.
THEJAS32 does not include any form of analog integration. No oscillator, no PLL, no ADC, no BOR, no temperature sensor…. Nope. None. Zilch. The “no batteries included” philosophy of the THEJAS32 is sure to get quite painful, requiring a lot of additional hardware on the PCB. Sample these quirks of the THEJAS32 :
No provision for pull up/pull down resistors on GPIOs
There is no internal oscillator in the SoC. A low frequency imprecise oscillator is typically included as a boot clock source, as well as for power/cost savings in competing mainstream solutions.
No internal voltage regulator is included. The SoC (more accurately “ASIC”) needs two voltage rails - 3.3V for IO and 1.2V for the core.
7 SoC pins need to be connected to 1.2V, 11 pins to 3.3V. How many decoupling capacitors would we need ?
THEJAS32 includes one innovation I haven’t seen anywhere else. It has a… hold your breath… heartbeat pin on the SoC - to prove the processor is alive? With a 100 MHz system clock, this toggles at an approximate rate of 2.3214 Hz2.
Curiously, THEJAS32 does not implement any form of pin multiplexing. The SoC is available only in a large 128 pin TQFP128 package. This, along with requirement for many external components adds to costs in terms of components, board area, and power consumption, limiting the scope of application of the SoC.
The one-pager claims “low power operation”, presumably to support applications such as smart meters, remote sensors, wearable devices, and electronic toys. Testing does not validate this claim - the THEJAS32 looks like a power hog that consumes around 250mW of power3! As it does not implement any low power(“sleep”) modes, THEJAS32 is unsuitable for use in IoT devices that use small batteries.
THEJAS32 is plagued by poor design and implementation at a software level as well. It boots from the built in ROM, with a noticeable delay. Consider the following program that sets GPIO pin 18 high on boot. Can you guess the time gap between the CPU coming out of reset (RSTN pin going high) and the GPIO turning high ?
int pinRef=18;
void setup()
{
pinMode(pinRef, OUTPUT);
digitalWrite(pinRef, HIGH); // guess when this happens ?
}It was much longer than I thought… 5.6 seconds !!? A quick oscilloscope capture to illustrate this:
This delay is very high for a micro-controller by the way. Also note that the boot logic is hard-coded into ROM, and there is no documentation to suggest that this can be reduced in some way. Basically, if you use the THEJAS32 in any device, be aware that it will take around six seconds after power up to react to a user input. That. is. a. long. time…
Without further experimentation and documentation, it’s hard to say why THEJAS32 takes so much time to boot. Here are two partial reasons:
The boot-loader spews out log messages at a 115200 baud over UART, on every boot.
+-----------------------------------------------------------------------------+ | VEGA Series of Microprocessors Developed By C-DAC, INDIA | | Microprocessor Development Programme, Funded by MeitY, Govt. of India | +-----------------------------------------------------------------------------+ | Bootloader, ver 1.0.0 [ (hdg@cdac_tvm) Tue Dec 15 16:50:32 IST 2020 #135] | | | | ___ _________________________ ISA : RISC-V [RV32IM] | | __ | / /__ ____/_ ____/__ | | | __ | / /__ __/ _ / __ __ /| | CPU : VEGA ET1031 | | __ |/ / _ /___ / /_/ / _ ___ | | | _____/ /_____/ \____/ /_/ |_| SoC : THEJAS32 | +---------------------------------------+-------------------------------------+ | www.vegaprocessors.in | vega@cdac.in | +---------------------------------------+-------------------------------------+ Copying from FLASH to IRAM [INFO] Flash ID: 1f:86:01 Flash initialized [INFO] Copying 250KB from address: 0x000000. Starting program ...These messages may cause complications if you interface real peripherals on the UART0. Also, this is not the place to display messages about sponsorship info, contact and support details.
The ROM next loads 250 kB of code from the flash. SPI frequency is 3.6 MHz, and it doesn’t look like they are using QSPI feature. This step seems to contribute to more than 1 second of extra delay. It would make more sense to load a small second stage bootloader from flash, and hand over execution from there to the flash itself. The RP2040 microcontroller from Raspberry Pi takes this approach, making it possible to support a variety of flash chips with the best performance. This of course, assumes that THEJAS32 can execute code from flash - which isn’t mentioned in the datasheet. Is it possible it can’t ? If no, then that would effectively mean that the 256 kB of SRAM is the combined limit for data & code.
Can the THEJAS32 be used as a useful base in education ? In a limiting way, yes, and some of those could be remedied:
THEJAS32 is both poorly documented and ill supported. Strangely for a complex product of this nature, only a one-pager brochure is available online. They did provide me a datasheet over email, albeit with a two-day delay. The datasheet is light on details. So I have asked them for a reference manual. If you are looking for anything, please don’t waste time contacting them on their more-or-less dead mailing list4. Also, do expect a lot of back and forth over email to make any board using the SoC.
THEJAS32 seems OK for simple sensor projects. It’s minimalist feature set, however, doesn’t offer scope for deeper learning and skill development. It’s peripherals simply aren’t rich enough. TEJAS32 is a borderline minimalist SoC to the point that the UART implementation doesn’t even include flow control (RTS and CTS)!
THEJAS32 is quite expensive. The SoC is available in single quantity at on-line retailers such as robu.in, costing Rs 289 including taxes. The fine package (0.4mm pad spacing) means that home-brew PCBs are out; any student looking to build a device would need to use a PCB manufacturing service.
To offer a quick start, CDAC has also built the ARIES series of development boards around THEJAS32. The Arduino IDE is officially supported. Several examples illustrating basic interfacing with peripherals are provided. The boards don’t seem to be in stock at this time. These boards themselves are strange in that JTAG is not exposed on any of these boards. This is inexplicable for a development platform and a clear red flag for professional users. The documentation also doesn’t mention any way of using JTAG - so it’s not clear if the limitation is related to hardware or software.
The least cost variant, ARIES DOT v1.0, costs 900 rupees. These boards include an I2C based ADC IC to provide 4 analog inputs. Try not to use it for any “wearable” device though - for you’ll just be swapping batteries all day long. But then, why go through all the hassle of trying this when you can get a feature rich, well documented, well supported Raspberry Pi Pico (with an RP2040 SoC) at a killer price of Rs 349 ?
Another strange thing I found is that the schematics of none of these ARIES boards is available online… almost as if they were holding onto a secret! This is certainly hindering their adoption, as it makes it difficult for almost anyone to build boards and devices with it. This reduces any chances of an active community forming around these products. The proof is also in the numbers. As of this writing (Feb 2024), their mailing list has a mere 35 members, with 14 topics in more than 18 months. On twitter5 they have 582 followers. I am positive they can get better adoption by following some industry standard practices:
Provide publish datasheet and documentation of the THEJAS32 SoC and make it available online freely for anyone to use. Use the documentation of any commercial vendor’s microcontroller as a reference. Also, for technical reasons, don’t use Microsoft Word to generate your documentation.
Publish schematics and layout of all the ARIES boards, plus information required by board designers. Publish all source code that users may need - including any tools and utilities. Again - just follow what the other vendors are doing. That method works.
Support must be directly provided on the mailing list, or a forum. This will make more information available directly over a period of time, aid troubleshooting, and help build a community.
Ideally, publish the source code of the bootloader (i.e ROM contents) of the THEJAS32 as open source software.
Overall, it’s shocking as well as a disappointment to see something as impractical as the TEJAS32 SoC in the market. To its credit, it does remain the first “made-in-India” SoC available in single quantity - which in itself is worth something. But there is no escaping the fact that in its current state, it resembles an academic project - rather than a finished product that merits adoption. It’s failings seem a lot to do with a lack of understanding of product specifications, as well as a lack of desire to serve the real end users of such a chip. We need a much better implementation of the Atma-nirbhar (self reliant) vision for micro-controllers, but with a greater sense of utility, purpose and accountability.
MeitY Annual Report 2021-22, p. 265, https://www.meity.gov.in/writereaddata/files/MeitY_AR_English_2021-22.pdf
What’s with the counter here.. any theories ?
A rough ballpark estimate, not based on accurate measurement. SoC power consumption is not mentioned in the datasheet.
https://groups.io/g/vegaprocessors has 35 members, 14 topics since July 22!
Nope, I refuse to call it “X” !