[Oberon] Spartan 6 Kickstarter project

skulski at pas.rochester.edu skulski at pas.rochester.edu
Sun Oct 12 19:23:04 CEST 2014


Paul:

I want to refer back to your old e-mail. Some of your points have been
obsoleted since your post was written.

https://www.kickstarter.com/projects/13588168/papilio-duo-drag-and-drop-fpga-circuit-lab-for-mak

> it's refreshing that the Papilio project description says:
> "SRAM - Easy to use SRAM is a must. We've used
> SDRAM in the past and it was a big mistake! The strict
> timing requirements and interfacing caused fits for everyone.
> SRAM is asynchronous and dead easy to use,
> you will greatly appreciate the simplicity
> of SRAM in your projects."

A few points. They released Papillo Pro since then. It uses Spartan-6,
which is a big step forward over Spartan-3. It also provides SDRAM on
board, so they backed off their reservations.

It is not quite true that SRAM is "dead easy to use". The book by Pong P.
Chu devotes 28 pages (an entire chapter 10) to SRAM interfacing, using the
Digilent Spartan-3 board that you are also using. Professor Pong develops
three different SRAM controllers in order to provide good timing and to
avoid contention on the SRAM bus. While the first controller is perhaps
dead easy, it is also slow. Accepting such a solution is not good
engineering, and therefore he does not stop at this point. Good
engineering always needs attention to details. SRAM interfacing appears a
good example.

Second, SRAM has less capacity for the same price. We are talking of a 2
MB SRAM versus 64 MB SDRAM, so it is not minor. The newer DDR chips reach
into gigabytes. It is not prudent to dismiss this technology. Fortunately,
SDRAM can be handled with soft controller cores, while DDR chips can be
interfaced to hard controllers in Spartan-6 and beyond. I am less familiar
with Altera or Lattice, but I bet it just the same. So, in both cases of
SRAM or SDRAM one is well advised to use ready-to-go open source soft
controllers, the Pong's one for SRAM or Hamster for SDRAM. One can also
use closed source from the Core Generator. Either way, the problem is
basically solved, though some details no doubt must be solved while
interfacing those controllers to the on-chip soft processor.

In case of SDRAM the Hamster soft controller seems reasonable. Hamster's
cores are available here:
http://hamsterworks.co.nz/mediawiki/index.php/FPGA_Projects

> The point of Project Oberon is not just to make something work, starting
> from scratch, but to make it completely clear and understandable (and
> convincing).  The entire book is just that, and amply rewards a careful
> read.  I think it's only after you read the whole book through that you
> can really start claiming to understand the philosophy.

As simple as possible is great, but as useful as possible would be even
greater. Project Oberon will come to fruition if it becomes rooted in an
FPGA ecosystem and community. Papillo is a good example of both. The
Hamster page is part of this bigger picture. I think that many wonderful
projects would come out of a marriage between the active FPGA community
and a great operating system.

Hope it helps,
Wojtek




More information about the Oberon mailing list