ATF22V10CQZ Address Decoder Not Working As Expected

[DRG]

I'm having issues attempting to get a ATF22V10CQZ to do my bidding. However, the source of the problem may be (at least) one of three things...

1) My lack of knowledge and understanding of what I think I'm attempting to do/the way I'm going about it,
2) An issue with Wincupl,
3) An issue with my verification process.

Using the address pins A15 to A5 inclusive, I am attempting to create the following memory map for my WDC65C02 system to use just one page for IO...

Code: Select all

0000 - 7F00   RAM
7F00 - 7F1F   IO0
7F20 - 7F3F   IO1
7F40 - 7F5F   IO2
7F60 - 7F7F   IO3
7F80 - 7FFF   IOX
8000 - FFFF   ROM

I have the connections to the ATF22V10 as follows...

Code: Select all

            ________
           |        |
   CLK x---|1     24|---x Vcc                      
    RW x---|2     23|---x IOX_CS                   
   A15 x---|3     22|---x IO3_CS                   
   A14 x---|4     21|---x IO2_CS                   
   A13 x---|5     20|---x IO1_CS                   
   A12 x---|6     19|---x IO0_CS                   
   A11 x---|7     18|---x ROM_CS                   
   A10 x---|8     17|---x RAM_CS                   
    A9 x---|9     16|---x OE                       
    A8 x---|10    15|---x WE                       
    A7 x---|11    14|---x A5                       
   GND x---|12    13|---x A6                       
           |________|

I generate the .jed file from Wincupl with no warnings or errors and I program the device using my TL866II+ again with no errors. I've used "ATF22V10CQZ" as well as "ATF22V10CQZ(UES)" when programming using minipro.
However, when I hook the CPLD up to my Arduino to check the logic between the address pins and the chip selects, I get the following (I reproduce the output around 8000 where all the action should happen)...

Code: Select all

AAAA AAAA AAA    R R I I I I I
1111 1198 765    A O O O O O O
5432 10          M M 0 1 2 3 X

0111 1110 101 -> 0 1 1 1 1 1 1
0111 1110 110 -> 0 1 1 1 1 1 1
0111 1110 111 -> 0 1 1 1 1 1 1
0111 1111 000 -> 1 1 1 0 1 1 1
0111 1111 001 -> 1 1 1 0 1 1 1
0111 1111 010 -> 1 1 1 1 1 0 1
0111 1111 011 -> 1 1 1 1 1 0 1
0111 1111 100 -> 1 1 1 1 1 1 0
0111 1111 101 -> 1 1 1 1 1 1 0
0111 1111 110 -> 1 1 1 1 1 1 0
0111 1111 111 -> 1 1 1 1 1 1 0
1000 0000 000 -> 1 0 1 1 1 1 1
1000 0000 001 -> 1 0 1 1 1 1 1
1000 0000 010 -> 1 0 1 1 1 1 1

I really expected this, however...

Code: Select all

AAAA AAAA AAA    R R I I I I I
1111 1198 765    A O O O O O O
5432 10          M M 0 1 2 3 X

0111 1110 101 -> 0 1 1 1 1 1 1
0111 1110 110 -> 0 1 1 1 1 1 1
0111 1110 111 -> 0 1 1 1 1 1 1
0111 1111 000 -> 1 1 0 1 1 1 1
0111 1111 001 -> 1 1 1 0 1 1 1
0111 1111 010 -> 1 1 1 1 0 1 1
0111 1111 011 -> 1 1 1 1 1 0 1
0111 1111 100 -> 1 1 1 1 1 1 0
0111 1111 101 -> 1 1 1 1 1 1 0
0111 1111 110 -> 1 1 1 1 1 1 0
0111 1111 111 -> 1 1 1 1 1 1 0
1000 0000 000 -> 1 0 1 1 1 1 1
1000 0000 001 -> 1 0 1 1 1 1 1
1000 0000 010 -> 1 0 1 1 1 1 1

RAM, ROM and IOX behave as expected, but I am stumped as to why IO0 and IO2 never get selected whilst IO1 and IO3 are selected twice.
Why do 0111 1111 000 and 0111 1111 001 give the same output? (as does 0111 1111 010 and 0111 1111 011).

I have tried 3 different ways of inputting the logic into Wincupl (becoming more verbose each time) - they all pass with no errors and provide the same result when testing. Here is my latest offering...

Code: Select all

Name     65C02GlueLogic ;
PartNo   00 ;
Date     13/08/2023 ;
Revision 00 ;
Designer DRG ;
Company   ;
Assembly  ;
Location  ;
Device   g22V10 ;

/* Input */
Pin 1        	= CLK;
Pin 2        	= RW;
Pin [3..11]  	= [A15..7];
Pin [13..14]	= [A6..5];


/* Output */
Pin 15	= WE;
Pin 16	= OE;
Pin 17	= RAM_CS;
Pin 18	= ROM_CS;
Pin 19	= IO0_CS;
Pin 20  = IO1_CS;
Pin 21  = IO2_CS;
Pin 22	= IO3_CS;
Pin 23	= IOX_CS;

/* Local Variables */
ROM 	      = A15;
IO		      = !A15 & A14 & A13 & A12 & A11 & A10 & A9 & A8;  /* Temp variable */
IO0		      = IO & !A7 & !A6 & !A5;
IO1		      = IO & !A7 & !A6 &  A5;
IO2		      = IO & !A7 &  A6 & !A5;
IO3		      = IO & !A7 &  A6 &  A5;
IOX		      = IO &  A7;
RAM		      = !(IO0 # IO1 # IO2 # IO3 #IOX # ROM);
!WE       	= CLK & !RW;
!OE       	= CLK & RW;
!RAM_CS   	= RAM;
!ROM_CS   	= ROM & RW;
!IO0_CS	    = IO0;
!IO1_CS	    = IO1;
!IO2_CS	    = IO2;
!IO3_CS	    = IO3;
!IOX_CS	    = IOX;

Previous to this, I used the following with the same pin definitions...

Code: Select all

/* Local Variables */
FIELD Address = [A15..5];
FIELD Decodes = [RAM, !IO0_CS, !IO1_CS, !IO2_CS, !IO3_CS, !IOX_CS, ROM];

/*  Logic */

TABLE Address => Decodes {
[0000..7EFF] => 'b'1000000;
[7F00..7F1F] => 'b'0100000;
[7F20..7F3F] => 'b'0010000;
[7F40..7F5F] => 'b'0001000;
[7F60..7F7F] => 'b'0000100;
[7F80..7FFF] => 'b'0000010;
[8000..FFFF] => 'b'0000001;
}


/*  Logic */
RAM       	= Address:[0000..7EFF];
IO0       	= Address:[7F00..7F1F];
IO1       	= Address:[7F20..7F3F];
IO2       	= Address:[7F40..7F5F];
IO3       	= Address:[7F60..7F7F];
IOX	        = Address:[7F80..7FFF];
ROM       	= Address:[8000..FFFF];

!WE       	= CLK & !RW;
!OE       	= CLK & RW;
!RAM_CS   	= RAM;
!ROM_CS   	= ROM & RW;

As well as my first effort...

Code: Select all

/*  Logic */
RAM       	= Address:[0000..7EFF];
IO0       	= Address:[7F00..7F1F];
IO1       	= Address:[7F20..7F3F];
IO2       	= Address:[7F40..7F5F];
IO3       	= Address:[7F60..7F7F];
IOX		      = Address:[7F80..7FFF];
ROM       	= Address:[8000..FFFF];
!WE       	= CLK & !RW;
!OE       	= CLK & RW;
!RAM_CS   	= RAM;
!ROM_CS   	= ROM & RW;
!IO0_CS   	= IO0;
!IO1_CS   	= IO1;
!IO2_CS   	= IO2;
!IO3_CS   	= IO3;
!IOX_CS	    = IOX;

My thinking is that 11 bits (A15-A5) will allow 64k to be divided into 2048 "blocks" of 32 bytes. Hence, my use of FF00-FF1F, FF20-FF3F etc.

I'm hoping someone from the forum can shed some light onto this as I have done as much self-help as I am able, trawling this forum and Google but not coming up with anything that highlights the problem.

Thanks.

Dave

[Martin A]

You could try replacing

Code: Select all

FIELD Address = [A15..5];

in the second attempt with

Code: Select all

FIELD Address = [A15..0];

Even though A0 to A4 aren't connected, they're part of the 16 bit address. As long as the addresses ranges resolve to don't care for the low 5 bits WinCUPL should be happy.

This code from my DIY Atom builds as expected, with only 7 of the address lines referenced in the Field statement being attached to the 22V10.

Code: Select all

Name     AtomGAL ;
PartNo   00 ;
Date     09/02/2018 ;
Revision 01 ;
Designer Engineer ;
Company  None ;
Assembly None ;
Location  ;
Device   p22v10 ;

/* *************** INPUT PINS *********************/
PIN   1  = A12                      ; /*                                 */ 
PIN   2  = A13                      ; /*                                 */ 
PIN   3  = A14                      ; /*                                 */ 
PIN   4  = A15                      ; /*                                 */ 
PIN   5  = A11                      ; /*                                 */ 
PIN   6  = A10                      ; /*                                 */ 
PIN   7  = A9                       ; /*                                 */ 
PIN   8  = rw                       ; /*                                 */ 
PIN   9  = phi2                     ; /*                                 */ 



/* *************** OUTPUT PINS *********************/
PIN  14   = wr                      ; /*                                 */ 
PIN  15   = rd                      ; /*                                 */ 
PIN  16   = ma2                     ; /*                                 */ 
PIN  17   = vram                    ; /*                                 */ 
PIN  18   = io6                     ; /*                                 */ 
PIN  19   = io4                     ; /*                                 */ 
PIN  20   = io2                     ; /*                                 */ 
PIN  21   = io0                     ; /*                                 */ 
PIN  22   = ramcs                   ; /*                                 */ 
PIN  23   = romcs                   ; /*                                 */ 


Field address = [A15..0];
!ramcs = address:[0000..7FFF] ;
!io0 =address:[B000..B3FF] ;
!io2 =address:[B400..B7FF] ;
!io4 =address:[B800..BBFF] ;
!io6 =address:[BC00..BFFF] ;

!romcs = address:[C000..FFFF] ;
!vram = address:[8000..97FF] ;
!ma2 = address:[A000..AFFF] 
;
!rd =  rw & phi2  ;
!wr = !rw & phi2  ;

[gfoot]

Before looking at your cupl code - have you checked the design with the simulator in WinCupl? I find that's always worth doing, it will highlight these issues with your logic, as well as forcing you to write out some test cases that express what you expect - that in itself sometimes leads to realising flaws in your design, in my experience.

Also, are you sure A5 is properly connected?

Edit: Here's a simulator-input file for your case, which works fine with the all four PLD code fragments you posted:

Code: Select all

Name     65C02GlueLogic ;
PartNo   00 ;
Date     13/08/2023 ;
Revision 00 ;
Designer DRG ;
Company   ;
Assembly  ;
Location  ;
Device   g22V10 ;

ORDER:  A15, A14, A13, A12, A11, A10, A9, A8, %1, A7, A6, A5, %1, IO0_CS, IO1_CS, IO2_CS, IO3_CS, IOX_CS;

VECTORS:
01111111 000 LHHHH
01111111 001 HLHHH
01111111 010 HHLHH
01111111 011 HHHLH
01111111 100 HHHHL
01111111 101 HHHHL
01111111 110 HHHHL
01111111 111 HHHHL

[DRG]

gfoot wrote:

Edit: Here's a simulator-input file for your case, which works fine with the all four PLD code fragments you posted:

Thanks for this - I just couldn't understand how to do the simulation at all. I opened your file, clicked "Simulate" and got the output in the attached image - 1 warning, no errors and a "Simulation successful" message. Do I have to do anything more?

If not, the output looks right to me - exactly how I expected it to look. Can you point me to somewhere to learn about how to write simulation input files like this, please? - that is so useful!
However, overall, no joy. I've moved the chip to a different area on the breadboard AND rewired to address the potential A5 issue - it is producing an output as if that pin wasn't working. I have even used a different ATF22V10CQZ.
Could it be then, that I'm just a shoddy coder and my verification program for the Arduino Mega2560 is the problem? Embarrassingly for me, the answer turns out to be a resounding "Yes". "C" is not my main language and the loop that sets the inputs was wrong...

Code: Select all

for (int n = 0; n < 6; n += 1) {

Guess what? When I change that to n < 7... Perfect!

Code: Select all

01111110100 -> 0 1 1 1 1 1 1
01111110101 -> 0 1 1 1 1 1 1
01111110110 -> 0 1 1 1 1 1 1
01111110111 -> 0 1 1 1 1 1 1
01111111000 -> 1 1 0 1 1 1 1
01111111001 -> 1 1 1 0 1 1 1
01111111010 -> 1 1 1 1 0 1 1
01111111011 -> 1 1 1 1 1 0 1
01111111100 -> 1 1 1 1 1 1 0
01111111101 -> 1 1 1 1 1 1 0
01111111110 -> 1 1 1 1 1 1 0
01111111111 -> 1 1 1 1 1 1 0
10000000000 -> 1 0 1 1 1 1 1
10000000001 -> 1 0 1 1 1 1 1
10000000010 -> 1 0 1 1 1 1 1
10000000011 -> 1 0 1 1 1 1 1

I am sorry for wasting your time, gentlemen, but can't thank you enough for taking that time in the first place - it did help me zero in to the source of the problem: A5 and my poor "C" coding skills.
It has also helped me understand Wincupl more too, for which I'm grateful.

[gfoot]

DRG wrote:

Thanks for this - I just couldn't understand how to do the simulation at all. I opened your file, clicked "Simulate" and got the output in the attached image - 1 warning, no errors and a "Simulation successful" message. Do I have to do anything more?

That's enough to run it. I'm not sure what the warning was. I don't do it through the awful, unstable GUI though - I use the command line instead. I don't know the command to run the simulator on its own, but there's an option to the "compile" command which causes it to automatically run the simulator after compiling.

Quote:

Can you point me to somewhere to learn about how to write simulation input files like this, please? - that is so useful!

This is the main reference I use for everything in WinCUPL - it has a section on the simulator and various syntaxes in the cupl file: https://ece-classes.usc.edu/ee459/libra ... erence.pdf

Quote:

Could it be then, that I'm just a shoddy coder and my verification program for the Arduino Mega2560 is the problem? Embarrassingly for me, the answer turns out to be a resounding "Yes". "C" is not my main language and the loop that sets the inputs was wrong...

Oops! It happens. It is often worth verifying that your test harness is actually working, and when a test fails, being open-minded and considering everything in the path from known conditions to the test outcome - including the test harness itself. Things like this can also be tested without any extra hardware, just by hardwiring pins to certain values, and that can be a good reality check when a test fails and you can't see why.

Now I believe there's also meant to be an option in minipro to run these simulator tests on the parts, but I don't use the official software so am not sure if it really exists. It definitely has options for testing 74-series logic ICs though so possibly might have this option too.