feature article
Subscribe Now

The Last Centimeter

LAVA Closes the Gap

The cool thing about connected devices is that… well, they’re connected. Which, these days, means that they have access to immeasurable amounts of… whatever is out there to be connected to. Word is that that stuff is pretty useful. Proof of that is playing out as the Internet of Things (IoT) rolls out.

Having electronics connected to the internet is nothing new. We’ve had connected computers for far longer than the internet has even been around. That was enabled by special hardware – a separate network card made by a different company – plugged into the computer.

More recently, phones have data connectivity riding alongside the voice information. Oh, and then they may have a WiFi or BlueTooth connection on top of that. Specific ICs made by specialists help there.

But now, seems like everything short of dirt will get a connection to the internet. Unlike the past, when you could delegate connectivity stuff to some specialist, it’s entirely likely that ambitious inventors, whose attention is focused mostly on what they’re inventing, will need to confront the communication beast face to face.

The problem boils down to one of tying the network to your processor, which implements your awesome high-level algorithmic engine. You’ve got an RJ-45 connector all set up; all you need is to get that network signal to join up with the processor. Sounds trivial, right?

Well, just like a riverboat may have a hard time accessing the shore if it has to work its way through reeds and thickets and mangroves between the channel and dry land, so the network data has to come off the wire and, somehow, get through a morass of processing to be turned into data that’s relevant to something going on inside the processor.

This is a problem that Lava Computer Mfg. is addressing with a dedicated chip that will magically make all of the futzing with TCP/IP (as well as related protocols like UDP) disappear. It can take data from some process and, just like your shipping department, package it all up and send it out onto the network. (Yes, it’s not your imagination. We just did a metaphor jump. It’ll be fine…)

“What’s so hard about shipping?” you ask. Well, if you’re up on the 9th floor fulfilling an order of widgets for a customer, the last thing you want to do is run downstairs and figure out which box size is needed and how much postage is required and what kinds of labels and fasteners are allowed and what the postal restrictions are and… and… Likewise, if you’re a Thing designer trying to get some cool new functionality going, the last thing you need is to take six months off to study TCP/IP so that you can package up and ship your data.

That’s the goal of the Lava chip: it buries TCP/IP – and a bunch of other stuff – for you. That’s great in theory, but how, in practice, do you manage this in a way that’s going to make sense to the person writing software on the processor? How do you cross this last centimeter between the Lava chip and your processor?

The Lava IP System (LIPS) includes a simple protocol for getting data onto the network without futzing with the network details. Actually, the protocol doesn’t get you onto the network; it lets you set the system up and then deliver data to the Lava chip. The Lava chip then handles getting the data out onto the network.

This is about more than simply formatting data for one of the network protocols. Yeah, UDP is simple enough, but it’s tantamount to tossing data over the fence and hoping someone is around to get it. TCP, by contrast, can involve persistent sessions – actual data conversations. Not only is there formatting going on; the system has to manage multiple sessions that may be in play.

From a designer’s perspective, the LIPS system gives you up to twelve processes to play with. The protocol lets you set these processes up in the Lava chip. For each of those processes, there is a simple packet that you use to send data from the processor to the Lava chip. The packet is based on the old SLIP format, bounded by BRK, and consisting solely of a process number and the arbitrary payload.

Drawing.png

So from a software standpoint, you simply package up your data and send it off. Special process IDs can be used to configure and maintain the states in the LIPS engine (process IDs 128 and higher are used for system control functions; process IDs under 128 are used for data going to or from the network).

Interaction with the Lava chip happens via low-level code; they expect that developers will bury that under headers and wrappers and what-not for better code maintainability and abstraction – depending on the amount of code space available (some of these systems may be resource-stingy).

The Lava chip also contains support for other higher-level protocols (not shown in the simplified figure above). For instance, data and variables and such can be automatically extracted from an HTTP request for passing to the processor.

Lava makes a module that carries this; it provides a 10/100 Ethernet connection. They’re also working on one for WiFi. The Lava chip contains everything down to the physical layer; the Ethernet module supplies a transformer and RJ-45 connector. The WiFi module will use a different processor, with the appropriate wireless pieces rather than an Ethernet plug.

Why might you use this solution? Simply to cut off a goodly chunk of development time. Their claim is that connectivity work that would normally take 4-5 months can now be handled in 2-5 days – and in some cases, even in just a few hours.

It competes, of course, with other solutions aiming to get your Thing connected easily (we’ll be looking at another one shortly). What’s different about the Lava solution is the fact that, at the programming level, it’s not just a single stream of data to be packaged up for the net; it’s an intermingling of up to twelve streams. Hence the need for the simple protocol.

It may also be useful to place this into the perspective introduced the other day, where I postulated three communication levels (protocol/generic data/business object) between a Thing and the cloud. The LIPS setup implements the generic data level.

I have to admit that hearing about a new “protocol” caught my attention – and I suppose it’s a little disappointing to learn that it exists only over a very short distance between two chips on a board. That’s a rather limited scope.  But if it makes the difference of several months in crossing that last centimeter, then there may well be some folks that are pretty happy that the protocol – and system – exists.

 

More info:

LAVA IP System

One thought on “The Last Centimeter”

Leave a Reply

featured blogs
Apr 11, 2021
https://youtu.be/D29rGqkkf80 Made in "Hawaii" (camera Ziyue Zhang) Monday: Dynamic Duo 2: The Sequel Tuesday: Gall's Law and Big Ball of Mud Wednesday: Benedict Evans on Tech in 2021... [[ Click on the title to access the full blog on the Cadence Community sit...
Apr 8, 2021
We all know the widespread havoc that Covid-19 wreaked in 2020. While the electronics industry in general, and connectors in particular, took an initial hit, the industry rebounded in the second half of 2020 and is rolling into 2021. Travel came to an almost stand-still in 20...
Apr 7, 2021
We explore how EDA tools enable hyper-convergent IC designs, supporting the PPA and yield targets required by advanced 3DICs and SoCs used in AI and HPC. The post Why Hyper-Convergent Chip Designs Call for a New Approach to Circuit Simulation appeared first on From Silicon T...
Apr 5, 2021
Back in November 2019, just a few short months before we all began an enforced… The post Collaboration and innovation thrive on diversity appeared first on Design with Calibre....

featured video

Meeting Cloud Data Bandwidth Requirements with HPC IP

Sponsored by Synopsys

As people continue to work remotely, demands on cloud data centers have never been higher. Chip designers for high-performance computing (HPC) SoCs are looking to new and innovative IP to meet their bandwidth, capacity, and security needs.

Click here for more information

featured paper

Understanding Functional Safety FIT Base Failure Rate Estimates per IEC 62380 and SN 29500

Sponsored by Texas Instruments

Functional safety standards such as IEC 61508 and ISO 26262 require semiconductor device manufacturers to address both systematic and random hardware failures. Base failure rates (BFR) quantify the intrinsic reliability of the semiconductor component while operating under normal environmental conditions. Download our white paper which focuses on two widely accepted techniques to estimate the BFR for semiconductor components; estimates per IEC Technical Report 62380 and SN 29500 respectively.

Click here to download the whitepaper

Featured Chalk Talk

Bluetooth Overview

Sponsored by Mouser Electronics and Silicon Labs

Bluetooth has come a long way in recent years, and adding the latest Bluetooth features to your next design is easier than ever. It’s time to ditch the cables and go wireless. In this episode of Chalk Talk, Amelia Dalton chats with Mark Beecham of Silicon labs about the latest Bluetooth capabilities including lower power, higher bandwidth, mesh, and more, as well as solutions that will make adding Bluetooth to your next design a snap.

Click here for more information about Silicon Labs EFR32BG Blue Gecko Wireless SoCs