5 ms·

That is simply not true. Building a CPU can be "easy" if you want to build something that works. If you want to build something that is power efficient and, at

That is simply not true. Building a CPU can be "easy" if you want to build something that works. If you want to build something that is power efficient and, at the same time, quite performant, then the complexity of the problem escalates very quickly. Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development. TSMC or Global Foundries will help translating HDL into a reliable node? Do you even know what you are talking about? This "translation" that you refer to is called synthesis and physical implementation and it is done by the design house. The foundry only provided the logic cells their technology and they manufacture the final die that is going to ship on the product. The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance. Nothing about your post made any shred of sense in terms of hardware design.

inteleng 9y ago
I'm not sure why pedroaraujo is being downvoted other than in response to his criticism of HN topcommenter Chuck McManis. Pedro is correct; toy CPUs , like what Chuck mentioned building, are so trivial that undergraduate students can build functioning models of them in a few days or hours. They are quite literally thousands of times less complex than the CPUs (even RISC arches) that are discussed in the article. I also concur with Pedro on the clock speed part - clock speed has absolutely nothing to do with your hardware design until you have written all the HDL, simulated its behavioral characteristics, actually synthesized the logic, completed the analog and I/O components of the design, and are actually preparing for tapeout. There's a reason only AMD and Intel make large CPUs for the consumer market, and it's not because college students are too busy. I'm going to fade into the grey background for this, but ChuckMcM's comment is yet another disappointing step toward the total calcification of this forum. It's not a commentary on the article; it simply states, lazily, and ignorantly, that whatever it is they're attempting at IIT-M, it can't be too hard. What an an incredibly condescending and blasé thing to say, especially on a public forum where what you say can't be erased. I'm actually quite glad to see another implementation of RISC-V from outside the US. The horde of nearly identical ARM cores on the market is terribly uninspiring.
- PinguTS 9y ago
  It seems both of you haven't read the article itself. The new CPU design is not about high-end CPU you expect from Intel or AMD. It is about CPUs for the IoT. We are talking about Cortex-M alike CPUs you find in micro-controllers from Infineon, NXP, Renesas, and alike. BTW there is competition to the ARM design. It is the micro-controllers from NXP former Freescale, which have their own CPU design heavily used in automotive.
  - pedroaraujo 9y ago
    The comment applies to both high-end CPUs and to microcontrollers as well. Power and performance are even more critical on a microcontroller than on an high-end CPU.
    - dkersten 9y ago
      And yet you yourself said: > The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance. So it seems his comparison was fair, after all? Given that the article is about microcontrollers too.
  - pkhagah 9y ago
    IITM will start with tapeout of microcontroller class(C-class) CPU. But IITM is designing mobile, server and HPC class CPUs. http://rise.cse.iitm.ac.in/shakti.html http://rise.cse.iitm.ac.in/shakti.html
  - gsmadhusudan 9y ago
    I am not sure where we have indicated that the focus is only on IoT class cores. The E and C class are aimed at that segment and this segment probably will account for the vast majority of cores shipped. So they are the first ones to be shipped. The I class for example, an early version which is on-line will be a full OO core - quad issue - dual threaded.Server, HPC and vector based cores are equally important for us. The core road-map is clearly outlined on the codeline.
m45t3r 9y ago
> Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development. I think what OP means is that you can simulate in software a 30-50MHz version of your own CPU, without having the hardware ready, so you can starting testing if i.e. Linux can boot.
- LeifCarrotson 9y ago
  I thought that what OP meant is that if you can only run the simulation for a relatively simple CPU at, say, 1 MHz, you can run and debug firmware for a 30 MHz CPU effectively, even if it's a little annoyingly slow - your 1-second init routine takes 30 seconds, but that's OK. If you have a 1 GHz CPU, whose more complicated architecture can only be simulated at 500 kHz, then a simulation is really tedious. A 20-second boot IRL of, say, Android takes half a day on your simulated processor. That's not to say there's not someone coming in this morning to step through the overnight simulation they ran, but it's a lot easier to work with when your simulation runs nearer real time.
  - ChuckMcM 9y ago
    For what its worth this captures it well. A processor design in the 30 - 50Mhz range can be usefully simulated on hardware on the engineer's desk (a workstation class PC).
- deleted 9y ago
  [deleted]
raverbashing 9y ago
> What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration You purport to correct him and then you drop this phrase, which is questionable at best and wrong at worse. You do design something that has different clock speeds differently. (Pipelining, power consumption, delays across different parts of the circuit). This is not anything too fancy, this is digital design/IC design 101. Your post makes a lot less sense than his
- mrob 9y ago
  For a well known example of how this matters, consider the Pentium 4. Intel designed it with a deep pipeline on the assumption that they'd be able to reach higher clock speeds than was actually possible. At the intended 10GHz, the Pentium 4 would have had impressive performance for the time. But they couldn't achieve that clock speed, so they had to revert to the simpler pipeline design first used in the Pentium Pro and continue development from there.
- posterboy 9y ago
  > delays across different parts of the circuit guess that's not "digital". After all i expect say gimp to run on my old linux 2.3 thinkpad or on a magnitudes faster i7, but of course with respect to the feasability of heavy effects and huge memory loads.
ChuckMcM 9y ago
Ok then. We clearly see things a bit differently, but I also want to separate what I said, and what you read. I don't think they were necessarily the same thing. My intention here is to share with you some of the thinking behind what I wrote. The article states, "The Shakti project is based on the RISC-V ISA started at UC Berkeley. ... The first chip of the Shakti series will be a C-class controller chip, an entry-level processor, which would find use-cases in IoT, smart cards, and security applications." The current CPUs in this space (IoT, Smart Cards, and Security Applications) are the ATMega AVR series, the ARM Cortex M0/M0+ and a handful of others like the PIC32 and the MSP series from TI. Designing the logic for such a CPU is an undergraduate exercise. It is "easy" in the sense that if you have been taught VHDL or Verilog, and someone hands you a RISC style instruction set architecture which defines the registers, instructions, and flags. A group of students should be able to get something working in a semester which simulates on a VHDL test bench. Here is the call out for Stanford's EE108 Class from the Fall of 2014[1]. Which states -- "EE108b introduces students to architecture and design of efficient computing and storage systems. The main topics include: overview of key techniques for efficient systems, efficiency metrics (performance, power and energy, cost), hardware/software interface (instruction set, data and thread-level parallelism), processor design (pipelining and vectors), custom accelerator design, cache memories, main memory, basic I/O techniques, and architectural support for operating systems. The lab assignments involve the detailed design of a processor on a FPGA prototyping system. The programming assignments involve optimizing the efficiency image processing applications on a portable computing platform." I wasn't dismissing the challenge as something kids in nursery school can do, but I do see the challenge as something of a 'solved problem' for new EE's. You asked about "Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development." which might make a bit more sense in the context of the previous comment about its a well solved problem. When you are building chips in FPGAs and ASICs the "challenge" after you have it running in a test bench, is getting a timing closure. In case you are new to this, that is making sure that signals from different gates arrive in time to be used in the next stage of the operation. This is important because the propagation of signals takes finite time and, assuming you are doing synchronous design, you want to have all the inputs settled given their worst case timing before the clock edge looks at them and does the next step. It has been my experience that when people do their first FPGA designs and the tool tells them how fast they can run reliably, they are disappointed. So they spend some amount of time floor planning and organizing their layout to speed that up. That problem is exacerbated in silicon because the velocity factor of polysilicon wires is much lower than that of metal wires. And typically to keep down costs and complexity you will want to run your signals on the metal layers. But sticking to that can spread out your gates and size is an issue as well when it comes to cost. There is a reason that the majority of the chips for the "IoT, Security, and Smart Cards" top out at clock rates under 50Mhz. It is a 'sweet spot' for cost versus chip complexity versus circuit design. If you want to build cost effective chips in that market you might find yourself in the same design space. As for design houses vs foundries, I am sure you can use your own design house if you choose to, I expect if you use the foundry's [2] you might avoid delays associated with disagreements between what the design house feels like the process should be able to do, and what the foundry feels like it can do. There is nothing quite so disappointing as a design team saying the foundry "should" be able to do something and the foundry saying that it is "impossible." If you want some interesting stories around that you can read the history of the SPARC 10 and Sun's interaction with Texas Instruments (foundry). But my assumption was that any fabless efforts today would go to the design services of the foundry they chose to minimize both schedule risk and the risk that the two won't get along. It may still be possible to show up at a foundry with a shipping box of masks and say "here make me some of these" but it would not be my starting strategy. And then you said (and this was me being unclear), "The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance." Perhaps the reason we saw this differently is that I have seen multi-billion dollar companies depending on a computer to run their business in the back office that didn't have a branch predictor. Before my time the machines didn't even have virtual memory. As a result, I don't think the first CPU out of the gate is going to be have multi-issue superscalar pipelined performance. I don't think the folks in the article do either. You see they mentioned they were starting simpler, like ARM did, like Intel did, like IBM did, like Sun and Apple did and every single company that has ever designed and deployed a new CPU design. It is absolutely a huge undertaking to improve the micro-architecture of a modern Pentium or the Power9 or the ARM A5x 64 bit architecture. If IIT-M gets to that point, that will be at least 10 years from now, maybe 15 or 20. And understanding that as I do I know that they need to get traction with their systems early on. > "Nothing about your post made any shred of sense in terms of hardware design." I can certainly agree with that, because what IIT-M is taking on is not hardware design. All of the hardware design between now and their first $100M is all well understood and doesn't push the envelope at all. They are trying to bring a new system into the world, one that has an ecosystem of software, peripherals, and a variety of CPU implementations. The article gave me the impression that the author of the article felt that if they just built a new CPU it would usher in a new era of computers from India. I think that is a necessary but insufficient step along the road, and that there will be many challenges unrelated to hardware design that will threaten the success of this effort decades before they have engineers wondering which form of register coloring provides fewer bubbles in a hyper-threaded execution pipeline. [1] https://lagunita.stanford.edu/courses/Engineering/EE108b/Winter2014/about https://lagunita.stanford.edu/courses/Engineering/EE108b/Win... [2] http://www.tsmc.com/english/dedicatedFoundry/services/design.htm http://www.tsmc.com/english/dedicatedFoundry/services/design...

inteleng 9y ago

I'm not sure why pedroaraujo is being downvoted other than in response to his criticism of HN topcommenter Chuck McManis. Pedro is correct; toy CPUs , like what Chuck mentioned building, are so trivial that undergraduate students can build functioning models of them in a few days or hours. They are quite literally thousands of times less complex than the CPUs (even RISC arches) that are discussed in the article. I also concur with Pedro on the clock speed part - clock speed has absolutely nothing to do with your hardware design until you have written all the HDL, simulated its behavioral characteristics, actually synthesized the logic, completed the analog and I/O components of the design, and are actually preparing for tapeout. There's a reason only AMD and Intel make large CPUs for the consumer market, and it's not because college students are too busy. I'm going to fade into the grey background for this, but ChuckMcM's comment is yet another disappointing step toward the total calcification of this forum. It's not a commentary on the article; it simply states, lazily, and ignorantly, that whatever it is they're attempting at IIT-M, it can't be too hard. What an an incredibly condescending and blasé thing to say, especially on a public forum where what you say can't be erased. I'm actually quite glad to see another implementation of RISC-V from outside the US. The horde of nearly identical ARM cores on the market is terribly uninspiring.

PinguTS 9y ago
It seems both of you haven't read the article itself. The new CPU design is not about high-end CPU you expect from Intel or AMD. It is about CPUs for the IoT. We are talking about Cortex-M alike CPUs you find in micro-controllers from Infineon, NXP, Renesas, and alike. BTW there is competition to the ARM design. It is the micro-controllers from NXP former Freescale, which have their own CPU design heavily used in automotive.
- pedroaraujo 9y ago
  The comment applies to both high-end CPUs and to microcontrollers as well. Power and performance are even more critical on a microcontroller than on an high-end CPU.
  - dkersten 9y ago
    And yet you yourself said: > The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance. So it seems his comparison was fair, after all? Given that the article is about microcontrollers too.
- pkhagah 9y ago
  IITM will start with tapeout of microcontroller class(C-class) CPU. But IITM is designing mobile, server and HPC class CPUs. http://rise.cse.iitm.ac.in/shakti.html http://rise.cse.iitm.ac.in/shakti.html
- gsmadhusudan 9y ago
  I am not sure where we have indicated that the focus is only on IoT class cores. The E and C class are aimed at that segment and this segment probably will account for the vast majority of cores shipped. So they are the first ones to be shipped. The I class for example, an early version which is on-line will be a full OO core - quad issue - dual threaded.Server, HPC and vector based cores are equally important for us. The core road-map is clearly outlined on the codeline.

m45t3r 9y ago

> Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development. I think what OP means is that you can simulate in software a 30-50MHz version of your own CPU, without having the hardware ready, so you can starting testing if i.e. Linux can boot.

LeifCarrotson 9y ago
I thought that what OP meant is that if you can only run the simulation for a relatively simple CPU at, say, 1 MHz, you can run and debug firmware for a 30 MHz CPU effectively, even if it's a little annoyingly slow - your 1-second init routine takes 30 seconds, but that's OK. If you have a 1 GHz CPU, whose more complicated architecture can only be simulated at 500 kHz, then a simulation is really tedious. A 20-second boot IRL of, say, Android takes half a day on your simulated processor. That's not to say there's not someone coming in this morning to step through the overnight simulation they ran, but it's a lot easier to work with when your simulation runs nearer real time.
- ChuckMcM 9y ago
  For what its worth this captures it well. A processor design in the 30 - 50Mhz range can be usefully simulated on hardware on the engineer's desk (a workstation class PC).
deleted 9y ago
[deleted]

raverbashing 9y ago

> What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration You purport to correct him and then you drop this phrase, which is questionable at best and wrong at worse. You do design something that has different clock speeds differently. (Pipelining, power consumption, delays across different parts of the circuit). This is not anything too fancy, this is digital design/IC design 101. Your post makes a lot less sense than his

mrob 9y ago
For a well known example of how this matters, consider the Pentium 4. Intel designed it with a deep pipeline on the assumption that they'd be able to reach higher clock speeds than was actually possible. At the intended 10GHz, the Pentium 4 would have had impressive performance for the time. But they couldn't achieve that clock speed, so they had to revert to the simpler pipeline design first used in the Pentium Pro and continue development from there.
posterboy 9y ago
> delays across different parts of the circuit guess that's not "digital". After all i expect say gimp to run on my old linux 2.3 thinkpad or on a magnitudes faster i7, but of course with respect to the feasability of heavy effects and huge memory loads.

ChuckMcM 9y ago

Ok then. We clearly see things a bit differently, but I also want to separate what I said, and what you read. I don't think they were necessarily the same thing. My intention here is to share with you some of the thinking behind what I wrote. The article states, "The Shakti project is based on the RISC-V ISA started at UC Berkeley. ... The first chip of the Shakti series will be a C-class controller chip, an entry-level processor, which would find use-cases in IoT, smart cards, and security applications." The current CPUs in this space (IoT, Smart Cards, and Security Applications) are the ATMega AVR series, the ARM Cortex M0/M0+ and a handful of others like the PIC32 and the MSP series from TI. Designing the logic for such a CPU is an undergraduate exercise. It is "easy" in the sense that if you have been taught VHDL or Verilog, and someone hands you a RISC style instruction set architecture which defines the registers, instructions, and flags. A group of students should be able to get something working in a semester which simulates on a VHDL test bench. Here is the call out for Stanford's EE108 Class from the Fall of 2014[1]. Which states -- "EE108b introduces students to architecture and design of efficient computing and storage systems. The main topics include: overview of key techniques for efficient systems, efficiency metrics (performance, power and energy, cost), hardware/software interface (instruction set, data and thread-level parallelism), processor design (pipelining and vectors), custom accelerator design, cache memories, main memory, basic I/O techniques, and architectural support for operating systems. The lab assignments involve the detailed design of a processor on a FPGA prototyping system. The programming assignments involve optimizing the efficiency image processing applications on a portable computing platform." I wasn't dismissing the challenge as something kids in nursery school can do, but I do see the challenge as something of a 'solved problem' for new EE's. You asked about "Sticking at 30-50 MHz? What is this even supposed to mean? Digital hardware design hardly takes clock speeds into consideration, except during physical implementation in the later stages of the hardware development." which might make a bit more sense in the context of the previous comment about its a well solved problem. When you are building chips in FPGAs and ASICs the "challenge" after you have it running in a test bench, is getting a timing closure. In case you are new to this, that is making sure that signals from different gates arrive in time to be used in the next stage of the operation. This is important because the propagation of signals takes finite time and, assuming you are doing synchronous design, you want to have all the inputs settled given their worst case timing before the clock edge looks at them and does the next step. It has been my experience that when people do their first FPGA designs and the tool tells them how fast they can run reliably, they are disappointed. So they spend some amount of time floor planning and organizing their layout to speed that up. That problem is exacerbated in silicon because the velocity factor of polysilicon wires is much lower than that of metal wires. And typically to keep down costs and complexity you will want to run your signals on the metal layers. But sticking to that can spread out your gates and size is an issue as well when it comes to cost. There is a reason that the majority of the chips for the "IoT, Security, and Smart Cards" top out at clock rates under 50Mhz. It is a 'sweet spot' for cost versus chip complexity versus circuit design. If you want to build cost effective chips in that market you might find yourself in the same design space. As for design houses vs foundries, I am sure you can use your own design house if you choose to, I expect if you use the foundry's [2] you might avoid delays associated with disagreements between what the design house feels like the process should be able to do, and what the foundry feels like it can do. There is nothing quite so disappointing as a design team saying the foundry "should" be able to do something and the foundry saying that it is "impossible." If you want some interesting stories around that you can read the history of the SPARC 10 and Sun's interaction with Texas Instruments (foundry). But my assumption was that any fabless efforts today would go to the design services of the foundry they chose to minimize both schedule risk and the risk that the two won't get along. It may still be possible to show up at a foundry with a shipping box of masks and say "here make me some of these" but it would not be my starting strategy. And then you said (and this was me being unclear), "The CPUs you mentioned were simple micro-controllers, they were not designed for heavy processing tasks, they don't even have a branch predictor which is something fundamental to have some significant performance." Perhaps the reason we saw this differently is that I have seen multi-billion dollar companies depending on a computer to run their business in the back office that didn't have a branch predictor. Before my time the machines didn't even have virtual memory. As a result, I don't think the first CPU out of the gate is going to be have multi-issue superscalar pipelined performance. I don't think the folks in the article do either. You see they mentioned they were starting simpler, like ARM did, like Intel did, like IBM did, like Sun and Apple did and every single company that has ever designed and deployed a new CPU design. It is absolutely a huge undertaking to improve the micro-architecture of a modern Pentium or the Power9 or the ARM A5x 64 bit architecture. If IIT-M gets to that point, that will be at least 10 years from now, maybe 15 or 20. And understanding that as I do I know that they need to get traction with their systems early on. > "Nothing about your post made any shred of sense in terms of hardware design." I can certainly agree with that, because what IIT-M is taking on is not hardware design. All of the hardware design between now and their first $100M is all well understood and doesn't push the envelope at all. They are trying to bring a new system into the world, one that has an ecosystem of software, peripherals, and a variety of CPU implementations. The article gave me the impression that the author of the article felt that if they just built a new CPU it would usher in a new era of computers from India. I think that is a necessary but insufficient step along the road, and that there will be many challenges unrelated to hardware design that will threaten the success of this effort decades before they have engineers wondering which form of register coloring provides fewer bubbles in a hyper-threaded execution pipeline. [1] https://lagunita.stanford.edu/courses/Engineering/EE108b/Winter2014/about https://lagunita.stanford.edu/courses/Engineering/EE108b/Win... [2] http://www.tsmc.com/english/dedicatedFoundry/services/design.htm http://www.tsmc.com/english/dedicatedFoundry/services/design...