On Wed, Jun 4, 2014 at 3:52 PM, Iztok Jeras <[email protected]> wrote: > Hi Julius, > > If the target application for OR2K is deeply-embedded systems, then in > addition to code size, power consumption should also be considered while > designing the ISA, not only during implementation.
I'm not saying it is _the_ target application, I'm saying it is _a_ target application. I'd welcome suggestions for other applications, but personally I don't see how a collaborative processor development effort (with a mere 10s of contributors like the OpenRISC project has) could achieve much beyond implementing the sort of processor systems seen in embedded devices that operate in the 10s-100s of MHz in ASICs (ARM Cortex-M range of stuff). I'd like to stand corrected though, but given past experience, I think that's what's achievable, and I'd like to remain realistic. You're right in pointing out that low power should also be a concern in the ISA. I'm not sure when it isn't a concern any more, though, and I think it'd be implicit in any contemporary processor architecture. Cheers Julius > > Regards, > Iztok Jeras > > > On Wed, Jun 4, 2014 at 3:58 PM, Julius Baxter <[email protected]> > wrote: >> >> On Thu, May 29, 2014 at 1:09 AM, Luís Vitório Cargnini >> <[email protected]> wrote: >> > Hello Julius, >> > >> > Please, which is the current state of the OR2K ? >> > >> > I would like to be more involved since I would like to use it to my >> > research >> > in my workplace. >> >> Hi Luis >> >> The current state of OR2k is that it's still vaporware. To be honest >> it would be great if we could get someone to kick start the process on >> this. I really think the OpenRISC project would be helped by >> developing a newer architecture with a more dense instruction set, and >> more suitable for deeply embedded use. It's a lot of work, though, and >> my time is very limited at the moment, so I've not been involved at >> all, however I'm excited by the prospect of the effort getting under >> way. >> >> However, if you're in a position to look at doing some work on it in >> any capacity, it'd be useful. Probably the initial steps are to figure >> out exactly what we're looking for. We'd need to think about what it >> is we're aiming for. Probably something which derives from OR1K would >> be nice, but not necessary? >> >> Probably it's something along the lines of what we have now, in that >> it's a configurable architecture which is capable of being stripped >> bare, in terms of features, to run small bare metal apps and RTOSes, >> and fully featured to run more complex operating systems such as those >> based on the Linux kernel. Things like the floating point and SIMD >> instructions are nice, but on FPGAs, of little use. Probably we should >> focus on a tight, neat control-based instruction set, to begin with >> anyway. >> >> I think it might be worth revisiting this topic on the mailing lists, >> so I'll CC them to see if anyone has any information or opinions. >> >> In my opinion, something which is a lot like OR1K at the moment (a lot >> of optional features such as caches, MMUs, parts of the instruction >> set) but with better code density, and a better system of doing >> conditional operations (branching, optional execution). Security is >> probably also a concern. Some people have mentioned things about >> virtualisation but I'm not too familiar with this, nor do I know if >> it's of any use in deeply-embedded applications, which is where I >> think OR2K could have its greatest potential. >> >> So I look forward to reviving this topic a little, and seeing what >> people come up with. As I say, I think if there's a proposal for an >> ISA which doesn't preclude people from being able to scratch their >> itch, add what they need and contribute it to the community (atomic >> operations are a good, recent example of this) then that'd be a good >> start. >> >> Cheers >> >> Julius >> >> >> > >> > Best Regards, >> > Luis Vitorio Cargnini >> _______________________________________________ >> Openrisc mailing list >> [email protected] >> http://lists.opencores.org/listinfo/openrisc > > _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
