Programming systems

A project log for Discrete YASEP

a 16-bits YASEP computer (mostly) made of DIP/SOIC chips like in the 70s and 80s... with 2010's twists!

Yann Guidon / YGDESYann Guidon / YGDES 11/07/2015 at 13:2212 Comments

As you might already know, one "design rule" of this project is to avoid "programmable" parts as much as possible.

This is not a luddite reaction or an arbitrary constraint "to make it more challenging". On the contrary: it actually eases development!

While digging in my "archives" I just found a box full of programming boards:

Here are the roadblocks to using them:

For now I have come to these conclusions:

Now, you understand better why it makes sense to use "fixed function" chips as much as possible.


K.C. Lee wrote 11/09/2015 at 15:40 point

You'll need to fill/update the SRAM content some how while the system is live.  i.e. 1 writer for the bits you want to set and the read is the matching logic.  Unfortunately dual port RAM aren't cheap or huge. MUXes / tristate buffers to drive the address/data line.  That's going to be boring wiring those up.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/09/2015 at 16:03 point

For the breakpoint system, yes, filling the SRAMs will be demanding and I am thinking about it. A new separate log would be a better place for this but here are my thoughts :

- during power-on, the reset signal disables the breakpoint masks (stored as '273 for example). SRAM contents can be anything and will not stop execution.

- The BP RAMs don't need to be dual port. Setting the breakpoints uses the internal bus, while the processor is stopped (all the buses are hi-Z). For a single point, 1) stop the proc 2) enter the value to match in the hex-keypad 3) send this value to the desired bus 4) in the corresponding BP pannel, toggle the output bit from the SRAM (it's usually in read mode but pressing a button will start a write cycle). Voilà. (repeat until all the RAM is filled ;-) )

- the user might use a free-running counter (like the one for the keyboard scan) to flush the SRAMs, one by one or in parallel. For precisely setting certain bits, buttons (up/down) and the mouse will send pulses.

- external assistance will later come with software running on a host computer. An interpreter would transform higher-level commands (gdb-style) to individual keycodes. Like "bpres 1 1234h-5678h" sets breakpoint n°1 on the result bus for all values between 1234h and 5678h. It would even manage "ignore bits".

- Serial communication speed will be a bottleneck so a 8-bits parallel interface is also necessary. You could hook up your Pi or whatever nanocomputer's GPIO on it.

  Are you sure? yes | no

Eric Hertz wrote 11/09/2015 at 11:06 point

two 32k's in parallel, and an inverter ;)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/09/2015 at 14:37 point

These "cache SRAM" consume quite some power so I would rather find larger chips to keep the current draw "reasonable" and save a bit of PCB room.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/09/2015 at 15:21 point

Additionally, these chips must be fast because slow chips would slow the whole system down... That's why I need fast 64K SRAM.
Fortunately I have a good supply of 3.3V asynch SRAM, but their TSOP44 package is not adapted for the prototype.

  Are you sure? yes | no

Eric Hertz wrote 11/07/2015 at 17:25 point

ROMs: "solve many arbitrary combinatorial problems" Indeed, thanks for the reminder... Need 16x 17-bit address-matchers? One (16-bit) FLASH chip. Nice. What was your 'ol buddy, the 74640? One flash chip'll do the work of 16 of 'em :)

Heck, could almost build an entire processor out of nothing but flash chips...

Though, speeds may be slower than a 74AHC...

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/07/2015 at 17:34 point

I agree on many points :-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/08/2015 at 02:47 point

(but my old buddy is the '688, not a bus transceiver ;-P )

For the address-matcher, you got me thinking and you're fsck DAMN RIGHT, I must thank/credit you for that. It took 9 hours for my tired brain to connect the dots : why use Flash ?

I think I'll use SRAMs for the next generation of breakpoints. The 688 can detect strict equality, but a SRAM can match any range and whatever condition you like... OK I can say goodbye to the 688 ;-)

OMG it will be way easier to develop and debug on this system than most other systems I know. And it will have more support/debug RAM than working RAM :-D

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/08/2015 at 03:19 point

So far, there would be one 64KB chip to spy on each 16 bits bus (instruction, instruction address, SI4, SND, DST) plus some more SRAM for the register addresses.

Now, let's say that 5 of the output bits of each condition can trigger a trap on its own. The remaining 3 bits of each SRAM chip can be combined with another SRAM to sieve complex conditions !

Let's say you want to set a breakpoint at instruction address 1234h when SND=234?h and result goes to register D4.

- set an instruction address breakpoint at 1234h
- set SND value breakpoints in the range 2340h to 234Fh
- set a write address breakpoint to D4
- keep these values "alive" on the bus so each breakpoint is active
- set the combined breakpoint to this "address" made of all those conditions

It looks like I'm reinventing gdb but in hardware :-D

  Are you sure? yes | no

Eric Hertz wrote 11/08/2015 at 08:33 point

Ah, hah! For breakpoints, nice! I was thinking to use it for e.g. recognizing whether the upper-address bits should activate a comparatively-small RAM or ROM, etc... But breakpoints, nice.

It's groovy to switch things up a bit, there's so many de-facto standards that've been around for decades, and yet so many new options available, like throwing huge amounts of RAM where it once would've been cost-prohibitive.
Keep it up!

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/08/2015 at 10:18 point

I'll keep it up, certainly !
And I'll figure out how to set a SRAM bit on every CPU cycle, to mark all the used addresses/data/instructions/etc. so it also performs code coverage. "what code addresses have (not) been executed ?" "what instruction opcode was not used ?" etc.

Now the problem is that for my prototype, I don't have very many 64KB cache chips, the stock I have is mostly 32KB.

The other concern is interface speed. For example, flushing one "LUT" chip would take ages manually, with the keyboard. Automating it with the host interface will be better but still not... fast: the 115200bps interface limits the speed to 11520 commands per second, about 6s to scan a whole LUT. And there will be 6 or 7 LUTs so doubling the serial speed will only make a dent in the wait... Reset procedures will be tedious. Onboard hardware assist becomes necessary.

Time to write another log ;-)

  Are you sure? yes | no

Yann Guidon / YGDES wrote 11/08/2015 at 11:18 point

OK I have 8×UM61512 (old pulls), that should be enough for the prototype... These damned 64K chips were rare, most Pentium motherboards had only 256KB cache.

Now I'm concerned that the breakpoints might add delays to the critical datapath. The 20ns access time is not the slowest part, the rest of the breakpoint and control logic will also add their own delay...

  Are you sure? yes | no