It's most likely heat related

I'm of the opinion that this is "too bad so sad" for Google, they had their opportunity to bid for the patents but didn't want to shell out for them. The billions of dollars in proceeds generated from that bid allowed my father to recoup some of his pension that he lost when Nortel collapsed. They didn't buy Nortel as a whole, they just purchased some of the IP that was auctioned off.

wrong architecture.

Cost sensitive embedded systems use ARM based microprocessors to which this is not applicable.

I used to have pet rats. Rats will eat anything

That's only when the AVX2 and FMA instructions are used. I do not know of any JS engines that vectorize code to allow the use of vector extensions. Most of them just make use of the basic scalar FP instructions or even use old x87 code.

Ideal virtual machines are indistinguishable from networked servers. Most x86 VMMs don't quite reach this level of isolation, but the VMMs used on IBM's PowerPC based servers and mainframes do.

From the perspective of system security, a single compromised application risks exposing to an attacker data used by other applications which would normally be outside of the scope of the compromised application. Most of these issues can be addressed through some simple best practices such as proper use of chroot and user restrictions, but those do not scale well and do not address usability concerns. A good example is the shared hosting that grew dominant in the early 2000s while x86 virtualization was still in its infancy. It was common to see web servers with dozens if not hundreds of amateur websites running on them at once. For performance reasons a web server would have read access to all of the web data; a vulnerability in one website allowing arbitrary script execution would allow an attacker to read data belonging to other websites on the same server.

From the perspective of users, a system designed to run 100 applications from 20 different working groups does not provide a lot of room for rapid reconfiguration. Shared resource conflicts, version conflicts, permissions, mounts, network access, etc... it gets extremely messy extremely quickly. Addressing this requires a lot of administrative overhead and every additional person that is given root privileges is an additional person that can bring the entire system down.

Virtual machines on the other hand give every user their own playground, including full administrative privileges, in which they can screw around with to their hearts content without the possibility of screwing up anything else or compromising anything that is not a part of their environment. Everyone gets to be a god in their own little sandbox.

Now, that doesn't mean that the entire operating system needs to be duplicated for every single application. Certain elements such as the kernel and drivers can be factored out and applied to all environments. Solaris provides OS level virtualization in which a single kernel can manage multiple fully independent "zones" for a great deal of reduced overhead. Linux Containers is a very similar approach that has garnered some recent attention.

Take a look at the image at the following link

http://www.anandtech.com/show/6355/intels-haswell-architecture/8

That's the backend of the Haswell microarchitecture. Note that 4 of the 8 execution ports have integer ALUs on them, allowing for up to 4 scalar integer operations to begin execution every cycle (including multiplication). Two of these are on the same port as vector integer unit, which can be exploited for an obnoxious amount of integer math to be performed at once. There are only two scalar FP units, one for multiplication on port-0 and one for addition on port-1.

The same FP hardware is used to perform scalar, vector, and fused FP operations, but taking advantage of this requires a compiler that is smart enough to exploit those instructions in the presence of a Haswell microprocessor only and fast enough to do it quickly. Exploiting multiple identical execution units in a dynamically scheduled machine requires no extra effort on behalf of the compiler.

Microprocessors used in PCs have always been very integer heavy for practical reasons (they're just not needed for most applications), and mobile devices are even more integer heavy for power consumption reasons.

Using FP64 for all data types is obnoxiously lazy and it makes me want to strangle front end developers.

Yeah that's where I found many answers to my questions. There's no easy way to look through it and few if any solutions are catalogued or included in the wiki. Sometime over the Christmas holidays I will write a more comprehensive guide.

Altera's reference Cyclone V SX Series development kit is $1600. This includes the subscription edition of Altera's SoCEDS suite which allows for bare metal debugging over JTAG.

The SoCKit is only $300. The hardware is (nearly) identical and it is designed to be compatible with Altera's reference design at both the harware and software level. It does not come with the subscription edition of Altera's SoCEDS so users are limited to either the 30 day trial or a free licence which supports only gdb over IP for application debugging (thus restricting it to linux only).

I love the PMOD connectors on the Zed. I purchased the analog essentials kit from Maxim to play around with. The documentation and reference designs are pretty good.

The on-chip memory on the Xilinx HPS is larger (256KiB) than Altera's (64KiB) but the Altera Cyclone V S and Arria V S chips have hard memory controllers on both the HPS and FPGA side (1 on the Cyclone V FPGA, 3 on the Arria V FPGA). This is why the ZedBoard has only 512MiB of DDR3 attached to only the HPS, while the SoCKit has 2GiB of DDR3 with 1GiB attached to each of the HPS and FPGA. This allows for 2x to 4x the DDR3 bandwidth with only marginal cost in soft logic.

Both chips use AXI bridges to connect the HPS and the FPGA together, but it seems like there are some minor differences in the way that they are configured; I haven't done enough work on this aspect yet though to make a judgement call.

I'm not at all trashing the Zynq chips. Xilinx and Altera are both terrific companies.

I haven't found any hardware errata yet, just a truckload of missing, poorly written, or conflicting documentation. I'll provide you with a rough workflow that I've followed to get started. Feel free to ask me any questions.

Step1: Grab the Arrow lab material from the following link and work through them on Quartus 13.1. They're written for Quartus 13.0sp1 but they can be followed on Quartus 13.1 without issue. The only additional step is upgrading the IP cores from those packaged with 13.0sp1 to those packaged with 13.1; this will be done automatically when the sopc is opened in Qsys

http://www.arrownac.com/solutions/sockit/files/SoCKIT_Materials.zip

Working through the hardware side will get you a usable sof file to program the FPGA. Working through the software side will get you a usable preloader. Although the SoCKit is heavily based off of Altera's reference development kit (GHRD) the preloader is different in large part due to slightly different SDRAM specifications. Attempting to use the preloader included in Altera's SoCEDS will not work.

The programming stage of the documentation is a bit flawed. The reference configuration assumes a single JTAG device, but there can be more. At a minimum there will be one for the HPS, but a bank of two dipswitches on the board can enable JTAG for the HPS itself and any devices connected via HSMC. Just use autodetect to pick up all JTAG devices and program the SOF file to the FPGA device, it's very clear as to which is which.

Next, grab the github repositories for the linux-socfpga (kernel), poky-socfpga (base filesystem), and u-boot-socfpga (bootloader). Grab the latest version tagged with '-rel'. I used the following:

kernel: socfpga-3.9-rel

u-boot: socfpga_v2013.01.01-rel

poky: danny-altera-rel

The wiki on rocketboards can be followed to install the dependencies and begin compilation. I can verify that everything builds nicely on CentOS 6.5 without much fuss, Ubuntu is extremely problematic so I would avoid it.

If you look at the SD Card image that ships with the SoCKit you'll notice that it has a FAT filesystem with two files on it, socfpga.dtb and uImage. These are the device-tree-blob, and linux-kernel-image respectively. The kernel is in a u-boot image format, which is simply a zImage with an additional header. The bootloader that ships with Terasic's SD card image uses an early 2012 version of u-boot and does not support booting directly from a zImage. Support for this (bootz command) is present in the 2013.01.01 release of u-boot so it is no longer necessary to attach the additional header to the kernel image. Just configure and compile the kernel as a zImage as they do in the wiki.

An additional step is missing in the wiki (at least it was last time I looked). The dtb is tightly coupled to the kernel version. Using a dtb from the terasic reference SD image will work for kernel version 3.7, but it will not work for kernel 3.9 or above. The reference one created by Altera's sopc2dts tool is crap and won't work either. However, a working dtb has been included in the linux-socfpga tree under arch/arm/boot/dts/socfpga_cyclone5.dts. This can be compiled to a dtb either through the dtc tool itself, or in-situ by running 'make ARCH=arm dtbs'. This is good enough to get started with, but if you add additional memory mapped devices to your system you will have to modify it by hand and recompile it.

NOTE: the socfpga_cyclone5.dts file exists in the 3.9-rel tree, but has been replaced and expanded in master by one specifically tailored towards the SoCKit. I haven't looked at this yet, it's on my todo list. You may wish to check it out.

OTHER NOTE:The bootloader will look for socfpga.dtb by default. You can change the name of the file that it looks for by tweaking the bootloader environment settings (this is good practice) or you can change the name of the file when you copy it to the filesystem.

Expand the compiled root file system tarball into a folder called rootfs. You must do this using sudo. It seems like a needless step.

Gather the compiled u-boot.img, zImage, socfpga.dtb, preloader, and rootfs directory together and run the tool to make the SD card image. Write the SD card image to an a SD card, insert, and powerup. Open a serial terminal at 112500 baud (57600 for older versions of u-boot) and watch the boot process. Hit the soft reset key to start the process over.

OTHER OTHER NOTE: This is mentioned in the documentation, but deserves mentioning anyway. If the system is configured to boot via Active Serial 4x it will load the FPGA image from the EPCQ256 which due to a bad default image will prevent the HPS from initializing. Supposedly this can be fixed by overwriting the EPCQ256, but the best way is to actually program the FPGA from a file stored on the SD card. This can be done through u-boot directly but I haven't figured out how yet (yay documentation...)

That should be enough to get you started. If you see no output or it hangs before u-boot has loaded, then the preloader is incorrectly packaged or misconfigured. Make sure that you didn't skip any steps in the tutorial.

If you get to the u-boot command prompt (interrupt the autoload) then your preloader is fine.

The next step is to load the kernel. just type 'bootz' (or let it autoboot) and watch the magic. If it says "Bad zImage Magic!" then there the dtb file is not correctly compiled. If it loads but hangs before running init then the dtb is compiled but not compatible with the kernel. Attempting to use a 3.7 dtb with the 3.9 kernel will at the very least result in the MMC failing to respond. u-boot can read it, and can thus load the kernel into memory, but the kernel itself cannot read it.

I hope that this helped a bit!

I have both the Zedboard and the SoCKit

The SoCKit is definitely the beefier of the two, as the Altera Cyclone V SX series FPGAs are far more powerful than their Zynq-7000 series counterparts.

However, the SoCKit has the most obnoxiously bad documentation that I've ever seen. The reference material from Arrow is extremely thin yet somehow still manages to have spelling mistakes in it that would prevent it from functioning if certain functions were enabled. Terasic's material "works" but Terasic does not include any documentation on the HPS whatsoever, just a prebuilt image and some C code to go with it.

I've spent the better part of the past 3 weeks just figuring everything out on my own. Altera's documentation is rock solid, but that only covers the FPGA itself, not the peripherals. Today was spent figuring out how the various clock sources are connected to the FPGA. Despite offering the exact same board in the exact same configuration, Arrow and Terasic provide conflicting and equally useless documentation. Sometime in the next couple of days I'm going to go probing at it with my scope.

The silver lining though is that I've been documenting that I've done, so I should be able to compile a very comprehensive and updated getting started guide in the near future. The ones on the RocketBoards wiki just don't cut it.

The Zedboard is accompanied by much superior documentation. The board design isn't as nice, but it's not as irritating to work with.

yeah because Terrorists have proven to be so incredibly afraid of dying

I have no doubt that the hardware-based random number generators works in the exact fashion that their manufacturers have specified. Given the amount of scrutiny that is presently being placed upon them I am certain that any sort of pattern in the entropy under normal operation would have been discovered by now.

However, this does not preclude the existence of a backdoor which alters normal operation. Setup certain registers in a particular fashion, call an undocumented instruction, and boom, the random number generator's entropy drops by several orders of magnitude. Not enough to be noticeable, but enough to make attacking it easier. There are however several problems with this:

1. It would require that the machine be compromised locally, with at least user level privilege. Security is mostly moot at this point and there are far better attack vectors available.

2. It would require sneaking undocumented instructions past dozens of engineers working at multiple levels of design and validation. Working backdoors into software is easy and can even slide under the radar if done properly, but in hardware they would stick out like a sore thumb. I have a hard time believing that the existence of a deliberate backdoor in hardware from a company the size of Intel would go unnoticed for long, or that everyone involved would be willing to keep it a secret.

3. There are far better attack vectors available to compromise cryptographic functions at the hardware level than messing with the RNG. Critics have taken a tunnel vision approach to the possibility that RDRAND and other hardware based random number generators may be compromised as they cannot be audited, yet completely overlook that nothing else about the hardware can be audited either. There are whole layers of management functions built into Intel's chips which could provide undocumented backdoors.

The ARM microarchitecture is hardly complex. It's very simple, employing only minor variations on technology that predates it by decades. Most computer engineers would call the bulk of the ARMv7 microarchitecture and other ARM IP obvious to one skilled in the trade. In fact, almost all straight RISC microprocessors follow a very similar architecture. ARM Holdings, despite manufacturing nothing, has wielded their patent portfolio offensively against companies and even bought a large stake in a consortium that acquired MIPS patents that ARM most likely infringed upon. What ARM has done very well is package it all together in a very verbose and detailed IP portfolio that can be instantiated, simulated, and fabricated with ease by licencors. I imagine that many of their patents could be challenged successfully, but no one has any motivation to do so.

You will not get any argument from me about Rambus being a patent troll, but it's important to remember that while usefulness is a requirement for patentability, marketability is not.

ARM Holdings PLC is an R&D company that doesn't manufacture anything. They generate all of their revenue through licencing IP to third parties whom in turn do the manufacturing. I do not see anyone calling them a patent troll.

Rambus Inc. is definitely a shady corporation but simply failing to manufacture products with IP that one owns and initiating litigation against those who infringe upon it does not automatically make one a patent troll.