[Librecores Discussion] GSoC: EDSAC museum on FPGA - architecture, external interfaces and stages

Hatim Kanchwala hatim at hatimak.me
Mon Mar 13 22:23:05 CET 2017


Hello!

Hope you are doing well! I have been developing the early stage
architecture of the project and would like to share thoughts.

1. External interfaces
Let's begin by looking at the original machine.
(Here input denotes signal(s) going into the machine; output denotes
signal(s) coming out of the machine.)
1.1 Input
- Orders and numbers coming in through 5-track paper tape-reader
- Controls (5) - Start, Stop, Reset, Clear, and EP (execute single
instruction)
- Rotary switch to cycle through long tanks (32 long tanks in latest
version of EDSAC, each tank holding 32 words)
- Rotary dial (input single decimal number, used in post-mortem routines)
1.2 Output
- Program output through teleprinter
- CRT display (6) - Accumulator, Multiplier, Multiplicand, Counter,
Sequence Control Tank, and Order Tank
- Alarm/buzzer

In order to make our project easily accessible to and reproducible by a
wide community, I propose we take a very flexible route for external
interfaces. So, how do we go about achieving this? I think we should
standardise the input/output communication over SPI. SPI is widely
supported and relatively easier to implement. Typical clock frequencies
for SPI are in MHz range which is far higher than EDSAC clock (500KHz).
Will need to place decoder and encoder at input and output respectively
(along with some "supporting" logic) - this is a standard problem that
an FSM can solve. This design approach will expose a consistent I/O
interface, which means that the exact combination of hardware to use for
I/O is a user choice depending on accessibility/availability of
components at her/his end.

For instance - a Raspberry Pi (with a monitor and keyboard/mouse) can be
hooked up with communication over the internal SPI bus. The required
Python script can be provided as part of this project. Another instance
- along with some glue logic, a matrix of LEDs on a breadboard can be
used as output display, or even an array of seven segment displays that
could directly show the result! The corresponding PCB designs can be
released as part of this project, and one could get it printed and
delivered online (via OSHPark for example). Yet another instance - a
Raspberry Pi that is connected to a thermal printer and a business card
reader can also be used. The Python script from the first instance can
be made generic enough to support this very easily. And, I can point to
open-source DIY business card readers based on Raspberry Pi and OpenCV.
(You must have noticed that your suggestion of using low cost thermal
printer and/or business card reader becomes a subset of this more
general solution). One could use and Arduino or a microcontroller or a
combination of any of the above.

The point I am driving at is - having a standardised communication
protocol will increase flexibility and serve our purpose of reaching a
wider community, at a correspondingly low cost of effort on our side.

I would now like to point you to a block diagram I made -
https://goo.gl/lmE56b and also attached (PDF). This should explain
things a lot better!

2. Stages of work
I think we can broadly break down the work into 3 non-overlapping stages -
(i) Logic of EDSAC
This entails study of documentation to extract logic. Output should be a
gate-level logic of the machine.
This will be covered mostly before the start of the coding period.
(ii) Map machine logic onto Verilog modules
Mapping gate-level logic from previous stage onto "modern" digital
blocks. Output of this stage should be the Verilog code itself. Arguably
this stage will take the most time in the coding period and will involve
an iterative process. We'll need to build a suite of test benches to
accelerate our passage here.
(iii) Hardware implementation

3. Version of EDSAC
Various documents point out that EDSAC was iteratively improved and
features were added over time. For instance - the ISA itself was
upgraded at least once, from what I know. Another instance - the memory
gradually increased from 16 to 32 long tanks (512 to 1024 words). I am
guessing we should go about implementing the newest version, but I am
doubtful because I haven't exhaustively been through every document
(still making my way through). So, I don't know if there is sufficient
information allowing to implement the newest version.

4. Next mail
I have an idea to model delay lines - circular shift registers. I am
prototyping it in code right now, so the next mail will contain more
concrete output in support of this idea.

Phew, this one was long! Thank you for your time. I am eagerly waiting
for your feedback and thoughts. Have a nice day!

Bye,
Hatim Kanchwala
Undergraduate, Electrical Engineering
Indian Institute of Technology Patna
hatim at hatimak.me, hatim.ee14 at iitp.ac.in (University)
(+91) 966 5154 719

References -
- http://www.dcs.warwick.ac.uk/~edsac/Software/EdsacTG.pdf
This was immensely helpful and so was the simulator.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EDSAC Museum on FPGA - Architecture.pdf
Type: application/pdf
Size: 12696 bytes
Desc: not available
URL: <http://lists.librecores.org/pipermail/discussion/attachments/20170314/8c83784c/attachment.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.librecores.org/pipermail/discussion/attachments/20170314/8c83784c/attachment.sig>


More information about the Discussion mailing list