339 karma · joined November 26, 2012
There's some pretty interesting rational behind the creation of those kinds of munition (including the "nuclear rifle") but their argument seems to boil down to 2 things: 1, at the time where the USSR and the Western European states were still living with a divided germany US assessments found that the number of troops we could collectively muster were vastly less than the current standing european force of the USSR. People were very worried there wouldn't be much we could do if a land invasion overran the troops other than immediately retaliate with a full nuclear strike against soviet cities. These were though of as a weird middle ground
2. The Army was getting worried it would be cut out of money and relevance as more and more focus was moved to the Air Force because most weapons at the time were delivered by planes under the control of the strategic air command. They became ever more worried later as submarine launched missiles gave more nuclear firepower to the navy. Afraid they'd be totally left out the Army started requesting hundreds of thousands of "tactical" weapons like nuclear landmines, nuclear man launched missiles, nuclear artillery shells etc.
Study controlling for type of crime and circumstances finds ~10% more severe punishment for crimes black to white: http://papers.ssrn.com/sol3/papers.cfm?abstract_id=1985377
Evidence that despite approximately equal occurrences of consumption of narcotics black citizens are arrested much more frequently than white citizens: https://www.washingtonpost.com/news/wonk/wp/2013/06/04/the-b...
http://www.vaildaily.com/article/20101104/NEWS/101109939 A hedge fund manager had his criminal charges substantially reduced over the victim's objections because having a felony would mean the hedge fund manager would have to admit what he did to his clients. The defendant in question struck a bicyclist in a hit and run, drove far away and called for roadside assistance for his car never mentioning anything about the bicyclist he left with lifelong injuries. Of course the excuse is that after he was caught he agree to pay some restitution to the victim...
Anyway, just a crazy story that I figured I'd share so not really a study of real national trends or anything.
There are a lot more "news" esk hardware design places as well but I'm assuming you're looking closer to stack overflow/github of HDL rather than the slashdot/reddit of HDL?
If you want HDL best practices any of the resources you can get your hands on from http://www.sutherland-hdl.com/papers.html <-- those folks are excellent
and I would highly recommend this book: http://www.amazon.com/SystemVerilog-Verification-Learning-Te...
The strange looking curve is really kind of two parts forward biasing/reverse biasing. Assuming you're starting from a virgin device you move along the curve where you're sweeping the voltage upwards but not really getting much increase in current (since there's no real channel yet). In these materials the mechanism is the establishment of little "fingers" of metal migrating and completing the circuit. As the "fingers" move forward you suddenly start seeing more and more current without increasing voltage (your effective resistance is dropping) and then jumps up as the connection is made. Eventually you sweep the voltage backwards. Something similar happens in the part of the AC curve in reverse.
There is a really good diagram in this paper: "Mechanism for resistive switching in chalcogenide-based electrochemical metallization memory cells" from Zhuge et al http://scitation.aip.org/content/aip/journal/adva/5/5/10.106...
arrays in lucid = system verilog arrays
"fsm" = basically system verilog enums and a little helper logic
"connectors" = system verilog interfacesIts definitely better to go where the tool support is. With system verilog you get a lot of nice verification: constrained randomization, built in process synchronization, support for differentiated test bench vs dut, assertions, complex coverage metrics.
The grad student I think you're talking about is (now) Dr. Carl Sechen who developed an Auto Place and Route tool he named Timberwolf. Those tools don't synthesize logic so much as they choose optimal locations and orientations for the standard cells on the wafer and then attempt to route the metal interconnects (all with respect to timing). I think it wound up being rather buggy (to the point they had to keep calling him back from school work to patch some things up) and a fair number of things had to be corrected by hand.
I did hear that some of the units on the 386 were written in some Stanford devised programming language from the pre Verilog/VHDL toolstack days and that a few engineers in design automate hacked up a tool flow to turn that programming language into something synthesizable.
That said I wasn't there and so I can't claim to know for sure. I would wager there are some good interviews and documents either with the Intel Museum folks or the Computer History Museum in Mountain View (which seems to always have both contacts from the day and documents for all the old fun computing hardware).
http://www.itrs.net/Links/2013ITRS/Summary2013.htm
The papers themselves as well as the models are all very interesting if a bit occasionally dry.
You'd actually be surprised about how much effort goes into hardening things against attacks like those these days (timing attacks, differential power analysis etc). There's a lot of interesting work around on the best ways of mitigating those risks.
There are alternatives for super high speed interconnects within a data center though (think infiniband and cousins) or high bandwidth options for longer distances (like fiber) etc.
I think perhaps we might not be starting programming with computers directly all the time, but perhaps there will always be some object that younger folks will learn to program. Heck maybe the next kids will decide to program phones or connected home appliances or something.
What you're not getting when you hack your hardware to perform outside its bounds is the guarantee from the company. For example if you're sold a processor for $X dollars clocked at 2 GHz you're receiving an implicit guarantee that for Y years the product will be capable of performing every advertised combination of operations correctly. If you have a problem with this processor it is then reasonable for you to seek support for your problem/design etc. If you notice you can run this processor at 2.5GHz which would normally cost more money and for your application nothing appears to glitch you're welcome to do so. If you later encounter issues with occasional incorrect calculations you pretty much gave up the right to complain about that issue.
A similar example might be bolts for spacecraft. Many of the bolts for these spacecraft cost 100x more than the incredibly similar bolts one could obtain at a hardware store and often times may come from a very similar production line. The reason the spacecraft bolts cost more is because they've specified a very rigid set of minimum tolerances they require and stringent tracking requirements (if a bolt fails on one part of a spacecraft you may be able to get a list of every other bolt made in that lot, get the reference samples to test and find every individual location they were placed on that and other craft). It's not necessarily that the bolts cost substantially more to make but they do cost somewhat more to verify or select each piece from the line to meet the requirements. Even though hardware store customers might be able to buy bolts with spacecraft quality performance they just didn't pay to ALWAYS get bolts with spacecraft quality performance.
That said being a hardware person I'm not sure I feel the same way about software as many of the people here. It sort of feels like the primary argument is "hardware modification feels hard to me so its different". To me it seems like where it would be acceptable to modify a piece of hardware I own I should be able to open a debugger or disassembler and patch my software to enable any feature that's inherently part of the product (or new features if I wanted to add them). Now if that breaks updates, causes me to lose work or leads to problems I'd expect to be on my own like I would with hardware.
I'm sure my opinion isn't particularly popular, but changing a resistor and changing an if( premium ) to if( true ) just really don't seem all that different from where I am.
It's certainly doable to reverse engineer out a cryptographic key from a chip, but most of the people who could afford to do this wouldn't really need to do so. Secure elements are typically substantially more protected than standard logic. The structures can be designed in a manner to be very difficult to access without damaging them rendering them unreadable.
Such a cryptographic key would likely be scattered in pieces around the chip, delivered through winding busses below enough critical logic connections and power rails so that the chip wouldn't be as vulnerable to a focused ion beam attack or infrared analysis. This makes it difficult to observe without destroying enough of the chip that live examination would not be possible. There are also tricks that would be used to mitigate the risk of differential power attacks etc.
The bigger threats to secure elements are sloppy design with DFT/DFM (Design For Test) features. Most complex chips have at a minimum a mechanism of connecting a large number of the designs flops to what's like a huge shift register. If you knew enough of the design you could try to locate the output of a block which has access to the secure value, scan in a vector that makes it easy to recover the value (e.g. an XOR element you can force to XOR with 0's) and scan it out.
There are also other DFT feature like on-die logic analyzers, micro-breakpoint engines, code signing overrides etc. Virtually all of these features are physically disabled prior to volume manufacturing. If a company was sloppy this could expose things that shouldn't be exposed.
There are other attacks as well though. If you could compromise the signing keys for the microcode delivered to a processor like a modern x86 processor you could change the behavior of instructions. With custom microcode you could catch and override basically any instruction (for example you could change where a LOAD instruction stores data or make ADD do jmp etc). You could definitely use something like that in a malicious manner.
After you get the images of the metal layers (you likely can't do this optically for things down near Metal1) you can image the poly and diffusions. You can probably guess which transistors are which based on which power rails they would have been connected to.
Things might be easier if you know what standard cell library the designers used when laying out the chip, as then you'd more easily be able to identify the base logical functions faster.
If you're being thorough you'd also have to make sure you obtain measurements of the widths of each of the transistors (so you can later figure out the relative drive strength which matters for things like identifying keeper circuits or more precision analog elements etc).
Determining some transistor behavior make require even more complicated tests to identify doping levels and if you were trying to duplicate the process you'd have to identify a large number of other materials (for example if they use copper you'd want to find what chemical they used to control the diffusion etc).
It's pretty interesting stuff though.
Honestly, when I'm debugging hardware where I have the high level specifications, the microarchitecture spec and the system verilog files that implemented the design it's still kind of a pain to trace things.
The other downside of having all the signals is that little things can be unintentionally misleading. As an example I was working with coworker trying to trace a memory transaction through some complicated logic blocks and there was a point we originally missed where the bottom few bits of an address aren't necessary for the hardware. Later after this point the bottom bits were reused to communicate transaction properties along with the significant address bits. There was a bit of confusion about why we were reading a "bad address" before we realized what happened.
I've been trying to plug Mathematica into my workflow in place of a number of tools I'm more familiar with and I keep running into issues where I either try to do things in a very un-Mathematica way or the default behaviors I assume of the program are wildly incorrect (e.g. Thread operates in the reverse order I would expect, importing an extracting a column from a csv file seems clunky, wrote up a worksheet with a number of E variables with subscripts only to find out its treated like Exp[], etc.)
There seems to be a wonderfully large amount of available training and tutorials all over the web but I don't know where to start to most effectively acclimate to Mathematica.
What I believe this book provides that CLRS does not is a series of succinct descriptions of common algorithms AND brief explanations of where you would most likely find those algorithms to be near optimal solutions.
Skiena's book does not provide a detailed theoretical analysis of each algorithm like CLRS does, nor does it include particularly exotic data structures and algorithms you'd find in journal papers. What Skiena does provide along with each algorithm is a series of references which do provide a lot of this additional background information that you could independently find if you need a more detailed look at a topic.
As a bonus the book also includes a series of "War Stories" describing how some of the algorithms solved specific real world problems. They're an amusing break from the rest of the book if you're trying to read it cover to cover rather than just as a reference.