Current inexpensive programmer for 22V10's 16V8's?

[PCB.Wiz]

Hello, I'm trying to build the ATF blaster, one question though. In the schematic 4.7k is used to pull the GPIO to 5V. Is it possible to use 10k instead? Because I've read the page that ATF blaster is based on, it has one section that mention this:

Use 4k7 resistors to connect all VIL pins to the GND pin (we use 4k7 instead of the 10k mentioned in other documents, because some GALs have internal pull-ups of only 50k and illegal input states would occur using 10k resistors). Use 4k7 resistors to connect all other pins (including GND and EDIT) to the VCC pin to prevent open inputs during programming.

That text looks to be talking about pull-downs on VIL pins, presumably there for miss-socket protection. Pull-ups is a different question, and either should be fine.

[MadTux]

Currently fiddling with some Lattice GAL16V8Bs to recreate/verify some cloned PAL16L8 for ancient TIG welder repair/backup.

From my experience, WinCUPL works great with non Atmel GALs.
TL866 is utter garbage for programming GALs, all kind of weird behavior, like inverted outputs and garbled input pins. Nice programmer for EPROMs/EEPROMs though.
Switched over to Topwin Top853 with software 6.x. Works great, so far, Lattice GAL16V8B does what it was programmed for

My messy setup, basically a 20bit 74HC193 counter to get every input state, connected to 2x PAL18L8/GAL16V8, (1x DUT and the other the hopefully correctly cloned device). HP-16500C to capture data and espresso logic minimizer to get logic equations. To check for good clone, I use 7A13 differential amplifier connected to outputs, a line means good clone, any logic signals between pins => bad clone

[ebastler]

My messy setup, basically a 20bit 74HC193 counter to get every input state, connected to 2x PAL18L8/GAL16V8, (1x DUT and the other the hopefully correctly cloned device). HP-16500C to capture data and espresso logic minimizer to get logic equations. To check for good clone, I use 7A13 differential amplifier connected to outputs, a line means good clone, any logic signals between pins => bad clone

Nice test jig, and an impressive bench! 
Can you test for correct tri-state behavior too?

I have only used my TL866 on one GAL design so far, an ATF16V8B in complex mode. (Some registers, some logic outputs, some of them tri-state outputs.) That worked nicely. Maybe I just got lucky?

[MadTux]

Interesting, also have some cheap ATF16V8s from china, but haven't used them so far, because I read everywhere about problems with programming them. So I stuck to the Lattice ones.

Not sure about tri-state output, since I'm mostly about cloning the still good ones in my 2 welders and eventually recreating a probably broken PAL20L8.
I have every input and IO pin connected to 74HC193 counter by 2.2k resistor. If PAL has IO defined as input, I see counter signal. Otherwise 74HC193 signal is overwritten by PAL internal logic.

I like my testbench as well, a result of 15years of TEA 

[PCB.Wiz]

I have only used my TL866 on one GAL design so far, an ATF16V8B in complex mode. (Some registers, some logic outputs, some of them tri-state outputs.) That worked nicely. Maybe I just got lucky?

The ATF16V8x are recently added, so they should also be recently tested

Interesting, also have some cheap ATF16V8s from china, but haven't used them so far, because I read everywhere about problems with programming them. So I stuck to the Lattice ones.

For initial clone testing, it makes sense to minimise variations, but the active production parts, for SPLDs are pretty much only ATMEL, so I would suggest you also check codes on the ATF16V8x, since you have everything there ?

I did ask the TL866 supplier to add Vector Testing, which the better programmers can do, & gave them some example ATF16V8BQL vector files for testing.
It seems you already have your own vector test setup, in a broader sense

[ebastler]

The ATF16V8 are recently added, so they should also be recently tested

I did that GAL project four years ago, so the ATF16V8B has been supported for a while.

[PCB.Wiz]

The ATF16V8 are recently added, so they should also be recently tested

I did that GAL project four years ago, so the ATF16V8B has been supported for a while.

You will be right, I was going by their release notes, which I see cover other ATF16V8x variants.
Version: V8.08 Support:15411--2018.10.30
ADD: ATF16LV8C ATF16LV8CZ ATF16LV8CEXT
Version: V8.07 Support:15401--2018.10.23
ADD: ATF16V8C ATF16V8CZ ATF16V8CEXT
ATF22V10C ATF22V10C(UES) ATF22V10CEXT
ATF22V10CQ ATF22V10CQ(UES)
ATF22V10CQZ ATF22V10CQZ(UES)
ATF22V10CZ ATF22V10CZ(UES)
Version: V8.05 Support:15360--2018.10.20
ADD: ATF20V8B ATF20V8BL ATF20V8BQ ATF20V8BQL
ATF22V10B ATF22V10BL ATF22V10BQ ATF22V10BQL
next step: will add more PLD chips.
FIXED: GAL22V10B M95320W M95128W

Anyway, they seem to be Atmel-PLD active, and should accept any bug feedback.

[nospam2000]

They can do IC test on logic, so the building blocks are already there, so PLD test vectors should be possible.

That would be very awesome if doable.

I started to implement PLD logic test for the TL866II Plus using 'minipro' as base. It can read test vectors from .jed and from .si/.sim files. It is not finished, but you might want to have a look at it.

In the .jed mode 22V10, 16V8 and 20V8 should work, when the test vectors contains all pins in linear order (pin 1,2,3,4,5...).
In the .si/.sim mode at the moment only 22V10 PLDs are supported, because I need a way to pass the GND+VCC pin numbers.

There are three command line switches:

• -T Perform chip logic test
• -U <filename> Test vectors for logic test, can be .DAT, .JED or or .SI (e.g. from WinCUPL; .SI also needs .SIM file)
• -W Increase verbositiy level for chip logic test output, can be given up to 6 times to increase level (e.g. '-W -W')

modified version of minipro: https://gitlab.com/michael.dreher42/minipro/-/tree/logic_test (make sure to fetch the 'logic_test' branch)
gitlab issue where the progress is discussed: https://gitlab.com/DavidGriffith/minipro/-/issues/77

  Michael

[Bud]

Just wanted to share my experience with Bruce's ATFBlast programmer and software he posted earlier

http://www.bhabbott.net.nz/atfblast.html

I built the programmer and it worked on my desktop but ATF chips did not work on my Thinkpad laptop, until I added a buffer (I used a 7407 logic IC) on the ACK line between the PLD output and pin 10 of the parallel port + pullup 4.7K resistor , since 7407 is open collector buffer. Apparently Atmel ATF chips were not able to drive well the output line, though GAL chips worked fine. The buffer fixed that.

In terms of software Bruce's ATFBlast was unstable and flaky on both the laptop and desktop (both WinXP) so I had to abandon that software. Also for some reason it did not detect LPT1, just LPT2 and LPT3 and the port addresses were mixed up. That happened both on the laptop and desktop. What worked perfectly was the software from the user marinovsoft who posted links to it on the previous page of this thread. That worked great and I programmed a few ATFs for a project.  So I can recommend marinovsoft's software for use with Bruce's hardware.

[nospam2000]

Just wanted to share my experience with Bruce's ATFBlast programmer and software he posted earlier
In terms of software Bruce's ATFBlast was unstable and flaky on both the laptop and desktop (both WinXP) so I had to abandon that software.

You might want to have a look at afterburner. It uses an USB connection instead of a parallel port and the time critical part is done by a ATMega MCU, so you can use a recent operating system.

It is based on ATFBlast.

  Michael

[vladutm]

Hello,

last days I started to create this kind of Parallel programmer scheme, starting from atfblast.
In my focus is ATF16V8BQL, I used the Bruce scheme from bhabbot,net.nz. on Win Xp
Currently I'm on status of conditioning with zeros or erasing with ones, but can't programm write with what I want. The single file that is write on the chip si conditio.jed file with zeros.
I also used a buffer for ACK line but didn't change the issue.

I used both applications atfblast and marinovsoft. same behavior.. I will put an oscilloscope on them or use a saleae8 tracer.

Any idea?
I will add some photos from home..

[vladutm]

Hello Bud,

Could you support me with any hints for my last week message? about ATFBlast and LPT + your modifications?

As you will read, I can write only conditio.jed content, it means set all memory to zeros and also Erase all chip memory which means set all memory with ones, any other write than conditio.jed is not accepted..

[vladutm]

Hello,

Solved !!!

Finally I solved the issue... the root cause was to a missing accent to the preparing device for writing... It's saying clear also on http://www.bhabbott.net.nz/atfblast.html on programming procedure on point 6 (6.) to erase the GAL if after reading not all bits are '1'.
Firstly maybe for more of us, erasing means all bits  shall be zeros ('0') because I condtioned with zeros, Erased GAL with ones and after that again conditioned with zeros and tried to write for example all with ones... but not in this PLD case, here Erase GALL means all bits shall be ones ('1'), which also the "Erase GAL" button is doing.

Why I did this mistake?  because ATMEL recommends to condition with zeros twice before programming but nothing about Erasing with ones between conditioning and new programming... 

So be carrefull here...

Second, I think point 6. and recommendation from ATMEL to condition two times with zeros ('0', Conditio.JED) and after that Erase GAL which will put all bits to one ('1', Erase GAL button) ARE A MUST and shoul be underlined on reference and application doc. 

The rest of the circuit and appl from Bruce (bhabbott) and marinovsoft are working fine with and without proposed ACK pin buffer. So both sheme proposed are fine. I tested on Win XP on desktop with integrated LPT port, but will try also on Win7 and Win10 with USB to LPT addapter.

So, in the end, be patient to do an Erase GAL with ones before each new writing process. As I saw it is not accepted to do Erase GAL -> write file_A content-> write file_B content. You have to do Erase GAL -> write file_A -> Erase GAL -> write file_B.

I am aware I wrote so many times same idea but maybe causing I lost so many nights with this programmer until worked fine..

For any questions please Reply.

[vladutm]

Today I did additional tests, reading / writting with ATF16V8BQL chips.

Unfortunatelly I think I found a bug in the applications or in my pcb, I'm not sure. The idea is that I worked with three packages type for the same ATF16V8BQL chip:  ATF16V8BQL-15XU, ATF16V8BQL-15SU and ATF16V8BQL-15JU . For the first two the reading and writting is doing fine, but for the last one, 15JU I saw some bugs on writting or reading, when I write my jed content I saw are wrote additional zeros in random places but somehow repetitive. I will add images later.
More over, I observed if I do many reading consecutive proceses, I can see zeros random in different places each time.

For all of these observations are not the case for 15SU and 15XU, they are working fine.

I tried to check ATMEL documentation to see any possible programming differences with no success until now.

Could somebody support me from applications?

I did teste with same behavior with all ATFBlast3.0, ATFBlast3.1 from Bruce and ATFBlast from marinivsoft.

[PCB.Wiz]

Today I did additional tests, reading / writting with ATF16V8BQL chips.

Unfortunatelly I think I found a bug in the applications or in my pcb, I'm not sure. The idea is that I worked with three packages type for the same ATF16V8BQL chip:  ATF16V8BQL-15XU, ATF16V8BQL-15SU and ATF16V8BQL-15JU . For the first two the reading and writting is doing fine, but for the last one, 15JU I saw some bugs on writting or reading, when I write my jed content I saw are wrote additional zeros in random places but somehow repetitive. I will add images later.
More over, I observed if I do many reading consecutive proceses, I can see zeros random in different places each time.

For all of these observations are not the case for 15SU and 15XU, they are working fine.

I tried to check ATMEL documentation to see any possible programming differences with no success until now.

Could somebody support me from applications?

I did teste with same behavior with all ATFBlast3.0, ATFBlast3.1 from Bruce and ATFBlast from marinivsoft.

The die is exactly the same in all packages, but it may be the PLCC one has longer leads via a socket  adaptor ?

You could try decoupling directly under the PLCC socket, and also try lowering Vcc slightly.
addit:
We have found some PLDs pass programmer vector tests at slightly reduced Vcc, and ATF16V8's seem to vector test ok to below 3V
Vcc during program is trickier, if the shorter leads mentioned below do not fix the issue, you could try lower Vcc during shift operations and restore at the write pulse times.


With longer leads,  moderate series R can also sometimes help improve programming problems.  Typically ~ 100R in series with clocks reduces the ringing, and overshoot can result in extra clocks.

[vladutm]

Thanks for fast answer.

Yes, I'm expecting also to have same die chip content inside and only the packages/pinstypes to be different.

Anyway, I will try to implement what you suggested and come back later.

If you have any other hints, please let me know...

Updated post:
As you can see in my image in the right side are that two PCB that are working fine and in left side is may hand made PCB which has problem..
 In this morning I remembered I had like same issue with SPI in 2013 when I worked on a 3D printer concept design and I did an SD addaptor to arduino SPI from this same Cu green PCB... old times.. I have to contact old company to find that addaptor and see on which pin I accidentally found that a small SMD capacitor to GND I think solved the communication Issue...

[PCB.Wiz]

As you can see in my image in the right side are that two PCB that are working fine and in left side is may hand made PCB which has problem..

Those look like quite long wires for PLD programming.
Can you reduce or eliminate those, so there is less cross talk and bounce ? 


Addit: I see you use ATF16V8BQL, you could also try ATF16V8BQ (if you have them) ?
The BQL parts have a dynamic power wakeup enabled, and that means more Icc variation with the clock.
The benefit is lower static power.