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

Jeremy Bennett jeremy.bennett at embecosm.com
Tue Mar 14 09:37:49 CET 2017


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Hatim,

I like your idea of standardizing interfaces, to give flexibility in
exploring different realizations of external behavior.

Am I correct that paper tape was also used as an output mechanism?

I seem to recall Andrew Back had some good ideas about how to model
mercury delay lines in physical hardware. Hopefully he can reply here.

There is a lot of discussion currently about the later versions of
EDSAC, and some of those who used the machine are still around and
active, particularly through the UK Computer Conservation Society. So
I think if anyone knows the information it should still be possible to
find out about it.

I look forward to seeing your application.

Best wishes,


Jeremy

On 13/03/17 21:23, Hatim Kanchwala wrote:
> 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.
> 


- -- 
Tel:     +44 (1590) 610184
Cell:    +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.bennett at embecosm.com
Web:     www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAljHq90ACgkQvvWBcvtHVOEZTACfYTREPDpS6cAblmL1DE/rHiSl
IqUAnRjzwkXvuG5qkNOZ+g5GkmMYDUtR
=ntbt
-----END PGP SIGNATURE-----


More information about the Discussion mailing list