[Oberon] Hardware versus software development.

[Jörg]

Wojtek

I fully agree, I know the problems of small series production.

I only wanted to say that we have to look at the overall cost not only at
the HW cost. I live in a country where a man hour is expensive. Spending man
hours to write a non-trivial driver just to be cheap on the HW side might
end up with a higher total cost.

Jörg

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

Jorg:

> 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.

Actually, I do both. My most successful project to date consisted of
hardware data acquisition and signal processing software written in
BlackBox. This experience motivates my insistence on the Oberon-2 because
I know how much good SW is available on the CPC website. Having the
Oberon-2 would make this SW pool more accessible.

> - 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.

Well, HW comes first in the sense that it really defines the reception.
The board has to be inexpensive in the first place, and this is where the
HW comes first. Take the LX9 packaging as an example. The TQ-144 cuts down
on the prototyping cost because we can assemble the proto boards by hand.
The end user can do the same. We can thus sell bare PCBs to those who want
to cut the cost to the minimum at the expense of their own time. We can
sell the PCBs plus the part kits. Or we can sell the assembled boards. Now
take the FT256 package. You cannot solder this by any means, unless you
are operating professional pick-and-place, the reflow oven, and you have
access to the post-reflow X-ray machine. This translates into a huge
difference in cost of short-series production runs. We know because we do
it all the time.

So we will settle on TQ-144. It means that Memory Control Blocks are not
available. This determines which memory chips you can use, and which you
cannot. The memory chips determine both the video timing and the Verilog
that you will need to develop. At the very end you end up with the SW
driver to use this entire chain of HW and FW blocks.

Now consider the other way. If you start with SW requirements, which you
can of course do, then it will determine the amount of memory, the video
speed, and so forth. OK, it implies which HW chips you can use and the pin
count. This will define the FPGA package. This in turn will tell how many
PCB layers, and which assembling technology you must use. It will
determine the cost, which can become unacceptable for short series
production.

My obvious thought is that the entry level board cannot be too ambitious
because it must be inexpensive. Having quite extensive experience with
board design and part selection, I narrowed down the parts. The choices
are very limited. Did I mention that the parts must not only be gull-wing,
but they also must be in-stock? You must be able to buy the chips. This
latter requirement is highly nontrivial. There are tons of catalog parts
that you either cannot buy, or you must buy in full rolls of say 1,000
chips. These are again unacceptable in prototype environment.

So the HW design of the entry-level board is in fact rigidly determined by
the assembly cost and part availability. You need to be a practicing HW
developer to appreciate how little space is left for HW maneuvers.

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

Papilio Duo is very nice. The problem with their design is that the video
timing may be hard to meet, esp. if you want to add color which will
triple the required memory bandwidth. I certainly want to use the 32-bit
memory bus. It will eat a lot of pins, but I do not want to limit the
video to just black-and-white.

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