Issue with ATF22V10C

[SteveD]

@Daniel

Your problem got me curious so I gave it a try this afternoon. Discovered that this works:
Device g22v10 ;
/* *************** INPUT PINS *********************/
PIN 1 = A ;
PIN 13 = OE ;
/* *************** OUTPUT PINS *********************/
PIN 22 = Y0 ;
PIN 23 = Y1 ;

Y0 = A;
Y0.oe = OE;
Y1 = !A;
Y1.oe = OE;

And that this doesn't:
Device g22v10 ;
/* *************** INPUT PINS *********************/
PIN 1 = A ;
PIN 13 = ! OE ;
/* *************** OUTPUT PINS *********************/
PIN 22 = Y0 ;
PIN 23 = Y1 ;

Y0 = A;
Y0.oe = OE;
Y1 = !A;
Y1.oe = OE;

Can you see the difference?

At this point I'd be tempted to write something up and pass it on to the Microchip engineers. I'm no GAL expert but this one just seems weird.

[Chromatix]

Surely for equivalence, you should have Y0.oe = !OE; and similarly for Y1?

[SteveD]

Wasn't trying for logical equivalence, just wanted to simplify Daniel's code to the point where I could make a demonstrable pass/fail scenario. Changing the polarity of OE simply changes the fuse between 86 and 87. This is easily seen in the WinCUPL .doc and JEDEC .jed files.

I'm testing with a TL866II+ programer running Xgpro v10.09 (latest). The device under test is an ATF22V10C-15PU, recently purchased from Element14 in the manufacturers tube.

Further testing:
Case 1 - working code, programmer device set to ATF22V10C
Works. Outputs enabled when OE high, tri state when OE low.

Case 2 - failing code, programmer device set to ATF22V10C
Fails. Outputs enabled regardless of OE level.

Case 3 - working code, programmer device set to ATF22V10C(UES)
Works. Outputs enabled when OE high, tri state when OE low.

Case 4 - failing code, programmer device set to ATF22V10C(UES)
Fails. Outputs disabled regardless of OE level.

Given these results the programmer is starting to look suspect. I'm going to try hacking up an Arduino programmer for comparison purposes. I need to know if the TL866 is able to program the ATF22V10 correctly.

[Chromatix]

There are apparently some nasty and non-obvious quirks in the Atmel programming algorithm, as detailed by someone who has reverse-engineered it. It wouldn't be beyond reasonable for a cheap programmer to have implemented something which mostly works.

Is this programmer able to read back the contents of the fuse map and check it against the original file?

[SteveD]

In the last day have read numerous accounts re Atmel GAL programming problems. Unfortunately, Atmel/Microchip are the only company still making GAL type chips. I'd really like to get a workable solution, GALs are just so handy for retro computing design.

Yes, have tried the write/read back experiment, got the same fuse map back. Presumably the person writing the code has made the same error in both directions. Easy enough to do when the vendor refuses to provide documentation.

[Chromatix]

My Dataman S4 can apparently support Atmel GALs, including (unusually) the ATF750 series. That would be officially sanctioned support, rather than the Chinese reverse-engineered variety.

Unfortunately it needs a £200 adapter to do so, as well as me finishing the power supply modification to get it running properly. I suspect it should be possible to reverse-engineer what the adapter needs to be, and build it by hand, but that's something I don't have the right tools for yet.

[BigDumbDinosaur]

SteveD wrote:

@Daniel

Your problem got me curious so I gave it a try this afternoon. Discovered that this works...

You can produce better formatting of source code by enclosing it in the [ CODE ] keywords, which will produce the following result:

Code: Select all

Device g22v10 ;
/* *************** INPUT PINS *********************/
PIN 1 = A ;
PIN 13 = OE ;
/* *************** OUTPUT PINS *********************/
PIN 22 = Y0 ;
PIN 23 = Y1 ;

Y0 = A;
Y0.oe = OE;
Y1 = !A;
Y1.oe = OE;

And that this doesn't:
Device g22v10 ;
/* *************** INPUT PINS *********************/
PIN 1 = A ;
PIN 13 = ! OE ;
/* *************** OUTPUT PINS *********************/
PIN 22 = Y0 ;
PIN 23 = Y1 ;

Y0 = A;
Y0.oe = OE;
Y1 = !A;
Y1.oe = OE;

[floobydust]

Chromatix wrote:

My Dataman S4 can apparently support Atmel GALs, including (unusually) the ATF750 series. That would be officially sanctioned support, rather than the Chinese reverse-engineered variety.

Unfortunately it needs a £200 adapter to do so, as well as me finishing the power supply modification to get it running properly. I suspect it should be possible to reverse-engineer what the adapter needs to be, and build it by hand, but that's something I don't have the right tools for yet.

Well, I have the Dataman 40Pro... also supports the ATF750... and yes, claims to require the over-priced adapter. However, if you're programming a 24-pin DIP version, simply insert a 0.1uF cap with pins 12 and 24 (power) and it will program fine. I've tried it and it works. While I like the Dataman products and software support, some of their adapters are a bit on the braindead side for implementation and cost. In short, the pricey adapter includes a few 0.1uF caps that you install depending on which part you're using. I checked this out with their tech support over two years ago. You can also make up you own adapter by taking a DIP socket and integrating the bypass cap into it and using it as a carrier. Good luck.

[Shawn Odekirk]

Daniel,
I started this thread to ask a question about excessive product terms while programming an ATF22V10, but it has evolved into a discussion about a problem I discovered with pin 13. I have been able to boil it down to a simple example.

Code: Select all

Name     GAL_Test ;
PartNo   00 ;
Date     4/24/2020 ;
Revision 01 ;
Designer Engineer ;
Company  Shawn Odekirk ;
Assembly None ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 13 = INP_A;
PIN 14 = INP_B;

/* *************** OUTPUT PINS *********************/
PIN 20 = OUT_A;
PIN 21 = OUT_A_INV;
PIN 22 = OUT_B;
PIN 23 = OUT_B_INV;

OUT_A = INP_A;
OUT_A_INV = !INP_A;
OUT_B = INP_B;
OUT_B_INV = !INP_B;

In this example, OUT_A seems to be correct, but OUT_A_INV is always high. OUT_B and OUT_B_INV work correctly. This problem only seems to occur when the input is pin 13. You are using pin 13 as the input for your OE signal. I wonder if you moved your OE signal to another pin if your outputs would tri-state correctly.
Daniel, would you be willing to program an ATF22V10 with my example using your programmer and see if your results match mine?

floobydust wrote:

I've been using a Dataman 40pro for about 7 years now... it wasn't cheap, but (software) updates are still frequent and it handles the Atmel versions without any issue.

floobydust, would you be willing to program an ATF22V10 with my example using your Dataman programmer and see if it works correctly?

SteveD wrote:

I've used both the ATF22V10C and ATF16V8B, programmed successfully with a genuine TL866II+.

SteveD, would you also be willing to program an ATF22V10 with my example using your programmer and see if your results also match mine?

Hopefully, the results of these tests will help us determine if it's the TL866II+ programmer or something else.
I am including my .jed file in case it is my WinCupl settings that are causing the problem.

Thanks,
Shawn

[SteveD]

Shawn,
looking at it again I've realised that both examples have one thing in common. They are both making use of fuses in column 43, i.e. input pin 13 negated. I am of the opinion that the programmer isn't handling fuses in that column correctly. I can't prove it but it's looking pretty likely.

Based on my reading of the source code for an alternate programmer, fuse columns are converted into rows during the programming phase. Column 43 is the 'last' column and this has me wondering if the TL866 code suffers from a bounds error, i.e. a possible 'one off' error.

As a workaround do you have a spare input pin? Your code indicates pins 20 and 21 are free. Experiment by moving the pin 13 function there.

I don't think it's your code that is the problem.

[cbscpe]

I would try to get some Lattice GALs and check with them.

[Shawn Odekirk]

SteveD wrote:

As a workaround do you have a spare input pin? Your code indicates pins 20 and 21 are free. Experiment by moving the pin 13 function there.

I have tried moving address line A6 from pin 13 to another pin and verified that it works as expected, but I was hoping to leave pins 20 and 21 free for future chip select outputs. As it is, a problem with pin 13 causes me the least amount of trouble with address line A6 connected to it. It just results in the 6522 and 6551 each being selected at 2 address ranges instead of just one. Not a huge problem to deal with until I can get the ATF22V10C programmed correctly.

[Shawn Odekirk]

cbscpe wrote:

I would try to get some Lattice GALs and check with them.

I actually ordered some Lattice GALs yesterday. The estimated delivery is sometime before June 4, so it may be a while before I get them.
The original poster mentioned that he had no problems with his Lattice GALs, and that he only had a problem with the Atmel chips, so I would be surprised if I had problems with the Lattice chips after they arrive.

[Shawn Odekirk]

SteveD wrote:

Shawn,
looking at it again I've realised that both examples have one thing in common. They are both making use of fuses in column 43, i.e. input pin 13 negated. I am of the opinion that the programmer isn't handling fuses in that column correctly. I can't prove it but it's looking pretty likely.

Based on my reading of the source code for an alternate programmer, fuse columns are converted into rows during the programming phase. Column 43 is the 'last' column and this has me wondering if the TL866 code suffers from a bounds error, i.e. a possible 'one off' error.

Steve,
This information is great. This really helps me understand the Fuse Map page of the datasheet better.
Does anyone else use minipro? It is an open source program for the TL866xx series of programmers. Unfortunately, it currently does not support the ATF22V10C. I am hoping that referring to the source code for afterburner and ATFBlast, this description of the ATF22V10C programming algorithm, and your comments, will give me enough information to add support for the ATF22V10C to minipro.

[Shawn Odekirk]

TL;DR - when programming an Atmel ATF22V10C using the TL866II+ and Xgpro software, you should probably select the "ATF22V10C (UES)" profile.

After working with one of the minipro developers who provided some very helpful information, and reading the Atmel ATF22V10C datasheet more closely, I have been able to correctly program an ATF22V10C using the TL866II+ and Xgpro software.
Table 10-1 in the ATF22V10C datasheet lists the various compiler modes that can be selected by specifying different device names. Specifying "P22V10" will cause WinCupl to use PAL mode (5828 fuses), while specifying "G22V10" will cause WinCupl to use GAL mode (5892 fuses). The table also refers to UES in the GAL columns. Xgpro has separate profiles for "ATF22V10C" and "ATF22V10C (UES)". Selecting the "ATF22V10C" profile will only program 5828 fuses, while selecting the "ATF22V10C (UES)" profile will program 5892 fuses.
I have programmed an ATF22V10C with a simple test and verified that it works as expected.
Additionally, I have also correctly programmed an ATF22V10C using afterburner.