FPGA Central

Just interesting, how often some company is able to develope their own
RISC soft-core processor for their needs, without any need to publish
that fact or reveal any details?

On Sep 25, 7:51 pm, drop...@gmail.com wrote:
> Just interesting, how often some company is able to develope their own
> RISC soft-core processor for their needs, without any need to publish
> that fact or reveal any details?

I believe this is reasonable when the soft-core is not supposed to be
marketed independently of a larger product (which is its context of
use).

It is also reasonable to worry since it your design effort You can
safely publish, anytime you wish, following patents filed (of course)
and the product being pushed in the market. Then, it is reasonable to
publish stuff from the internals in order to increase momentum among
the users of the product.

This is from my own working experience, even though i'm mostly on my
own here (in pswrokwstaina Greece).

Regards
Nikolaos Kavvadias

On 25 Sep, 17:51, drop...@gmail.com wrote:
> Just interesting, how often some company is able to develope their own
> RISC soft-core processor for their needs, without any need to publish
> that fact or reveal any details?

I know there are quite a few companies that have done this.

Jon

>Just interesting, how often some company is able to develope their own
>RISC soft-core processor for their needs, without any need to publish
>that fact or reveal any details?

What do you mean by "RISC soft-core processor"?

It's fairly easy to make an ALU unit. It's also fairly easy
to make a simple CPU if you use wide instructions to simplify
decoding. If your code is small enough to fit in local
ROMs, then you don't need anything fancy like caches.
You may not even need a memory interface.

We used to call that sort of stuff microcode.

--
These are my opinions, not necessarily my employer's. I hate spam.

[email protected] writes:
> Just interesting, how often some company is able to develope their own
> RISC soft-core processor for their needs, without any need to publish
> that fact or reveal any details?

As often as they want to, and can afford to pay the engineers.

Given the low cost of licensing existing soft cores (no charge for some),
it seems that it would not be cost effective for most companies to develop
their own, unless their requirements are so extreme that it doesn't make
sense to customize an existing core.

On Sep 25, 6:51 pm, drop...@gmail.com wrote:
> Just interesting, how often some company is able to develope their own
> RISC soft-core processor for their needs, without any need to publish
> that fact or reveal any details?

Buying a core from a third-party has some advantages.
1) not too expensive
2) they usually come with development environment
3) you get (what is expected to be) well tested core ready to apply

If You intend to use the CPU of yours in many projects then it makes
more sense to make your own.

Just my 2 eurocents.

[email protected] a écrit :
> Just interesting, how often some company is able to develope their own
> RISC soft-core processor for their needs, without any need to publish
> that fact or reveal any details?
>
Hi
I did develop a RISC a few weeks ago, mainly for fun and to see how it's
done. The problem I am now facing is that there is absolutely *no* tool
that supports it, and I am unable to write a compiler.

Nicolas

On Sep 29, 7:31 am, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:

> Hi
> I did develop a RISC a few weeks ago, mainly for fun and to see how it's
> done. The problem I am now facing is that there is absolutely *no* tool
> that supports it, and I am unable to write a compiler.

try http://www.cs.princeton.edu/software/lcc/

You have a working compiler probably in few hours ...

On Sep 29, 4:31 pm, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:
> drop...@gmail.com a écrit :> Just interesting, how often some company is able to develope their own
> > RISC soft-core processor for their needs, without any need to publish
> > that fact or reveal any details?
>
> Hi
> I did develop a RISC a few weeks ago, mainly for fun and to see how it's
> done. The problem I am now facing is that there is absolutely *no* tool
> that supports it, and I am unable to write a compiler.

You may use GCC compiler with specially build back-end for your
processor, that's how it done for Nios II.
http://en.wikipedia.org/wiki/GNU_Com...ction#Back_end

> > I did develop a RISC a few weeks ago, mainly for fun and to see how it's
> > done. The problem I am now facing is that there is absolutely *no* tool
> > that supports it, and I am unable to write a compiler.
>
> You may use GCC compiler with specially build back-end for your
> processor, that's how it done for Nios II.http://en.wikipedia.org/wiki/GNU_Com...ction#Back_end

Of course, but that's a lot more work than it sounds. You'll need to
add support for you architecture to binutils. And test it. Then write
a new backend to GCC. And test it. GDB also. Finally you need to port
a libc, like glibc or newlib.

Just _how_ much work this requires depends on how close to an existing
architecture you are, eg. making a MIPS variant with just a few more
instructions is a lot easier than a completely new architecture -
especially if the latter has funny irregularities. For many
architectures, writing the softcore implementation is much less work
than writing the software tool chain support.

On Sep 29, 2:31 pm, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:
> done. The problem I am now facing is that there is absolutely *no* tool
> that supports it, and I am unable to write a compiler.

Of course, if you are developing many processors then using an
architectural tool like LISATek may help considerably.
This has the advantage of being able to direcly create an ISS and
compiler. (not withstanding arguments about whether the result would
be efficient, at least it is quicker than the manual route)
I believe this was the reason that ARM acquired Axsys a couple of
years ago.

Andrew

On Sep 30, 2:06 am, Andrew Burnside <andrew.burns...@sli-
institute.ac.uk> wrote:
> Of course, if you are developing many processors then using an
> architectural tool like LISATek may help considerably.
> This has the advantage of being able to direcly create an ISS and
> compiler. (not withstanding arguments about whether the result would
> be efficient, at least it is quicker than the manual route)
> I believe this was the reason that ARM acquired Axsys a couple of
> years ago.

As long as the processor matches the underlying assumptions of
LISATek. Presumedly, a classic style MIPS-like RISC processors is
fairly trivial, but how about a, say, VLIW? Or a true exotic like
IA64? Or a graph reduction machine like TRIPS? A massively parallel
machine like RAW?

Tommy

Tommy Thorn wrote:

> As long as the processor matches the underlying assumptions of
> LISATek. Presumedly, a classic style MIPS-like RISC processors is
> fairly trivial, but how about a, say, VLIW? Or a true exotic like
> IA64? Or a graph reduction machine like TRIPS? A massively parallel
> machine like RAW?
>
Looking back at what happened, LISA as part of Axys went to ARM.
LISATek became Coware Processor Designer.
>From Coware's latest webpage:
Processor Designer is used to develop a wide range of processor
architectures, including architectures with DSP-specific and RISC-
specific features as well as SIMD and very long instruction word
(VLIW) processors

Obviously, such tools have their constraints. However, the OP asked
about developing soft processor cores for FPGA.

>I did develop a RISC a few weeks ago, mainly for fun and to see how it's
>done. The problem I am now facing is that there is absolutely *no* tool
>that supports it, and I am unable to write a compiler.

Do you need a compiler? How about a simple assembler?

How much code are you expecting to write?

Note that if you are writing timing critical code, it might be
simpler to write it in raw assembler where you see every cycle
rather than wondering what code the compiler will actually generate.

If things are slow enough, you can hide all the delays behind magic
constants and just recalibrate when you get a new compiler.

--
These are my opinions, not necessarily my employer's. I hate spam.

On Sep 30, 4:47 am, Tommy Thorn <tommy.th...@gmail.com> wrote:

> > You may use GCC compiler with specially build back-end for your
> > processor, that's how it done for Nios II.http://en.wikipedia.org/wiki/GNU_Com...ction#Back_end
>
> Of course, but that's a lot more work than it sounds. You'll need to
> add support for you architecture to binutils. And test it.

Not necessarily. If you already have an assembler, you can have gcc
stop with assembly output, no binaries involved.
And writing a primitive assembler is actually not that bad, once
you've seen the code for one to get an idea of how to tackle the
problem.

> Then write a new backend to GCC. And test it.

Yes, that's the part that can't be avoided, except as you observed to
the degree to which you can find one for something similar to your
processor and use that as a starting point.

>GDB also.

Only if you want it. There are other ways to debug code too, which do
work even if being more primitive. The decision to invest work in
getting a debugger going would depend a lot on how much need you
expected to have for it.

>Finally you need to port a libc, like glibc or newlib.

Embedded work does not necessarily involve a standard c library.

> For many architectures, writing the softcore implementation is much less work
> than writing the software tool chain support.

Agreed. When I did it, I had an allegedly working primitive version
of gcc already available, which only needed some fixing.