[Oberon] Large Displays / 64 bit...

[Jörg]

Markus

Thanks for the effort you are doing.

Just a remark to see what complexity Markus is aiming at:
- To synthesize the whole RISC5 architecture with the CPU and all
  input/output routines into FPGA on the SPARTAN-3 board, we have
  today a Verilog code of approx 700 lines in total.
- I could imagine that on the SPARTAN-6 only the driver for the SDRAM
  alone will need approx 700 lines of Verilog code :-)

br
Jörg

-----Original Message-----
From: greim [mailto:greim at schleibinger.com] 
Sent: Freitag, 20. Juni 2014 10:59
To: Charles Perkins; ETH Oberon and related systems
Subject: Re: [Oberon] Large Displays / 64 bit...

Charles,

 >
>> I am just trying to port the Spartan 3 design with static RAM to a
>> Spartan 6 with dynamic SDRAM. Thats because Spartan 3 is at the end of
>> lifetime and all newer reference designs of Xilinx (and all the open or
>> cheap boards are following this reference designs) are using SDRam (or
>> better said, one special chip, the MT48 from Micron).
>>
>
> Which Spartan 6 board are you using?

I am now working with the Xula2
http://www.xess.com/shop/product/xula2-lx25/

Its near identical with the PapilioPro (maybe a fork of the Xula)

http://papilio.cc/index.php?n=Papilio.PapilioPro

Both are OpenHardware afaik.


>> 64 bit could be possible with Spartan-6 but not with Spartan-3.
>> But is this really necessary?
>>
>
> I don't think 64 bits is useful in an FPGA if one doesn't have the large
> memory to go with it.

The only thing possible useful could be a 64 bit ALU.
But i would prefer first to implement a Cordic unit for some 
trigonometric calculations in HW.

> A related question: What are the minimum changes required to support
> multiple processors?
>
> The multiple processor question is one that might be attractive to explore
> in an FPGA. I think that a compare-and-swap opcode, an IO address
> that one can write to to interrupt peer processors, and another IO
> address registering which processor(s) will accept hardware interruptions,
> and a third IO address that reflects which processor is reading it (for
CPU
> identity -- we don't want to use up opcodes unnecessarily) would be
sufficient.
>
> System changes to support multiple processors will require much more
> thought. Can you embrace multiprocessing without abandoning the simple
> architecture of the current V5 Oberon?  Aos and Bluebottle show one
> way to go. But how about incorporating CSP (Communicating Sequential
> Processes) instead? It might be fun to find out.

To implement 2 or 4 RISC CPUs on one big FPGA is not the problem, the 
problem seems for me the inter-processor communication.

The most clever and simple system i know, is the round-robin system of 
the Parallax Propeller. Its full deterministic, and, or because, it has 
no interrupts!

<http://www.parallax.com/sites/default/files/downloads/P8X32A-Propeller-Data
sheet-v1.4.0_0.pdf>

Some pseudo-gurus are skit upon it, but i was using this processor for a 
real world application for years and its really simple in the sense of 
Wirth!



>
>> I am not sure how the actual situation is, but for me, on the software
>> side, a smooth out of the box boot image generator, based on the
>> emulator, would be more important. Also a tool writing the Oberon File
>> system directly to a SD-Card and a real PC-Link using the RS232
>> RISC<->PC would be nice to have, as a stable, easy to use infrastructure.
>>
>
> I also want a boot image generator and a file system creator, and also
> interfaces to other file systems. I would also like to re-introduce other
> architecture targets, including Intel and ARM for native-speed operation.

Two adapt the machine code generator of the RISC5 Project to another 32 
bit RISC processor should be possible, but I would prefer to focus on 
the FPGAs. This a real unique and new thing. Otherwise you are always 
running against Linux. And this is a race you could not win.


>
> I would like to see compatibility maintained between these architectures.
>
> Other operating systems are built to multiple targets from one source
tree,
> I believe Oberon can do it too.

i hope so, but i am not so optimistic.

>
>> Also the license situation is not finally clarified!
>> (Maybe because the ETHZ is realizing similar things in cooperation with
M$)
>>
>
> Can you tell us more about what is n

I pointed it out in some e-mail before.
N. Wirth said Oberon is free, but what is free
Free to use? Free to sell? Free to modify and sell? Free only if my 
modifications are free again?
All the GNU, MIT, BSD etc story...

Regards

Markus





--
Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
https://lists.inf.ethz.ch/mailman/listinfo/oberon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6097 bytes
Desc: not available
Url : https://lists.inf.ethz.ch/pipermail/oberon/attachments/20140620/6898af05/attachment.bin