Array of I2C buses

Thread Starter

c.weaver

Joined Jun 19, 2018
9
Hi! I am new to FPGAs and I am working on a project that involves an array of I2C sensors. I need to record real-time data from all sensors at the exact same time. For now, I am just trying to plan and understand more about how I would do this with an FPGA. For an FPGA such as the LCMXO2 (https://www.digikey.com/en/products...tor-corporation/LCMXO2-4000HC-4BG332C/2785563) which has 274 I/O pins, am I able to allocate all 274 in pairs of 2 as a different I2C bus? Or is there a different limiting factor?

Thank you for any advice!
 

bogosort

Joined Sep 24, 2011
696
Hi! I am new to FPGAs and I am working on a project that involves an array of I2C sensors. I need to record real-time data from all sensors at the exact same time. For now, I am just trying to plan and understand more about how I would do this with an FPGA. For an FPGA such as the LCMXO2 (https://www.digikey.com/en/products...tor-corporation/LCMXO2-4000HC-4BG332C/2785563) which has 274 I/O pins, am I able to allocate all 274 in pairs of 2 as a different I2C bus? Or is there a different limiting factor?
I'm not familiar with that FPGA, but typically there are subsets of I/O that have varying electrical restrictions. The datasheet will be definitive. In any case, a separate bus for each device -- 274/2 =137 different I2C buses -- is most likely not what you want. That would require 137 different bus masters (implemented in the FPGA) and some way to coordinate them all.

A much more reasonable approach is to have one or two I2C buses with multiple devices on each bus. Many I2C sensors use a 7-bit addressing scheme, so potentially you could have up to 127 different sensors on a single I2C bus. Depending on the number of sensors and their input capacitance, you may need to run the bus at slower speeds to meet I2C's timing specs. The sensor's datasheet should have sections on addressing, capacitance, and bus speeds.

Stepping back a bit, have you thought about the overall architecture? It can help to think about how the data will flow. Since the sensors have an I2C interface, I take it that each sensor has its own ADC. Are the sensors continuously sampling or triggered? In either case, the notion of "exact same time" is not well defined, Is synchronous within a clock period sufficient? Most likely you will be reading the latest sensor sample from a register; where will you store this data (FIFOs?), how much processing needs to be done on it, and how will the processing affect the timing of the data collection? Does the data from each sensor have to be aggregated before it can be processed? What happens to the processed data?

Depending on the complexity of your project, you might consider using a SoC/SoM, which integrates an FPGA with a microprocessor. The FPGA would handle data collection/aggregation/DSP, while a high-level application running on the microprocessor takes care of orchestration, communication, long-term data storage, etc. You also gain all the comforts of having a full OS at your disposal, which makes it easy to network your project, set up a web-based configuration/diagnostics page, etc.
 

Deleted member 115935

Joined Dec 31, 1969
0
The point I see , is the requirement for "exactly the same time "

How exact needs to be defined ?

Typically , one would use off the shelf I2C / SMBus sensors.

Typically , as @bogosort highlighted,
I2C is a bus, each part is connected in series, and each device has an individual address,
The typical I2C sensor, such as the LM75 , can have one of 8 addresses.

Back to "instantaneous" ,
you can read 8 sensors in a few micro seconds,
is that fast enough ?

If so, you could simply have 16 controllers in the FPGA , and read all 127 temperatures in a few micro seconds,


BTW: This does sound like a classic interview question that I have seen bigger companies use to pre select interviewees,
is this what its for ?
if so good luck, get back to us as to how it goes,
 

Papabravo

Joined Feb 24, 2006
21,159
IMHO, trying to get that number of devices to take simultaneous readings is the height of folly. As has already been noted a definition of simultaneous would be most helpful in estimating the difficulty. As long as the sampling "strobe" is independent from the I2C bus you have a shot. I don't know of any I2C sensor devices that have this capability, but that really doesn't mean they don't exist. In the early days of the PLC, a 5 millisecond scan time was a practical definition of simultaneous. I have to believe that things have improved since then.
 

Thread Starter

c.weaver

Joined Jun 19, 2018
9
Thank you for your response! I think I may consider instead having only a couple of I2C buses. The overall idea, although rather simplistic, is to have an array of I2C sensors such as the SGP30 or CCS811 (perhaps 50+ sensors in an array) and take data from all of these over a period of time (2 seconds or so). Is this amount of sensor data possible with one bus? Each sensor will have its own ADC. I think I need to do more research about what the overall architecture may look like. The plan is to process this data externally from the FPGA. I simply need a way to offload the data to a computer.


I'm not familiar with that FPGA, but typically there are subsets of I/O that have varying electrical restrictions. The datasheet will be definitive. In any case, a separate bus for each device -- 274/2 =137 different I2C buses -- is most likely not what you want. That would require 137 different bus masters (implemented in the FPGA) and some way to coordinate them all.

A much more reasonable approach is to have one or two I2C buses with multiple devices on each bus. Many I2C sensors use a 7-bit addressing scheme, so potentially you could have up to 127 different sensors on a single I2C bus. Depending on the number of sensors and their input capacitance, you may need to run the bus at slower speeds to meet I2C's timing specs. The sensor's datasheet should have sections on addressing, capacitance, and bus speeds.

Stepping back a bit, have you thought about the overall architecture? It can help to think about how the data will flow. Since the sensors have an I2C interface, I take it that each sensor has its own ADC. Are the sensors continuously sampling or triggered? In either case, the notion of "exact same time" is not well defined, Is synchronous within a clock period sufficient? Most likely you will be reading the latest sensor sample from a register; where will you store this data (FIFOs?), how much processing needs to be done on it, and how will the processing affect the timing of the data collection? Does the data from each sensor have to be aggregated before it can be processed? What happens to the processed data?

Depending on the complexity of your project, you might consider using a SoC/SoM, which integrates an FPGA with a microprocessor. The FPGA would handle data collection/aggregation/DSP, while a high-level application running on the microprocessor takes care of orchestration, communication, long-term data storage, etc. You also gain all the comforts of having a full OS at your disposal, which makes it easy to network your project, set up a web-based configuration/diagnostics page, etc.
 

Thread Starter

c.weaver

Joined Jun 19, 2018
9
Thanks for your response! I am actually doing this for research for one of my professors. I think your idea to have 16 controllers is likely a better approach. In terms of data collection, what would you recommend to store the data and ultimately transfer that data to a computer to process?

The point I see , is the requirement for "exactly the same time "

How exact needs to be defined ?

Typically , one would use off the shelf I2C / SMBus sensors.

Typically , as @bogosort highlighted,
I2C is a bus, each part is connected in series, and each device has an individual address,
The typical I2C sensor, such as the LM75 , can have one of 8 addresses.

Back to "instantaneous" ,
you can read 8 sensors in a few micro seconds,
is that fast enough ?

If so, you could simply have 16 controllers in the FPGA , and read all 127 temperatures in a few micro seconds,


BTW: This does sound like a classic interview question that I have seen bigger companies use to pre select interviewees,
is this what its for ?
if so good luck, get back to us as to how it goes,
[/QUOTE
 
Last edited:

Thread Starter

c.weaver

Joined Jun 19, 2018
9
Do you mind explaining what you mean by an independent sampling "strobe"? I understand the idea of sampling each sensor one by one on a bus, but am a little confused.

IMHO, trying to get that number of devices to take simultaneous readings is the height of folly. As has already been noted a definition of simultaneous would be most helpful in estimating the difficulty. As long as the sampling "strobe" is independent from the I2C bus you have a shot. I don't know of any I2C sensor devices that have this capability, but that really doesn't mean they don't exist. In the early days of the PLC, a 5 millisecond scan time was a practical definition of simultaneous. I have to believe that things have improved since then.
 

bogosort

Joined Sep 24, 2011
696
The overall idea, although rather simplistic, is to have an array of I2C sensors such as the SGP30 or CCS811 (perhaps 50+ sensors in an array) and take data from all of these over a period of time (2 seconds or so). Is this amount of sensor data possible with one bus? Each sensor will have its own ADC. I think I need to do more research about what the overall architecture may look like. The plan is to process this data externally from the FPGA. I simply need a way to offload the data to a computer.
Note that the SGP30 has been obsoleted by its manufacturer ("not recommended for new designs"). It looks like the sensor's max sampling rate is 1 s, so in 2 seconds you'd get two samples of data from each sensor. If this is typical for this type of sensor, you could probably do this much more simply on an Arduino, Teensy, or equivalent.
 

Papabravo

Joined Feb 24, 2006
21,159
Do you mind explaining what you mean by an independent sampling "strobe"? I understand the idea of sampling each sensor one by one on a bus, but am a little confused.
The idea behind a "stobe" is having a method that is independent of any I2C bus activity that says to the system "sample now". All sensors will take a sample within some small time delta from the edge of the "strobe". Then at it's leisure, the primary controller can read out the data from each I2C device. The key point is that you cannot use the I2C bus to say "strobe" or "sample now". Compare this with DeviceNet which does have such a concept.
 

Deleted member 115935

Joined Dec 31, 1969
0
Reading the above,
I would interject that temperatures tend to change relatively slowly inn terms of electronics speed,
fast temperature change is 10s of ms.

This I think has been alluded to by the OP, as they are now looking at bus's of 16 sensors.

There are a few things to consider in your solution.

Bus length, I2C buses can suffer large capacitance with the use of long wires,
resulting in un reliable transfers.

There are I2C buffers to account for that,

On the other hand, having a single I2C controller has its advantage ,
you then use an external multiplexor as highlighted by @bogosort

There are also chips such as this
https://www.analog.com/en/products/ltc4317.html
That allow an I2C bus address to be "translated" on fly
for instance the master could talk to "address 4C" , but on the bus that wold go out ass "address 7E"

There are also I2C buffers and length extenders on the same site.

Re sensor,
I'd strongly suggest a standard part, such as the LM75 if practical.


One last thing,

There is another format of link that might be of interest
Onewire,

Yep it needs one wire shared power and data and an earth.

such as

https://datasheets.maximintegrated.com/en/ds/DS18B20.pdf

also available as FPGA cores, such as

https://www.maximintegrated.com/en/design/technical-documents/app-notes/1/119.html

You can have an almost unlimited number of onewire chips on a single bus .

just a thought
 

n3rdx

Joined Jan 29, 2021
5
Hi! I am new to FPGAs and I am working on a project that involves an array of I2C sensors. I need to record real-time data from all sensors at the exact same time.
I will defer to more experienced FGPA developers, as I am only a medium experienced engineer, if I am wrong in any of the following.

To the OP: I think you may be able to take advantage of the following observations (easy to miss, and often used, but until you do it, you won't learn it's possible):
  • I2C communication can be done, with appropriate bit-banging code support, on any pair of digital I/O lines. I repeat, ANY PAIR of digital I/O lines. Reference: Bit Banging I2C by Hand and a bit-banging code sample (you may have to search for bit-banging code that fits your development environment, if this doesn't match, but if you are a decent programmer, you can follow the code example shown)
  • Using the bit-banging method, if you wanted to use many N (N = tens or hundreds of pins from an FPGA device) you could poll/interrogate/program N/2 number of I2C devices) all referenced to any number of internal clocks (that you control from the the FPGA code).
  • So a possible low-complexity answer to your question : Obtain an FPGA board or select a FPGA device that has a huge number of GPIO pins, and then layout the schematic such that each I2C sensor has its own FPGA-I2C matched pair pins (same length, same route, same voltage, same polarity, etc.)
  • Thought for the day, if each sensor has individual I2C lines, you could program some of the clocks that drive the individual I2C devices on that particular bus to communicate at different frequencies and thus allow for the possibility of coarsely synchronizing the query/arrival of the individual sensor data cycle at the FGPA core. This would allow banks of sensors to report in a particular cadence (sequence) or trigger internal functions based upon certain events if you are doing some sort of non-circular array.
  • The above is not useful if you chain I2C devices to a common bus as the Nth I2C device will have different timing parameters than the N-1th I2C device and so forth with the same clock.
  • I realize your overall design goals could be different, but it should be easy to define in a Vivado type tool and then run Simulation to see what happens with probes.
 

n3rdx

Joined Jan 29, 2021
5
and thus allow for the possibility of coarsely synchronizing the query/arrival of the individual sensor data cycle at the FGPA core
And for the fine synchronization, I would suggest you specify the timing correction factors for each individual I2C bus to your FPGA IP Core location (within the FPGA device itself) using the FPGA timing constraints file. That will cause the synthesis/implementation/place algorithms to attempt to reroute the device-internal pathways for each individual I2C bus so that they pass timing constraints, and ensure the data sought arrives at the IP Core within the acceptable timing error window. At least, that is what I think is possible - not having done it myself, but I do want to do it now that I have thought about it.
 
Top