4 ms·

I thought it was pretty bad as well ... But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, l

I thought it was pretty bad as well ... But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU. I have much higher hopes for RISC-V, the community is really booming and the architecture is better than SPARC. I say this as a former Gaisler employee and SPARC proponent :-)

nickpsecurity 11y ago
"But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU." There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in its current form is suitable for replacing a Core Duo or anything. Yet, that it's suitable for many apps but ignored for all apps by FOSS in favor of proprietary MCU's/CPU's might reveal a problem on their side. Far as RISC-V, the community is booming and I have high hopes for them. Maybe they'll make something. My recommendation was to create Pi-like board with RISC-V SOC by licensing Leon3 or Leon4, replacing SPARC components with RISC-V, and getting the rest w/out effort. I think we would anyway given it's designed for easy configuration/modification. In parallel, continue developing clean-slate replacements. Gives us a rich, interim product to use with full FOSS down the line. What you think of that idea?
- kristoffer 11y ago
  I agree that LEON is overlooked in the MCU market. Wrapping up one or multiple of the RISC-V cores in GRLIB is something I think would benefit both Gaisler and the RISC-V community and something I have thought of doing myself if I had the time!
  - nickpsecurity 11y ago
    That's about half the peer review I need on that given your background. Next I need a SPARC opponent with HW/SOC experience background giving same recommend haha. Might send it to some of the academics. Another part of my plan was to get academics to build and public domain the source/verilog/whatever so we can benefit from their cheap EDA licensing and shuttle runs. Pick bare minimum I.P. we need, like DDR or PCI, to get SOC's working. Slowly crank them out at many universities to eventually arrive at a platform with ASIC-proven components. Then, startups can just do integrations with whatever little part is custom for them. Much cheaper. Also, I think analog academics doing open, cell libraries would be a good idea at 350, 180, 90, 45, and 28nm. As money comes in, can just shrink from one tech to another using pre-existing I.P. or cells. People could probably use Qflow OSS ASIC flow with 350nm (maybe 180nm) without or w/ little commercial tooling. Always looking for HW people's review on these things. What you think?
    - kristoffer 11y ago
      Academics should absolutely open source their stuff to a larger degree and contribute it a common open source community. I don't think LEON/GRLIB will be that community but may be a part of it. OpenCores did not succeed but I have hopes for what's cooking around FOSSi foundation/LibreCores.
    - analognoise 11y ago
      Most academic shuttle runs are still at 90nm, or bigger. There are a few reasons for this: cost of runs, cost of tooling (hundreds of k), and the fact that your assumptions about transistor action and modeling are exponentially more complicated at advanced process nodes. Academics also sign NDAs about the processes they use, and can only make certain things available; the most open is probably MOSIS, but that's absolutely no good for advanced nodes. I'd say throw low power and advanced anything out the window, demonstrate a working chip, then look for funding to advance it.
      - nickpsecurity 11y ago
        I'd agree that most runs are at 90nm or above. Yet, the rest is confusing given I have quite a few papers with competitive stuff done at 45-65nm with some at 28 or 32nm. So, why you say forget about it or MOSIS below 90nm if academics are getting working chips done that low?
- petra 11y ago
  Nick, The larger context of all this issue is defense. So on one side there are the five eyes governments wanting it this way. On the other side(and probably very interested in 100% security), you might have various countries supporting terrorist organizations, terrorist organizations, crime syndicates, russia, china, etc. Doesn't this context hints to us that 100% security would be much harder than creating some design and manufacturing it using standard fabs?
  - nickpsecurity 11y ago
    I've addressed a good chunk of what it takes for system and hardware security in at least two places: http://pastebin.com/y3PufJ0V http://pastebin.com/y3PufJ0V https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624 There won't be 100% security because underlying physics fights you and our field is too new. Best we can hope for is making attacks hard and physical. There's great work in secure HW/SW architectures that should knock out about all SW stuff with effort. Details published in all kinds of CompSci publications. HW, too, far as implementing it correctly with some security properties. The rest, esp tamper-resistence, is still in infancy far as having stuff that actually works. Now, what we're talking about in this thread is having an ISA, chip implementation, firmware, and SW stack that is not a black box and is under your control. Preferably without built-in, convenient spyware. Mainstream FOSS users are currently so far away from this that it's a reasonable, interim goal. So, I had to bring up SPARC as an addition to the list that has side benefit of reducing legal risks.
    - petra 11y ago
      Ok. Maybe that may work. But what about legal risks? extra-legal risks(like vanishing in the dead of night) ? soft risks - how would the wife of someone who is just the customer will respond when guys in black suits will come to her home ? Or if you're method will work so well, are you sure TSMC/Samsung will even accept you as a customer ? Because it doesn't seem like something that could scale without the legal/political side and that's really much harder than the tech(which is hard, no doubt).
      - 11y ago

nickpsecurity 11y ago

"But the SPARCs you mention have their drawbacks. LEON is not that competetive in the high end (in order single issue, low clock freq) and T1/T2 are only cores (i.e. without interesting "uncore" stuff) and not that good as general purpose "desktop like" CPU." There's definitely drawbacks. I've just not even seen interest in embedded sector of FOSS for SPARC even with open cores. I wouldn't argue stuff like Leon4 in its current form is suitable for replacing a Core Duo or anything. Yet, that it's suitable for many apps but ignored for all apps by FOSS in favor of proprietary MCU's/CPU's might reveal a problem on their side. Far as RISC-V, the community is booming and I have high hopes for them. Maybe they'll make something. My recommendation was to create Pi-like board with RISC-V SOC by licensing Leon3 or Leon4, replacing SPARC components with RISC-V, and getting the rest w/out effort. I think we would anyway given it's designed for easy configuration/modification. In parallel, continue developing clean-slate replacements. Gives us a rich, interim product to use with full FOSS down the line. What you think of that idea?

kristoffer 11y ago
I agree that LEON is overlooked in the MCU market. Wrapping up one or multiple of the RISC-V cores in GRLIB is something I think would benefit both Gaisler and the RISC-V community and something I have thought of doing myself if I had the time!
- nickpsecurity 11y ago
  That's about half the peer review I need on that given your background. Next I need a SPARC opponent with HW/SOC experience background giving same recommend haha. Might send it to some of the academics. Another part of my plan was to get academics to build and public domain the source/verilog/whatever so we can benefit from their cheap EDA licensing and shuttle runs. Pick bare minimum I.P. we need, like DDR or PCI, to get SOC's working. Slowly crank them out at many universities to eventually arrive at a platform with ASIC-proven components. Then, startups can just do integrations with whatever little part is custom for them. Much cheaper. Also, I think analog academics doing open, cell libraries would be a good idea at 350, 180, 90, 45, and 28nm. As money comes in, can just shrink from one tech to another using pre-existing I.P. or cells. People could probably use Qflow OSS ASIC flow with 350nm (maybe 180nm) without or w/ little commercial tooling. Always looking for HW people's review on these things. What you think?
  - kristoffer 11y ago
    Academics should absolutely open source their stuff to a larger degree and contribute it a common open source community. I don't think LEON/GRLIB will be that community but may be a part of it. OpenCores did not succeed but I have hopes for what's cooking around FOSSi foundation/LibreCores.
  - analognoise 11y ago
    Most academic shuttle runs are still at 90nm, or bigger. There are a few reasons for this: cost of runs, cost of tooling (hundreds of k), and the fact that your assumptions about transistor action and modeling are exponentially more complicated at advanced process nodes. Academics also sign NDAs about the processes they use, and can only make certain things available; the most open is probably MOSIS, but that's absolutely no good for advanced nodes. I'd say throw low power and advanced anything out the window, demonstrate a working chip, then look for funding to advance it.
    - nickpsecurity 11y ago
      I'd agree that most runs are at 90nm or above. Yet, the rest is confusing given I have quite a few papers with competitive stuff done at 45-65nm with some at 28 or 32nm. So, why you say forget about it or MOSIS below 90nm if academics are getting working chips done that low?
petra 11y ago
Nick, The larger context of all this issue is defense. So on one side there are the five eyes governments wanting it this way. On the other side(and probably very interested in 100% security), you might have various countries supporting terrorist organizations, terrorist organizations, crime syndicates, russia, china, etc. Doesn't this context hints to us that 100% security would be much harder than creating some design and manufacturing it using standard fabs?
- nickpsecurity 11y ago
  I've addressed a good chunk of what it takes for system and hardware security in at least two places: http://pastebin.com/y3PufJ0V http://pastebin.com/y3PufJ0V https://news.ycombinator.com/item?id=10468624 https://news.ycombinator.com/item?id=10468624 There won't be 100% security because underlying physics fights you and our field is too new. Best we can hope for is making attacks hard and physical. There's great work in secure HW/SW architectures that should knock out about all SW stuff with effort. Details published in all kinds of CompSci publications. HW, too, far as implementing it correctly with some security properties. The rest, esp tamper-resistence, is still in infancy far as having stuff that actually works. Now, what we're talking about in this thread is having an ISA, chip implementation, firmware, and SW stack that is not a black box and is under your control. Preferably without built-in, convenient spyware. Mainstream FOSS users are currently so far away from this that it's a reasonable, interim goal. So, I had to bring up SPARC as an addition to the list that has side benefit of reducing legal risks.
  - petra 11y ago
    Ok. Maybe that may work. But what about legal risks? extra-legal risks(like vanishing in the dead of night) ? soft risks - how would the wife of someone who is just the customer will respond when guys in black suits will come to her home ? Or if you're method will work so well, are you sure TSMC/Samsung will even accept you as a customer ? Because it doesn't seem like something that could scale without the legal/political side and that's really much harder than the tech(which is hard, no doubt).
    - 11y ago