alexvoica

If this many-core, multiple cluster architecture implements HMP then you can theoretically run all cores across every cluster.

I think we need a broader discussion about what mobile apps will use many-core/multi-core processors. If we are talking video processing, then why do it on the CPU, if you have a dedicated video encoder/decoder already there?

One situation where you might want to use a mobile CPU for video decoding is for small window, low-res preview modes (some browsers and mobile apps use it) but even then, do you really need eight or ten CPUs to do the job?

There have been a few articles recently about whether SoCs for mobile devices need to scale beyond a certain core count.

One side says that 8 cores and above is overkill and that building highly scalable dual- and quad-core processors is the way forward:

http://www.forbes.com/sites/patrickmoorhead/2015/05/11/why-8...

Another side says that more cores offer more granularity for workloads and that we shouldn't be afraid to move to 10- or 12-core processors:

http://www.androidauthority.com/why-8-and-10-cpu-cores-in-sm...

I tend to be in the first camp so I've linked to an article I wrote on the topic.

It would be interesting to see what others here think.

There is also the RISC-V ISA (http://riscv.org/) being developed at Berkeley and the lowRISC SoC incorporating a 64-bit RISC-V CPU (http://www.lowrisc.org/) by a team in Cambridge.

Patterson and Hennessy worked together to write http://www.amazon.com/Computer-Architecture-Fifth-Edition-Qu...

The vast majority of practical references in the book are based on the MIPS architecture (as an example of a RISC processor).

So back to your point, a lot of universities teach computer architecture based on MIPS since it was defined by Patterson and Hennessy (Hennessy also co-founded MIPS Computer Systems Inc. and went into production with MIPS R2000 based on the MIPS I ISA).

MIPS is a very popular architecture, having shipped in over 800 million devices last year.

Now these universities that teach MIPS in their coursework have a chance to enhance the course by giving students access to the RTL too. When those students leave university, they will have the skills required to understand and work with a commercially-available CPU architecture.

Yes, that is true. MIPS Technologies held patents on the MIPS ISA and most of those were transferred to Imagination when we completed the acquisition. However, many of these patents are also owned by an internationally-backed consortium which includes ARM: http://www.arm.com/about/newsroom/arm-announces-participatio...

I think this announcement is particularly important because it gives students the chance to study a piece of RISC history. When I was in University studying for my Electrical Engineering degree, we were asked to clone an 8-bit MCU. While it was a useful exercise, everyone was dreaming of seeing a fully open MIPS CPU. We were taught it yes, in the Computer Architecture course, but never got a chance to see any RTL code.

RTL code + slides beats slides in my book so that's why I feel this announcement is so important for me, personally - but also for universities worldwide.

This is not simplified, we include the full RTL and all the building blocks required to run Linux (cache controllers, MMU, debug interface, load/store unit etc.).

We are granting an open license, which means you can see the code. CPU IP usually includes many options (i.e. parameters) that need to be set by design teams before doing any FPGA integration work (synthesis, functional simulation and verification, place and route, etc.). Setting those parameters up requires a lot of expertise which is usually accumulated over years of work in SoC design.

The blog article mentions a case where a university struggled to configure the MIPSfpga CPU because (naturally) IP can be quite complex, especially if you haven’t used it before. So we’ve actually done a lot of work to create a pre-configured, pre-validated version that is easy to use by academics (lecturers, students, etc.) for FPGAs. Of course, we also state in the press release that users can change it but they need to talk to us first to ensure that the changes they make are valid and sensible. The last thing you want is to break a CPU architecture; this will affect not just the behavior of the hardware, but also the toolchain.

This matters because you get access to the full Verilog code for a modern CPU and a complete toolchain to boot Linux and write software. This also matters because these two vital elements (hardware and software) are coming straight from the source.

Open cores might get close to an implementation, but usually they break code compatibility or implement older versions of the architecture, which limits your ability to run (or update to) a modern Linux kernel or use a standard toolchain from established providers.

The package includes a microAptiv CPU (MIPS32 Release 3) written in Verilog, a getting started guide, and various files for debugging, simulation and synthesis (free SDK, tools from Modelsim and Xilinx, etc.)

greybeards, if you have any questions, please don't hesitate to ask.

Companies would create a separate Vulkan driver that would live alongside the OpenGL ES driver; the article mentions some of the advantages in terms of performance and stability.

It is a type of connector for MIPS debug probes. Probably the best place to ask for more info is http://forum.imgtec.com/categories/creator

No, only OpenGL (ES).

Next year.

Not really - and if they are, they are usually biased. You can try this: http://www.ece.gatech.edu/academic/courses/ece2035/readings/...

This is the first board in a series of many. We have some very exciting things planned for the future.

Everything should be on https://github.com/mips. Please have a quick look and tell me if there is something missing that you'd like to see.

Here is quick breakdown:

Newer/faster processor: 1.2 GHz dual-core MIPS32 vs. 700 MHz single-core ARMV6 More memory: 1 GB DDR3 vs. 512 MB DDR2 More storage options: 4 GB of flash + SD card expansion vs. microSD expansion Better connectivity: Ethernet + Wi-Fi + Bluetooth vs. Ethernet-only Wider operating system support: Linux + Android vs. Linux only.

I've ran some Linux/Android benchmarks on it and will publish the results in an article soon.

We wanted a balanced feature set; things like USB 3.0 or Gigabit Ethernet can upset the low power mojo of a design.

Because it's lower power.

There are schematics available at http://elinux.org/CI20_Hardware/Documentation

Is that enough?

The kernel part is open while the user space is in binary blob form.

We wanted a general purpose platform at a decent price and the SoC from Ingenic offered that - and more.

We have documented our progress on eLinux http://elinux.org/MIPS_Creator_CI20.

http://elinux.org/CI20_upstream is probably the place to start.

Please let me know if you have any questions.

Some context: SELTECH is a Japanese company that is well-known for creating hypervisors for NVIDIA Tegra and other high performance mobile platforms running Linux.

SELTECH has now ported its new FEXEROX hypervisor to MIPS M5150, a microcontroller-class CPU that has two main features; both these features have never been implemented in an MCU before:

- full hardware virtualization which enables it to run a hypervisor.

- an MMU which enables it to run the full Linux operating system.

This hypervisor creates the framework for next generation security solutions based on the TEE (Trusted Execution Environment) concepts defined by GlobalPlatform (more on what TEE is here: http://www.globalplatform.org/mediaguidetee.asp).

This demonstration also proves how virtualized-based security can be deployed to next-generation IoT applications running Linux. For example, wearable devices can run multiple applications securely (Linux can handle DRM for multimedia streaming or in-app billing while an RTOS can take care of e-health data collection).

For those who are interested in TEE and security under Linux, here is a very cool whitepaper from Elliptic that describes how one can easily implement multi-domain TEEs: http://www.elliptictech.com/images/stories/whitepapers/Embed...

I don't know if you saw this MIPS-based dev board being announced http://blog.imgtec.com/powervr-developers/new-mips-creator-c...

The new coherency manager that we've designed allows us to build up to 64 clusters of 6 cores each.

For legacy, native non-MIPS code, we rely on binary translation.

That was the first 64-bit RISC CPU, indeed. I think we can also claim first 64-bit CPU - but not 100% sure.