Multiplexing a Large Number of Digital Signals

[Renate]

You say 230 ksps, but that still doesn't tell everything.
Maybe your application is a dead cow falling though a set of laser beams.
You may need a time resolution of 4 µS but you don't need to stream the data at 230 ksps.

Also, what is the geometry of this? How far apart are the sensors? Are they in groups?

[Poorly Calculated]

Also, what is the geometry of this? How far apart are the sensors? Are they in groups?

Rectangular geometry, they are roughly a meter apart, and each laser/sensor pair operates independently of each other.

[Renate]

You're not giving us any hints to how/what this thing is.
There is a big difference between various scenarios that would affect how you implement this.

Possibility #1
This is used for discrete tests that take about one second.
Something happens and each of the 150 sensors is broken once.

Possibility #2
This is used for continuous monitoring over the course of a month.
There is much activity and each sensor will get broken 1000 times a second.

Also what is the longest distance from the central measuring point to the farthest sensor?

[Nominal Animal]

11 of the 74HC4067, a 16 way analogue multiplexer, could enable up to 160 channels to be read by a microcontroller with a single ADC input and eight output pins.

Or ten of 74HC4067, if your FPGA has 16 ADCs (or signal inputs), and shares four address pins among all 74HC4067.
Then, it'd take 16 sample cycles (switching the mux address at each step) to sample all 160 inputs.

I like the look of those 74HC4067's.

[BrianHG]

A laser diode pointed at a photodiode is going to be a make or break condition.  There will be no in between, no need for analog.  Even at 100 feet.

[Nominal Animal]

Unless you use the information for self-testing and calibration, essentially a programmable comparator with a self-test/signal analysis mode, true.

Let's look at ATtiny404 in SOIC16, which at Mouser costs about 0.40€ apiece.  It has SPI slave capability at up to 5 MHz clock, and enough pins for 8-bit parallel input.  The sampling is synchronized so that all input channels are sampled at the sample SPI clock, every 8 SPI clock cycles.
So, let's say you have 20 of those.  The FPGA then needs one SPI clock output, and 20 inputs.  You can then theoretically sample at 5/8 MHz or 625 kS/second (one set of 8 samples per 32 clock cycles – doable, since most AVR instructions take one cycle to execute).

On the ATtiny404, the input pins would be PA4-PA7 and PB0-PB3, so a sample cycle consists of two GPIO port byte reads, two ANDIs (AND with immediate), and one OR; and a write to the SPI output register; or six cycles or so.  In Master mode (so the FPGA would need to handle 40 input data and 40 input clock lines), the maximum SPI clock is 10 MHz, so the sample rate could reach 1.25 MHz, or 16 clock cycles per sample byte.  It should be doable, although might need a tight assembly loop with all interrupts except start/stop signal line disabled for a continuous sampling run.

If OP needs only 250 kS/second, that's a data rate of 40 Mbits/s; quite doable.  (Even a simple USB test on Teensy 4.0 can do 200 Mbits/s; much more if one uses USB bulk transfers instead of the tty layer.  With Teensies, the problem is getting the 160 digital inputs read in time – maybe if one used a bunch of 74HC4067's with all sharing the four address/selector bits?)