Engineers Garage

  • Electronic Projects & Tutorials
    • Electronic Projects
      • Arduino Projects
      • AVR
      • Raspberry pi
      • ESP8266
      • BeagleBone
      • 8051 Microcontroller
      • ARM
      • PIC Microcontroller
      • STM32
    • Tutorials
      • Complete Sensor Guide
      • Engineering Deep Dives
      • AI
      • ARDUINO Compatible Coding
      • Audio Electronics
      • Battery Management
      • Beginners Electronics Series
      • Brainwave
      • Digital electronics (DE)
      • Electric Vehicles
      • EMI/EMC/RFI
      • EVs
      • Hardware Filters
      • IoT tutorials
      • LoRa/LoRaWAN
      • Power Tutorials
      • Protocol
      • Python
      • RPI Python Programming
      • Sensors
      • USB
      • Thermal management
      • Verilog
      • VHDL
    • Circuit Design
    • Project Videos
    • Components
  • Articles
    • Tech Articles
    • Insight
    • Invention Stories
    • How to
    • What Is
  • News
    • Electronic Product News
    • Business News
    • Company/Start-up News
    • DIY Reviews
    • Guest Post
  • Forums
    • EDABoard.com
    • Electro-Tech-Online
    • EG Forum Archive
  • DigiKey Store
    • Cables, Wires
    • Connectors, Interconnect
    • Discrete
    • Electromechanical
    • Embedded Computers
    • Enclosures, Hardware, Office
    • Integrated Circuits (ICs)
    • Isolators
    • LED/Optoelectronics
    • Passive
    • Power, Circuit Protection
    • Programmers
    • RF, Wireless
    • Semiconductors
    • Sensors, Transducers
    • Test Products
    • Tools
  • Learn
    • Design Guides
    • Learning Center
    • Tech Toolboxes
    • Tech Terms
    • Webinars & Digital Events
  • Resources
    • EE Training Days
    • LEAP Awards
    • Podcasts
    • White Papers
  • Guest Post Guidelines
  • Advertise
  • Subscribe

Understanding the different types of AI

By Nikhil Agnihotri July 26, 2026

In the previous article, we discussed artificial intelligence (AI) domains and walked through ten areas you can specialize in: machine learning, natural language processing, computer vision, robotics and physical AI, agentic AI, reasoning models, generative AI, multimodal AI, scientific AI, and edge AI.

Each of these areas can become part of a learning path or career direction. But they’re not all the same kind of category.

Edge AI describes where a model runs. Generative AI describes what a model produces. Multimodal AI describes the kind of data a model handles. Reasoning models describe how a model arrives at an answer. Robotics describes where the intelligence acts.

These terms point to different dimensions of AI, and those dimensions can be narrowed down later in a learning path or career.

AI is a broad landscape that can be categorized using multiple parameters. Once those axes are clear, the field starts to look less like a list of unrelated topics and more like a set of choices that can often be combined.

A career in “multimodal edge AI for industrial inspection” isn’t three separate careers stitched together. It’s one point selected across three different axes.

A single AI system can carry five or six different labels at once, and each one can be correct. Terms such as frontier AI, edge AI, generative AI, foundation models, narrow AI, agentic AI, multimodal AI, and TinyML can quickly pile up and create confusion.

A model can be frontier, multimodal, generative, cloud-hosted, closed-weight, and transformer-based at the same time. Some terms describe how large a model is. Some describe where it runs. Others describe what it does, how it was trained, or what kind of data it processes. These aren’t competing descriptions. They answer different questions.

That’s why it’s important to understand the main parameters used to classify AI, what each one measures, and where common terms fit. The goal is to create a mental filing system so that a phrase such as “agentic edge AI” can be unpacked into its parts instead of treated as one undifferentiated buzzword.

In this article, we’ll cover the parameters roughly in order of how often they come up in practice. We’ll also flag where the boundaries are genuinely fuzzy, because a fair amount of AI vocabulary is marketing that hardened into jargon before anyone agreed on a definition.

AI across different axes

AI can be classified based on multiple parameters. A single system may be labeled differently depending on which parameter is being used.

An AI system can be broadly classified by the following parameters:

  1. Capability level
  2. Deployment location
  3. Generality of intelligence
  4. Function or task type
  5. Modality
  6. How the model learns
  7. Architecture
  8. Openness
  9. Domain and application framing

Why axes are important

Understanding AI classification helps explain how a system works and how different learning paths or career directions relate to one another.

This framework separates real choices from false either/or decisions. For example, “computer vision” and “multimodal AI” may sound like competing paths when viewed as a flat list of domains. But both sit on the modality axis. One can be an expansion of the other rather than a completely separate direction.

The more useful questions are about the axes that are genuinely independent: what data the system works with, what the model does, and where it runs.

Knowing the axis also helps clarify what kind of skill shift is involved. Moving from computer vision to multimodal AI is a step along the modality axis. Moving from computer vision to edge deployment is a move onto a different axis, which brings in a different skill set, including compression, quantization, and hardware constraints.

Neither move is wrong, but they require different kinds of preparation.

This framework also shows which skills transfer and which are more specialized. Deployment-axis skills travel across many areas. Experience with compressing and running models on constrained hardware can apply whether the model is vision-based, language-based, or multimodal.

Modality-axis skills are more closely tied to the data type. Function-axis skills, such as agent orchestration or evaluation, sit on top of whatever models exist. This distinction can help learners invest in skills with broad reach or choose deeper specialization where technical scarcity matters more.

In practice, the strongest career positions are often points on two or three axes rather than a single label. Edge AI plus vision plus compression creates an industrial inspection profile. Agentic AI plus enterprise applications creates an automation profile.

Thinking in domains can hide these combinations. Thinking in axes makes it easier to design a direction around existing strengths, technical interest, and market demand.

Parameter 1: Capability level

This axis describes how powerful a model is relative to the current state of AI development.

Frontier AI refers to the most capable systems available at the current stage of the field. The defining feature isn’t a specific size or architecture, but a position. These are the models pushing the current limit, and their full range of capabilities and failure modes may not be fully understood, even by the teams that build them. The term appears often in safety and policy discussions because these are the systems regulators tend to watch most closely. What counts as frontier changes over time. A model that was considered frontier three years ago may be ordinary today.

State of the art (SOTA) is a related but narrower phrase. A model is SOTA on a specific benchmark or task if it currently achieves the best measured result on that test. Frontier is a general capability claim; SOTA is a claim about performance on a particular benchmark.

Foundation models are large models trained on broad datasets that can be adapted to many downstream tasks rather than being built for one specific job. The name captures the idea that these models are built once, often at great expense, and then other systems are built on top of them. Most frontier models are foundation models. The reverse isn’t always true. Many foundation models now sit well behind the frontier after being overtaken by newer systems.

The capability axis also has a lower end that matters just as much for hardware engineers.

Small language models (SLMs) are compact language models, usually in the range of roughly one to ten billion parameters, designed to run on modest hardware without a data center behind them. Microsoft’s Phi family, Google’s Gemma, and various distilled models fall into this category. SLMs are growing quickly because many useful tasks don’t require frontier-scale reasoning. Running a smaller model locally can also be cheaper, more private, and faster.

TinyML sits at the smallest end of the axis. It refers to models small enough to run on microcontrollers with kilobytes of RAM and milliwatts of power budget. This is the world of keyword spotting on an ESP32, vibration anomaly detection on a Cortex-M, or gesture recognition on a wearable. TinyML models are often only tens or hundreds of kilobytes, quantized down to 8-bit integers or smaller. The engineering challenge is as much about fitting into memory as it is about accuracy.

Between these poles are the mid-sized models used in many production systems. Frontier models get the attention, but mid-sized models often do much of the practical work.

Two of the career domains discussed earlier map directly onto opposite ends of this axis. Reasoning models and much of generative AI depend on frontier-scale systems. Edge AI lives closer to the SLM and TinyML end, where the engineering discipline is about getting acceptable capability into a small footprint.

When edge AI shifts from “make models bigger” to “make them smarter per parameter,” it’s describing capability moving down this axis. That’s what makes edge AI a growing field rather than a niche.

Parameter 2: Deployment location

This axis describes where the model physically runs. It’s the axis where “edge” belongs, and it’s independent of capability. A small model can run in the cloud, and a capable model can run at the edge, although the largest models usually remain tied to centralized compute.

Cloud AI runs in centralized data centers on powerful hardware. Most large-model inference happens here today because frontier-scale models don’t fit anywhere else. The design considerations include network dependency, round-trip latency, ongoing cost per query, and the fact that data leaves the device.

Edge AI runs on or near the device that generates the data, such as a phone, camera, sensor, embedded board, or industrial gateway. The move toward edge deployment is driven by several practical pressures:

  • Latency: There’s no server round trip.
  • Bandwidth and cost: Raw data doesn’t have to be sent elsewhere.
  • Privacy: Sensitive data can stay local.
  • Resilience: The device can keep working when the network doesn’t.

The constraint is that edge hardware has far less compute, memory, and power than a data center. As a result, edge models are usually smaller and often less capable than cloud-hosted models.

Fog AI, or fog computing, sits between edge and cloud. It runs on local servers, gateways, or nearby infrastructure that’s close to the devices but has more resources than the devices themselves. A factory-floor server that aggregates and processes data from hundreds of machines before deciding what to forward to the cloud is using fog computing. In a well-designed system, fog handles work that’s too heavy for the device but too latency-sensitive or bandwidth-heavy to send all the way to the cloud.

On-device AI is often used as a synonym for edge AI, though it sometimes refers more specifically to consumer hardware, such as phones and laptops, rather than deeply embedded systems.

Embedded AI overlaps heavily with edge AI but emphasizes deployment inside embedded systems and dedicated hardware rather than general-purpose consumer devices. In practice, on-device AI, embedded AI, and edge AI often blur together. The term a person uses may say more about their industry than about a strict technical distinction.

Hybrid AI describes systems that deliberately split a workload across locations, deciding which parts run locally and which are sent to the cloud. A voice assistant that detects its wake word on-device but sends the actual question to the cloud is a simple example.

This axis maps directly onto design decisions. Where a model runs determines its power budget, privacy properties, latency, and failure behavior when connectivity drops.

In the previous article, we described a three-tier hybrid architecture as the enterprise standard: cloud for heavy workloads and training, on-premises servers for data sovereignty and consistent performance, and edge devices for real-time inference. That is this axis expressed as a system. Edge AI emphasizes model compression, C++, and frameworks such as TensorRT or TFLite, with the goal of making models fit the bottom two tiers: on-premises servers and edge devices.

Edge AI doesn’t compete with generative AI or multimodal AI. A compressed multimodal model can also be deployed at the edge.

Parameter 3: Generality of intelligence

This is the classic textbook taxonomy of AI, the one that predates the current wave by decades. It has become less clear as models have become more general, but it still frames a lot of discussion.

Narrow AI, also called weak AI, performs one kind of task. Examples include image classification, speech transcription, game playing, spam filtering, or defect detection on a production line. It doesn’t have capability outside its trained domain. In the strict sense, essentially all deployed AI today is narrow AI, even when it appears broad.

Artificial general intelligence (AGI) would match or exceed human ability across most cognitive tasks, generalizing to problems it wasn’t specifically built for. It doesn’t exist today. There’s real disagreement about how close current systems are and whether AGI is a coherent target or a moving goalpost.

Artificial superintelligence (ASI) would exceed human ability across essentially all tasks. This remains speculative and is mostly discussed in long-term safety and philosophy contexts.

This axis has become muddy for a reason. A modern large language model is mechanically doing narrow next-token prediction, trained on a single objective, yet it can write code, summarize contracts, and translate languages it wasn’t explicitly taught. It’s technically narrow AI displaying broad behavior, which doesn’t fit the old categories cleanly.

That’s why the term “general-purpose AI” appears more often now. It sidesteps the AGI debate while acknowledging the breadth of modern systems. None of the career domains discussed in the previous article are AGI. They’re all narrow AI in the strict sense, even if some act broadly.

Parameter 4: What the model does

This axis classifies AI by the kind of job it performs. It’s one of the more practical groupings because it maps directly onto what a system is being built to do.

Discriminative AI classifies inputs or predicts labels. Given an image, is it a cat or a dog? Given an email, is it spam? Given a solder joint, is it defective? These models learn the boundary between categories. Most traditional machine learning and classic computer vision fall here.

Generative AI produces new content, such as text, images, audio, video, code, or 3D models. Instead of drawing a boundary between existing categories, it learns the distribution of the data well enough to produce new samples from it. This is the category behind much of the current public excitement, from chatbots and image generators to code assistants.

Predictive AI forecasts future or unknown values from historical data. Examples include sales forecasting, demand prediction, predictive maintenance, and weather modeling. It overlaps with discriminative AI but often implies a time-series or regression task rather than pure classification. The term has also become more common as a way to distinguish established, practical AI from the generative wave.

Agentic AI refers to systems that pursue goals across multiple steps by taking actions, such as calling tools, browsing the web, running code, querying databases, and chaining these actions together with some autonomy. Agentic AI isn’t really a distinct architecture. It’s a usage pattern built on top of capable models, usually LLMs, wrapped in a loop that lets them act, observe results, and act again. The important questions are less about the model itself and more about reliability, oversight, and what happens when a multi-step process goes wrong partway through.

Reasoning models are models trained to work through a problem step by step before committing to an answer, spending extra computation at inference time to improve accuracy on hard tasks. They trade latency and cost for correctness, and they tend to help most with math, coding, and logic-heavy problems. They offer less benefit for simple lookups. This category barely existed as a distinct product tier a few years ago and is now offered by most major AI labs.

The useful point is that generative AI, agentic AI, and reasoning models may be presented as separate career domains, but on the function axis, they stack rather than compete. A modern system can be generative in output, reasoning in method, and agentic in deployment, all at once. That is three function-axis labels describing one product.

Parameter 5: Modality

Modality classifies AI by the type of information it processes. This axis is straightforward but important, especially as systems increasingly handle several modalities at once.

Text AI, often discussed under natural language processing, handles language tasks such as translation, summarization, question answering, sentiment analysis, and related language workflows.

Computer vision handles still images and video, including tasks such as object detection, segmentation, classification, tracking, and optical inspection.

Speech AI handles audio. It includes speech recognition, such as speech to text, and synthesis, such as text to speech. It also includes related tasks such as speaker identification and wake-word detection.

Multimodal AI handles more than one type of information together, and this is increasingly the default for frontier systems. A model that can take an image and a text prompt and answer questions about the picture is multimodal. So is a model that generates audio from text or reads a chart and explains it.

Vision-language models (VLMs) are an important subclass of multimodal systems built around images and text. They power image captioning, visual question answering, and document understanding.

Modality matters at the edge as much as anywhere else. An audio keyword spotter, a vision-based people counter, and a sensor-fusion anomaly detector are all edge systems, but they require different model architectures, preprocessing, and hardware acceleration.

Natural language processing, computer vision, and multimodal AI aren’t unrelated fields. They’re positions on one axis, and multimodal AI expands across the others. That’s why specializing in one modality first and then expanding cross-modally can be a practical sequence. Moving from computer vision to multimodal AI is a move along the same axis, not a move to a completely unrelated field.

Parameter 6: How the model learns

This axis classifies AI by the method used to train it. It’s the most technical grouping and the one where the categories are often most precisely defined.

Supervised learning trains on labeled examples. The model is given inputs paired with correct outputs and learns the mapping between them. It works well when high-quality labels are available, though those labels are often expensive to produce.

Unsupervised learning finds structure in unlabeled data, such as clustering similar items or reducing dimensionality, without being told the correct answer.

Self-supervised learning is the approach that made modern LLMs possible. The model generates its own labels from raw data. Predicting the next word from the preceding words is a self-supervised task: the label is just the next word in the text, which is already there. This lets models learn from enormous quantities of unlabeled text and other data, which is why it underpins the pre-training of nearly every large model today.

Reinforcement learning (RL) learns through trial and error guided by a reward signal. The model, usually called an agent in this context, takes actions and receives feedback. Over time, it learns behavior that maximizes reward. RL drove well-known game-playing systems, is central to robotics, and has become important in shaping the behavior of large models after pre-training.

Reinforcement learning from human feedback (RLHF) is the process that turns a raw pre-trained language model into something more helpful and better behaved. Humans rank model outputs, those rankings train a reward model, and RL uses that reward model to steer the language model toward preferred behavior.

Reinforcement learning from AI feedback (RLAIF) replaces some human judgments with AI-generated preferences to scale the process. This is related to the idea behind constitutional approaches to alignment.

Transfer learning takes a model trained on one task and adapts it to a related task, reusing learned representations rather than starting from scratch.

Fine-tuning is a specific form of adaptation where a foundation model continues training on a narrower dataset to specialize it for a domain, style, or task. It is how a general model can become a medical-notes summarizer or a company-specific assistant.

Federated learning trains a shared model across many devices without pooling their raw data centrally. Each device computes updates locally, and only the updates, not the data, are combined. This is valuable for privacy-sensitive edge deployments and is used in production for applications such as mobile keyboard prediction.

The important point is that these paradigms can be combined. A typical large model may be pre-trained with self-supervised learning, then fine-tuned, then aligned with RLHF. That is three training paradigms applied in sequence to one model, which is why machine learning sits underneath every other domain rather than beside them.

Parameter 7: Architecture

This axis classifies AI by the underlying structure of the network. It matters most to people building or optimizing models, and it also explains why certain systems are efficient at certain tasks.

Transformer models dominate current AI. Introduced in 2017, the transformer uses an attention mechanism that lets the model weigh the relevance of different parts of the input to one another. Transformers scale well with data and compute, which is one reason modern AI advanced so quickly. They underlie almost every large language model and most multimodal systems.

Convolutional neural networks (CNNs) were the dominant architecture for vision before transformers arrived, and they remain widely used, especially at the edge. CNNs are efficient and well-suited to spatial data, which is why they still appear in embedded vision where compute is limited.

Recurrent neural networks (RNNs) and their more capable variant, long short-term memory networks (LSTMs), were the standard for sequential data such as text and time series before transformers displaced them. They are largely historical for large-scale language work now, though they still appear in some resource-constrained settings.

Diffusion models generate images, audio, and video by starting from noise and iteratively refining it into a coherent output. They are behind many current image and video generation systems.

Mixture of experts (MoE) is an architectural pattern, usually layered on top of transformers, where the network is divided into many sub-networks called experts and only a few are activated for a given input. This lets a model have a very large total parameter count while keeping the compute cost per query much lower, since most of the network stays idle on any single pass. Several large models use this approach to gain scale without proportional inference cost.

State space models, including approaches such as Mamba, are a newer line of research aimed at handling long sequences more efficiently than transformers, whose cost grows steeply with sequence length. Whether they displace transformers or settle into a niche remains an open question.

Architecture is one area where it’s difficult to make firm claims about which specific commercial models use which internal designs. Labs often don’t disclose those details, and public write-ups sometimes rely on guesses. The general categories above are solid, but the specific attribution of a closed model to a given architecture is often uncertain.

Parameter 8: Openness

This axis classifies AI by how freely a model can be accessed, inspected, and modified. It has become a genuine dividing line in the field, with real disagreement about what the labels should mean.

Closed-source AI is available only through a controlled interface, usually an API. Users send inputs and receive outputs, but they can’t see or download the weights, and they can’t inspect the training process. This is the model behind many well-known commercial systems.

Open-weight AI releases the trained model weights so users can download, run, and fine-tune the model. It doesn’t necessarily release the training data, training code, or full documentation of the process. Many models people casually call “open source” are actually open-weight. The distinction matters because access to the weights allows deployment and adaptation, but it doesn’t allow full reproduction or auditing of how the model was built.

Open-source AI, in the strict sense, would include the weights, training code, data, and enough documentation to reproduce the system. Fully open models exist, but they’re less common than the loose use of the term suggests. There’s active debate about what qualifies. When “open source” is attached to a large model, it’s worth checking whether it means open weights or the full stack, because those two meanings imply very different things about what can be done with the model and what can be trusted about it.

The openness axis intersects with the others in important ways. A common comparison is between an expensive closed frontier model and a cheaper open competitor that delivers much of the reasoning performance at a fraction of the cost per token. That turns openness into an engineering and budget decision, not just a philosophical one.

Openness also intersects with deployment. Open-weight models make serious edge and on-premises deployment more feasible for organizations that can’t or won’t send data to an external API. That’s why this axis matters far beyond ideology.

Parameter 9: Domain and application framing

The final grouping is less a technical taxonomy and more a set of labels the industry uses to describe where AI is applied. These terms cut across the axes above and are mostly about audience and use case.

Industrial AI refers to AI applied to manufacturing, energy, logistics, and heavy industry. Predictive maintenance, quality inspection, process optimization, and yield prediction all fit here.

Enterprise AI describes AI deployed inside organizations for internal workflows, including document processing, customer support, knowledge retrieval, and business analytics.

Consumer AI is AI that faces end users directly, such as personal assistants, recommendation systems, and creative tools.

Physical AI covers AI that senses and acts in the physical world through robots, vehicles, and drones. In the previous article, we highlighted this distinction: software AI deals in tokens and probabilities, while physical AI has to deal with gravity, friction, sensor noise, and the variability of the real world.

Embodied AI is the closely related research term for intelligence that learns through a physical or simulated body.

Scientific AI applies machine learning to research problems in biology, chemistry, climate, and materials. It was treated as a full career domain earlier, and it’s worth noticing that it’s defined by its application area rather than by any position on the technical axes. A scientific AI system might be a generative diffusion model, a supervised classifier, or a foundation model fine-tuned on biomedical text. The label tells you the problem, not the method.

These application labels are useful for orienting a conversation, but their boundaries are loose. The same underlying system could be described as industrial, physical, and enterprise AI depending on who’s describing it and for which audience.

Although a learning path or career path may align with one primary axis, an AI system or application developed within that domain can still fall into several categories across different axes.

Conclusion

The most useful thing to remember is that these parameters are independent. Any real system sits at a point on several of them at once.

A large commercial chat assistant, for example, might be:

  • Frontier on the capability axis
  • Cloud-hosted on the deployment axis
  • General-purpose on the generality axis
  • Generative, and increasingly agentic, on the function axis
  • Multimodal on the modality axis
  • Trained with self-supervised pre-training plus RLHF on the learning axis
  • Transformer-based, possibly with a mixture-of-experts architecture
  • Closed-weight on the openness axis
  • Consumer-facing or enterprise-focused on the application axis

When someone uses a compound term such as “agentic edge AI” or “open-weight multimodal SLM,” they’re specifying several of these coordinates at once. Once the phrase can be decomposed, it stops being jargon and becomes a fairly precise description.

For anyone working in electronics, embedded systems, or IoT, a few of these axes carry most of the weight in day-to-day decisions. Deployment location determines power, latency, and privacy requirements. Capability level, from TinyML through SLMs to frontier models, affects hardware and cost. Function type, whether classification, generation, or multi-step action, shapes the overall system design. Modality determines sensors, preprocessing, and acceleration needs.

The other axes matter, but those four tend to drive the practical engineering decisions.

When choosing a domain, it helps to know which axis it belongs to because that reveals the most natural adjacent moves. A specialization on the modality axis, such as computer vision, can expand into multimodal work along the same axis. A specialization on the deployment axis, such as edge AI, depends more on hardware-software co-design and compression, and that skill set can travel across many modalities and functions. A specialization on the function axis, such as agentic systems, focuses more on orchestration and evaluation, and it sits on top of whatever models exist rather than inside them.

Some combinations are especially durable because they pair axes that reinforce each other. Edge AI plus vision plus compression creates an industrial inspection profile. Multimodal AI plus scientific application creates a clinical AI profile. Agentic AI plus enterprise application creates an automation profile. None of these is a single domain by itself.

A closing caution is worth keeping in mind: the vocabulary in this field is younger than it sounds, and some of it was coined by marketing before the technical community agreed on definitions. Terms such as “frontier,” “agentic,” and “physical AI” can mean slightly different things to different people, and the definitions are still moving.

Treat the categories as a map rather than fixed territory. The map is useful, but the ground keeps moving, and a term that is precise this year may be obsolete or redefined next year. The value of the framework is not in memorizing the labels. It is in learning to ask, for any system you encounter or build, which question each label is answering.

You may also like:


  • The top AI tools of 2026

  • How to choose the ideal AI subscription in 2026

  • Top AI domains and career paths in 2026

  • What are AI chips and why are they important?

Filed Under: AI Engineering Collective, Tech Articles
Tagged With: ai, artificial intelligence, Tech Article
 

Next Article

← Previous Article
Next Article →

Questions related to this article?
👉Ask and discuss on EDAboard.com and Electro-Tech-Online.com forums.



Tell Us What You Think!! Cancel reply

Log in to leave a comment:

Lost your password?

Don't have an account? Register here

Submit a Guest Post

submit a guest post

EE TECH TOOLBOX

“ee
Tech Toolbox: Wide Bandgap Semiconductors
Moving from silicon to GaN or SiC feels like a whole new ballgame, doesn’t it? It isn’t just about faster switching; it’s about managing the layout parasitics and thermal realities that come with that speed. This month’s Tech Toolbox features a curated eBook that tackles these design hurdles head-on.

EE Learning Center

EE Learning Center
“engineers
EXPAND YOUR KNOWLEDGE AND STAY CONNECTED
Get the latest info on technologies, tools and strategies for EE professionals.

HAVE A QUESTION?

Have a technical question about an article or other engineering questions? Check out our engineering forums EDABoard.com and Electro-Tech-Online.com where you can get those questions asked and answered by your peers!


RSS feed: EDABOARD.com Discussions. EDABOARD.com Discussions.

  • How to select the pre-charge current for low-current charging solutions?
  • Choosing a Suitable Capacitor for Power Supply Smoothing
  • Are there any differences in energy harvesting between ISO15693 and ISO14443A protocols for NFC chips?
  • Ground pour won't go to GND vias in KICAD
  • Use unidirectional TVS as normal general purpose diode?

RSS feed: Electro-Tech-Online.com Discussions Electro-Tech-Online.com Discussions

  • 4060 counter doesn't stop ?
  • My Advanced Realistic Humanoid Robots Project
  • Semi-automatic battery handler
  • PWM Dimming for 24V LED Strips: What Should I Consider?
  • Looking for help with wiring PJ Bass (Series/Parallel blend bypass)

Featured Tutorials

VHDL Series (1-24)

  • VHDL Tutorial 17: Design a JK flip-flop (with preset and clear) using VHDL
    VHDL Tutorial 17: Design a JK flip-flop (with preset and clear) using VHDL
  • VHDL Tutorial 18: Design a T flip-flop (with enable and an active high reset input) using VHDL
    VHDL Tutorial 18: Design a T flip-flop (with enable and an active high reset input) using VHDL
  • VHDL Tutorial – 19: Designing a 4-bit binary counter using VHDL
    VHDL Tutorial – 19: Designing a 4-bit binary counter using VHDL
  • VHDL Tutorial – 20: Designing 4-bit binary-to-gray & gray-to-binary code converters
    VHDL Tutorial – 20: Designing 4-bit binary-to-gray & gray-to-binary code converters
  • VHDL Tutorial – 21: Designing an 8-bit, full-adder circuit using VHDL
    VHDL Tutorial – 21: Designing an 8-bit, full-adder circuit using VHDL
  • VHDL Tutorial – 22: Designing a 1-bit & an 8-bit comparator by using VHDL
    VHDL Tutorial – 22: Designing a 1-bit & an 8-bit comparator by using VHDL
More Tutorials >

Recent Articles

  • Teradyne launches 24-slot tester for edge AI devices
  • Stackpole adds 25 mΩ and 30 mΩ sensing values
  • Novotechnik LWX transducers provide IP67 position measurement
  • TDK varistors provide 15 kV ESD protection
  • Microchip POL-05-20S-T delivers 20 A for space processing

EE ENGINEERING TRAINING DAYS

engineering
Engineers Garage
  • Analog IC TIps
  • Connector Tips
  • Battery Power Tips
  • EDABoard Forums
  • EE World Online
  • Electro-Tech-Online Forums
  • EV Engineering
  • Microcontroller Tips
  • Power Electronic Tips
  • Sensor Tips
  • Test and Measurement Tips
  • 5G Technology World
  • Subscribe to our newsletter
  • About Us
  • Contact Us
  • Advertise

Copyright © 2026 Arrowfly LLC. All Rights Reserved. The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of Arrowfly
Privacy Policy

Search Engineers Garage

  • Electronic Projects & Tutorials
    • Electronic Projects
      • Arduino Projects
      • AVR
      • Raspberry pi
      • ESP8266
      • BeagleBone
      • 8051 Microcontroller
      • ARM
      • PIC Microcontroller
      • STM32
    • Tutorials
      • Complete Sensor Guide
      • Engineering Deep Dives
      • AI
      • ARDUINO Compatible Coding
      • Audio Electronics
      • Battery Management
      • Beginners Electronics Series
      • Brainwave
      • Digital electronics (DE)
      • Electric Vehicles
      • EMI/EMC/RFI
      • EVs
      • Hardware Filters
      • IoT tutorials
      • LoRa/LoRaWAN
      • Power Tutorials
      • Protocol
      • Python
      • RPI Python Programming
      • Sensors
      • USB
      • Thermal management
      • Verilog
      • VHDL
    • Circuit Design
    • Project Videos
    • Components
  • Articles
    • Tech Articles
    • Insight
    • Invention Stories
    • How to
    • What Is
  • News
    • Electronic Product News
    • Business News
    • Company/Start-up News
    • DIY Reviews
    • Guest Post
  • Forums
    • EDABoard.com
    • Electro-Tech-Online
    • EG Forum Archive
  • DigiKey Store
    • Cables, Wires
    • Connectors, Interconnect
    • Discrete
    • Electromechanical
    • Embedded Computers
    • Enclosures, Hardware, Office
    • Integrated Circuits (ICs)
    • Isolators
    • LED/Optoelectronics
    • Passive
    • Power, Circuit Protection
    • Programmers
    • RF, Wireless
    • Semiconductors
    • Sensors, Transducers
    • Test Products
    • Tools
  • Learn
    • Design Guides
    • Learning Center
    • Tech Toolboxes
    • Tech Terms
    • Webinars & Digital Events
  • Resources
    • EE Training Days
    • LEAP Awards
    • Podcasts
    • White Papers
  • Guest Post Guidelines
  • Advertise
  • Subscribe