adapteva

Too much focus on ARM OR RISC-V. The processor space is incredibly diverse. There are tons of embedded applications that don't require massive software ecosystem. The tenslica, arc, ceva ISAs have all shipped in the billions sitting next to arm inside SoCs.

If by the alternative you are referring to VPR, you are wrong. There are both public and non-public FPGA tool chains based on modified versions of VPR (and some of them are far more complex than what is currently handled by nextpnr).

No, it it is not a competetitor to openroad. It's more like a build system, like how make sits on top of llvm. Openroad is one of the tools under the hood.

Thanks for reading the docs! The only open manufacturable PDK is skywater 130, I wish there were more. Flow supports other commercial PDKs but for obvious reasons we can't publish those.

Expressing a complex project succinctly enough that all of HN will get it within 5sec is an np hard problem...here are the full docs. https://docs.siliconcompiler.com/en/latest/

Authore here. Python is for the build system. Plug in any front end you want. If you want to turn it into silicon, you will need to go through commercial tools which interface through proprietary tcl. How would you solve that problem? We solved it using python.

Over 200 comments and not a single benchmark comparison, if only there was some way to settle this argument...sigh.

Zero ASIC | Software Director, Analog Designer, Physical Designer | Boston or Remote (US) | Full-time | https://www.zeroasic.com/careers

Zero ASIC is an early stage Boston based startup working to remove barriers to silicon development. Open positions in system software, analog design, and physical design.

We only have 3 official openings right now, but we expect to grow significantly in the next few months. If you want to help revolutionize the way hardware is designed, don't hesitate to send a note to work@zeroasic.com.

Happy to! Looks like the website broke during updates. The bios used to be there. Hopefully it will be fixed soon.

Soon...

Still early days, but I disagree with some of your assertions. Seems to be a bit of an echo chamber in osh these days...

The effort was not created in vacuum.

-The skywater effort sits on top of darpa's openroad (I am currently on the board and so is serge)

-Prof Gaillardon and Xifan created the "openfpga" open source generator and taped out a skywater and 12nm (see woset best paper) [edit: and they are the founders of osfpga]

-Vaughn Betz created VTR which symbiflow is based on.[edit: and he is on the board]

-Yosys/Claire has done amazing work but it was possble thanks to Alan Mishchenko's ABC. De Michelli and Gaillardon have similar package to ABC that is definitely worth a look.

-The fees seem to be in line with other organizations, chips alliance, riscv foundation, etc.

Let’s not forget the legendary Mensen Ernst. He raced against horses (and won?) in the 1700’s

https://en.m.wikipedia.org/wiki/Mensen_Ernst

Not sure what you are referring to, but the majority of DARPA’s recent $110M investment in silicon design tools and opens source IP is dedicated to analog design.

Working on it...

https://www.fbo.gov/spg/ODA/DARPA/CMO/HR001117S0054/listing....

Touche!

Thanks for sharing your painful lesson. I feel your pain brother...I am still working on KS debt created 4 years ago:-( Don't EVER let the haters get you down. If you you are shipping products that people enjoy, you did not fail!

https://www.kickstarter.com/projects/adapteva/parallella-a-s...

Modern SOCs might have 100 complex blocks. We had 3 simple RTL blocks (9 hard macros). Top level communication approach was "correct by construction". Nothing is for free.

For Epiphany: GCC upstream already, working on GDB upstreaming. THere is no linux, qemu,uboot

For Parallella: Linux upstream, uboot might be as well? Runs Debian, Ubuntu, etc

https://github.com/adapteva

Sure...but probably not with all cores running full throttle. Would need to build an appropriate board.

Larger FPGA support 64-bits with custom memory controllers.

Impossible to characterize without high volume silicon or accurate yield models. We can say that historically, most failures are in SRAM cells and they are limited to a few bits (core still works!) and that in general only one out of N cores will fail. For arguments sake, let's assume the while network always works, but 1 CPU may be broken. (this is what needs to be confirmed later). Does that help?

We are quite happy with our GCC port so LLVM hasn't been a priority. If anyone wants to take over the port, please do! We could give financial assistance for getting it completed, but the budget would be modest.

Up to 1 petabyte supported theoretically through FPGA interfaces.

We can't disclose MPW costs. Chip was funded by DARPA. For standard MPW costs, check with MOSIS.

https://www.mosis.com/

PAPER: https://www.parallella.org/wp-content/uploads/2016/10/e5_102...

(access until we resolve the hosting issues, wordpress completely hosed...)

External RAM, up to 1 Petabyte would be connected through an external FPGA, containing an epiphany link, some glue logic, and a memory controller.

In modern DSP chips programmers have to contend with: VLIW, SIMD, pipelines, caches, and multicore.

In Epiphany, the programmers are challenged by the manycore and an SRAM size cliff (so 0 or 1 in terms of pain).

It depends...but I personally prefer having one big dragon to slay rather than 10 little ones.

No ECC on chip, but we do have column redundancy. We are pushing the envelope in terms of SEUs, making an assumption that the right programming model and run time will be able to compensate for high soft error rates. It's a contentious point, but basically our thesis is that with 1024 cores on a single chip, cores are "free" and it "should" be possible to avoid putting down very expensive ECC circuits on every memory bank (x4096). Some of our customers don't notice all bit flips because they have things like Turbo/Viterbi ..channels aren't perfect...

You have to look at all the numbers (I/O, on-chip memory, flops, threads) and see if the architecture fits your problem. Some algorithms like matrix matrix multiplication are FLOPS bounds. It's rare to see a HPC architecture (don't know if there is one?) that can't reach close to the theoretical flops with matrix matrix multiplication. Parallel architectures and parallel algorithm development go hand in hand.

The issue is not bandwidth, it's the system cost. The chip has 1024 IO pins. (more than enough for MANY 10Gb nics...)

Some parallel algorithms will scale to bigger (more parallel) chips the way binary programs got more performance with clock higher frequencies. That's the holy grail..

I know...it's painful, we honestly weren't expecting this.

Here are direct links if you are in a rush:

Amazon: https://www.amazon.com/Adapteva/b/ref=bl_dp_s_web_9360745011...

Digikey:

http://www.digikey.com/en/product-highlight/a/adapteva/paral...