Based on some of the previous posts (in other threads) and its feedback, we have now tried to write down some of our initial suggestions. This is however something that we do not want to decide on our own, we want to do this together with the community.

OpenRISC ASIC roadmap and initial suggestion:
Since we can't get all advantages with a limited fund of money, we need to prioritize the end-goals:
- Prio 1: More important to get a lower-unit cost then supporting allot of features and high performance.
- Prio 2: Selecting "the right" features are more important then high performance.
- Prio 3: Getting high performance.

With the above suggestions, we mean that it is more important that the end-results of this project lead to the fact that we all can purchase the OpenRISC ASIC and use it as a cost-efficient solution for HW development, without having to buy millions in volume. Compared to just developing samples of an ASIC that will be to expensive to use in real life, or require massive MoQ (minimum order quantities).

So our "low end, limited fund" ASIC design suggestion is:
- Selecting a gate-array-ASIC (0.35um - 0.18um) or and std-cell-ASIC (0.35um- 0.18um). Target price $5 at reasonable volumes ~5.000-10.000/year.
- Selecting a single OpenRISC processor solution with suitable peripherals (based on the community feedback/needs). The idea is to find a common minimal base of features, and then add an extension port (access to the internal WB-bus) so that if needed it will be possible to attach a small FPGA outside, implementing missing features or very application specific algorithms etc.
- Estimation of needed fund: $30.000-$50.000


Our "high end, less limited fund" suggestion is:
- Selecting a std-cell-ASIC (90nm - 65nm). Target price $3 at reasonable volumes ~50.000-100.000/year.
- Selecting a multiple OpenRISC processor solution with suitable peripherals (based on the community feedback/needs). With extension ports.
- Estimation of needed fund: $100.000-$150.000


What do you all say about these suggestions/statements stated above?


We have a suggestion, if we create an online "OpenRISC feature survey" where the community users can add their specific "wanted" features for this low-end ASIC solution, then we can summaries this "feature-list" and hopefully we will see a nice pattern showing us the "common feature base". How does this sound?

I think that the "low end, limited fund" is the right first step with achieveable and realistic target. Time and requirements will show the need of next evolution, maybe to the second and more complicated design.

These look like good options. Both aren't too prohibitive in price. I agree that the first one is easier to aspire to. It would mainly be aimed at existing OpenRISC users who could benefit from using an ASIC, so it's worth trying to find out how many users like these there are and what features they want. Then you'll have some customers, which should make getting money easier.

Along with a chip you also have to release a reference design as well as offering a demo board containing that design . These demo boards are usually offered at or below cost and are considered part of your cost of sales.


A design project team could buy one board simply to check out the tool chain and see how hard it is to run the debugger. If they can cobble up a minimal code set that can run their products basic functions then that becomes a great show and tell for management.

A small product developer could buy a small quantity of boards and use them in their product during initial production. They could then cost reduce the design onto a single board after they see how well it sells.

A big customer could simply by the chips and do their own breadboarding.

Remember that this industry has a history of choosing the better marketed product over the better designed one.



Why don't you start a project that could hold all of the design candidates so that users could compare them and maybe come up with some additional ideas. We could copy over existing modules and it would give us a safe place to clean up the code, documentation and testbenches that would not affect those already using those blocks

John Eaton

In my view, Gated-Array (0.35um-0.18um) would be preferable because:
------------------------
Gated-Array v/s std_cell
------------------------
1) Being first designs of its kind, there may be small/big issues or changes which might crop till last. And Gated-Array design are easier handle those.

2) It frees design-team from process characteristics and other analysis which std-cell has (like I/O characterization etc). "its good to have lesser unknowns" ..

Recently i came across advertisement from following company. You may want to have a look..
http://www.easics.com/

------------------------
0.35um-0.18um v/s 0.90nm-0.65nm
------------------------
3) Already $5 per-chip cost is quite high (unless we are too advanced). So better not drain resources right from start, and save it for "known unknowns".

4) As pointed earlier, there is board cost involved, and also tool-chains, debuggers, emulators needs to be matured first

5) And anyway digital part of design is independent of technology. So if you get good returns, you can always re-invest in more and better..


with regards, pekon

Suggest starting more conservatively.
Target design to eASIC. Midvolume, 90nm process. Quick turnaround.

Based on 100 MHz Xilinx Virtex5, should be able to hit 40-50% faster, at around 150MHz.
It'll be lower power than Xilinx, but not as good as ASIC.