> The whole of your second point is ridiculous conspiracy theory.
Theory, yes. Conspiracy theory, emphatically not, sorry for the misunderstanding. I have no ill will towards the RISC-V ISA and no disagreement with SiFive's operations. Like others here I was just trying to figure out the huge disparity between the CPU clock speed and the onboard memory, in my case with sorely insufficient understanding of the field.
> It is perfectly reasonable to do enough formal verification to ensure that your chip works first time.
Oh, okay then. That's really amazing, I didn't know that :)
> Linux is not going to "stress" your chip more.
Like I said, I'm a bit ignorant here. I was just thinking along the lines of how eg an i7 with faulty L2 cache could be re-designated as an i5, but in this case they're not sure what's faulty, etc.
There's also the fact that CPUs do have errata... (?)
> And nobody deliberately cuts out a viable market sector unless they've got another product to put in it.
Absolutely! What I was saying was that I theorize that this is a first-run design and that another chip was going to follow up. I'm increasingly confident I'm wrong about exactly why (eg, now I understand about the RAM problem)
> On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM.
I see. Mmm :/
> People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package.
Has a look at a picture oh wow so it is, that's amazing.
> Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves.
Hopefully this run is an incentivisation to get some support for that!
> I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days.
Hmm, that's quite true, yeah. (It's kind of sad how speed-hungry the kernel is nowadays - I have a 32MHz PDA with an OS (EPOC, precursor of Symbian) that draws draggable windows on a little monochrome touchscreen LCD, I can fling the windows around faster than the crystals can update :D)
I would absolutely buy a 320MHz Linux device with an open-source secure boot story though. Text communication doesn't need a snappy CPU.
> huge disparity between the CPU clock speed and the onboard memory
I think that's RISC "working as intended"; the tradeoff was always supposed to be that you got to issue lots of simple instructions at high speed. I can't find what manufacturing process they're using (?nanometers) but it sounds like it's simply a "why not?" outcome of the design process that the chip is very fast. It doesn't have all that many peripherals either, by modern standards.
SRAM just takes up a lot of space. Hard to tell without gate counts or die shots but the 16k+16k could easily be over half the die.
EPOC is one of those extraordinary things that can be called a great technological achievement with a tiny dedicated fandom that nonetheless became a dead-end. Like Amiga, Concorde, BBC Domesday Project, etc. I do wish we could have snappier GUIs on our ten-times-faster systems.
>> huge disparity between the CPU clock speed and the onboard memory
> I think that's RISC "working as intended"; the tradeoff was always supposed to be that you got to issue lots of simple instructions at high speed.
I see.
> I can't find what manufacturing process they're using (?nanometers) but it sounds like it's simply a "why not?" outcome of the design process that the chip is very fast.
Heh.
> It doesn't have all that many peripherals either, by modern standards.
This looks to me to have all the hallmarks of a first-gen MVP. A very decent offering likely with some long-term support, but an MVP nonetheless.
I noticed that, it's a fascinating design tradeoff they picked.
> SRAM just takes up a lot of space. Hard to tell without gate counts or die shots but the 16k+16k could easily be over half the die.
Wow, TIL
> EPOC is one of those extraordinary things that can be called a great technological achievement with a tiny dedicated fandom that nonetheless became a dead-end. Like Amiga, Concorde, BBC Domesday Project, etc. I do wish we could have snappier GUIs on our ten-times-faster systems.
Mmm. I consider it insane that the Web is as slow as it is, but it makes a sad sort of sense. I've been wondering about making a cut-down general-purpose information rendering engine with a carefully-designed graphical feature set that's really easy to optimize. Would be really cool.
EPOC was awesome: some hand-wavy testing showed me that the OPL environment was fast enough to support full-screen haptic scrolling of information. It would have totally worked in just a few simple lines of code. If only full-panel capacitative touch were viable in '98 ;)
Theory, yes. Conspiracy theory, emphatically not, sorry for the misunderstanding. I have no ill will towards the RISC-V ISA and no disagreement with SiFive's operations. Like others here I was just trying to figure out the huge disparity between the CPU clock speed and the onboard memory, in my case with sorely insufficient understanding of the field.
> It is perfectly reasonable to do enough formal verification to ensure that your chip works first time.
Oh, okay then. That's really amazing, I didn't know that :)
> Linux is not going to "stress" your chip more.
Like I said, I'm a bit ignorant here. I was just thinking along the lines of how eg an i7 with faulty L2 cache could be re-designated as an i5, but in this case they're not sure what's faulty, etc.
There's also the fact that CPUs do have errata... (?)
> And nobody deliberately cuts out a viable market sector unless they've got another product to put in it.
Absolutely! What I was saying was that I theorize that this is a first-run design and that another chip was going to follow up. I'm increasingly confident I'm wrong about exactly why (eg, now I understand about the RAM problem)
> On-chip SRAM is just expensive in terms of area. It's comparable to what you get on Cortex-M devices. There are no chips with enough onboard SRAM to run Linux. You can't really run Linux without an external DRAM interface, and then you have to find somewhere to put the DRAM.
I see. Mmm :/
> People keep forgetting about this on the Pi because the DRAM is stuck on top of the SoC package.
Has a look at a picture oh wow so it is, that's amazing.
> Sure, maybe if this is a success they'll pay the licensing fees for a DDR3 interface + MMU, or write one themselves.
Hopefully this run is an incentivisation to get some support for that!
> I think you'd also want at least 600MHz for Linux, 320 is kind of slow these days.
Hmm, that's quite true, yeah. (It's kind of sad how speed-hungry the kernel is nowadays - I have a 32MHz PDA with an OS (EPOC, precursor of Symbian) that draws draggable windows on a little monochrome touchscreen LCD, I can fling the windows around faster than the crystals can update :D)
I would absolutely buy a 320MHz Linux device with an open-source secure boot story though. Text communication doesn't need a snappy CPU.