Last visit was: Fri Sep 18, 2020 11:18 pm
It is currently Fri Sep 18, 2020 11:18 pm



 [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next
 G6A-RISC Relay Computer 
Author Message
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
oldben wrote:
As reminder complex relay computers used some sort of error checking code, just keep things safe
if you had a bad relay.

Hi Ben, this is an interesting matter and something that I agree that must be considered. A quick calculation of the expected duration of a relay subjected to the switching frequencies of a relay computer, gives surprisingly low and worrisome figures. A typical relay has a duration expectancy for the electrical contacts of 100,000 operations at its rated current. More expensive ones may support up to 500,000 operations, but that’s not the general case. Assuming a relatively conservative clock frequency of only 4 Hz, that means that the normal relays may fail after 25,000 seconds, which is less than 7 hours (!) Therefore, just leaving the computer running overnight may cause it to fail and requiring relay replacement. Of course, these figures are based on relays switching at their rated current, which shouldn’t normally apply on a relay computer, so a somewhat larger duration should be expected in practice, although still extremely short.

So yes, error checking code must be run as part of regular maintenance. The question is, what this code should actually do or check? How to detect all sorts of failures? A register malfunction is easy to detect, an ALU defect too, but what about relays involved in control lines, instruction decoding or other auxiliar circuitry, which may just crash the error checking code without even getting the opportunity to report anything?

Joan


Sat Dec 07, 2019 11:34 pm

Joined: Tue Dec 11, 2012 8:03 am
Posts: 282
Location: California
How about reed relays, which are in an envelope that's either evacuated or has some inert gas, and even mercury-wetted? I ride bicycle a lot. The bike I ride most has nearly 50,000 miles on it, all on the same cycle computer. The sensor at the front wheel is just a reed switch that gets closed every time the magnet mounted on a spoke goes by. 50,000 miles, times the (approximately) 770 times the wheel has to turn to go a mile, is over 38 million. I would expect it to last pretty much indefinitely. It would be good to look up the lifetimes on reed relays.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources


Sun Dec 08, 2019 12:15 am WWW

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1440
I wonder if there's a simple approach which energises the switched circuit after the switching has happened?


Sun Dec 08, 2019 8:11 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
Garth wrote:
How about reed relays, which are in an envelope that's either evacuated or has some inert gas, and even mercury-wetted? I ride bicycle a lot. The bike I ride most has nearly 50,000 miles on it, all on the same cycle computer. The sensor at the front wheel is just a reed switch that gets closed every time the magnet mounted on a spoke goes by. 50,000 miles, times the (approximately) 770 times the wheel has to turn to go a mile, is over 38 million. I would expect it to last pretty much indefinitely. It would be good to look up the lifetimes on reed relays.

Yes, I'm aware of reed relays and they are certainly an interesting approach. I looked at them some time ago, and now re-visited them again.

I think I can put now a list of pros and cons compared with normal small signal relays:
[I base that mostly on what I have read from data sheets and articles from major manufacturers of both kinds, namelly Pickering UK, and OMRON Japan. First ones are made in the Czech Republic, and the second ones in China.
Reed Relay from Pickering UK (SPST): https://static.rapidonline.com/pdf/565698_v1.pdf
Small Signal Relay from OMRON (DPDT): https://omronfs.omron.com/en_US/ecb/pro ... en-g6s.pdf

Pros:

- Very fast, around x4 faster than small signal relays
- Longer life expectancy (as you explain). Figures are:
Zero load switching: 1e9 operations for reed relays versus 1e8 for normal ones
Rated load switching: 1e7 operations for reed relays (1 A resistive load, no data for inductive load) versus 1e5 for normal ones (2 A resistive load or 1 A inductive load)

Cons:

- Expensive, around x5 more expensive than small signal relays
- 'Normally Closed' versions are not as popular or as readily available (definitely not from china providers). This is required for NOT gates
- About 3x to 4x total number of SPST relays required for a relay computer application compared with DPDT.
- About 2x to 3x PCB area required for reed SPST relays compared with miniature DPDT

So basically, I need to balance how much (money) I want to spend. The difference is huge considering that I was meant to use about 500 DPDT relays, that can be purchased from china at about 0.5 € each for such quantities. In the case of reed relays the price is about 5x per unit (can't be really purchased from china if they are meant to come from a reputable brand) and I may need up to 4x more. (other purchasing suggestions are welcome)

With respect to life expectancy, it turns to be that (maybe) the difference is not that huge. By carefully looking at the figures for the OMRON relay, and considering that one 2A relay will drive up to 50, 1000 Ohm relays (that's 12mA per relay, or a total of 600mA for 50 relays), the "Durability" graphic in the Omron data sheet for resistive load shows about 1e6 operations. Still much worse than reed relays, but maybe
not that bad in absolute terms after all...

(mixed feelings about this)

Joan


Last edited by joanlluch on Mon Dec 09, 2019 10:39 am, edited 4 times in total.



Mon Dec 09, 2019 10:05 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
BigEd wrote:
I wonder if there's a simple approach which energises the switched circuit after the switching has happened?

My understanding is that the worse scenario is disconnection with load, as this tends to cause a 'sparc' that transfers metal from one contact to the other, thus eroding both sides, or creating metal oxides that increase contact resistance until eventual contact failure.

I have read about some ancient relay computers dealing with this problem by implementing what you suggest, but no details on the actual procedure was mentioned. I have given this some thought, and I believe this requires additional clock phases and additional circuitry to make it happen. I'm unsure if it is actually worth the additional complication...

On the other hand, the still operating Japanese relay computer that I linked before, and apparently is still run daily, appears to have relatively small requirements for relay replacement and maintenance, which was quite surprising to me and makes me wonder, how do they achieve that (?)

Joan


Mon Dec 09, 2019 10:21 am

Joined: Wed Jan 09, 2013 6:54 pm
Posts: 1440
This doc suggests a series R and C, of appropriate sizes, either across the gap or across the load:
https://www.illinoiscapacitor.com/pdf/P ... ession.pdf


Mon Dec 09, 2019 11:05 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
BigEd wrote:
This doc suggests a series R and C, of appropriate sizes, either across the gap or across the load:
https://www.illinoiscapacitor.com/pdf/P ... ession.pdf

Thanks Ed, that's interesting stuff !


Mon Dec 09, 2019 11:57 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
Regarding relay reliability, I have now found that the Omron G6A-274P (the key here is the "7" on the reference number) offers an enhanced reliability and improved bouncing figures, thanks to "gold-clad" contacts.
Attachment:
G6A-274.png
Attachment:
G6A-274_.png


The above was copied from the official spec: https://omronfs.omron.com/en_US/ecb/products/pdf/en-g6a.pdf

So, according to that, with a load of 0.6 A the relay will still work after 1e7 operations for resistive loads and 3e6 operations for inductive loads,

BUT, I calculated the 0.6 A figure based on a different model of 12 VDC relays. If I use 24 VDC rated G6A-274P relays instead (with 2880 Ohm coil resistance) it turns that one relay driving 50 relays will use only 0.42 A, so the duration figure essentially duplicates: 2e7 operations for resistive loads and 6e6 operations for inductive loads.

Also, any reduction of load below 0.4 A rapidly increases contact life expectancy to up to 5e7 operations, which is still not as good as reed relays, but quite impressive for a relay. This figure can be attempted by trying to design the computer circuitry in a way that single relays never drive more than say 16 or 20 additional relays.

The down side is that these relays are more expensive than my previous budget of 0.5 € per relay, but they are still below 1 € if purchased in the required quantities from China. So I think these should be the ones that I will use :-)


You do not have the required permissions to view the files attached to this post.


Tue Dec 10, 2019 11:55 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
It took me some time but I finally figured out the instruction set that I want for this CPU. I prepared a document with the essential information about the architecture and instruction set that I attach as pdf

Attachment:
g6a-risc.pdf


One of the important aspects is that it is not a load/store architecture, as it allows ALU operations directly on memory. For example it will be possible to load a value from memory and add it directly to another memory location without intermediate operations.

For example, let's assume we have implemented some sort of Stack based machine that works on 32 bit data values and we want to add two (32 bit) values that are on top of the Data Stack. It will be possible to implement it like this:

Code:
// assume register a0 is used as the pointer to the Data stack, and the stack grows down the memory locations with little endian convention
mov [a0, 0], r0    // load the word on top of the stack to r0, that's the lower word of the first value
add r0, [a0, 2]     // add to the lower word of the second value
mov [a0, 1], r0   // load the upper word of the first value
adc r0, [a0, 3]     // add with carry to the upper second value
add 2, a0           // update a0 so now the pointer points to the new top of the stack.


So the Stack-based-machine 32 bit addition was performed in only 5 cycles.

I found this very handy on a relay computer because memory accesses are as cheap as register accesses (or not more expensive if you want to look at it this way). Given the nature of relay computers, which always require two clock phases for everything, including the update of a register to itself, such as incrementing the Program Counter, it is possible to load memory and perform an ALU operation on the first phase as expected, but then store the result on the same memory address during the second phase of the same execution cycle.

I believe that my approach is not limited to 'modern' relay computers using IC memory chips, but it should be possible too on the early relay computers with old-technology based memory, because after all the (at least) two clock phases should be there to update a register, so there's enough time to update a memory location instead of a register if similar load/store times apply to memory and registers.


You do not have the required permissions to view the files attached to this post.


Tue Dec 24, 2019 4:36 pm

Joined: Mon Oct 07, 2019 2:41 am
Posts: 130
The problem with a stack machine in general with a high level language is you tend waste memory
pushing argments to the stack, A-B -> C LOAD A, PUSH , LOAD B, PUSH , COMPILENT and ADD
,POP , STORE C. To be effecient you need to load(push) and st(pop) to memory as compared to the FORTH model.


Tue Dec 24, 2019 9:57 pm
Online

Joined: Wed Apr 24, 2013 9:40 pm
Posts: 188
Location: Huntsville, AL
Joan:

Very nice instruction set. Like your other instruction set, it's nice and compact. I like that you're continuing the use of the prefix instruction concept that we discussed in your other thread. I will be following with interest how the T(est) result flag you included will work for your instruction set; I think it will be a great addition, and simplify the status register.

From the instruction set, it appears that you're using the mnemonics b, bt, or bf to signify what I would term absolute jump instructions. Why not use the mnemonics j, jt, of jf instead, to signify absolute jumps and leave the mnemonics starting with b to signify pc-relative branches? It may make your assembly language easier to understand as jump instructions are generally understood to be absolute jumps rather than pc-relative branches.

It seems that you've made a trade-off regarding your branch distance by choosing to force the programmer / compiler writer to signify a forward or backward branch. I don't know that the benefit of being able to branch forward or backward an additional 16 locations by treating the 5 bit branch address field as unsigned and having the branch instruction define the direction is going to be of much practical use. To me it appears to complicate the assembler language unnecessarily. If a branch is going to a target further than -16...+15, then you're very likely going to need the prefix instruction to fill in the upper bits in any event. If the prefix register is not filled by the previous instruction, bit 4 of the branch target field is simply sign extended. With your present definition, you're going to have to perform the two's complement of the combination of the 11-bit prefix register and the 5-bit branch target field from the instruction register for any backward branches.

I can't say definitively that forward branches will be more common than backward branches. They are certainly more common for certain structured programming constructs like if then else statements, while loops, switch statements, etc., but there will likely be a fair number of backward branches / jumps in order to implement loops. Therefore, I think you'd be better served by assuming that the branch target value is signed, and sign extending the least significant 5 bits if the prefix register is not loaded. (A simple single bit state register that is set when the prefix register is loaded, and cleared when the following non-prefix instruction completes can be used to implement the sign extension mechanism.)

Looking forward to your continued postings on this and your other processor project. Have a good Christmas.

_________________
Michael A.


Wed Dec 25, 2019 1:26 am

Joined: Mon Oct 07, 2019 1:26 pm
Posts: 43
Hi Joan, very good instruction set indeed.

I also understand why your branch is not signed, its because your 5-bit immediate is also unsigned for other instructions.
Now you use the same bit that switches between ADD and SUB to select forward or backward.

A signed 5 bit value would make the short-branch distance even shorter. And I also think forward branches are much more common than backward ones.

Just one point, if I understand it correctly, the short zero-page addressing is just 32 words. That looks too small for me.

have a good Christmas !


Wed Dec 25, 2019 8:33 am
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
Hi Ben,

About the push/pop instructions, I realised while developing the instruction set of the CPU74, that they are in fact not as useful as they may seem for a general purpose cpu, particularly if you already have indexed memory addressing. Even if the architecture has a dedicated stack pointer for calling conventions, the stack frame for local variables and function arguments must be explicitly created by adding or subtracting to the SP, therefore it is possible to just use that to allocate the required space for the callee saved registers, thus removing the need of push/pop instructions. This is exactly what I did for my CPU74 architecture. In other architectures, the push/pop instructions are also missing if pre-decrement/post-increment addressing modes are available. For a relay based cpu, I think it's not worth to go that far, as it doesn't even has a stack pointer. The mention I made of a Stack Based Machine, is just because I anticipate that one of the applications will be a RPN calculator, but otherwise the processor is meant to be a 'normal' one, not a stack based processor.


Wed Dec 25, 2019 8:15 pm
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
Hi Michael,

Yes, I really like the 'prefix' idea, I think the concept is pretty cool!. Interestingly, I later on discovered with great surprise and satisfaction that the MIPS16e ISA also uses the same idea to enlarge immediates to 16 bits, by prepending a special "extend" instruction, so effectively doing the same as the 'prefix' instruction. They call it "Extensible Instructions". See section 3.11 (page 40) on the following document https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00076-2B-MIPS1632-AFP-02.63.pdf

About the 'T' flag, this is in fact something that I already introduced on my CPU74 set. I thought why don't use the same for the relay cpu. For instruction encodings with 3 operands, I think it's really advantageous because it saves encoding space. The positive effect is that for the comparison instructions I can use the third operand to encode the condition code (which is free), and then the range of conditional execution instructions is greatly simplified.

I agree that it's good to name absolute jumps differently than relative ones. I suppose I named all them 'branch' due to influence of the ARM processor, which calls them all 'branch", but I will change that. About forward and backward branches, this is to keep consistency with the instruction decoding. All immediate fields for this processor are positive unsigned values, and if you look at the encoding positions of the b+ and b- instructions you'll realise that they match with the add, sub instructions (as roelth rightly found!).

From the point of view of the user, forward/backward branching should not be a problem because the assembler can handle it all. The user will just put a branch to a label and the assembler will generate the correct instruction, and will prefix it appropriately if it gets out of range. The assembler will also handle the fact that the PC is pointing to the next instruction when it is incremented or decremented, so the actual offset placed on the branch instruction must take this into account (this is pretty common for most processors, as far as I can tell).

Just in case this needs clarification, the prefix instruction does not need to care about signs because the combined constant is a 16 bit value (processor word size). The assembler just reads any constant the user has placed in an instruction as an int value. If the constant does not fit in the range specified by the instruction, then the constant is split between the instruction encoding and the prefix. The cpu will combine them again to obtaint the original 16 bit value (signed or not)


Last edited by joanlluch on Thu Dec 26, 2019 9:10 am, edited 1 time in total.



Wed Dec 25, 2019 9:25 pm
User avatar

Joined: Fri Mar 22, 2019 8:03 am
Posts: 271
Location: Girona-Catalonia
Hi Roelh,

You got the reasons why I have forward/backward branches exactly right :-)

About Zero Page size, you are right, it is very small. But it's difficult to make it bigger because I do not want to introduce different size immediates, or to loose encoding space. On the CPU74 I managed to make it 256 bytes, but that instruction set is very compressed and has additional complexity to allow this.

I ended naming the ZP addressing mode as "Direct Memory" instead of "Zero Page" (although I still use "ZP" acronym) because thanks to the prefix instruction I can reach the entire 16 bit wide address space with the same instructions, only that the first 32 words are cheaper. I suppose that I can use these 32 words for frequently used global variables, and go to higher addresses for not so common variables or constant data.


Wed Dec 25, 2019 9:55 pm
 [ 71 posts ]  Go to page Previous  1, 2, 3, 4, 5  Next

Who is online

Users browsing this forum: CCBot and 0 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software