Own soft-processor

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

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

Jon

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.

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.

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.

snipped-for-privacy@gmail.com a écrit :

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

try

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

s able to develope their own

You may use GCC compiler with specially build back-end for your processor, that's how it done for Nios II.

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

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

Looking back at what happened, LISA as part of Axys went to ARM. LISATek became Coware Processor Designer.

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.

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.