Speck with signed math I find myself implementing Speck in an industrial controller that only does signed math. 

What cryptographic ramifications would there be if the Speck algorithm was implemented using signed math?
There are a number of things to watch due to signed arithmetic:


If the hardware was not using 2's complement arithmetic (representing range $[-2^{k-1},2^{k-1})$ on a $k$-bit word, with negative integer $x$ represented as $x+2^k$ is in binary), then it would be difficult to use the full word width $k$. It would then likely be a better idea to keep everything non-negative and less than $2^{k-2}$.
That is easy for Speck-$n$ (where $n$ is the block width) when $k\ge n/2-2$. E.g. for Speck-32, $k\ge18$ allows to compute $(x+y)\bmod 2^{16}$, as required, using (x+y)&amp;0xFFFF, without depending on the representation of negative numbers.
Or, another option is using multiple-word arithmetic. That's what a compiler does on an 8-bit CPU to implement wider arithmetic types, and how large integers are usually implemented in asymmetric cryptography. It reduces speed and increases code size by a factor like 3 when going from one to two native words, thus is best avoided.
Fortunately, 2's complement arithmetic is common. That would make Speck-$n$ with $k=n/2$ feasible without multiple-word arithmetic, baring the next issue.
Some industrial controllers detect overflow (e.g. when $2^{k-2}+2^{k-2}$ is attempted). When using words to their full width, overflow will occur often, and its detection should be disabled. An alternative is to avoid overflow by keeping everything non-negative and less than $2^{k-2}$ as above.
Speck requires rotation by constants, often implemented with a combination of left and right shift followed by bitwise OR, e.g. For Speck-32 (x&gt;&gt;13)|(x&lt;&lt;3). Right shift by $b$ positions on signed variables sometime replicates the sign bit $b$ times rather than introduce $b$ zero bits. That would require extra masking, e.g. ((x&gt;&gt;13)&amp;7)|(x&lt;&lt;3). With $k&gt;16$ make that ((x&gt;&gt;13)&amp;7)|((x&amp;7)&lt;&lt;3) when needing to avoid negatives and overflow.


To watch also, but not directly related to signed arithmetic:


Speck is a block cipher, thus needs an operating mode to become a cipher, and for more than a single use a True Random Number Generator to generate its IV (or at least persistent storage for a counter), before it can be used to encrypt arbitrary data.
Most of the time, when encryption is thought, integrity/proof of origin is functionally needed also (sometime, only). That's authenticated encryption, and while it can be implemented with a block cipher, there are a few catches.
Industrial controllers need to be reliable, not fast. Speed might be an issue, especially if multiple-word arithmetic has to be used due to signed arithmetic. 
For security, the implementation should have execution time independent of data if an adversary can time execution (which should be the default assumption), and a number of things (like overflow detection, and more) could introduce timing dependencies.
Industrial controllers are usually not designed to keep secret the data they manipulate; I've met one (emulating relay logic) that blinked a led according to the state of its (one-bit wide) data register! And there could be much more subtle side-channels.