[Oberon] Hardware versus software development.

[Jörg]

Wojtek

I love this kind of interaction. It shows that the way more HW related
people (you) and the way more SW related people (me) are thinking differ.
- I say: The SW does it like that and HW has to adapt, without considering
the HW impact of my decision
- You say: we take this HW and the SW has to adapt, without considering the
SW impact your decision might have.

We are inline with the LX9 :-) Knowing that these days SDRAMs is more
prominent than SRAM, I was looking at it and found that the LX9 offers MCBs
that might simplify Verilog code. But we would then need the FT256 or CSG324
package. Did you consider this option?

A word on SRAM: At first view, the kickstarter project "Papilio Duo" looked
promising to me as it was using SRAM iso SDRAM. But we would have to adopt
the Verilog memory driver quite a bit to emulate the 32bit access of RISC5.

In essence: Interaction of HW aspects and SW aspects are the things that are
important.

br
Jörg


-----Original Message-----
From: skulski at pas.rochester.edu [mailto:skulski at pas.rochester.edu] 
Sent: Freitag, 31. Oktober 2014 17:04
To: "Jörg"
Cc: skulski at pas.rochester.edu; oberon at lists.inf.ethz.ch
Subject: RE: Hardware versus software development.

Jorg:

> I know. I had the following step-by-step approach in mind
> 1) - try to find another board, possibly with more memory for future use

Did I not say that I am working on designing the board? I do not want to
set a firm deadline because I have a few urgent projects to complete
before rolling out the new board. Basically, I have one of my previous
designs that I want to adopt. It will be an entry-level board targeting
the Oberon System development. In order to keep the cost down I will use
Spartan-6 LX9. More powerful boards may follow later. I have plans how
these should look like, but no firm commitment to develop these.

>    - port the Verilog code to the new board.
>    - whole Oberon system stays untouched
> 2) introduce color
>    - SW decision (Oberon)
>      Assuming I have one bit per R-G-B:
>      How do I represent the color in the
>      framebuffer? RGB in 3 separate planes or RGB
>      as 3 consecutive bits.

This is secondary because HW can route bits. I was thinking of PWM
modulation, which is a cheap but not a very good solution. The image may
get blurred. Nexys is using a R-2R resistor ladder. There are DACs on the
market that are pretty easy to use. So there are different ways. Also, a
more modern solution would be an HDMI chip. These decisions will be driven
by hardware cost and complexity, while the SW will adopt.

>    - HW decision (Verlog)
>      There, I have to decide with RISC5 or with RISC6.
>      RISC5: I stay with 1 GB, I allocate more memory to video,
>      and have less for code, heap and stack.

In the entry-level board I want to use the SRAM chips. This is due to the
pin count that the LX9 has in the TQ-144. In future designs the video
memory needs to get physically separated. Video has stringent timing
requirements, while the program/data memory has a more relaxed timing. A
good video solution is BRAM, but there is never enough of it.

>      RISC6: increase address bus by 1 and hence add another 1GB

The advanced boards will use DDR3 chips which are cheap. Then the RISC
processor can be adopted to the required address size.

BTW, I have a better name for the CPU than RISC which is too generic, but
I am afraid of N.Wirth reaction to changing his beloved names.

Wojtek

-------------- 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/20141031/ffe199ab/attachment.bin