What's happening in the world of MIPS?

[Whales]

Traditionally I've seen MIPS have a stronghold in the consumer router market, mainly through Broadcom.  I recall hearing a rumour about this being due to licensing costs being lower than ARM.  That and they don't really have to care about power consumption, the customer pays.

Now I'm seeing some home routers come out using ARM based chipsets, and I'm wondering is MIPS SoCs are losing their financial edge.

Q1: Are there any new MIPS chips coming out?
Q2: Who are still using them?  Any other stronghold markets?

[NorthGuy]

Microchip uses MIPS in PIC32. They bought Atmel, which used ARM in their MCU. I think they're about to drop their MIPS line and will rename Atmel SAM chips into PIC32.

[legacy]

Probably future MIPS will be found only in Chinese products based on the successors of the Dragon chip. And they will be MIPS64-LE.

[kfnight]

It lives on in RISC-V.

[legacy]

It lives on in RISC-V.

and in our computer science's books 

[SiliconWizard]

I believe this has been discussed several times in other threads, so you may want to do a little searching in the forum which will avoid people repeating themselves endlessly.

That said, this is some kinda recent news that could change matters completely for the future of MIPS:
https://www.mips.com/press/wave-computing-extends-ai-lead-by-targeting-edge-of-cloud-through-acquisition-of-mips/

[westfw]

I think MIPS has had happening what I am afraid will happen to ARM after the Softbank acquisition.   Probably some high management guru decided "enough with all this diversification, trying to be everything for everyone.   Focus exclusively on THIS "highly profitable" market segment (I think it was network appliances for MIPS.  It'd probably be phones for ARM.)  :-(It may sound good on paper, but it tends not to be what ends up providing innovation in CPU technology.

[Whales]

Microchip uses MIPS in PIC32. They bought Atmel, which used ARM in their MCU. I think they're about to drop their MIPS line and will rename Atmel SAM chips into PIC32.

I had no idea those were MIPS, I presumed they were their own fancy arch.  Thanks.

It lives on in RISC-V.

Does RISC-V use a lot of MIPSy content, or do you mean spiritually?

I believe this has been discussed several times in other threads, so you may want to do a little searching in the forum which will avoid people repeating themselves endlessly.

Hey, are you trying to tell me you prefer RETs over JMP loops? 

I'll have a hunt

[Whales]

Ironically in a SPARC topic:

https://www.eevblog.com/forum/microcontrollers/sparc-is-it-dead/?all

[technix]

I think MIPS has had happening what I am afraid will happen to ARM after the Softbank acquisition.   Probably some high management guru decided "enough with all this diversification, trying to be everything for everyone.   Focus exclusively on THIS "highly profitable" market segment (I think it was network appliances for MIPS.  It'd probably be phones for ARM.)  :-(It may sound good on paper, but it tends not to be what ends up providing innovation in CPU technology.

For ARM both the phones and microcontroller markets are at least equally profitable. A good portion of the world’s CPU supply last year is Cortex-M. The Cortex-R line might see the axe drop, as those chips feature-overlap Cortex-M, and it won’t be too hard to port lockstep to Cortex-M33F or Cortex-M4F.

As of MIPS, the problem is that people has realized that Cortex-A is as good in routing IP packets as MIPS, especially with the recent push by various vendors to build server-centric Cortex-A chips; meanwhile the talents accumulated in developing smartphone software is easily transferable. This enabled Cortex-A to encroach on the market segment previously dominated by MIPS.

As an practical example, the ATSAMA5D36 chip has two Ethernet interfaces. Connect the RMII to a PHY and RGMII to an Gigabit Ethernet Switch chip like RTL8367, add 128MB DDR2 and 16GB eMMC and you get a reasonable and highly expandable router.

[brucehoult]

It lives on in RISC-V.

Does RISC-V use a lot of MIPSy content, or do you mean spiritually?

RISC-V assembly language is very close to MIPS assembly language. The binary encodings are completely different.

RISC-V rearranged the instruction encoding to:

• provide a huge amount of room for future extensions, even within the standard 32 bit opcode format
• provide uniform support for versions with 32, 64 and 128 bit integer registers
• provide integrated support for optional 16 bit opcodes (like Thumb2) and for 48, 64, 80 ... 192 bit opcodes for future extensions. You can tell the length of an instruction by examining the low-order bits of the first byte: 00/01/10 for 16 bit 00011-11011 for 32 bit, 011111 for 48 bit, 0111111 for 64 bit, nnnXXXXX1111111 for 80+n*16 bit (the XXXXX is for the register to put the instruction result in

All this was achieved, basically, by shortening the field for immediate constants, load/store offsets, and conditional branch offsets from 16 bits to 12 bits. To compensate, the field for LUI and AUIPC is increased from 16 to 20 bits so you can still load any 32 bit constant or refer to anywhere in a 32 bit address space (absolute or PC relative) with two instructions. Unconditional branches also have a 20 bit offset.

The downside is literals and offsets between +/-2k and +/-32k need two instructions instead of one in MIPS. If you use things like the standard "LI" pseudo-instruction then this is transparent.

As well as this, in RISC-V you can compare two registers for EQ/NE/LT/GE and branch in a single instruction (recent MIPS has this too), and load and branch delay slots were removed.

For anyone who knows MIPS it's very very familiar, just improved. And free for anyone to use.

In May, MIPS announced a new 32 bit chip with a new "NanoMIPS" encoding that has 16, 32 and 48 bit opcodes. That looks pretty good too, but it's proprietary as hell and late to the party.

[legacy]

load and branch delay slots were removed.

even in m88k, but at the cost of a bubble in the pipeline.
do you know how is it implemented in RISC-V? 

[NorthGuy]

and load and branch delay slots were removed.

The delay slot is a good thing. The cycle is lost anyway. Why not to execute an instruction?

[andersm]

The delay slot is a good thing. The cycle is lost anyway. Why not to execute an instruction?

It's an exposed pipeline implementation detail, which makes high-performance implementations more difficult. On the software side it also complicates exception handlers and debuggers.

[legacy]

and load and branch delay slots were removed.

The delay slot is a good thing. The cycle is lost anyway. Why not to execute an instruction?

for several reasons, starting from the fact that it usually drives your crazy with hw-debuggers and ICEs.
You can handle it, in theory, but at the end of the day, it's ... annoying.

edit:
for the record, it's what makes the use of SPIM (MIPS-R2K PC-simulator) very comfortable in computer science classrooms and laboratories, and it's *the* reason why Motorola put a bit in the configuration register of their m88K in order to disable the delayed slot. It has been appreciated by everyone has ever needed to use an ICE.

[nctnico]

and load and branch delay slots were removed.

The delay slot is a good thing. The cycle is lost anyway. Why not to execute an instruction?

for several reasons, starting from the fact that it usually drives your crazy with hw-debuggers and ICEs.
You can handle it, in theory, but at the end of the day, it's ... annoying.

I totally agree. The delay slot cures your lust to program MIPS assembly quickly.

[NorthGuy]

I totally agree. The delay slot cures your lust to program MIPS assembly quickly.

You can always put "nop" into the delay slot if you don't like it. However you often can find something better than "nop" for the delay slot.

MIPS architecture is very good for C compiler. Therefore, using assembler doesn't give you much advantage over C on MIPS. Regardless, the vast majority of users write in C/C++ and most of them know nothing about delay slots. The complier, though, behind their back, can utilize the delay slots to increase performance.

[legacy]

You can always put "nop" into the delay slot if you don't like it. However you often can find something better than "nop" for the delay slot.

emmmm 

[brucehoult]

load and branch delay slots were removed.

even in m88k, but at the cost of a bubble in the pipeline.
do you know how is it implemented in RISC-V? 

RISC-V is an instruction set. There are already dozens of different implementations at varying levels of performance, so they don't do things the same way.

[brucehoult]

and load and branch delay slots were removed.

The delay slot is a good thing. The cycle is lost anyway. Why not to execute an instruction?

The cycle may or may not be lost. On a simple implementation at low clock rate with only SRAM the result of a load might well be available to the next instruction. On a more complex implementation with scoreboarding or reservation stations etc the load might take several (or even many) clock cycles and the instruction using its result is put aside until the result is ready. This has been common in the x86 world since at least the Pentium Pro in 1995. On intermediate implementations the load might take several clock cycles (even from SRAM or cache) and if the result is needed by the immediately following instruction then the pipeline stalls -- in this case yes it's a good idea to put another instruction (or more) between the load and the use, if one is available.

Thee problem with delay slots baked into the instruction set (and you have to put a NOP there if you don't have anything more useful to do) is that they assume one particular implementation point -- probably the first one you do -- while being totally inappropriate for both higher end and lower end implementations later on.

As for branch delay slots, they have been made obsolete for 99% of branches by modern branch prediction techniques, even on microcontrollers such as the SiFive E31 (in the HiFive1) and E51. One those CPUs when the prediction is wrong you get to eat 3 clock cycles of stall, but it doesn't happen often. On the very low end E20/E21 (Cortex M0 competitor) there is no branch prediction and taken branches simply take 2 clock cycles. But you get compare-and-branch in one instruction.

[Marco]

On DSP loops anything but data based branch prediction always gets it wrong once every loop.

[NorthGuy]

As for branch delay slots, they have been made obsolete for 99% of branches by modern branch prediction techniques, even on microcontrollers such as the SiFive E31 (in the HiFive1) and E51. One those CPUs when the prediction is wrong you get to eat 3 clock cycles of stall, but it doesn't happen often. On the very low end E20/E21 (Cortex M0 competitor) there is no branch prediction and taken branches simply take 2 clock cycles. But you get compare-and-branch in one instruction.

I understand. Delay slots make sense only when you fetch instructions one by one. When you have "far" DDR3/DDR4 memory and a system of caches, the delay slot certainly doesn't help much. It may even be harmful, for example if it is located beyond the cache line boundary and would require fetching the whole new cache line. Thus, it has been removed from the low end systems simply for uniformity reasons. Makes sense.

[brucehoult]

On DSP loops anything but data based branch prediction always gets it wrong once every loop.

Aren't most DSP loops controlled by a counter (e.g. array size) not by the data?

[westfw]

Heh.  Look what showed up elsewhere...

[coppice]

I think MIPS has had happening what I am afraid will happen to ARM after the Softbank acquisition.   Probably some high management guru decided "enough with all this diversification, trying to be everything for everyone.   Focus exclusively on THIS "highly profitable" market segment (I think it was network appliances for MIPS.  It'd probably be phones for ARM.)  :-(It may sound good on paper, but it tends not to be what ends up providing innovation in CPU technology.

When ARM were developing the M3 and M0, MIPS was trying hard to go head to head with them, as they knew they could only survive by broadening their appeal across the whole of the embedded space. A number of MCU vendors evaluated the MIPS small core options, and found they had some pretty good qualities. In the end only Microchip signed up.

[nctnico]

I think MIPS has had happening what I am afraid will happen to ARM after the Softbank acquisition.   Probably some high management guru decided "enough with all this diversification, trying to be everything for everyone.   Focus exclusively on THIS "highly profitable" market segment (I think it was network appliances for MIPS.  It'd probably be phones for ARM.)  :-(It may sound good on paper, but it tends not to be what ends up providing innovation in CPU technology.

When ARM were developing the M3 and M0, MIPS was trying hard to go head to head with them, as they knew they could only survive by broadening their appeal across the whole of the embedded space. A number of MCU vendors evaluated the MIPS small core options, and found they had some pretty good qualities. In the end only Microchip signed up.

This probably also had to do with the large ecosystem ARM already had created. Long (20 years ago) before ARM cores turned up in microcontrollers there was already a lot of support for the ARM based SoCs. Years ago I had to work with a MIPS based SoC. It was like being in friggin no-one's land. Every piece of software had ARM optimisations but nothing for MIPS. IMHO MIPS has missed the boat. If Broadcom and Microchip stop using MIPS then it is probably game over.

[coppice]

I think MIPS has had happening what I am afraid will happen to ARM after the Softbank acquisition.   Probably some high management guru decided "enough with all this diversification, trying to be everything for everyone.   Focus exclusively on THIS "highly profitable" market segment (I think it was network appliances for MIPS.  It'd probably be phones for ARM.)  :-(It may sound good on paper, but it tends not to be what ends up providing innovation in CPU technology.

When ARM were developing the M3 and M0, MIPS was trying hard to go head to head with them, as they knew they could only survive by broadening their appeal across the whole of the embedded space. A number of MCU vendors evaluated the MIPS small core options, and found they had some pretty good qualities. In the end only Microchip signed up.

This probably also had to do with the large ecosystem ARM already had created. Long (20 years ago) before ARM cores turned up in microcontrollers there was already a lot of support for the ARM based SoCs. Years ago I had to work with a MIPS based SoC. It was like being in friggin no-one's land. Every piece of software had ARM optimisations but nothing for MIPS. IMHO MIPS has missed the boat. If Broadcom and Microchip stop using MIPS then it is probably game over.

Perhaps more relevant to MCUs is the old ARM7TDMI. It only got into a few (mostly really lousy) MCUs near the end of its life, but from the mid 90s it was doing a LOT of MCU like jobs embedded in larger parts, like hard disc controllers, GSM chips, and automotive parts.

[brucehoult]

Perhaps more relevant to MCUs is the old ARM7TDMI. It only got into a few (mostly really lousy) MCUs near the end of its life, but from the mid 90s it was doing a LOT of MCU like jobs embedded in larger parts, like hard disc controllers, GSM chips, and automotive parts.

In 2006-2008 I was working for a company selling a Java compiler for mobile phones. At least 90% were using the ARM7TDMI then.

[technix]

I think MIPS has had happening what I am afraid will happen to ARM after the Softbank acquisition.   Probably some high management guru decided "enough with all this diversification, trying to be everything for everyone.   Focus exclusively on THIS "highly profitable" market segment (I think it was network appliances for MIPS.  It'd probably be phones for ARM.)  :-(It may sound good on paper, but it tends not to be what ends up providing innovation in CPU technology.

When ARM were developing the M3 and M0, MIPS was trying hard to go head to head with them, as they knew they could only survive by broadening their appeal across the whole of the embedded space. A number of MCU vendors evaluated the MIPS small core options, and found they had some pretty good qualities. In the end only Microchip signed up.

This probably also had to do with the large ecosystem ARM already had created. Long (20 years ago) before ARM cores turned up in microcontrollers there was already a lot of support for the ARM based SoCs. Years ago I had to work with a MIPS based SoC. It was like being in friggin no-one's land. Every piece of software had ARM optimisations but nothing for MIPS. IMHO MIPS has missed the boat. If Broadcom and Microchip stop using MIPS then it is probably game over.

Perhaps more relevant to MCUs is the old ARM7TDMI. It only got into a few (mostly really lousy) MCUs near the end of its life, but from the mid 90s it was doing a LOT of MCU like jobs embedded in larger parts, like hard disc controllers, GSM chips, and automotive parts.

And, y'know, Game Boy Advance. It is the ARM7TDMI that gave it SNES-level game experience without touching the helper chips like SuperFX and being power restricted by the handheld form factor. Nintendo stayed with ARM ever since on handhelds, even recently axed the PowerPC-based home consoles and merged it with the handhelds in the ARM-based Nintendo Switch hybrid console.

I wonder if Nintendo is one of the driving forces behind Japan-based SoftBank buying out ARM...

[Marco]

Aren't most DSP loops controlled by a counter (e.g. array size) not by the data?

For most non-DSP architectures the difference is academic, they have no loop instructions, they can only branch on data comparisons. They don't know the data is a counter, so they can't anticipate what the comparison will be, they have to predict it and get it wrong once every loop. The x86 loop instruction is translated to branching too, so that doesn't help.

Zero overhead looping was one of the common distinguishing features of DSPs.

PS. there are ways to avoid it without loop instructions, prepare to branch instructions and manual BTB loading for instance ... but those are rare in modern architectures.

[legacy]

I wonder if Nintendo is one of the driving forces behind Japan-based SoftBank buying out ARM...

probably, but ... Japan is weird since they are also supporting SuperHitachi chip which they like to use their GPS, and it's not clear why they like to do so, but they do

[legacy]

to predict

branch prediction

[Marco]

It is better to know than to predict, with branch prediction you often know ... but have no way to tell the processor. You just have to sit there seeing it waste cycles.

[legacy]

well, dealing with Branches in the processor pipeline has been solved by several branch prediction techniques, from Static Branch Prediction (the cheapest) to Dynamic Branch Prediction.

in every conditional branch Instruction, the branch is taken only if the condition is satisfied, and the branch target address is stored in the Program Counter (PC) instead of the address of the next instruction in the sequential instruction stream.

The branch that is guessed to be the most likely is then fetched and speculatively executed. If it is later detected that the guess was wrong then the speculatively executed or partially executed instructions are discarded and the pipeline is flushed and it starts over with the correct branch, incurring a delay.

In short, the smarter the branch prediction goes the fewer penalties are in computation being.

Therefore the point is: enhancing the prediction is a good point, and within the class of Dynamic Branch Prediction we are able, in theory, to collect a deep history of instructions and conditions running in the CPU in order to apply advanced statistics and even AI algorithms to predict branches with a low failure rate, it's called hyperdynamic branch prediction, which sounds exciting (so they said in Intel, "hyper" comes from the need of using a hyperplane, a matrix with 3 dimensions, to keep the information) except this introduces more complexity in the design of the chip, it potentially slows down the CPU ( it doesn't scale well on frequency) and more area needs to be taken in the silicon.


So ... we all prefer the KIS approach, and we have resolved the problem with the compromise of accepting a smaller pipeline. The smaller the pipeline goes (which means fewer stages) the shorter the delay of penalty goes on wrong branch predictions.


oh, reintroducing instructions like "do loop until this counter is greater than zero" would be great, but ... again it costs more complexity in RISC design.

umm, to be honest, not so much, and "Arm" stands for [A]dvanced [R]ISC [M]achine therefore if it wishes it can copy this feature from whatever implementations we have seen in CISC CPUs, even take the challenge of implementing the hyperdynamic branch prediction that will turn a CPU into a Skynet AI-driven chip(1), but ... for sure it's not compliant to the pure and minimalistic approach of MIPS processors 


(1) kidding. The chip mentioned in Terminator movies.

[brucehoult]

Aren't most DSP loops controlled by a counter (e.g. array size) not by the data?

For most non-DSP architectures the difference is academic, they have no loop instructions, they can only branch on data comparisons. They don't know the data is a counter, so they can't anticipate what the comparison will be, they have to predict it and get it wrong once every loop.

No, that's not correct.

Modern branch prediction techniques -- which started with the Pentium MMX and Pentium Pro in the mid 90s and are now incorporated into even mid-range microcontrollers -- are capable of executing loops with trip counts of up to maybe 20 or so with *zero* mispredictions after the first couple of times.

[NorthGuy]

For most non-DSP architectures the difference is academic, they have no loop instructions, they can only branch on data comparisons. They don't know the data is a counter, so they can't anticipate what the comparison will be, they have to predict it and get it wrong once every loop. The x86 loop instruction is translated to branching too, so that doesn't help.

Even naïve branch prediction (e.g. take it if it jumps back and don't take it if it jumps forward) works reasonably well and won't create much overhead on tight fast loops.

However, all these heuristic methods (caching, re-ordering, branch prediction) are good when you want to optimize average speed, but at the same time, they make the worst case worse.

[legacy]

Do you know? we have reached a level of artificial intelligence in our algorithms able to predict people's purchase wishes before people actually decide to do any purchase.

These algorithms are used by Amazon, eBay, and many others for many other applications which need to predict something by identifying common patterns.

I have recently done some personal researching by applying these algorithms to my softcore with the specific purpose of reducing the failure rate at branch predicting and it has actually made by several orders of magnitude, which is extremely good! Unfortunately, the downside is that these algorithms need to learn, they need time for this, and they consume a lot of memory.

My softcore runs as a software HDL simulation, while the branch prediction unit is an external module written in C and able to interact with the HDL simulator , and every plan for a hardware translation of its algorithms has always come into the need of more ram than the FPGA can provide(1), and no less than 90 cycles to speculate on the branch prediction.

Which is definitely too crazy even for a hobby, it slows down the clock by two orders of magnitude (1:100), therefore it has been abandoned, but it has been a crazy cool show 


(1) more than 8Kbyte of BRAM on my little Spartan3 considering a prediction matrix to speculate on  2Kbyte of instructions.

I would infer two points on a hypothetical corollary
1) these algorithms can only be applied to small RAMs, like an L1 cache
2) judging by my implementation, 1Mbyte of L1 cache needs 4Mbyte of space for the matrix

[legacy]

with *zero* mispredictions after the first couple of times.

yup, These algorithms are on made on second order statistic, and they work well for loops.

[NorthGuy]

Do you know? we have reached a level of artificial intelligence in our algorithms able to predict people's purchase wishes before people actually decide to do any purchase.

Marketing doesn't work by predicting purchaser's wishes. It works by controlling purchaser's wishes, which is much more efficient approach.

[legacy]

Marketing doesn't work by predicting purchaser's wishes. It works by controlling purchaser's wishes, which is much more efficient approach.

no doubt they make us more prone to purchase by well-done advertisements, but this is psychology matter, while computer science it's more interested in predicting algorithms based on statistics. They used these algorithms to increase the efficiency of warehouses in the first place. These algorithms are also used by the police, e.g. the "big brother" project used in the UK.

there was a crazy and funny fact happens when an artificial-intelligence-driven data analyzer predicted a sixteen years old girl was pregnant by suggesting her several purchases for a baby before her consciousness was aware of what was happening.

Oh, you could even think the data analyzer was pushing the young girl to be pregnant, but this for me sounds more "mind control" than how it should be. Why? it's just software, without any human intervention, and it keeps analyzing where you click, and for what 

[SiliconWizard]

I believe this has been discussed several times in other threads, so you may want to do a little searching in the forum which will avoid people repeating themselves endlessly.

Hey, are you trying to tell me you prefer RETs over JMP loops? 

I'll have a hunt

I was suspecting we'd get to read it all over again, the quirks of the dated MIPS architecture, how it's more of an academic learning tool than a practical one, how ARM has been eating MIPS alive, and a pinch of RISC-V. And finally how MIPS is dead without being really dead. Turns out that's pretty much what we got.

The acquisition of MIPS by "Wave Computing" may not bode too well for the future of MIPS. AI and deep learning is all the rage, but this is just some kind of start-up as far as I got it, and this kind of acquisitions often have a bad ending.

Quoting them:

Wave is a venture capital backed startup. We will never have all the resources, as many people or as much time as we want to bring new creative solutions to the market. To be successful, we must continue to rely on innovation, the speed of action, and working hard to get our job done.

Ahem.

[brucehoult]

Do you know? we have reached a level of artificial intelligence in our algorithms able to predict people's purchase wishes before people actually decide to do any purchase.

Marketing doesn't work by predicting purchaser's wishes. It works by controlling purchaser's wishes, which is much more efficient approach.

Mostly I find that I see ads on every site I visit for a product or service I need once or once a year AND BOUGHT YESTERDAY.

Right now, I'm seeing ads everywhere from booking.com for a hotel in Fiji that I already booked on expedia on Saturday. I had checked the price on booking.com as well, just in case it was better.

[NorthGuy]

Marketing doesn't work by predicting purchaser's wishes. It works by controlling purchaser's wishes, which is much more efficient approach.

Mostly I find that I see ads on every site I visit for a product or service I need once or once a year AND BOUGHT YESTERDAY.

Right now, I'm seeing ads everywhere from booking.com for a hotel in Fiji that I already booked on expedia on Saturday. I had checked the price on booking.com as well, just in case it was better.

This is an example of good marketing. You didn't have any desire on checking prices for what you already have. Google showed you the ad. This inspired a desire to click and check prices. You clicked, Google got the commission for the click. Brilliant marketing.

It certainly doesn't matter for the Google if your click was of any use to the advertiser.

[brucehoult]

Marketing doesn't work by predicting purchaser's wishes. It works by controlling purchaser's wishes, which is much more efficient approach.

Mostly I find that I see ads on every site I visit for a product or service I need once or once a year AND BOUGHT YESTERDAY.

Right now, I'm seeing ads everywhere from booking.com for a hotel in Fiji that I already booked on expedia on Saturday. I had checked the price on booking.com as well, just in case it was better.

This is an example of good marketing. You didn't have any desire on checking prices for what you already have. Google showed you the ad. This inspired a desire to click and check prices. You clicked, Google got the commission for the click. Brilliant marketing.

It certainly doesn't matter for the Google if your click was of any use to the advertiser.

No, I checked the price on booking.com before I booked it on expedia.

Google showed me the ad for booking.com after I already had the hotel booked.

I didn't click the ad, google didn't get click commission.

[Marco]

yup, These algorithms are on made on second order statistic, and they work well for loops.

For loops which loop twice and are still in the BTB next time they loop ...

[legacy]

anyway, the intriguing question is now: what happened to R8K? what?!?
you know what! it was that big chip in the prototype suit offered by SGI!

it was a strange beast, with a weird branch prediction unit

[srce]

In May, MIPS announced a new 32 bit chip with a new "NanoMIPS" encoding that has 16, 32 and 48 bit opcodes. That looks pretty good too, but it's proprietary as hell and late to the party.

A RISC-V fan talking about being late to the party? 

[legacy]

I wonder who has ever used or seen one of the eval boards made by IDT.



This one was manufactured around the 2000's and looks funny

[nctnico]

Offtopic: someone had fun while combining a TQFP and BGA footprint 

[legacy]

Offtopic: someone had fun while combining a TQFP and BGA footprint 

LOL 

[SiliconWizard]

Offtopic: someone had fun while combining a TQFP and BGA footprint 

LOL 

Looks funny indeed, but they were probably unsure of the short-term availability of either package when they designed the board and were probably pressed by upper management to release it ASAP.

[Whales]

That's a very interesting looking board. Thanks for the high-res pic

RAM

Three types:
 - 1 DIP for 8-bit (occupied)
 - 4 DIPS for 32 bits
 - more traditional SODIMM (occupied)

I'd guess the 32bit memory bus is split across four 8-bit DIP rams so that it can access them all in parallel, rather than sequentially.  Presumably this is an alternative to using the SODIMM.

The 8-bit slot is however more interesting -- did someone mention these processors booting up in an 8-bit mode?  Maybe the entire addressing system changed electronically as well as logically, so this processor required an 8-bit RAM chip for boot.

I/O

Unless you use some PCI I/O cards you are limited to just RS-232.

By golly that MAX23 at the top-right has a lot of big caps attached, they were not taking any chances about it not being able to charge pump.


EDIT: It comes with an OS built into its EEPROM too.  Lots of curly details.  https://www.idt.com/document/mae/79s334a-evaluation-board-manual