Support GAL18V10

[rhgndf]

Initial GAL18V10 support. Reading PES works, but writing is not tested.

Need a wire on the new afterburner for this to work. RA2 is not wired up in the design so a wire is needed to connect it to the shift register. Connect Pin 5 of the shift register (QF) to ZIF20.

[ole00]

Nice one. I can see the DIN and SCLK pins are a bit awkward because they need to be toggled via the shift register, but you managed to find a way. Well done. I've routed the new track on the PCB design file (not uploaded yet) and modified the schematic as you indicated on your image (again not uploaded). I've ordered few GAL16V10's and would like to try them first before I merge this MR. Could you please fix the merge conflict, it looks like I merged your previous MR and that probably caused it. Thank you.

[ole00]

Could you please also check whether the pinout of the 16V10 in the image is correct? Thanks.

[rhgndf]

Wiring looks correct. Although there's a typo: GAL is supposed to be 18V10 not 16V10. Also, you might want to add the pinouts of the other chips like 6001/6002 and 26CV12 with the GALmate adapter. Furthermore 20XV10/20RA10 can be in the column header with 22V10 since they have the same pinout.

[ole00]

Just an update from me. I've got my GAL18V10B-15LP, but they do not work for me so far. The GALS are branded as Lattice, but I suspect they might be fake. I've made the hardware mod, merged your branch (to my local test branch) and checked the pins are toggling as expected - they do, but still PES reads 0xFF for all the bytes. I've ordered a different batch of GAL18V10B, hopefully they'll work better.

[ole00]

Actually, I realised that the GALs may have been completely erased (including the PES data). Could you please send me your GAL18V10 PES bytes and I'll try to write it to the IC. That might make them work. Thanks.

[rhgndf]

Might want to try reading the fuses out with -nc to see if there's a fusemap burned inside.

[rhgndf]

PES raw bytes:
00 05 50 A1 CD A6 03 0C FF FF

[rhgndf]

Can confirm reading works. Currently don't have a test image to burn it into the 18V10. Maybe those 18V10s you got already have a fusemap in it to test.

[rhgndf]

I just noticed that the identification byte in PES is 0x50, but documentation online states that the 18V10B is 0x51. Do you want to compare pictures of the markings on the chips?

[ole00]

Thanks for the PES data. Unfortunately the trick with -nc or writing the PES did not work. Reading the fuses with -nc reads all FF (which is expected because of the Arduino's internal pull up on the DOUT pin). Here is the GAL chip - the Logo L does not have a quality print - I bet it is a knock off, not a real Lattice.
.

[ole00]

To test writing and functionality, you can try this jed file:

Simple test for 18V10
*
QP20* QF3540* QV0* F0*
 X0*
NOTE Table of pin names and numbers*
NOTE PINS A:3 B:4 C:5 Y1:13 Y2:14 Y3:15*
L1332 111111111111111111111111111111111111*
L1368 111111111111111110111111111111111111*
L1728 111111111111111111111111111111111111*
L1764 111111111011101111111111111111111111*
L2124 111111111111111111111111111111111111*
L2160 111111110111011111111111111111111111*
L3456 00000000110111000000*
C1AEB*
7489

The equations are as follows:

module simple
title 'Simple test for 18V10'

	simple	device 'P18V10G';

	A,B,C,Y1,Y2,Y3	pin 3,4,5,13,14,15;

	X = .X.;

equations
	Y1 = A & B;
	Y2 = A # B;
	Y3 = !C;
end

[rhgndf]

The write PES functionality might not be complete since 18V10 might need a sendAddress after sending the PES

It might be a 16V8 relabelled though, so maybe reading it as a 16V8 gives something

[ole00]

Relabelled 16V8 - I thought that as well, tried to read as 16V8, but that did not work either.
PES writing not implemented for 18V10 - good point, I'll take a look.

[rhgndf]

The 18V10s I have are not laser etched. Although I have a few laser etched 16V8s that read properly.

[ole00]

Thanks for the image. My new order of GAL18V10 is 20LP - same as yours, so hopefully they will work.

I've tested GAL6001 and GAL6002. I found 3 issues on GAL6001, I'm wondering whether you've noticed them as well:

1. The erase command erases the chip and the PES. Rewriting the PES fixes the issue, but it is not consistent with the other GAL chips. I could probably fix that by rewriting the pes after write, but I want to be sure that is is a common issue, not just specific for the few of my GAL6001 samples. BTW I tested eraserow=61 as well and it does not erase the fuses completely. The eraseall=62 erases all fuses including the PES (as is expected). GAL6002 does not have the issue.
2. The write command does not write the fuses properly, it needs to be written at least 4x. This is because the afterburner reduces the VPP by 2V (as I mentioned earlier). I can fix that by not reducing the VPP for 6001 and 6002.
3. After writing the fuses afterburner is in a 'unresponsive' state whereby it does not respond to serial commands for ~ 20 seconds. I wonder whether afterburner gets reset or browns out. I would be good to understand it and ideally fix it.

[ole00]

BTW. I could not find any software that can make JED files for GAL6001 or GAL6002. The ispLever software from Lattice no longer supports free licence, so I coud not use it. It's a shame as these these GALS are still available and seem to be quite advanced compared to GAL22V10. I wonder whether the GAL could be supported by GALasm.

[rhgndf]

That is odd, the erase command didn't erase the PES for GAL6001, it's just that my 6002 has the PES wiped for some mysterious reason: it read fine at first and I didn't send in any erase command and the CFG bits are not wiped.

I did not observe behaviour 2 and 3 on my afterburner, except when the chip is faulty and has the EDIT pin on 12V shorted to ground.

Let me do a few more tests to try to reproduce your observations.

[rhgndf]

Also, mind posting the PES of the GAL6001 and GAL6002 before it was erased?

Here's mine:
GAL6001: 00 05 41 A1 CD A6 03 00
GAL6002: 00 05 44 A1 CD A6 03 00

[rhgndf]

1. Here's what I found on my side:
   Trying ./afterburner e -d /dev/ttyACM0 -t GAL6001 then ./afterburner r -d /dev/ttyACM0 -t GAL6001 works, fuses are all 1 but the PES is intact. Trying ./afterburner e -d /dev/ttyACM0 -t GAL6001 -all wipes the PES to all 0 and writing it back with ./afterburner p -d /dev/ttyACM0 -t GAL6001 -nc -pes '00:05:41:A1:CD:A6:03:00' works as expected.
   In the code, eraserow=63 and eraseallrow=62, and I can confirm the same behaviour with row 61. Row 63 erases the fuses but not the PES for my 6001.

2. Here's the PES decoded info:
   PES info: 5V Lattice GAL6001 VPP=12.50 Timing: prog=40 erase=25
   Running ./afterburner wv -d /dev/ttyACM0 -t GAL6001 -f 6001.jed gives 0 verify errors

3. Is it due to issue PC program does not recognize output sometimes #41?

[ole00]

GAL6001B 30LP
01 01 40 A1 1C 9C 4C 9C 00 00

GAL6002B 15LP
00 05 44 A1 CD A6 03 00 00 00

Thanks for testing that.

[rhgndf]

GAL6001B 30LP
01 01 40 A1 1C 9C 4C 9C 00 00

Based on documentation online it seems like 0x40 is a 6001 without the B?

[rhgndf]

Here's the image if you wish to do a visual comparison.

[rhgndf]

Or maybe it would be better to add support for the reimplementation of GALasm: https://github.com/simon-frankau/galette

You can try GALasm that runs in your web browser here: https://rhgndf.github.io/galasm-web/
Do you want to add this to your docs?

[ole00]

Possibly, one of the 6001 IC was programmed when I got it. The PES was probably overwritten by the contents as specified in the JED file - which could be designed for 6001 (non B). Anyway, the programming seems to work reliably with the non-reduced VPP so I'll use that and consider it as a pass. Thanks for the info.

These are the IC I got, they look quite similar to yours.

[ole00]

Ah - yes, I tried your Web bases Galasm and it is good. I'll check galette...

[rhgndf]

In general, if they are pulls it's unlikely for them to be the same date code. There's a date code on the underside of the chip, could be useful to check that and see if it matches. If not it could be a 6001 relabelled to 6001B.

[ole00]

There is no date code on my GAL6001B ICs, but there is a barely seen smudge indicating the date code was probably cleaned. Yes, they are pulls, some of the pins are tinned a bit. These were bought on Aliexpress. OTOH my GAL6002B do have date code underside (was not aware of it) - also bought on Aliexpress.

[rhgndf]

Tested writing and reading from 18V10 using your example jed file. Looks like working.

[ole00]

Just received my new GAL18V10-20LP and they work OK (tested erase, read and write ) on my modded Afterburner board. I'm merging your request. Thanks.