Yeah, there are lots of interesting applications of getting other vehicles or traffic signals to favor you by sending wrong data!
There are a bunch of references to "Security Credentials Management System providers" in the DOT document. So it sounds like there will be some attempt to reject self-serving incorrect data, and even a mechanism to report and exclude "misbehaving" devices. But there are lots of gray areas and value judgements in what's allowed to be sent.
The message types are interesting to read (second link below). I thought at first that the Red Light Violation Warning was a message where your own vehicle sends out "Hey, we're blowing this red light, everybody watch out!" But I think that one is intended to be sent by the traffic signal system. But still, if you aren't in control of what your vehicle sends, what's to stop it from broadcasting data you don't want it to send, like "Hey, we're exceeding the speed limit by 17 mph"? Another value judgement that seems like it would be made at some regulatory level. Even if the messages are completely anonymous as claimed, you probably (at a personal level) don't receivers to clue in traffic police to show up further along your route, or have insurance companies try to match those with private roadside license plate reader data. At a societal level I'm sure some people would favor that, and others wouldn't.
> I need to take expressions, or programs, and break them down to a directed acyclic graph of binary logical operations.
This strikes me as not quite a correct description of the problem. What you described in that sentence above is closer to a description of compiling a combinational subset (just expressions, no state) of a hardware description language to logic gates.
The BitGrid has two differences from that. One, you have state registers after every cell: essentially it's pipelined at the single-cell level. Two, the routing of signals is fixed to be able to reach nearest-neighbors only. That means you end up needing to spend logic cells for routing and incur a one cycle delay for every hop away that you need to reach (whereas that's essentially "free" in gates).
Those make the problem significantly more complicated because you're not just mapping a function on to logic, but needing to do routing and a kind of delay analysis ("which cycle is this input signal from?) at the same time.
My suggestion would be to simplify the problem first. For example, allow routing any cell's input to any cell's output in the first stage of complication, then do a phase where you insert the routing.
To me, the level of pipelining and nearest-neighbor restriction makes it hard to approach the problem: the seeming simplicity ends up making it hard to wrap your mind around a larger computation. The routing is nontrivial; using cells for plain routing wastes logic resources; and the one-cycle delays become a complex problem to be worked around instead of a feature. It's interesting to think about but if it were my project, I'd think about changes to the model first to make life simpler.
I understand how adding delays at every step seems like a really bad idea, especially when coming from a world of FPGAs and trying to squeeze out every nanosecond of latency.
What you get in trade, is an architecture that doesn't have any fiddly timing issues. You also get something that is inherently pipelined. So, in theory, you could shove data in one side of the fabric at the full clock rate, and get results out the other side at that same rate. I assume that it should be feasible to run a BitGrid at 1 Ghz, which means that if it's big enough, you could run real time FFTs, signal processing, etc... sure the latency sucks, but the throughput is enormous.
I understand that wasting gates, instead of having dedicated routing hardware also seems like a horrible idea.
What you get in trade, is freedom from the routing issues that always arise when you have a lumpy fabric with special functions in fixed locations. In theory (as all I have right now is theory), it should be trivial to move a whole section of the flow graph over 1 cell, or rotate, flip the flow, etc. Routing around a bad cell is going to incur a small penalty, perhaps as low as 1 full clock cycle in most cases.
If you have working software that gives orders of magnitude improvements, needing $100k worth of hardware would be no barrier at all. That's a fraction of just the EDA software license budget for many projects.
> In about 25% of [study patients] their lung cancer had already spread to the brain when the study began.
and
> “Lorlatinib is the only ALK TKI that has reported five-year progression-free survival, and even after this time, the majority of patients continue to have their disease controlled, including control of disease in the brain.”
Yes, it's much easier to buy ahead of time in the app and have it automatically activate upon arrival, instead of having to find a kiosk in the airport.
I've used the Airalo app to buy data-only eSims in multiple regions, and they have global ones also. I would guess it's not as cheap as you'd get if you waited to buy from local providers in arrival, but it's very convenient.
Yeah, I found the Conventions section baffling. It defines both "giga" and "gibi" as 2^30! Why define both if they have the same value? Then it confuses the issue further by using "gibi" when the underlying unit is bytes, and "giga" when it is bits, which, given those definitions, doesn't convey any difference in meaning.
I think you are a little optimistic that the full EDA flow would be "not... particularly difficult to write." On the implementation side alone, you'd need to write a SystemVerilog compiler, logic synthesis, timing analysis, timing optimization, power analysis, clock gating, coarse placement, global routing, detailed routing, placement legalization, physical design planning, clock tree synthesis, design rule checking, lots more underlying technology to make it work, and lots of steps I'm not remembering. Every one of those sub-areas is it's own specialty. Then you can start thinking about verification.
Cable cars are a poor and misleading analogy for interoperability -- that is truly a difficult, one of a kind system, with significant mechanical and switching limitations that don't apply to streetcar systems.
As for dangerous? During the multi-decade period in question, your link lists two accidents in the US. One is the crash of a gasoline tanker that also destroyed five buildings, which I don't think we can lay at the feet of the streetcar itself.
By the 1920s, the tracks for many streetcars and interurbans were already being dismantled because there was no perceived utility to them - even for future rail systems. Very few of them would have been capable of even supporting the weight of a PCC streetcar.
As for the danger, besides the well-publicized disasters, fatalities and accidents involving trolleys was a very well perceived danger of the time:
There are a bunch of references to "Security Credentials Management System providers" in the DOT document. So it sounds like there will be some attempt to reject self-serving incorrect data, and even a mechanism to report and exclude "misbehaving" devices. But there are lots of gray areas and value judgements in what's allowed to be sent.
The message types are interesting to read (second link below). I thought at first that the Red Light Violation Warning was a message where your own vehicle sends out "Hey, we're blowing this red light, everybody watch out!" But I think that one is intended to be sent by the traffic signal system. But still, if you aren't in control of what your vehicle sends, what's to stop it from broadcasting data you don't want it to send, like "Hey, we're exceeding the speed limit by 17 mph"? Another value judgement that seems like it would be made at some regulatory level. Even if the messages are completely anonymous as claimed, you probably (at a personal level) don't receivers to clue in traffic police to show up further along your route, or have insurance companies try to match those with private roadside license plate reader data. At a societal level I'm sure some people would favor that, and others wouldn't.
https://www.its.dot.gov/resources/scms.htm
https://www.its.dot.gov/research_areas/cybersecurity/scms/SC...