RISC-V, what do you think about ? - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 02:59:03 pm
content: riscv dot org, they seem to be almost ready

author: HAL-42b
author_rank: Frequent Contributor
timestamp: January 21, 2016, 03:11:46 pm
content: I'll print one as soon as I get my FIB Milling machineIn all seriousness though, I think it has a great potential. India is already interested and may have taped out one in one of their universities. As soon as we see it taped out commercially in China we might see a serious contender to ARM.

author: marshallh
author_rank: Unknown
timestamp: January 21, 2016, 05:04:04 pm
content: Don't know much about it but if it's like the previous "efforts" it will be a design by committee disaster and cost buttloads to produce, ensuring its demise.Hoping I'm wrong.

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: January 21, 2016, 05:56:12 pm
content: i think this will sink like a stone and nobody will care. much like the whole open sparc thing.maybe china will knock something out on risc-v and move on from their mips loongson stuff.

author: Rasz
author_rank: Super Contributor
timestamp: January 21, 2016, 06:33:27 pm
content: brilliant .. if you are in academia

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 07:48:49 pm
content: I believe this core was taped out in real products. I think that was some European company doing ICs for DVRs and set-top boxes.I can't say I'm impressed with the instruction set, but it is actually a real working core, not like one of a few thousands MIPS clones made by students and beginner FPGA designers.

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 09:59:32 pm
content: like my soft core, which is really useless from the industry point of view(1), but very awesome for hobbyist who want to develop in assembly as they did in 1980' with m68k, but over a modern risc-like, provided with a useful TAP (debug interface (2))(1) I wanted to reduce the complexity, so I removed the pipelining stuff, I progressively introduced the cache (coherent) and multi processing (even if up to two CPUs), also the code density is really obscene () , this is not good for BRAM, but it's decent enough if you can use an external DRAM of 32 Mbyte at least(2) I like my TAP, as THE main reason to use this toy in my free time, obviously I do not want to sell to google, or to the first chinese company, even if …… even if ... if I was a genius at marketing, I might say that I have inventedthe reality Engine, Einstein on chipso, if someone wants to pay me thousand and thousand UKP, I might sell my super marvelous && Supercalifragilisticexpialidocious core, which is a crap from the computer science point of view (because it's not superscalar, and it comes with no pipeline under the hood) but it can easily includes a tensor do-processing unit, which can actually accelerate things within tensor components, in a quadri-dimensional coordinate system, ... whose columns are the forces per unit area, acting on the e1, e2, and e3, plus a column for e-time, which is a superset compliant with the introduction of Einstein's theory of general relativity, around 1915.I am kidding, but I have really designed (as proof of concept, which sounds more like intellectual challenge, "we do because we can do") a TPU, and odiously nobody will ever use it even if it might be implemented

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 10:01:18 pm
content: Quote from: Rasz on January 21, 2016, 06:33:27 pmin short it's what I guess

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 10:15:08 pm
content: Quote from: marshallh on January 21, 2016, 05:04:04 pmcurrently it's available as1) simulator (it comes free, open source, it just takes effort to configure and compile a few things)2) arm+fpga board (the hardware side is expensive, the software side is free but takes more effort to configure and compile things)in choice2, the arm core initializes things, load the bitstream, bootstrap the soft core, then it provides a sort of I/O virtualizationI guess that all of this means: good only for academia, for people who want to experiment

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 10:28:12 pm
content: Quote from: legacy on January 21, 2016, 10:15:08 pmIt is not. The core has been taped out in real products. They are specialty ICs, not general purpose mass-market controllers. But this thing is much more than a toy.They also have very good documentation and toolchains.I can't instantly find info, but I have been tracking progress of this project for quite some time. There are plenty of things I don't like about it, but it is the best shot at free and open processor we have right now.It is like KiCad, not the best thing out there, but it is the best as far a free and open goes.

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 10:31:02 pm
content: Quote from: ataradov on January 21, 2016, 10:28:12 pmwhich ones ?edit:and no, there is no chance to compare Kicad with Eagle/CAD (or Altium)not for me, at least (I am used to use both to the last two, for job purposes)

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 10:32:45 pm
content: Calledboom, it's an Out-of-order RISC-V variantRISC-V has a number of features that make an OOO machine more manageable to implement.

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 10:35:35 pm
content: I wonder if it will teach theTomasulo Algorithm, let's check it

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 10:47:11 pm
content: Quote from: legacy on January 21, 2016, 10:31:02 pmAnd yet some people do use KiCad successfully for reasonably big projects. It is not a commonplace, of course. So is RISC-V is not a common core and I would not use it in my projects in a foreseeable future, may be never. But the only way to create a competitor to ARM and others is to create anything at all and persistently work on improving it and making people aware of it existence.

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: January 21, 2016, 10:50:50 pm
content: Supposing the industry implements this (which I don't think will happen), it's just a matter of time until each company add their own specializations and extensions to the standard, and making these extentions proprietary, just so they can advertise their product's differential. Intel will have RISC-V+, then AMD will have a RISC-V2, followed by NVidia marketing a RISC-Vmax, and then in a couple of years what was meant to be an industry standard just became a sea of incompatible instruction sets, requiring tons ofifdefsin the code. So long standards!Marketing people hate standards. Imagine this ad fromNVidia: "We're just like AMD, but with a lot more hype and a nice case sticker at a higher price tag".Besides, they don't seem to have the big players in the industry jumping on the RISC-V bandwagon. It all seems pretty limited to academia, like other forum members have stated and I agree. At the very least, they should have Samsung supporting the initiative. Intel would be nice too!OTOH, there have been nice things that came out of Berkley, so who knows.

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 10:56:48 pm
content: Quote from: AlxDroidDev on January 21, 2016, 10:50:50 pmAnd that's why you need a governing organization and certification program. They are not stupid, and I hope they have claimed proper trademarks.Everyone had implemented the same USB specification without making changes. The core is no different.But you are right, there is no point for big companies to jump on it. But smaller companies may very well implement this into their products. Imagine ESP8266, but with RISC-V instead of Xtensa. Both are non-standard cores, so why not go with open if it is developed to a reasonable level.

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 10:57:15 pm
content: Quote from: ataradov on January 21, 2016, 10:47:11 pmtell me which projects

author: legacy
author_rank: Super Contributor
timestamp: January 21, 2016, 11:00:02 pm
content: Quote from: AlxDroidDev on January 21, 2016, 10:50:50 pmexactly what I think, including species { RISC-V+, RISC-V2, RISC-Vmax }, which is written in a brilliant funny way

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 11:02:57 pm
content: Quote from: legacy on January 21, 2016, 10:57:15 pmThey are not public. If you don't want to believe me, then don't.I personally prefer DipTrace and hate Altium. People have different tastes and used to different things. All those tools are perfectly usable, some provide more service, some less, not a big deal.And I'm hearing really good things about recent code contribution to KiCad from CERN, but have not tried it myself.

author: aventuri
author_rank: Contributor
timestamp: January 21, 2016, 11:19:13 pm
content: turning back to the main topic, i.e. if RISC-V, an interesting open source CPU, could get some steam into the "real taped-out" world... let me note that those "crazy folks" at Allwinner (who you all know for the A10/A20 family of tablet chips) did put in their new lineup H3 (flagged as a 4 core ARM32 cpu), also a "fifth" CPU, called AR100:http://linux-sunxi.org/AR100looks like this CPU should be an ASIC version of the OpenRisc project:http://github.com/openrisc/the funny thing is that people on linux-sunxi ML are investigating how to repurpose it, supposedly born to "control" the PMIC during deep-sleep mode of main CPUs, for real time task as it seems it can drive the whole IO space. next to that, security concerns are investigated too, as malicious code too could try to exploit it..let's see, but these open cores are someway compelling at some degree for manufacturers, as they do not bring the usual long NDAs and licensing paper filling tasks..

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: January 21, 2016, 11:41:20 pm
content: Quote from: ataradov on January 21, 2016, 10:56:48 pmI think differently, but there are pros and cons of having a governing body in a standard. A company's R&D might be limited if there are too many standards to follow. OTOH, if several companies are developing on the same standard, there will be more competition on the marketplace, eventually leading to price drops.QuoteBluetooth is a standard too, but that didn't stop Apple from making bluetooth devices that were completely incompatible with everything else and still call it Bluetooth.QuoteAgreed, but if one is to follow RISC-V without implementing proprietary extensions, it will be just another product in the market, w/o any advantage or differential. It will just like buying 74xx chips: you choose by the price, not by the manufacturer or marketing, since there are several people manufacturing the exact same product. It isn't so interesting to be in a market where the only deciding purchase factor is the price, unless:- you have lower production costs than the competition, so you have a better price- you are in an area hard to reach by the other manufacturers (due to geographic location, taxes, politics, and so on)- you have a supply contract with a big customer- the overall demand is still high to keep all the manufacturers "happy"How many identical chips aren't produced by Fairchild, TI, ST, KEC, ICF, NJR, NXP, and all the other semi-conductor companies? They don't even bother marketing chips like LM317, LM324, 555, 40xx, 74xx and so on, and that's why many companies in this business either disappeared, stopped producing ICs or where bought. You don't buy "TI's LM324". You buy whichever LM324 is cheapest and in the package you need. This doesn't keep companies in the business.

author: MrSlack
author_rank: Frequent Contributor
timestamp: January 21, 2016, 11:42:51 pm
content: Quote from: aventuri on January 21, 2016, 11:19:13 pmThat's not a new idea. Intel ME has an ARC processor derived from a Nintendo SuperFX on the PCH that runs the ThreadX RTOS. That's chock full of shitty holes under S3 sleep as well as it can talk to all sorts of things. That covers most recent Intel CPUs and chipsets. Service processors are a horrible idea if they can talk directly to the host machine.Open cores miss strong standardisation. We'll be in Z80 clone territory again in no time. I'd rather a license dictatorship like ARM.TBH though the only strong, standard open ISA that has been successful is the JVM and perhaps 1% of end users actually give a crap past the high level managed compiler/interpeted layer anyway. Doesn't matter what is underneath it all. The machine is a means to an end and that end us usually piles of cash.

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 11:49:20 pm
content: Quote from: blueskull on January 21, 2016, 11:40:24 pmOR has been taped out many times. As it has been pointed out, its microcontroller profile is used as a system controller in many proprietary designs.

author: ataradov
author_rank: Super Contributor
timestamp: January 21, 2016, 11:54:49 pm
content: Quote from: AlxDroidDev on January 21, 2016, 11:41:20 pmI don't see RISC-V used in standalone general purpose MCUs.But in things like ESP8266, you are not differentiating on the core. Wi-Fi component is the selling point here. There are many application-specific parts that a different enough on their own, the MCU core is secondary.And from there, it can eventually spread into general purpose market. But very eventually, like 10-15 years from now.

author: AlxDroidDev
author_rank: Frequent Contributor
timestamp: January 22, 2016, 12:02:42 am
content: Quote from: MrSlack on January 21, 2016, 11:42:51 pmI believe I've been using the wrong machines then! The ones I have never ended me piles of cash, unless I exchange my salary for zimbabwe dollars!

author: HAL-42b
author_rank: Frequent Contributor
timestamp: January 22, 2016, 08:09:06 am
content: Looks like it has already been taped out. This guy says they can ship to academia packs of 100 for an incredibly low price of 30.000$.https://youtu.be/mD-njD2QKN0?t=40m45sAlso it appears India has officially adopted the ISA and NPTEL is spending 80 millions on it.

author: legacy
author_rank: Super Contributor
timestamp: January 22, 2016, 11:39:54 am
content: Quote from: HAL-42b on January 22, 2016, 08:09:06 amso, Instruction Sets Want To Be Free: will be called "India core" ?

author: legacy
author_rank: Super Contributor
timestamp: January 22, 2016, 11:41:49 am
content: Quoteno open alternative to proprietary offerings from ARM and Intel

author: MT
author_rank: Super Contributor
timestamp: January 22, 2016, 06:38:57 pm
content: I read years ago, like 10-12, a article about a CPU guru who said: the world dont need yet another cpu architecture.

author: Kalvin
author_rank: Super Contributor
timestamp: January 22, 2016, 06:47:25 pm
content: Quote from: MT on January 22, 2016, 06:38:57 pmI also read an CEO who said ""There is no reason anyone would want a computer in their home."When I first looked at this thread my thoughts we also "oh no, yet another academic architecture". After watching the Patterson's lecture I think now otherwise, there is still room for another ISA.

author: aventuri
author_rank: Contributor
timestamp: January 22, 2016, 08:11:30 pm
content: Quote from: Kalvin on January 22, 2016, 06:47:25 pmyes, ..one that doesn't need to win just for the technical merit (pure performance like Intel did for many years, or better ratio performance/power/money like more recently Arm) but for other reasons too, for becoming the ISA for "the rest of us"..as always, a "new kid in town" does just need to be "good enough" and mainly with NO-STRINGS-ATTACHED! :-)

author: Jeroen3
author_rank: Super Contributor
timestamp: January 22, 2016, 08:31:17 pm
content: Not reading all the papers in depth it looks like this: "arm is expensive, we can do better".Mandatory xkcd:

author: ataradov
author_rank: Super Contributor
timestamp: January 22, 2016, 08:40:21 pm
content: Quote from: Jeroen3 on January 22, 2016, 08:31:17 pmARM, MIPS, PowerPC, and dozens of other RISC processors are exactly the same with minor variations on the theme.So having at least one robust and open solution will not hurt. After all, they are doing their own thing and not asking for money, so it all god in my book.

author: timb
author_rank: Super Contributor
timestamp: January 22, 2016, 08:45:31 pm
content: Quote from: AlxDroidDev on January 21, 2016, 11:41:20 pmWhat are you blathering about? All Apple devices implement Bluetooth as defined by the Bluetooth SiG.Now, they might implement custom Bluetooth 4 (LE) protocols, for talking from say the phone to computer (Handoff, etc.) but so do hundreds of other companies! It's part of the Bluetooth LE standard!In fact, on iOS they actually open this up and allow apps to implement any custom protocols they want. This is how third party devices talk to iPhones without having to register with Apple's Made for iPhone program (as is the case with the Lightning and formerly Dock interfaces).What they *don't* support is Classic Bluetooth file transfer (aside from contacts and photos), on iOS at least; OS X fully supports it.If you don't like Apple, fine, but try knowing what you're talking about before spouting off. It takes 60 seconds on Google to verify something.

author: HAL-42b
author_rank: Frequent Contributor
timestamp: January 22, 2016, 09:01:24 pm
content: QuoteThere are two reasons that might make somebody say that: 1 - He did not anticipate the end of Moore's law. 2 - He doesn't care about Open Source.

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 08:37:35 pm
content: Quoteinteresting

author: edavid
author_rank: Super Contributor
timestamp: January 23, 2016, 09:38:06 pm
content: Quote from: legacy on January 23, 2016, 08:37:35 pmI don't agree that it has to be customized to be useful... it could be adopted by anyone who wants to develop an SoC, but doesn't want to pay the ARM tax (like the already mentioned example of the ESP8266, or the SkyTraq NavSpark GPS).

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 09:44:08 pm
content: Quote from: edavid on January 23, 2016, 09:38:06 pmin this case, ins't better OpenRISC? OpenRISC cores come under the GPL, which requires that all derivative works also be open and free, while the RISC-V authors aim to provide several freely available CPU designs, under a BSD license, but (if I am correct) the BSD license allows derivative works such as RISC-V chip designs to be either open and free like RISC-V itself,or closed and proprietary

author: MrSlack
author_rank: Frequent Contributor
timestamp: January 23, 2016, 09:45:12 pm
content: I'd rather pay the ARM tax myself if I was building a product. There's enough experience out there to be able to solve any speed bumps you hit. Also TTM is likely lower on something vendored and staff fungibility is better with something more mainstream. Not all cost is production; a lot is R&D and support and you need.I'd rather write software with Erlang at work but it's not the real cost centre.

author: ataradov
author_rank: Super Contributor
timestamp: January 23, 2016, 09:45:53 pm
content: Quote from: legacy on January 23, 2016, 09:44:08 pmIn ideal world, yes. In ideal world we also have communism.In real world, it is not always possible to have things free and open.

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 09:54:22 pm
content: Quote from: MrSlack on January 23, 2016, 09:45:12 pmthis is my mind position (including gcc, which i'd rather prefer to avoid, and I pay keil and green hills myself)I was just trying to understand their motivations

author: ataradov
author_rank: Super Contributor
timestamp: January 23, 2016, 09:56:27 pm
content: Quote from: legacy on January 23, 2016, 09:54:22 pmBut the reality is, all those special use applications do want to avoid ARM tax, and use crap like Cortus and Xtensa. If you are picking between ARM and anything else, no contest, ARM wins. If you are picking Cortus vs. RISC-V, RISC-V wins, IMO.

author: MrSlack
author_rank: Frequent Contributor
timestamp: January 23, 2016, 10:10:33 pm
content: Quote from: legacy on January 23, 2016, 09:54:22 pmIndeed - can't stand GCC/gdb. LLVM+clang is my daily driver albeit on x86-64.

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 10:13:21 pm
content: Quote from: MrSlack on January 23, 2016, 10:10:33 pmgdb is pure crap from my point of view, even if I have developed (when I was a student) a gdb-stub for both my MIPS32 board (Atlas) and 68EC000 board (IDP)

author: MrSlack
author_rank: Frequent Contributor
timestamp: January 23, 2016, 10:19:07 pm
content: Quote from: legacy on January 23, 2016, 10:13:21 pmRather you than me. About as often as I use it now is backtraces from core files. Thank goodness for valgrind, unit tests and assertions sprinkled everywhere.

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 10:22:55 pm
content: Quote from: ataradov on January 23, 2016, 09:56:27 pmah, ok, understoodI am more "experienced" with NIOS* (Altera IP), and picoBlaze (Xilinx IP)I admit I still have no serious job experiences with SOC and uncommon "soft cores"I mean, when I happen to be involved with SOC I used an ARM ASIC coreand I developed all the hardware customization (VHDL side) around itso my experiences are: ARM chip attached to an FPGA, and the ARM side usually involves Keilwhile I happen to use green hills only for tasks in avionics, and I rarely used picoblaze and NIOS2practically I used them only when I was in academy, and I sometimes happen to use them for hobby

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 10:26:37 pm
content: Quote from: MrSlack on January 23, 2016, 10:19:07 pmyes, that is a good point, as I hate "CodePurify" and "VectorCast"

author: legacy
author_rank: Super Contributor
timestamp: January 23, 2016, 11:39:46 pm
content: basically you are using something likethis, I have a few positive hobby experiences with ARM

author: MT
author_rank: Super Contributor
timestamp: January 24, 2016, 07:39:46 pm
content: Quote from: HAL-42b on January 22, 2016, 09:01:24 pmOr maybe he just worked undercover for IBM/Microsoft who enjoy black box designs. Newer trust the words from a guru...

author: legacy
author_rank: Super Contributor
timestamp: January 24, 2016, 09:14:06 pm
content: Closed, end-to-end systemsin the new movie about Steve Jobs, the actor said- "so, you can send an email only from a NextCube to a NextCubebecause I want it closed, end-to-end systems" -that talk has begun years earlier, inside a garage, where Wozniak said "no, absolutely no!"The best Guru, ever

author: autobot
author_rank: Regular Contributor
timestamp: January 24, 2016, 09:53:50 pm
content: Quote from: AlxDroidDev on January 21, 2016, 10:50:50 pmThere was an eetimes story about support from Google and other big companies.

author: helius
author_rank: Super Contributor
timestamp: January 24, 2016, 10:46:00 pm
content: Quote from: legacy on January 24, 2016, 09:14:06 pmMovies are usually sexed up a lot (like the recent The Big Short which made commodity analysts much more exciting than they really are)In reality NeXT Mail was a regular mail client with the ability to display PostScript programs through the system PostScript interpreter (something shared with other Unix systems). This made it able to embed graphics, animations, and sounds in mail messages. It also had other abilities:Quote from: "RISKS Digest Volume 15 Issue 56" link=https://catless.ncl.ac.uk/Risks/16.56.html

author: legacy
author_rank: Super Contributor
timestamp: January 24, 2016, 10:58:10 pm
content: Quote from: helius on January 24, 2016, 10:46:00 pmin the movie, it happens becauseWoz said "no, I will never build what you want" (Apple-II, Jobs wanted 2 slots, Woz wanted 8 slots)other people said the same to mr.Jobs, persuading him to change his silly end-to-end idea (NextCube, iMac @ hello again)and so we get the NextStep kernel adopted by Apple, and used for the new Darwin (OSX) generationwhich comes to be BSD-like

author: legacy
author_rank: Super Contributor
timestamp: January 27, 2016, 12:05:38 am
content: specifically the RISC-V's ISA: what do you think, guys?

author: ataradov
author_rank: Super Contributor
timestamp: January 27, 2016, 12:20:02 am
content: Quote from: legacy on January 27, 2016, 12:05:38 amIt is new, so it did not have enough time to grow with all sorts of special cases and extensions.But the design is reasonably extensible, which is good.Instruction set itself seems to be reasonable and on par with any other RISC ISA.

author: legacy
author_rank: Super Contributor
timestamp: January 27, 2016, 12:37:51 am
content: I have downloaded it into my Kindle, and I am reading it carefullyI might grab (and learn) something interesting from them

author: legacy
author_rank: Super Contributor
timestamp: January 27, 2016, 10:18:12 am
content: analyzing RISC-V's ISA, compared to Epiphany

author: HAL-42b
author_rank: Frequent Contributor
timestamp: January 27, 2016, 01:57:11 pm
content: Quote from: legacy on January 27, 2016, 10:18:12 amRisc-V and OpenRisc are open RISC architectures. I think they have an advantage over x86.Epiphany on the other hand is a dark horse and is based on a very old favorite of mine - theTransputer.That architecture was far superior to x86 even in the 80's but it was British and the world monopoly had to be 'Merican. So the transputer died in obscurity while Intel took over the world.It is very interesting how the transputer eliminated the multi-core bottlenecks that early. Iann Barron is definitely worth listening to:

author: Kalvin
author_rank: Super Contributor
timestamp: January 27, 2016, 02:44:37 pm
content: Quote from: HAL-42b on January 27, 2016, 01:57:11 pmXMOS's XCORE is based in transpurter and is quite popular in real-time audio signal processing (DSP). The devices are quite inexpensive and the devices can process 1000MIPS - 4000MIPS per device. Each device can have 8 to 32 cores, and each core can run 50 MIPS up to 100+ MIPS. Some of the devices can have USB 2.0 PHY and Gigabit Ethernet RGMII interface, too. The programming is done in C with XMOS extensions. Basically no operating system is required as the task synchronization and communications is done at hardware level using the XMOS C priimitives. The user can create additional on-chip peripherals (like CODEC I2C interfaces etc.) using XMOS C and allocating one core for each I/O task without any overhead to system functionality or real-time performance. Pretty cool.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 27, 2016, 05:01:33 pm
content: Quote from: Kalvin on January 27, 2016, 02:44:37 pmXMOS is an under-appreciated and cool architecture that's worth taking a look at. It some ways it's like dealing with an FPGA where multiple things are happening in parallel and some people just can't wrap their heads around that.

author: ataradov
author_rank: Super Contributor
timestamp: January 27, 2016, 05:20:06 pm
content: Quote from: Sal Ammoniac on January 27, 2016, 05:01:33 pmXmos only looks "cool". In reality, what you can do is rather limited, so if your application calls for parallelism, then just stick with FPGAs. You will be able to use normal HDLs instead of some non-intuitive C with quirky parallel extensions.Low end Xmos devices available in reasonable packages are not capable of that much, and higher end devices are only available in BGA and require complicated power supplies. Just like FPGAs.

author: Sal Ammoniac
author_rank: Super Contributor
timestamp: January 27, 2016, 05:26:13 pm
content: Quote from: ataradov on January 27, 2016, 05:20:06 pmDepends on your background. Software people are more likely to grok the XMOS C extensions than Verilog/VHDL.

author: helius
author_rank: Super Contributor
timestamp: January 27, 2016, 06:46:53 pm
content: Quote from: ataradov on January 27, 2016, 05:20:06 pmI thought the word "intuitive" had already been banned by all thoughtful engineers? It is a red herring every time it appears.FPGAs are very bad at dynamic processes where you add or remove activities in response to certain conditions, because the allocation of resources to each process is fixed. The languages used (HDLs) don't help you to even understand the problem, and the chips have very primitive support for it.

author: legacy
author_rank: Super Contributor
timestamp: January 27, 2016, 07:41:57 pm
content: so, he said "future languages ? deprecate as many features as possible"

author: Kalvin
author_rank: Super Contributor
timestamp: January 28, 2016, 07:54:42 am
content: Quote from: ataradov on January 27, 2016, 05:20:06 pmAll depends on the application. The XCORE processors are quite easy for an embedded designer with C background wanting to do real-time DSP stuff, for example. The XMOS provides C compiler, the simulator and wealth of software examples how to do things:https://github.com/xcoreAnd 32x32bit MAC with 64-bit accumulator doesn't hurt either as you can process 24-bit audio quite nicely, for example. The DSP library is quite extensive:https://www.xmos.com/download/private/lib_dsp-%5Buserguide%5D%281.0.3rc1%29.pdfHere is XCORE DSP performance application note:https://www.xmos.com/de/download/private/AN01011%3A-DSP-performance-on-XS1-L-devices%281.0.1rc1%29.pdfOne core running at 50MIPS can perform- Single cycle channel communication between cores- Single cycle 32 * 32 into full 64 bit precision MACC instruction- Single cycle instruction latency- 16 million MACs / second- 20 biquad EQ filters, 48kHz- 100 tap FIR filter, 150kHz- 256 point fast FFT, 48kHz (8 bits)- AES decoder at 9 Mbits/secEach device can contain 8 to 32 of these cores and the inter-core communication is very efficient, the devices are very suitable for real-time signal processing. The performance of one core may not be too impressive (16 million MACS/s), but dividing the problem into individual blocks and running each block on a separate core, all cores running in parallel, the total performance may be quite impressive for a chip in $5 - $20 price range:www.digikey.com/product-search/en/integrated-circuits-ics/embedded-microcontrollers/2556109?k=XMOSI would say that it takes 10x - 100x less effort to implement  signal processing on XCORE compared to FPGA. The designer does not have to build the DSP-processing blocks, worry about interprocess-interfaces, write microcode assembler in order to get the algorithm implemented, write testbenches for each block, simulate and debug the damn thing. That said, the modern FPGA devices are wonderful beasts containing lots of DSP processing resources with a decent price-tag, but creating and completing the actual design can be a nightmare because of the reasons stated above.Edit: The XCORE might have been a suitable solution for David's 3D-printer as the G-Code parser and the motor controlling algorithms could have been running in parallel without a need for any G-code parser optimization:https://www.eevblog.com/forum/blog/eevblog-843-david's-rprint-3d-printer/I am not endorsing XMOS, but I see it as a good alternative for a real DSP-processor or FPGA.

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 11:26:22 am
content: Interesting. I wonder if the RISC-V specification is realized with ProjectOberon.I can ASSURE you that this 'RISC-V' is much like Professor Wirth's RISC5 processor for Oberon. You know, Professor Wirth, who invented Pascal.ProjectOberon.comis truly awesome. You have the whole kit: the Verilog files to synthesize the RISC5 'core', the excellent Oberon operating system which is developed in Oberon the language+compiler. All in LESS THAN 2mb. A full, graphical, OS, networking, mouse, keyboard, and sdcard file system on an FPGA.You need the right FPGA board (with the right ram setup). Several boards are available based on this open source project. Saanlima.com has several options just for ProjectOberon. Saanlima is the producer of the Pipistrello FPGA which is like a high end version of the Pipistrello from Gadget Factory. Here is the brand ne arrival:http://saanlima.com/store/index.php?route=product/product&product_id=64.You can actually just use the emulator to develop on to try out before you buy the FPGA board.http://www.paddedcell.com/projectoberon/RISCW32.zipI, honestly don't know of anywhere you have a system that you can actually begin to GRASP it all like Oberon. You really can know the whole system and nothing is too overly complex or hidden.Truly unique. Have a look!

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 02, 2016, 11:34:25 am
content: First time I hear about Project Oberon, seems very interesting. Thanks for introducing me.

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 12:01:54 pm
content: Quote from: HAL-42b on February 02, 2016, 11:34:25 amI just found the official webpage for the new Pepino. It must have just recently been added.http://www.saanlima.com/pepino/index.php?title=Welcome_to_PepinoI would love to see Dave do 'unboxing video' of this one. I know he doesn't do silly 'unboxing videos' but this one might be a fun exception, just to demonstrate how simple you can build up this whole system from raw Verilog to a full blown development station, ON A WHIM! I had zero problems as a total noob with FPGA's to get Oberon going on the Pipistrello.

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 01:10:18 pm
content: Quote from: Sal Ammoniac on January 27, 2016, 05:26:13 pmHow about this:Lola-2 (LOgical LAnguage)Lola-2 is a Verilog pre-processor written in Oberon. It takes the cryptic edge off of Verilog and presents it in a very understandable 'pascal-ish' dialect. It is really effective to help you actually see what is happening more intuitively.Here is what's going to blow your mind: here is the Lola-2 code to BUILD THE COMPLETE PROJECTOBERON! Yes, Professor Wirth has the full RISC5 processor described in Lola-2 which compiles the Verilog files, which compiles the processor, which compiles the Oberon OS, which hosts the Oberon compiler....that compiles Lola-2!!!!How 'complete-round-trip' is that?Read the last line of the Lola-2 documentationhttps://www.inf.ethz.ch/personal/wirth/Lola/LolaCompiler.pdfTo show the viability of Lola, the entire RISC processor, including its environment and deviceinterfaces, has successfully been expressed in Lola

author: legacy
author_rank: Super Contributor
timestamp: February 02, 2016, 01:25:29 pm
content: Quote from: captbill on February 02, 2016, 12:01:54 pmthe ram is not enough: only 2 MBytes (in the PRO version)

author: coppice
author_rank: Super Contributor
timestamp: February 02, 2016, 01:47:22 pm
content: Quote from: HAL-42b on January 27, 2016, 01:57:11 pmThey certainly didn't eliminate the multi-core bottleneck. In the released silicon the communications channels were so crippled it didn't even alleviate the bottlenecks much. Most Transputer designs were limited by comms bandwidth.

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 01:56:12 pm
content: Quote from: legacy on February 02, 2016, 01:25:29 pmNot enough ram for what though? This little puppy will compile the whole system from the ground up in less than a minute (or was that 10 seconds?), or something crazy like that. It is very fast and I have never witnessed any lag that I remember. It also, if you dig into the specs, is only running at a measly 25mhz but I can't find anything 'slow' !! Astonishing really. I can't even imagine why I would need any more ram. In fact, if you buy the 2mb version, you will have wasted ram while Oberon is running. The 2mb 'Pro' version is to accommodate some of the other bitfiles like MacintoshPlus, Pac-Man, Doom etc.Granted, it is not going to do 3d graphics with only a 1mb frame buffer, but this is a development system built for learning and as such has a 'simple as possible but not simpler' philosophy. The minute you add on high capacity ram you will have greatly over-complicated this beautifully simple design. Besides, nothing is to stop you from adding anything you need/desire. You simply build your own Ram.v design.

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 02, 2016, 01:59:34 pm
content: Quote from: coppice on February 02, 2016, 01:47:22 pmThey did that in the era when the closest competitor was strictly single core. By reducing the need for inter-core communication they designed around the connectivity bottleneck.Moreover, they proved even then that parallel computing can't be solved in software.

author: legacy
author_rank: Super Contributor
timestamp: February 02, 2016, 02:00:32 pm
content: preface: I do not like fanatics and fanboys, including gnu-boys, apple-boys, and oberon-boysQuote from: captbill on February 02, 2016, 01:56:12 pmto put a few useful applications on, including debuggers2 Mbyte is definitively too pooralso, I'd like to recycle the fpga board for other projectsand again, the ram is too poor!

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 02:02:26 pm
content: Quote from: legacy on February 02, 2016, 02:00:32 pmWell, this is definitely not for you then.

author: legacy
author_rank: Super Contributor
timestamp: February 02, 2016, 02:05:48 pm
content: Quote from: HAL-42b on February 02, 2016, 01:59:34 pmI'd like to see the Epiphany, and hear about real-life feedbacks from usersunfortunately it seems that only a few guys are using itand as far as I read, the IV 64-core Microprocessor (aka E64G401)is going to have its End of Lifea kit costs ~250 euro (from Amazon), which is a bit expensive for meand to tell you the Truth, I am tempted to "try" the fun in first person

author: legacy
author_rank: Super Contributor
timestamp: February 02, 2016, 02:09:16 pm
content: Quote from: captbill on February 02, 2016, 02:02:26 pmI think soI am interestedonlyin the RISC-V coreand I am going to home-build a Papilio/PRO-like boardit will come with 8Mbyte, which is exactly what I need

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 02:22:03 pm
content: Quote from: legacy on February 02, 2016, 02:09:16 pmI didn't intend to derail your thread. Although it wasn't too clear if you were interested in options in the RISC5 department generally or if you were specific to the 'RISC-V' from the link you provided.Just to clear up your ram concerns: all your programs are stored on an sdcard so no worries there. The 'flash ram' that houses the bitfiles is 16mb, much more than comes standard with most FPGA dev boards. Oberon only takes 2mb so you have plenty of room for many more. Oberon boots in less than two seconds. I can go from Oberon to Pac-Man in less than 5 seconds and that is manually. Store them in flash and switch them in probably 2.5 seconds.Regards

author: coppice
author_rank: Super Contributor
timestamp: February 02, 2016, 02:32:52 pm
content: Quote from: legacy on February 02, 2016, 02:05:48 pmIf you just want to experiment to get a feel for the potential of these things, the E16G301 board is only $99 at Amazon. The E64G401 is EOL, but they don't appear to have a follow on part. It looks a lot like a business starving to death. Iann Barron is quite dismissive of nVidia in the video posted above, but they did make sure to build a sound funding base before they tried high performance computing. They also made sure every device had a good market even if HPC didn't work out. Even if Epiphany has real potential, I don't see how someone like Adapteva can hope to survive through the lean years until they reach decent revenue.

author: coppice
author_rank: Super Contributor
timestamp: February 02, 2016, 02:44:03 pm
content: Quote from: HAL-42b on February 02, 2016, 01:59:34 pmThey didn't reduce the inter-core comms much. That was the problem. When they came to implement 4 proper message passing comms ports they found the silicon area needed was substantial. So, they ended up with fairly primitive ports and a lot of software overhead for comms.Quote from: HAL-42b on February 02, 2016, 01:59:34 pmThey didn't prove that. It appears to be true, but they didn't prove it. Every successful highly parallel machine to date has use predominantly hardware to make the parallelism work well, from the MPP to an nVidia GPU. That's not a proof of anything, though. I don't know whether Iann Barron was the one to instigate the use of hardware context switching while an Elliott Bros, or whether he picked it up from other people there. Elliott, and later GEC Computers, used a predominately hardware method of context switching until their end days. Although they never had the resources, or perhaps the motivation, to expand that idea into highly parallel machines, the framework was actually there and worked well. Running real time multitasking stuff on their single core machines was very efficient.

author: edavid
author_rank: Super Contributor
timestamp: February 02, 2016, 03:31:39 pm
content: Quote from: captbill on February 02, 2016, 11:26:22 amI can assure you that it's not... the Wirthian languages have zero influence or following in the US (for good reason, in my opinion).

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 04:18:14 pm
content: Quote from: edavid on February 02, 2016, 03:31:39 pmI will agree with the 'no following' part but zero influence? The man is the most watched player in all of the programming industry. C++ was created just to keep up with Delphi's success which is built from Pascal.I'm sorry, but even the looks of this 'RISC-V' spec looks like Oracles' answer to Professor Wirth's RISC5. I think they are very intimidated by 'ProjectOberon', frankly.I would LOVE to see an honest matchup here. You? Or are you just going to be run around in the maze of never-ending complexity because "everybody is doing it"?

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: February 02, 2016, 06:43:12 pm
content: Quote from: captbill on February 02, 2016, 04:18:14 pmc++ (1979 at bell labs), (delphi) object pascal (1986 at apple).....

author: Kalvin
author_rank: Super Contributor
timestamp: February 02, 2016, 06:55:50 pm
content: Quote from: BloodyCactus on February 02, 2016, 06:43:12 pmBoth Stroustrup's C++ and Borland Inc.'s Turbo Pascal ($49 USD) appeared first in 1983. At first the C++ compilers were slow, generated poor code, and were expensive compared to Turbo Pascal, thus Turbo Pascal was very popular among the hobbyist. Turbo Pascal was replaced by the Borland Delphi in 1995.https://en.wikipedia.org/wiki/C%2B%2Bhttps://en.wikipedia.org/wiki/Turbo_Pascal

author: captbill
author_rank: Contributor
timestamp: February 02, 2016, 07:14:39 pm
content: http://cs.brown.edu/~adf/programming_languages.htmlIn the late 1970’s and early 1980’s, a new programing method was being developed. It was known as Object Oriented Programming, or OOP. Objects are pieces of data that can be packaged and manipulated by the programmer. Bjarne Stroustroup liked this method and developed extensions to C known as “C With Classes.” This set of extensions developed into the full-featured language C++, which was released in 1983.Pardon the imprecise history I stated. I could have swore C++ came later. C++ was actually C's version of OOP Pascal which most certainly was and still is the prime mover in many aspects.The whole thing to understand is that the 'Wirthian' approach was and still is the one everyone attempts to emulate. Have you guys ever seen Lazarus/FreePascal? It has far excelled even Delphi, and it just keeps getting better and better.http://www.lazarus-ide.org/

author: BloodyCactus
author_rank: Frequent Contributor
timestamp: February 02, 2016, 07:20:24 pm
content: Quote from: Kalvin on February 02, 2016, 06:55:50 pmwhich is nice and all except captbill specifically said c++ was created to keep up with delphi... only c++ predates delphi (1995) and what delphi is built on (object pascal, 1986) by quite a bit.being in ram compiler, turbo pascal was interesting, but still pascal and was not yet object pascal.

author: eas
author_rank: Frequent Contributor
timestamp: February 03, 2016, 01:08:21 am
content: Quote from: captbill on February 02, 2016, 07:14:39 pmOOP was broached in the 60's and most of the concepts were really fleshed out with SmallTalk, which started in 1972, though it wasn't made publicly available until 1980.It's kind of silly to say that wirthian languages don't have much influence in the US when one considers that Pascal was everywhere in the microcomputer world of the late 70s and well into the 80s. The original Macintosh APIs were designed to be called from Pascal. TurboPascal was quite popular on PCs until Microsoft managed to seize more control over the PC software ecosystem with Windows 3. Even then, Delphi was quite popular for Windows development. The creator of the TurboPascal compiler was heavily inspired by Wirth, went on to be the architect of Delphi AND C#.On the other hand, its probably true that most of Wirth's impact dates from work he did decades before. The same is probably true of Allan Kay (who worked on SmallTalk). I appreciate though that both seem to remain interested in designing modern, full-featured, networked computing environments that are compact, coherent, and understandable. Whether either of their later work ends up being widely adopted, I expect both will have some influence on whatever emerges once Moore's Law runs its course.

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2016, 06:29:16 am
content: I am going to completed my TAP (debug processor)I can say that it has been designed for pre-pipelined machines (e.g. 68k, 6809)so, it also works great with multi cycles (the R2K version described in MIPS book)while it has a LOT of problems with pipelined-coresin first place, I can't easily do "code injection"I am going to try to add my TAP to RISC-V core, in its easiest formpersonally I thing its ISA is very well done, and so the HDL code!

author: captbill
author_rank: Contributor
timestamp: February 03, 2016, 08:16:09 am
content: I have been looking closer at the RISC-V and I have to say that it is quite obviously, a direct challenger to Professor Wirth's RISC5. In fact it looks to me to be simply a much more complicated version of the brilliantly simple ProjectOberon RISC5 core. One might even say 'hey, this is a fake imposter of the true RISC5, beware!!'.How about simply have a head to head challenge?Here is 'Angel' the web based emulator for 'RISC-V'http://riscv.org/angel/index.htmlAnd here is the Oberon equivalent, that you cannot tell me wasn't where 'Angel' was inspired:http://schierlm.github.io/OberonEmulator/So far, for me, all 'Angel' does is appear to load for about 10 seconds and the freeze up, with a note that I need to install Chrome to make it load reasonably fast. Been waiting for over an hour and nothing. I do get a blinking cursor though.The Oberon emulator opens almost immediately. Definitely less than 1 second. I will admit, getting a "HelloWorld" is tricky because the backspace causes the browser to do a backpage. Were it not for that, it appears to be surprisingly workable.Now I will go try the RISC-V downloadable emulator for an honest test.

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2016, 08:32:39 am
content: Quote from: captbill on February 03, 2016, 08:16:09 amI could try to add my TAP to this core, too.and It will be interesting, as it comes with less complexity.

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2016, 09:01:03 am
content: Quotefound while I was googling

author: captbill
author_rank: Contributor
timestamp: February 03, 2016, 09:32:35 am
content: Quote from: legacy on February 03, 2016, 09:01:03 amVery interesting. What is the link to the original or what search term will get me there?I think it is most important to carefully note this statement:QuoteHe is apparently making a positive reference to "Oberon the language" which is truly a step forward in the programming language realm. We have only discussed the RISC5, the "core", up until now. It is Oberon the language you will really come to appreciate, as the author seems here to be pointing out. Pay close attention to that right there.I assume by 'Oberon System Modules' he means the 'core' with the 'Oberon OS modules'. He could actually be referencing the 'Oberon Verilog Modules'.

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2016, 09:51:08 am
content: Quote from: captbill on February 03, 2016, 09:32:35 amhereit is

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2016, 10:06:10 am
content: andhereit is a little topic about Oberon on Papilio/pro

author: westfw
author_rank: Super Contributor
timestamp: February 03, 2016, 10:17:38 am
content: (heh. In the commercial world, you get your core and/or chip using it "good enough", ship it, and compete with other vendors' decisions in the marketplace, where factors other than elegance and architectural excellence come into play (support, availability, salesmanship, price, bundling, tools, community, and more.) (We can all come up with examples of extremely popular products that do not seem to reflect the best core design choices...) In academia, the personalities are no less intense, the competition no less fierce, but those "other factors" have a lot less weight; dueling papers and a grab for the most grad students, or something.)(I took part of a Smalltalk class back about 1985, when I was working at Stanford. I was quite negatively impressed with just how slow they managed to make a maxed-out (for the time) SUN workstation run. OTOH, given how fast Moore's law pushed performance, maybe they were right to not care...)

author: legacy
author_rank: Super Contributor
timestamp: February 03, 2016, 10:39:10 am
content: Quote from: westfw on February 03, 2016, 10:17:38 amlucky you are, I envy you

author: captbill
author_rank: Contributor
timestamp: February 03, 2016, 05:25:17 pm
content: Quote from: legacy on February 03, 2016, 09:51:08 amThat is hilarious. The first link is 'Wojtek' in a discussion at the Oberon mailing list a everyone (including me) was searching for a compatible FPGA board for ProjectOberon. There were no FPGA development boards that had suitable ram setup. We were all knocking around ideas then.The second link is ME (look at the OP's name), over at the Papilio forum begging for someone to try to fit it on the Papilio. That is the very thread that tipped off Magnus at Saalima about ProjectOberon. He obviously 'saw the light' and less than a week later he had Oberon running on the Pipistrello.A small world indeed. haha

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 03, 2016, 05:51:31 pm
content: Ok, what exactly is the light?I have no experience with Oberon. It is obviously small and simple, which is nice but what exactly is setting it apart?I watched one of Wirth's lectures start to end but it was rather autobiographical and didn't go into detail. I probably watched the wrong thing. Is there anything where the architecture is explained?

author: captbill
author_rank: Contributor
timestamp: February 03, 2016, 06:53:24 pm
content: Quote from: HAL-42b on February 03, 2016, 05:51:31 pmIt is all very nicely document to a very high degree. Everything is spelled out in the PDF's listed at ProjectOberon.com. Everything you need is on this one page.Lot's of other exciting gems to be found at Professor Wirth's personal homepage. It's a goldmine, I tell ya:https://www.inf.ethz.ch/personal/wirth/How about comparing the 'official spec sheets' of both RISC5 and RISC-V:RISC-V:http://riscv.org/download.html#tab_spec_user_isaRISC5:https://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC-Arch.pdf

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 04, 2016, 02:16:37 am
content: Seems like the utter simplicity itself, I love it!Definitely the best core for learning VHDL and processors.

author: JoeN
author_rank: Frequent Contributor
timestamp: February 04, 2016, 04:03:19 am
content: "32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."128 bit address space? What is this good for? 64 bit is 16 EiB. Are we pushing this for any computer system? Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB. So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far. I guess it might be useful sometime in the semi-near future. When do you think the first computer with 16 EiB of memory will becomesentientoperational?https://en.wikipedia.org/wiki/Tianhe-2

author: HAL-42b
author_rank: Frequent Contributor
timestamp: February 04, 2016, 04:14:16 am
content: Quote from: JoeN on February 04, 2016, 04:03:19 amNot much use if you think in terms of a normal Von Neumann machine. Extremely useful if your memory consists of many physically separate chunks which you may want to share or isolate according to some criteria.Extremely useful for security in multi-processor systems.For example if you want cores A B C D to be able to read from a chunk of memory but only cores D E to be able to write to it. Wide address space lets you manage this in a single instruction, moreover it lets you to verify its security in hardware, regardless of the code running.In a sense it lets you program with your soldering iron, which I like, a lot.

author: C
author_rank: Super Contributor
timestamp: February 04, 2016, 05:24:28 am
content: Quote from: JoeN on February 04, 2016, 04:03:19 amHow about simple hardware reducing software load.Storage directly mapped to memory space.the simple memory management hardware would know if a write back was needed.

author: JoeN
author_rank: Frequent Contributor
timestamp: February 04, 2016, 05:40:51 am
content: Quote from: C on February 04, 2016, 05:24:28 am128 lines just to put an address on the bus.Commensurate decoding logic for every memory mapped device.etc.

author: ale500
author_rank: Frequent Contributor
timestamp: February 04, 2016, 06:05:18 am
content: 64 bit Processors today don't use 64 bit physical addresses anyways, they have like 42 or 48. It is an extensible ISA, they prepared it for growth, if tomorrow there is a new way of cpu in terms of quantum something of trinary systems or whatever, it may remain unused. But at the current rate, maybe in 10 years are 128 bit systems a real possibilityThe RISC5 verilog shows a very compact and simple design of a 1 cycle CPU. Very nicely done. With the same concepts I designed a RISCV core, it mostly worksThere is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult... too many projects...I tried the simulator and I find it just great. The kind of fun that where home computers some time ago, no windows, no drivers, no updates every other day...

author: captbill
author_rank: Contributor
timestamp: February 04, 2016, 06:48:38 am
content: Quote from: legacy on February 03, 2016, 08:32:39 amA TAP interface. I had to look that one up. "Test Anything Protocol" you mean? Sounds very interesting. So you have some 'TAP interface routines' you could apply to the RISC5, which sets up 'taps' for probing signals via JTAG? I have no clue how to go about 'tapping' the actual core but will gladly test anything like that on my setup. One question: does all this happen over USB or would you be physically probing some pin with a logic analyser?

author: helius
author_rank: Super Contributor
timestamp: February 04, 2016, 07:16:58 am
content: A TAP is a Test Access Port, for monitoring theinternalmemories of the CPU. It is needed for detailed testing and instrumentation of the CPU, for instance to capture or replay pipeline stalls, hazards, and exceptions. The interface from it to the debug host can be anything, but a serial protocol like SWD or JTAG would be a usual choice; USB would be absurd.IEEE 1149.1 JTAG only has access to I/O pins; to implement real emulators and trace tools you must have a logic block with special access to internal data and control paths.

author: legacy
author_rank: Super Contributor
timestamp: February 04, 2016, 11:06:57 am
content: Quote from: helius on February 04, 2016, 07:16:58 amall of the above, but my TAP is not jtag driven, it implements a custom protocol which does not look like SWDI am developing for hobby, tempted to put it on business, may be

author: legacy
author_rank: Super Contributor
timestamp: February 04, 2016, 11:33:52 am
content: Quote from: ale500 on February 04, 2016, 06:05:18 amwhile the Oberon mini FPGA board costs up to 150 USD

author: legacy
author_rank: Super Contributor
timestamp: February 04, 2016, 04:30:55 pm
content: so, they are both pronounced "risk-five", even if Risc-5 is Oberon, while Risc-V is Berkeley, and they are two different projects with little things in commonthisXcell article talks about Oberon System implemented on a low cost fpga, with a little review of the whole.

author: captbill
author_rank: Contributor
timestamp: February 04, 2016, 08:33:06 pm
content: Quote from: ale500 on February 04, 2016, 06:05:18 amHow about this:Just like the ProjectOberon emulator, there is a Macintosh Plus core + emulator up and running on the Pipistrello/Pepino.You have to see this Mac+ emulator...awesome. In fact, I don't remember being able to load and run an 'emulator' of any sort without lot's of setup hassles, do you? These you just download and run like any other 'application'. I haven't yet flashed this to the Pipistrello, on the 'real hardware' mainly because the emulator is just so awesome.http://saanlima.com/store/index.php?route=module/blog/view&blog_id=9I literally have only played around with this core and managed to find and install ThinkPascal, which to this day has the neatest debug facility I have ever seen. I even found a full TCP stack written in ThinkPascal!...which I am very tempted to hook up to my new fangled ESP8266 'transparent UART' I just managed to get running with this thing.This is probably a fun project for one of you Mac enthusiasts out there. I will be glad to assist where I can. Of coarse, to be fair and legal, the way to go about it is to find an old MacPlus on Ebay and build an awesome supercharged Mac+.I think the <$200 price point is a great bargain when you consider all you are getting here. You want your FPGA development system to be oversized and not undersized. You can design small projects on oversized boards but you cannot build a big project if you have an undersized FPGA.**BEEP ALERT lower your volume**https://youtu.be/GM59aJmsZ4g

author: C
author_rank: Super Contributor
timestamp: February 04, 2016, 10:06:48 pm
content: One thing I noticed on the very quick read of the risc-VThe section where they state it is a little endian machine and ethernet is big endian.If you want to talk to something other then more risc-V you need to match.If it does not match then you have to spend more instructions to make it match.If you have a data structure then you are adding the convert to and convert from this data structure functions.Extra programming that could be slow as it is not the normal way the CPU would access the data.If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

author: edavid
author_rank: Super Contributor
timestamp: February 04, 2016, 11:51:54 pm
content: Quote from: C on February 04, 2016, 10:06:48 pmYes, this is why we don't connect our X86 and ARM based computers to Ethernet

author: C
author_rank: Super Contributor
timestamp: February 05, 2016, 03:56:43 am
content: Quote from: edavid on February 04, 2016, 11:51:54 pmJust wanted to quote something and respond and skip the read the whole thing part.Slower, more problems and more software does not prevent!Just burns up a bunch of computer time.

author: helius
author_rank: Super Contributor
timestamp: February 05, 2016, 04:28:11 am
content: There are many different endian conventions used in I/O devices. When comparing CPU architectures, the main difference is thebyte orderbetween big-endian (e.g. Motorola) and little-endian (e.g. Intel) architectures. With I/O, it's the order ofbitsthat matters, which is independent of the CPU's byte order. For example, serial links such as RS-232 are LSB first, and Ethernet is MSB first. The conversion takes place in the I/O hardware, takes no time at all, and is very rarely of concern to software.A different issue yet again are interchange formats, that are defined so that data will have a consistent format regardless of the hardware used. Most Internet protocols are defined with big-endian numbers and macros likehtons()are used to maintain this ordering. Some formats like ISO9660 CDROMs or DVDs consistently store two copies of numbers, one big-endian and the other little-endian. This is an issue for all computers and there is no way to avoid it by choosing the "right" byte order in hardware. If you have a byte-swap instruction it is very fast to do the conversion though.

author: westfw
author_rank: Super Contributor
timestamp: February 05, 2016, 10:05:43 am
content: QuoteAlmost all of today's processors are little endian. Most of them have some sort of byteswap instruction, so if you do things right, you end up adding a nanosecond or so to each 20+ns memory read or write. Hardly deadly. A near-SOTA intel processor with the Intel bi-endian compiler, with EVERYTHING in memory byteswapped, still out-performs a near-SOTA big-endian CPU. Been there, did the tests, shipped the product...

author: coppice
author_rank: Super Contributor
timestamp: February 05, 2016, 10:15:48 am
content: Quote from: C on February 04, 2016, 10:06:48 pmMost machines are little endian these days, but swapping bytes around can be done quickly on most machines. Its often just a single instruction. What really hurts performance when building or dissecting message buffers is the inability to perform misaligned reads and writes. If you have to chop up words to pack them into a transmit buffer things get really slow. On machines which support misaligned reads and writes they are usually a bit slower than aligned ones. However, its much much faster than chopping things up and manipulating them in software.

author: legacy
author_rank: Super Contributor
timestamp: February 05, 2016, 10:39:06 am
content: Quote from: coppice on February 05, 2016, 10:15:48 amMIPS can have misaligned-load/store instructionswhy slower ? do you mean because it implies two sub-cycles, so the pipeline needs to be stalled twice ?

author: helius
author_rank: Super Contributor
timestamp: February 05, 2016, 03:42:45 pm
content: Memory is always several times slower than instructions, so all software realignment does is increase code size. If you understand what you're doing you don't define unaligned data fields in the first place.Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

author: coppice
author_rank: Super Contributor
timestamp: February 05, 2016, 04:46:42 pm
content: Quote from: helius on February 05, 2016, 03:42:45 pmWhen you are dealing with comms protocols you rarely get to choose whether things are aligned.

author: C
author_rank: Super Contributor
timestamp: February 05, 2016, 08:51:30 pm
content: Quote from: helius on February 05, 2016, 03:42:45 pmSuggests that inside processor should be risc to keep small CPU while in memory should be CSC to lower memory use.

author: edavid
author_rank: Super Contributor
timestamp: February 05, 2016, 09:07:47 pm
content: Quote from: helius on February 05, 2016, 03:42:45 pmThat's odd, since MIPS doesn't have misaligned load/store (it uses LWL/LWR/SWL/SWR instead).

author: legacy
author_rank: Super Contributor
timestamp: February 05, 2016, 09:31:24 pm
content: in MIPS, lwl/lwr and swl/swr are for accessing unaligned words in memory.The actual specification is complicated, but what it boils down to is thatlwl RT, offset(RS)lwr RT, (offset+3)(RS)loads the 32-bit value starting at RS+offset, no matter what the alignment of that address is. swl/swr behave analogously.RFE rotates the lower six bits of the status register by two to the right, so the "previous" interrupt/usermode state becomes the current state and the "old" state is copied into the "previous" state. This inverts what happens on an exception. RFE is normally found in the delay slot of a jump instruction of some kind.

author: justanothercanuck
author_rank: Frequent Contributor
timestamp: February 07, 2016, 11:02:20 am
content: i haven't seen a RISC (besides ARM) since PA-RISC... that horse should have stayed dead.

author: legacy
author_rank: Super Contributor
timestamp: February 07, 2016, 11:40:19 am
content: emmm, don't forget to mention the MIPS horse in your router

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 07:19:56 am
content: Quote from: ataradov on January 21, 2016, 07:48:49 pmSorry to reply to such an old topic, but we're all just getting hardware now :-) Has your HiFive1 arrived yet?What is it you're not impressed about with the instruction set?I think the design is very elegant and even with the gcc somewhat immature comparisons of compiled C code with other ISAs show RISC-V to be very competitive with x86, x86_64, ARM, Aarch64 on things like number of instructions needing to be executed (especially if you count uOps for x86, not instructions), code size etc.There are some fairly obvious things missing from the base instruction set that help some specialised tasks: popcount, count-leading-zeros, bitfield extraction and insertion. There isn't even a rotate instruction :-) It does pretty well even without those, but a "B" standard extension is being designed right now. Even Intel only introduced many of those fairly recently in x86 history e.g. popcount in Nehalem and clz in Haswell!

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2017, 07:26:14 am
content: Quote from: brucehoult on February 09, 2017, 07:19:56 amGot a tracking number today. Should be here in a few days.Quote from: brucehoult on February 09, 2017, 07:19:56 amIt is a typical RISC. It is good for simplicity, but not really for performance. Fewer of short, but more capable instructions means better cache utilization. It does not matter how many cycles (uOps) it takes to execute a complex CISC instruction, getting it to the core is the slowest process in reality.Quote from: brucehoult on February 09, 2017, 07:19:56 amExactly.

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 08:08:06 am
content: Quote from: C on February 05, 2016, 08:51:30 pmExcept that it turns out that the smallest code (from existing, real compilers at least) is for RISC ISAs with 16 bit instructions or even better a mix of 16 and 32 like Thumb2 and RISC-V. Compiler-generated i386 code is pretty bloated, and x86_64 adds an extra REX byte to a large percentage of instructions. VAX code wasn't all that compact either.Some purists will say "It's not real RISC unless there is only one length of instruction". Pragmatically, two instruction lengths is a heck of a lot better than "anything you like, from 1 to 15 bytes -- and you have to decode almost all the bytes before you even know how long the instruction actually is". On Thumb2 you can tell the instruction length from the first 4 bits, and on RISC-V from the first 2 bits.Interestingly, this is something IBM got right 50 years ago with the IBM 360. Instructions could be 2, 4, or 6 bytes long and you could tell the length from the first two bits. Something else they got right was that each instruction has at most one operand in memory (one of the few redeeming features of x86).

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2017, 08:16:50 am
content: Quote from: brucehoult on February 09, 2017, 08:08:06 amDoes not make much of a difference. You are thinking how hard it is to make a decoder, not how fast the resulting decoder is. Most X86 instructions are decoded via combinatorial logic, it is just much more complicated, but it does not matter all that much. Well, except for parameters that have noting to do with computational performance, like power consumption and die area.The fact is, today X86 has the best performance of all available architectures. It is not just ISA, it is a general architecture of the system. X86 is incredibly complicated, that's why all home brew cores are RISC, something average person can actually comprehend.AArch64 may get somewhat close, especially considering much better power consumption and lower price, but that's in the future.

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 08:38:29 am
content: Quote from: ataradov on February 09, 2017, 07:26:14 amI agree that program size and making best use of L1 instruction cache and fetch(&decode) bandwidth is one of the most important things. Not only for speed but especially for power usage.The Berkeley guys have shown that across SPECINT by far the smallest code sizes for 32 bit ISAs are Thumb2 and RISC-V, while for 64 bit RISC-V stands alone as it's the only one with 16 bit instructions available.Thumb2 is a couple of percent smaller because of PUSH/POP multiple at function entry/return. Interestingly, that's been deprecated even in 32 bit mode in ARMv8 and new code is encouraged to use load/store pair and compilers already do so if you specify -march=armv8.RISC-V has a trick to replace PUSH/POP multiple when code size is the most important thing: using a non-standard link register (e.g. t0) to call special subroutines to push or pop a set of registers. If you don't insist on a complete set but just, say, a choice between ra&s0 or ra&s0-s1 or ra&s0-s2 or ra&s0-s6 or ra&s0-s11 (i.e. 2, 3, 4, 8, or 13 registers) then it's a total of less than 200 bytes of library code.riscv-gcc already has an experimental flag to do this -msave-restore and later it will probably migrate to being standard for -Os or -OzDid you see my little counting primes benchmark I've tried on the HiFive1 and a bunch of other things? The RISC-V code turned out to be by far the smallest, 10% less even than Thumb2. The ARM code uses push/pop multiple to free up enough registers, but because it has 32 registers including 15 volatile registers (8 argument plus 7 temp) RISC-V turned out not to need to save/restore anything at all.https://www.eevblog.com/forum/crowd-funded-projects/raspberry-pi-zero-82789/msg1131652/#msg1131652

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2017, 08:47:41 am
content: Quote from: brucehoult on February 09, 2017, 08:38:29 amThat's because there are lots of problem with them, especially with bus time scheduling and interrupts with the need to either increase interrupt latency or implement abandoning.Quote from: brucehoult on February 09, 2017, 08:38:29 amAVR-GCC did this from the beginning with -mcall-prologues.Quote from: brucehoult on February 09, 2017, 08:38:29 amI'm not sure if I'm interested in code size anymore. Flash is reasonably cheap, and in reality, price difference between different flash size MCUs is not that huge (for adjacent memory sizes that is). QSPI flash is even cheaper and can be as fast as embedded flash. I'd rather see manufacturers move in that direction.

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 08:51:36 am
content: Quote from: ataradov on February 09, 2017, 08:16:50 amNot too much in the future. Apple's A10 in the iPhone 7 is faster than the x86s that have been in MacBook Airs. The A9x in the iPad Pro is thereabouts too.Not that hobbyists have access to those. The Odroid XU4 is the fastest cheapish ARM SBC I know of, with a 2 GHz quad A15. It turns out that (at least on that one benchmark I just gave a link to) RISC-V on qemu on an i7 is slightly faster!Turns out riscv-qemu is around 2.5 times faster than arm-qemu or aarch-qemu. I think that's mostly because there is no need to emulate condition codes, and the translation of RISC-V's "compare and branch" instruction "cmp rx,ry;bxx" is fused into a single uOP on recent x86s.

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2017, 08:56:23 am
content: Quote from: brucehoult on February 09, 2017, 08:51:36 amI'll believe it, when I see desktop machines running on ARM and not being painfully slow, like some ARM-based Chromebooks.

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 08:58:47 am
content: Quote from: ataradov on February 09, 2017, 08:47:41 amThen I don't understand what you meant a few minutes ago when you wrote "Fewer of short, but more capable instructions means better cache utilization. It does not matter how many cycles (uOps) it takes to execute a complex CISC instruction, getting it to the core is the slowest process in reality."Small code size makes better use of cache and fetch bandwidth, both among the most power hungry things, which is important in both battery powered embedded and in racks of servers with thousands of cores. The only place it doesn't matter now is laptops and desktops :-)

author: ataradov
author_rank: Super Contributor
timestamp: February 09, 2017, 09:01:20 am
content: Quote from: brucehoult on February 09, 2017, 08:58:47 amThat jump to the register load/store place incurs slow jump instruction and additional cache fetches for that load/store code. I don't really care if each function has all of its register saves/restores explicitly listed.

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 09:26:44 am
content: Quote from: ataradov on February 09, 2017, 09:01:20 amThat's correct of course.But the call/return are only 1 cycle each (thanks to BTB and return address stack -- even on HiFive1) and the code will be shared by so many functions that it probably stays in cache. With even 16 KB of L1 it should even reduce cache pressure overall -- that only requires each prologue/epilog routine to be used from two functions (especially if one of the larger ones is).But if you don't want to pay that then fine, put your save&restore code inline. You'll still only be a couple of percent bigger than Thumb2 and smaller than anything else (much smaller on a 64 bit system).

author: hamster_nz
author_rank: Super Contributor
timestamp: February 09, 2017, 08:55:04 pm
content: Quote from: brucehoult on February 09, 2017, 08:08:06 amNot wanting to be pedantic, but from my youth I remember MOVS/MOVSB/MOVSW/MOVSDMove byte/word/dword from DS:[(E)SI] to ES:[(E)DI]http://www.fermimn.gov.it/linux/quarta/x86/movs.htmPS. My HiFive1 is everything that was promised - everything I tried worked. So it is now living on the shelf looking for a project. About the only thing that surprised me was I/O was a little bit slower than I am used to with a uC - 9 or so cycles per register access.

author: legacy
author_rank: Super Contributor
timestamp: February 09, 2017, 09:35:24 pm
content: Quote from: brucehoult on February 09, 2017, 07:19:56 amno problem, glad to see new postsQuote from: brucehoult on February 09, 2017, 07:19:56 amwhich hw are you talking about? Here I am on fpga

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 09:42:29 pm
content: Quote from: hamster_nz on February 09, 2017, 08:55:04 pmYes, I'm aware of that :-) That's one of the big warts on x86 and at various times has run a lot lot slower than writing a loop or unrolled code yourself. *Especially* as you may have had to load one or both of DS and ES beforehand, and that's been a major cycle suck, depending on which CPU.You could do a segment override to make it copy both from and to ES, but that turns out to have had a major problem early on .. see "Chapter 27, In Which It Blows Up In My Face" here:https://trixter.oldskool.org/2013/01/18/optimizing-for-the-8088-and-8086-cpu-part-3-a-case-study-in-speed/Note that normal x86 instructions have one register operand and one register/memory operand. They might both read and write the memory operand, but they only have to calculate and check the address for segfault/pagefault etc once. That's important.Quote from: hamster_nz on February 09, 2017, 08:55:04 pmYes, but 9 cycles isn't very long at 320 MHz :-)All my Arduino bits and pieces are back in NZ. I just took delivery a couple of days ago of a little kit of partshttp://onpad.ru/shop/cubie/arduino/ardiuno_kit2/1852.htmlI've put the 4 digit 7 segment display on the breadboard and run all 12 pins from the display to digital I/Opins (7 segments plus dot, 4 for digit select) and made a little minutes:seconds countdown timer. There's one 595 shift register there, so in the weekend I'm going to change it to use that for the segment/dot select. I'm trying to find out where I can get some more 595's by themselves.I'm actually a bit worried that the "shiftOut()" arduino function might be a bit too fast for the 595 if the RISC-V is running with a fast clock! After setting the data line it just does digitalWrite(clockPin, LOW); digitalWrite(clockPin, HIGH) with no delay between. The 595 should accept about 20 Mhz with 5V power, but at 2 V it's only spec'd for 5 Mhz. 3.3 will be somewhere between.Anyway, I'll see.

author: brucehoult
author_rank: Super Contributor
timestamp: February 09, 2017, 09:51:39 pm
content: Quote from: legacy on February 09, 2017, 09:35:24 pmThis hardware:https://www.crowdsupply.com/sifive/hifive1Seems hamster_nz and I have ours, ataradov should have very soon.I'm thinking of getting an Arty to play with as well. Looks like a good way to learn FPGA things, whether you load the HiFive1 bitfile into it (or modify it), or use their MicroBlaze one, or just play with something else entirely. I see there are small bare FPGA chips under $10, but $99 seems not bad for one with 20k LUTs and LEDs and switches and ethernet and USB and 256 MB RAM and Arduino connectors.

author: brucehoult
author_rank: Super Contributor
timestamp: February 11, 2017, 01:59:30 am
content: This evening I made a quick hack trying to do D/A just by calling good old digitalWrite(pin, bool) from software once every microsecond. I don't seem to have the filtering quite right, but it's much better with it than without it.(The "Challenge accepted" bit is about thishttps://twitter.com/DavidGrubb18/status/829711362016342017)

author: ataradov
author_rank: Super Contributor
timestamp: February 11, 2017, 02:05:37 am
content: This is awesome. My board arrives on Monday. Unfortunately, on Tuesday I'm leaving for a business trip

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 04:16:24 am
content: Got my board today. USPS rocks.Compiling the toolchain right now. Their build system seems to be a bit wanky and it looks like it rebuilds absolutely everything from scratch after a failure. EDIT: It appears that it does not actually rebuild everything, which is good.I can't find any links to precompiled toolchains either. They really need to step up their game if they want this to go anywhere.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2017, 07:47:37 am
content: Quote from: ataradov on February 12, 2017, 04:16:24 amIf you want everything pre-compiled and hand-held all you have to do is open preferences in your Arduino IDE and enter "http://static.dev.sifive.com/bsp/arduino/package_sifive_index.json" into "Additional Boards Manager URLs". Can't get much easier than that!If you want to use them from the command line you'll then find the build stuff in ...~/.arduino15/packages/sifive/tools/riscv32-unknown-elf-gcc/3f7b3696217548bc31aeccf9a0c89bdfa4e16a8f/bin... and openocd in ...~/.arduino15/packages/sifive/tools/openocd/9bab0782d313679bb0bfb634e6e87c757b8d5503/bin... so you can just add those to PATH.Personally, I don't begrudge the 4m53s it takes (I just checked) for "make -j8 tools" and I keep several different variations sitting around for comparison e.g. with and without using 16 bit "C" instructions.It takes nearly as long just to upload the "Killer Queen" player app (4 MB) to the board!

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 07:59:45 am
content: Quote from: brucehoult on February 12, 2017, 07:47:37 amYeah, but if they want this thing to go anywhere, they need to provide prebuilt tools. A lot of ARM success can be attributed to standardization efforts with CMSIS (at least for header files) and excellent support for GCC builds.I've been playing with this thing since I've got it, and boy, it brings me back to mid 90s. Assembly startup, no vectored interrupts, register bits are not defined, documentation is all over the place.I'm working on creating a simple minimal example in the spirit of my starter projects -https://github.com/ataradov/mcu-starter-projectsAnd the next step must be creation of SVD file, I'm not about to type a lot of magic offsets.Also, its internal RC is all over the place. I understand that RC oscillators are not the most accurate thing ever, but +/- 50%, really?Also, PLL seems to be pretty random as well, but I have not checked what is used for the reference there.

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 08:11:20 am
content: Right now I'm struggling to find any sort of description for MCAUSE and specifically CAUSE field.It looks like some (?) of the values are listed in encoding.h, but clearly not all. How do I configure UART interrupt?Found interrupts, but got even more confused

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2017, 09:04:59 am
content: Quote from: ataradov on February 12, 2017, 07:59:45 amThe hardware is deliberately minimal. Their complaint against ARM etc is it's become too complex, big, power hungry. Software can vector interrupts very nearly as quickly as hardware can and ROM is cheaper. It's nice to be able to just poke a pointer to a C function into a vector as on Cortex M, but hardware sequencing to save registers takes extra hardware and may well save more than you need.I'm frustrated by the lack of documentation as well. I'm figuring most things out by finding the Arduino library implementation and then stripping out the unneeded stuff. Next I want to find how to work proper hardware PWM manually so I can convert my silly little music player to use PWM instead of software bit-banging. Should improve the quality a lot, plus one of the problems with my 1 MHz toggling a pin is reading the next byte of music sample from flash takes 3 uS!To be precise, at 256 MHz (includes timing overhead):int8: 791 clocks = 3.09 usint16: 935 clocks = 3.65 usint32: 1223 clocks = 4.78 usA consistent exactly 144 clocks (0.5625 us) per extra byte.I think they're being conservative with the clock for the SPI and it could be faster.I'm giving them a pass on documentation for now. They're about 10 people and mostly rushing to get hardware (including Pi class) out.I'll take working example code over wrong documentation ANY day!Quote from: ataradov on February 12, 2017, 07:59:45 amI'll check it out.Quote from: ataradov on February 12, 2017, 07:59:45 amThe is considerable discussion at the moment in the whole RISC-V community over the best format. Device tree? Config string? They definitely intend to have it standardised across boards in such a way that bootloaders/kernels will Just Work on different hardware without configuration.https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/z6Lc8D9IuIg/0GQtIpPEDgAJhttps://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/DS4v8slQm8Q/oMlA8QqaAAAJhttps://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/dd7jC_zVOXE/MPjOhH22AgAJetcQuote from: ataradov on February 12, 2017, 07:59:45 amThe speed reported to the UART at program start is all over the place. It's done with what looks like a fairly quick&dirty loop measuring it. I suspect the actual MHz is more stable than the reporting of it :-)

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 09:15:40 am
content: Quote from: brucehoult on February 12, 2017, 09:04:59 amNope, it is minimal because they could not make more complicated stuff. There is no market for this this as it stands right now. It is a good first step, but they have a long way to go.Quote from: brucehoult on February 12, 2017, 09:04:59 amI actually support customers using ARM products, and one if the most common complaints / misunderstandings is how long interrupts entry/exit takes. And in this case I see trap_entry that does 32 stores and 32 restores. This is not going to fly in a real world. All that talk that software can vector interrupts fast is just not gonna do it, they will have to figure out how to make vectored IC.Quote from: brucehoult on February 12, 2017, 09:04:59 amJust use SVD. I know NIH syndrome won't let them, but SVD is a good format that is understood by all industry tools.Quote from: brucehoult on February 12, 2017, 09:04:59 amPossibly. I'm trying to get rid of assembly stuff for now.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2017, 09:45:46 am
content: Quote from: ataradov on February 12, 2017, 09:15:40 amI recently did a kernel patch for Aarch64 linux. I wanted to make, effectively, a custom instruction implemented by trapping.I was shocked to find that all synchronous traps (SWI, segfault etc etc) have a single handler and it does a 32 register save before doing anything at all to figure out the cause or dispatch on it.I implemented my patch (which is for internal use, not upstreaming) before the register saving. I only needed two registers, grab the cause, decide if it's for me and branch to my own handler (which did its stuff and interrupt return in less than 10 instructions), otherwise fall through to the normal full register save and dispatch.So don't tell me ARM is different or better :-)If you want a trap handler that doesn't save all 31 registers every time you have the source and can change it to do whatever you want. Meantime, it works and is safe.I think they pretty definitely will not do vectoring in hardware on bigger CPUs because they say it impacts badly on virtualization and hypervisors. Also register saving using normal instructions is better on big machines because it will use the normal mechanisms for wide dispatch, register renaming, out of order completion etc.Maybe it can be different on microcontrollers though I find their arguments that a handler in ROM will perform well convincing.

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 10:03:50 am
content: Quote from: brucehoult on February 12, 2017, 09:45:46 amWell, this thing is a microcontroller. Attempts at pushing the same exact core/system architecture for all applications will fail, for sure.And I'm specifically comparing it to Cortex-M7, which achieve similar performance, but are much nicer to work with.This this is a lot of fun, but "fun" is not what you want when working on real projects. In this stage, I simply don't see why anyone would use this.Also, code security is unclear. Who would use a micro where you can dump the firmware from external device?

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 10:34:32 am
content: Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.So far the amount of code that need to be written just to make stupid timer work is mind boggling.And I still don't get how UART interrupts will work.Now I do. Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

author: benSTmax
author_rank: Regular Contributor
timestamp: February 12, 2017, 11:35:59 am
content: Quote from: ataradov on February 12, 2017, 10:34:32 amI got the same feeling when reading about interrupt subsystems for MIPS or PowerPC micros. Read it a few more times and it will get through. You can also try to read about the MIPS or PowerPC interrupts and you'll see the similarities. MIPS uses priorities and sub-priorities while RISC-V PLIC's priorities and thresholds behave in pretty much the same way. The difference between MIPS and RISC-V PLIC being the latter is also able to "merge" more interrupts. MIPS can only do single or multi vector interrupts. It cannot merge the multiple interrupts in more than one vector. Sometimes, I find I need to re-read the same part over and over again to get into author's shoes and understand the concept it tries to explain.We're too used with patterns ...Quote from: ataradov on February 12, 2017, 10:34:32 amAdding more pictures or some potential real-life examples will certainly help. Seeing David Patterson's name in the spec I can see why the RISC-V specs are resembling so much the MIPS ones.I guess the difference here can be made only by silicon companies providing RISC-V based MCUs and also known for fairly good documentation. They would try to explain it better for the customers.Quote from: ataradov on February 12, 2017, 10:34:32 amAgain, a lot of resemblance to the ARM's NVIC, MIPS or PowerPC Interrupt controllers.

author: brucehoult
author_rank: Super Contributor
timestamp: February 12, 2017, 05:14:05 pm
content: Quote from: ataradov on February 12, 2017, 10:34:32 amYou might want to start from 25:00 in this (or the whole thing):

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 10:18:47 pm
content: Ok, here is a very minimal, self contained, bare-metal example -https://github.com/ataradov/mcu-starter-projects/tree/master/fe310

author: ataradov
author_rank: Super Contributor
timestamp: February 12, 2017, 10:23:20 pm
content: I'm also tempted to blow off the bootloader, since it is very slow. But I'd like to figure out the recovery strategy.Are there any known tricks, easier than erasing the flash via external programmer? I guess something like pulling DQx to ground may do the trick?

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2017, 07:04:59 am
content: Quote from: ataradov on February 12, 2017, 10:23:20 pmI'm sure you're aware the delay in the bootloader is there to give time to hit reset again to recover to safe mode if you've loaded a disastrous app.Quote from: ataradov on February 12, 2017, 10:23:20 pmI plan to look into writing to the flash from a running program. I'd like to do a little jit compiler, or a filesystem in the upper 8 MB of flash (which the standard config of openocd will not touch).That requires turning off the memory-mapped reading of it temporarily, so your code has to either be safely and securely already in the cache (NOT easy to do, as there is no prefetch instruction), or else copied to the SRAM.I don't think anyone (SiFive) has written code to do this yet. Talking to the flash via SPI to do the writing is straightforward enough -- I've read the flash chip manual -- I haven't tracked down how the memory mapping is set up (or disabled).

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 07:09:19 am
content: Quote from: brucehoult on February 13, 2017, 07:04:59 amWell, yes. But there are better ways to deal with that. For example, many kits I've seen simply have a jumper to disconnect CS from the memory. I'm sure something similar will work here, but there is no easy way to disconnect CS. That's why I was looking at alternative ways to break the external flash in a way that ROM will just wait for the debugger.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 07:36:34 am
content: Ok, so I tried to short pin 2 (MISO) of the flash to the ground and device appears to be in a recoverable state.So I tried to blow off the bootloader in flash and link my program at offset 0x20000000 (start of flash). It works fine, but there is still a huge delay before the first instruction of my program runs (1.5 seconds actually).Do they mean to say that "helpful" delay is in the ROM? Or am I missing something here? Who needs a microcontroller that takes 1.5 seconds to "boot"?

author: legacy
author_rank: Super Contributor
timestamp: February 13, 2017, 10:38:51 am
content: 1.5 second is a very long time

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2017, 05:18:37 pm
content: Quote from: ataradov on February 13, 2017, 07:36:34 amAs documented in the HiFive and FE310 manuals, at boot it executes instructions starting at 0x1000 in mask ROM. Execution is as follows:0x1000: j 0x20000 # start of OTP ROM0x20000: j 0x21FF40x21FF4: fence0x21FF8: lui t0, 0x20000000 #start of flash0x21FFC: jr t0I've checked those locations and they contain what the documentation says (except 0x21FFC which contains 0x28067 not 0x28057. 0x28067 is the correct opcode for a JALR zero,t0 while 0x28057 is a reserved major opcode, so that's a doc problem.(Note: I had to run at 16 MHz to read the OTP. It misread (in different ways) at 256 MHz and 320 MHz. If this is known it should be documented)I took the documentation to mean that the start delay is caused by the bootloader code at 0x20000000. If not, then the only other option is before we get to 0x1000.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 05:25:32 pm
content: Quote from: brucehoult on February 13, 2017, 05:18:37 pmAm I reading this correctly, and there is no actual code anywhere before the execution from flash? Only jumps? There must be some sort of flash initialization code and all that stuff.Quote from: brucehoult on February 13, 2017, 05:18:37 pmMe too, and I think it was deliberately written this way. I'm pretty sure this delay before the green led comes on from the bootloader, is not caused by the bootloader itself. My board has no bootloader at this point, and delay is still there, I've moved turning on of the LED right after stack initialization, so it is as close to the beginning as it gets.But I also feel like OTP ROM must do some initialization work. And I think that's were the delay is.

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2017, 05:59:14 pm
content: Quote from: ataradov on February 13, 2017, 05:25:32 pmYou'd think so.The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction. But even if hardware does that, you'd expect that hardware to need some setting up, get the SPI into the right mode etc.Quote from: brucehoult on February 13, 2017, 05:18:37 pmThe ROMs aren't all that big. Someone could dump and disassemble them.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 06:02:56 pm
content: Quote from: brucehoult on February 13, 2017, 05:59:14 pmI really hope this is not the case, otherwise the whole thing is a joke.And when done right, QSPI is actually not that much slower than on-chip Flash. A lot of Cortex-M7 devices have execute in place capability from QSPI and it works just fine.Quote from: brucehoult on February 13, 2017, 05:59:14 pmExactly. I though that's what ROM code is doing.Quote from: brucehoult on February 13, 2017, 05:18:37 pmWith the whole thing being open, I'd expect ROM to be open as well. But I could not find it on a quick search.

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2017, 06:26:55 pm
content: Quote from: ataradov on February 13, 2017, 06:02:56 pmFrom the datasheet: "The IS25LP128 Serial Flash memory offers ... Clock frequencies of up to 133MHz allow for equivalent clock rates of up to 532MHz (133MHz x 4) allowing more than 66Mbytes/s of throughput.""FAST READ DATA QPI OPERATION (FRD QPI, 0Bh)The QPI FAST READ (FRD QPI) instruction is used to read memory data at up to a 133MHz clock.The FAST READ instruction code (2 clocks) is followed by three address bytes (A23-A0—6clocks) and modebits, dummy byte (4clocks)"And then the data comes back at 4 bits per clock.So reading a 32 bit word for a "load word" instruction takes 2 + 6 + 4 + 8 = 20 clocks = 150.4 ns at 133 MHz. That's enough time for 38 instructions at 256 MHz, more at 320. Less the time to enter/exit a trap of course.But the flash doesn't seem to be being run that fast, at least at the moment, as I said elsewhere I measured 144 CPU clocks (562.5 ns @256 MHz) for each additional byte read after the first one. That's about what you'd expect from standard SPI run at 50 MHz, not QSPI at 133.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 06:32:31 pm
content: Quote from: brucehoult on February 13, 2017, 06:26:55 pmBut with cache and reading one page at a time, it is not that bad.Flash in fast MCUs also needs a lot of wait states. SAM V71 needs 5 wait states with code running at 300 MHz.Quote from: brucehoult on February 13, 2017, 06:26:55 pmThe flash right now is way underclocked. I even made a comment about this in my simple code. I'm not sure why and I have not had time to investigate and try to make it faster.

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2017, 07:20:09 pm
content: From Megan at SiFive:We recently added some helpful functions for setting the clock sources:https://github.com/sifive/freedom-e-sdk/blob/master/bsp/drivers/fe300prci/fe300prci_driver.h. But the SDK doesn't actually use them.In the Freedom E SDK, the "init.c" code switches over to the PLL clock source (with the HFROSC as the input), and the code there sets the SPI clock divider high out of paranoia since we know we are running out of SPI, and sets the UART appropriately so printf will just work. We're not expecting to do anything with OTP in general, so we didn't make the corresponding change to the OTP's clock divider.The PLL code is in init rather than in main so that it can be applied for the benchmark codes, which don't allow us to change main.The majority of the time before code execution at 0x1000 is the internal "reset stretcher" logic inside the chip. When you release the reset button, this circuit inside the chip is tuned to wait 1-2s before deasserting the reset to the AON block. This is to give time for the LFROSC which AON is running off of to be nice and stable. Once the AON block is running, it spends a few of its slow (32kHz) cycles taking the rest of the chip out of reset. (note that actually on the FE310 the LFROSC isn't used, there is an external LFOSC).Once the CPU is out of reset, it starts running at 0x1000. It is running off its HFROSC source which is not particularly accurate, at 12-20MHz or so. So all the code sources that we might start fetching from at reset (mask ROM, OTP, and mem-mapped SPI) have their clock divider settings with this in mind.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 07:22:36 pm
content: So 1-2 second delay actually happens? That's not ideal to say the least.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 07:23:47 pm
content: Also, the whole PLL initialization thing was reduced to this:QuoteI don't understand why you need a library to do this.

author: brucehoult
author_rank: Super Contributor
timestamp: February 13, 2017, 09:22:27 pm
content: Quote from: ataradov on February 13, 2017, 07:22:36 pmThat's true.It's the first production silicon, first evaluation board for not only this particular tiny company (about ten people), but for the architecture as a whole. I'm completely prepared to understand if they play it conservative to make sure that they have something that works, not something that doesn't work.A hardware two second boot delay is not ideal and of course there are applications where you would not want to deploy this board in production as a result. None of the applications I've ever used an Arduino in, as it happens, but your applications may be different. The most critical thing I've used an Arduino for is my home heating control system. I turn it on mid autumn and it runs until the middle of spring. I'm pretty sure it's never restarted mid-season unless I decided to tweak the code and flash a new version.Everything else is in your hands to make it less conservative if you want. Push the CPU. Increase the SPI clock and enable QSPI (or even "DDR", as I see). Find the limits.Looks like we're stuck with the two second boot delay for now though. I'll live.

author: ataradov
author_rank: Super Contributor
timestamp: February 13, 2017, 09:29:55 pm
content: Quote from: brucehoult on February 13, 2017, 09:22:27 pmI'll live as well. In its current form, there is no way anyone will put this into a real product. There are too few peripherals, too many pins occupied for no good reason, peripheral feature set and selection is very limited. And too many power supplies. It is a fun toy, though.And they really need NVIC for the MCU market. Interrupts are very-very slow at the moment. I'm consistently getting complaints from people about 15 cycles on Cortex-M cores.

author: brucehoult
author_rank: Super Contributor
timestamp: February 14, 2017, 09:44:35 am
content: Quote from: ataradov on February 13, 2017, 09:29:55 pmFrom Krste Asanovic, SiFIve Co-Founder & Chief Architect:HiFive1 is a development board for our FE line of custom SoCs, and the current FE310 parts are engineering samples (that's why ES is stamped on package). We can quickly and cheaply customize a production FE310 variant to have the features you need. The reset stretcher is indeed configurable and hardware vectored interrupts are also available in custom SoC designs.