captbill

Project Oberon on Papilio Pro?

Recommended Posts

Hi All,

Very interesting project, the Papilio!

 

Has anyone attempted to install Project Oberon on the Papilio? It is a full system: RISC5 "processor", Oberon the programming language, Oberon the OS(written in Oberon) plus a fully integrated IDE with state of the art compiler. All this will fit on a Spartan 3 200k gate FPGA!

 

ProjectOberon.com

 

This is actually the life works of Professor Nicolas Wirth, the inventor of "object oriented programming". He wrote Pascal, Modula, and Oberon. This is all he has learned distilled down into a few dozen pages and is based around a WORKING machine.

 

I think this is a wonderful opportunity to learn about FPGA's from the master of language/compiler design himself!

 

I am not so much interested in FPGA programming as much as I am interested in Oberon itself. If we Oberon guys can easily adapt the Papilio to install Project Oberon, you would have a very serious new group of members.

 

I am clueless yet about FPGA's and would love to see if one of you pro's could have success loading it to the Papilio. It looks to be very strait forward.

 

Thanks,

Bill

Share this post


Link to post
Share on other sites

Hello Bill,

 

I took a quick look at the verilog sources, and it looks like it would most likely work with the new Papilio DUO and Computing Shield combo that should become available in December. The biggest question mark is if the memory used in the Papilio DUO will be suitable. It looks like the source code is targeting the Spartan 3 Starter kit with 1Mb of SRAM which is 32 bits wide. The Papilio DUO comes in two versions - with 512Kb and 2Mb of SRAM - both of which use 8 bit wide SRAM. It looks like we would have to use the 2Mb version but then the question is whether the 8 bit wide SRAM is going to be fast enough. Someone would have to modify the source code to make it work with the 8 bit wide SRAM. That's something that I can maybe work on after the Papilio DUO is ready to go, but right now I'm on the hook to get these boards, and DesignLab, out by December so I can't stray from those tasks at the moment...

 

Maybe someone else in the community might want to take a look?

 

Jack.

Share this post


Link to post
Share on other sites

Hi Jack,

Thanks for taking a look. The RAM is indeed the issue limiting it to the old Spartan 3. It is the only board suitable with the 10ns ram.

 

The Papilio Duo is an awesome concept. I am just wondering how/if Astrobe Oberon (the Arduino IDE equivalent for Oberon on ARM) could fit into the picture. It is really powerful. Think of it as the "NASA grade" Arduino IDE. The compile produces code that is over 12 times smaller than the Arduino compiler. Twice as small as C++. 

 

Astrobe.com 

 

I need to study the Duo closer to see how Astrobe might play a part.

 

Cheers,

Bill

Share this post


Link to post
Share on other sites

I misunderstood the nature of the DUO. I was thinking it was a FPGA + Arduino chip combined on one board. I see now that the "pairing" as in "DUO", is between the Arduino IDE and an FPGA as a type of "VHDL scripting language". Very cool. That would mean that Astrobe Oberon (ARM Cortex M3/M4 mc's IDE) would not apply after all. Will be good for making some cool ARM based "wings" though.

 

This is very fascinating. Makes me wonder if of the possibilities of pairing up the Pipistrello and the Papilio DUO. Are these boards "stackable" like shields?  Could we have the Pipistrello host the OS and let the Pipilio DUO be an FPGA shield/development layer? How awesome of a development "platform" would THAT be?

 

This arrangement of two FPGA's will probably be the practical route anyway. This way you guys would have an awesome "development workbench" for an "FPGA GPU" on the DUO. Imagine the effects of working closely with the language/compiler designers on this.

 

I really think the Papilio DUO, with it's VHDL IDE concept is an excellent direction. Being able to drop a couple "stepper motor controller components" into a project and have the VHDL automagically program the FPGA cannot be beat for the "programmer finding the FPGA" crowd, such as myself. I honestly, don't want to be forced to learn VHDL but want to utilize the platform as a target for my code to run. This frees up the programmer to be able to focus on their particular language.

 

Good luck with the DUO release, and congrats too.

 

Regard,

Bill

Share this post


Link to post
Share on other sites

Bill,

 

Thank you, I think the most exciting thing about the DUO project is the software itself. :) Just to clarify though, the Papilio DUO is the combination of an FPGA and an Arduino compatible chip. DesignLab is the software that I'm working on to be released at the same time.

 

Jack.

Share this post


Link to post
Share on other sites

Hi All,

 

This is actually the life works of Professor Nicolas Wirth, the inventor of "object oriented programming". He wrote Pascal, Modula, and Oberon. This is all he has learned distilled down into a few dozen pages and is based around a WORKING machine.

 

Niklaus Wirth is a stellar computer scientist and language designer, but I don't think he deserves the blame for OOP.  That goes back to Smalltalk, Simula 67, and earlier (see Wikipedia).  Oberon has its debut in 1986, much later.  I think I did take a glance at Oberon a long time ago and I was impressed with how clean it was, as is typical with Dr. Wirth's work.  I got to hear him speak in the mid-1980's and he's very entertaining.

Share this post


Link to post
Share on other sites

I looked at the Oberon code and it's amazing how you can simplify the code and still have a system.  For instance, the VID module that creates a 1024 x 768 monochrome display with timing generation and memory access etc. is only 46 lines long, and the 32-bit processor module (excluding the multiply subunit, the divider subunit, the floating point adder, the floating point multiplier and floating point divider) is only 193 lines long.

 

The problem implementing the Oberon system on a general purpose FPGA board like Papilio or Pipistrello is that it's designed for a memory system using fast (10ns) 32-bit wide 1 MB SRAM.  My first thought was to write a caching memory controller for Pipistrello and use LPDDR as memory but the complexity of that code would be in stark contrast to the simplicity of the Oberon code so I decided to abandon that plan and instead design a simple SRAM add-on board for Pipistrello that can hold up to 2 MB of 10ns 32-bit wide SRAM.  The rest of the system is basically covered by the on-board I/O (video via HDMI, sd-card using the micro-sd socket, and PS2 keyboard/mouse via PMOD) so I could use all 48 pins in the wing connectors for the SRAM board. 

 

The original oberon code is basically unchanged, the only major code addition is a module that takes the signals that normally drive an analog VGA monitor and convert it to DVI output via the HDMI connector. 

 

The only hickup I had was that the 3-button mouse needed 5V and the PMOD only supplies 3.3V so I had to jumper-in 5V to the PS2 PMOD board.

 

Pics:

Pipistrello with add-on boards: http://www.saanlima.com/images/oberon1.jpg

Close-up of the display: http://www.saanlima.com/images/oberon2.jpg

System setup: http://www.saanlima.com/images/oberon3.jpg

 

Complete source code for the Pipistrello version: http://www.saanlima.com/download/pipistrello-v2.0/Oberon_sram_wing_src.zip

 

BTW, I'm sure the SRAM wing can be used as general-purpose SRAM memory for retro-computer type implementations.

 

Magnus

 

 

Share this post


Link to post
Share on other sites

I haven't decided on that.  The board in the picture is just a prototype from OSH Park but I do have 20 additional PCBs from Seeed Studio if anyone is interested.

 

Some info about the design: To directly drive a 1 MB 32-bit wide memory you would need 32 + 18 + 7 = 57 signals (32 bit data, 18 bit address, 4 bit BE, CE, WE, OE) but there are only 48 signals available on the wing banks.  The solution was to directly drive A7- A0, BE3 - BE0, CE, WE and OE to the memory and use an address latch for the remaining upper address bits. 

 

In the original Oberon code the 25 MHz cpu clock is derived from 50 MHz and all the signals to the SRAM are driven during the 25 MHz clock cycle except for WE which is only driven during the second half of the 25 MHz clock cycle.  For the Pipistrello version I changed this so that the 25 MHz cpu clock is derived from the 75 MHz video clock.  This allowed me to divide the 25 MHz clock cycle into three phases - the first phase is used for latching the upper address bits, then phase 2 and 3 are used to drive all the signals to the SRAM except for WE which is only driven during phase 3.  Each phase is 13.333 ns so there is plenty of timing margin for the 10 ns SRAM.  The timing should allow a 33.333 MHz cpu to access the RAM without wait states by having a 100 MHz base clock.

 

An alternative way would be to run the cpu at 50 MHz (or maybe even 66.666 MHz) and take a wait-state to update the address latch if the current access is outside currently addressed 1KB block.

 

Here is a link to the schematic: http://www.saanlima.com/download/sram_wing1.pdf

 

Magnus

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now