WinCupl / 22V10 - Excessive Number of Product Terms

[Shawn Odekirk]

I was trying to make my memory map decoder easier to read by using FIELD, but I am getting "excessive number of product terms: CSROM".

Code: Select all

Name     mem_v2 ;
PartNo   00 ;
Date     4/22/2020 ;
Revision 01 ;
Designer Engineer ;
Company  Shawn Odekirks ;
Assembly None ;
Location  ;
Device   g22v10 ;

/* *************** INPUT PINS *********************/
PIN 1  = CLK;
PIN 2  = RW;
PIN 3  = A15;
PIN 4  = A14;
PIN 5  = A13;
PIN 6  = A12;
PIN 7  = A11;
PIN 8  = A10;
PIN 9  = A9;
PIN 10 = A8;
PIN 11 = A7;
PIN 13 = A6;
PIN 14 = A5;
PIN 15 = A4;

/* *************** OUTPUT PINS *********************/
PIN 16 = !CS6551;
PIN 17 = !CS6522;
PIN 18 = !CSROM;
PIN 19 = !CSRAM;
PIN 22 = !WE;
PIN 23 = !OE;

FIELD address = [A15..A0];

CSRAM  = address:[0000..7FFF];
CS6522 = address:[8000..800F];
CS6551 = address:[8010..801F];
CSROM  = address:[8020..FFFF];

WE = !RW & CLK;
OE = RW;

If I instead use this, it compiles and seems to work fine.

Code: Select all

CSROM  = A15 & !(CS6522 # CS6551);

I hate to say it, but I don't really know why that works. Could someone explain why I am getting the error and how the CS6522 and CS6551 outputs are being used in the logic for CSROM?
Also, can I leave the pin assignments blank and have WinCupl fit the design into a 22v10, or is that not supported for that device. I got errors when I tried.

Thanks,
Shawn

[BigDumbDinosaur]

Shawn Odekirk wrote:

I was trying to make my memory map decoder easier to read by using FIELD, but I am getting "excessive number of product terms: CSROM"...

Referring to the following code fragment:

Code: Select all

FIELD address = [A15..A0];

CSRAM  = address:[000x..7FFx];
CS6522 = address:[800x..800x];
CS6551 = address:[801x..801x];
CSROM  = address:[802x..FFxx];

You are trying to decode your chip selects all the way to A0, but you haven't declared A0-A3 in your input assignments. Hence the above statements are not resolvable unless you make bits 0-3 "don't cares." Try those changes and see if it works for you.

That said, your memory map is unwieldy. It appears you are trying to maximize the amount of ROM visible to the MPU, which isn't going to work the way it would seem. The chip select may be at $8020, but as you will soon discover, unless ROM falls on a even block boundary, i.e., $8000, $A000, $C000, etc., you won't be able to access all of it. For example, in my POC V1.2 unit, I have a 32KB ROM mapped in at $00D000-$00FFFF (this is an '816, but the principle is the same). The first 1KB of the ROM is not accessible because it falls in the range $00C000-$00CFFF, an address range in which I/O hardware appears. This is an artifact of the way in which the ROM's address lines have to wired into the system. So when I burn a ROM I have to start at $1000 in it so code appears at $00D000. The most ROM I can access is 12KB, which is plenty.

If it were me, I'd map ROM in at $A000 or $C000. The former will give you 24KB and the latter 16KB. In both cases, that's a lot of ROM. Also, I'd map I/O in at page intervals. There is little to be gained in trying to decode to anything less than A8.

[cbscpe]

Shawn Odekirk wrote:

You are trying to decode your chip selects all the way to A0, but you haven't declared A0-A3 in your input assignments. Hence the above statements are not resolvable unless you make bits 0-3 "don't cares." Try those changes and see if it works for you.

No that's not the case here. WinCUPL knows that the the term

Code: Select all

CS6551 = address:[8010..801F];

is equivalent to A0..3 being don't cares (part of it's internal optimiziation). Either way using don't cares or a range that makes some address bits not required works.

The problem is within the term

Code: Select all

CSROM  = address:[802x..FFxx];

If you translate this to boolean equations it requires too many product terms as the address range is not nicely aligned to address bits and the output assigned to CSROM does not support that many product terms. However when using the combination of already existing equations that are as well used as outputs it requires on 2 product terms

[BigDumbDinosaur]

cbscpe wrote:

No that's not the case here. WinCUPL knows that the the term

Code: Select all

CS6551 = address:[8010..801F];

is equivalent to A0..3 being don't cares (part of it's internal optimiziation). Either way using don't cares or a range that makes some address bits not required works.

Actually, that is not something upon which you can rely. I know from playing around with it that it will not function that way when programming a CPLD. Bits that are not assigned to a pin should always be 'X'ed out to assure the compiler understands they are "don't cares."

[Martin A]

The field statements look fine to me.

I'd advised checking the compiler options, it won't build on the default settings. Set minimization to Quinn-McCluskey, and it will build to:

Code: Select all

*******************************************************************************
                                    mem_v2
*******************************************************************************

CUPL(WM)        5.0a Serial# 60008009
Device          g22v10  Library DLIB-h-40-1
Created         Thu Apr 23 08:49:09 2020
Name            mem_v2 
Partno          00 
Revision        01 
Date            4/22/2020 
Designer        Engineer 
Company         Shawn Odekirks 
Assembly        None 
Location        

===============================================================================
                            Expanded Product Terms
===============================================================================

CS6522 =>
    !A4 & !A5 & !A6 & !A7 & !A8 & !A9 & !A10 & !A11 & !A12 & !A13 & !A14 & 
      A15

CS6551 =>
    A4 & !A5 & !A6 & !A7 & !A8 & !A9 & !A10 & !A11 & !A12 & !A13 & !A14 & A15

CSRAM =>
    !A15

CSROM =>
    A5 & A15
  # A6 & A15
  # A7 & A15
  # A8 & A15
  # A9 & A15
  # A10 & A15
  # A11 & A15
  # A12 & A15
  # A13 & A15
  # A14 & A15

OE =>
    RW

WE =>
    CLK & !RW

address =>
    A15 , A14 , A13 , A12 , A11 , A10 , A9 , A8 , A7 , A6 , A5 , A4 , A3 , A2 , 
      A1 , A0

A4.oe  =>
    0 

A5.oe  =>
    0 

CS6522.oe  =>
    1 

CS6551.oe  =>
    1 

CSRAM.oe  =>
    1 

CSROM.oe  =>
    1 

OE.oe  =>
    1 

WE.oe  =>
    1 


===============================================================================
                                 Symbol Table
===============================================================================

Pin Variable                                    Pterms   Max     Min    
Pol   Name              Ext     Pin     Type     Used   Pterms  Level   
--- --------            ---     ---     ----    ------  ------  -----   

    A4                          15       V        -       -       -     
    A5                          14       V        -       -       -     
    A6                          13       V        -       -       -     
    A7                          11       V        -       -       -     
    A8                          10       V        -       -       -     
    A9                          9        V        -       -       -     
    A10                         8        V        -       -       -     
    A11                         7        V        -       -       -     
    A12                         6        V        -       -       -     
    A13                         5        V        -       -       -     
    A14                         4        V        -       -       -     
    A15                         3        V        -       -       -     
    CLK                         1        V        -       -       -     
 !  CS6522                      17       V        1       14      2     
 !  CS6551                      16       V        1       12      2     
 !  CSRAM                       19       V        1       16      2     
 !  CSROM                       18       V        10      16      2     
 !  OE                          23       V        1       8       2     
    RW                          2        V        -       -       -     
 !  WE                          22       V        1       10      2     
    address                     0        F        -       -       -     
    A4                  oe      15       D        1       1       0     
    A5                  oe      14       D        1       1       0     
    CS6522              oe      17       D        1       1       0     
    CS6551              oe      16       D        1       1       0     
    CSRAM               oe      19       D        1       1       0     
    CSROM               oe      18       D        1       1       0     
    OE                  oe      23       D        1       1       0     
    WE                  oe      22       D        1       1       0     


LEGEND    D : default variable         F : field      G : group
          I : intermediate variable    N : node       M : extended node
          U : undefined                V : variable   X : extended variable
          T : function


===============================================================================
                                   Fuse Plot
===============================================================================

SP 
 05764 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

AR 
 00000 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

Pin #23  05808 Mode  x- 
 00044 -------------------------------------------- 
 00088 ----x--------------------------------------- 
 00132 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00176 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00220 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00264 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00308 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00352 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00396 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #22  05810 Mode  x- 
 00440 -------------------------------------------- 
 00484 x----x-------------------------------------- 
 00528 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00572 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00616 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00660 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00704 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00748 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00792 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00836 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00880 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #21  05812 Mode  xx 
 00924 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 00968 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01012 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01056 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01100 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01144 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01188 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01232 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01276 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01320 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01364 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01408 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01452 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #20  05814 Mode  xx 
 01496 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01540 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01584 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01628 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01672 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01716 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01760 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01804 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01848 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01892 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01936 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01980 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02024 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02068 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02112 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #19  05816 Mode  x- 
 02156 -------------------------------------------- 
 02200 ---------x---------------------------------- 
 02244 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02288 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02332 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02376 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02420 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02464 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02508 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02552 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02596 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02640 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02684 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02728 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02772 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02816 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 02860 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #18  05818 Mode  x- 
 02904 -------------------------------------------- 
 02948 --------x-----------------------------x----- 
 02992 --------x---------------------------------x- 
 03036 --------x-------------------------------x--- 
 03080 --------x---------------------------x------- 
 03124 --------x-----------------------x----------- 
 03168 --------x-------------------x--------------- 
 03212 --------x---------------x------------------- 
 03256 --------x-----------x----------------------- 
 03300 --------x-------x--------------------------- 
 03344 --------x---x------------------------------- 
 03388 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03432 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03476 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03520 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03564 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03608 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #17  05820 Mode  x- 
 03652 -------------------------------------------- 
 03696 --------x----x---x---x---x---x---x-x-x-x-x-x 
 03740 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03784 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03828 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03872 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03916 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 03960 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04004 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04048 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04092 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04136 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04180 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04224 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04268 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #16  05822 Mode  x- 
 04312 -------------------------------------------- 
 04356 --------x----x---x---x---x---x---xx--x-x-x-x 
 04400 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04444 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04488 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04532 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04576 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04620 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04664 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04708 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04752 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04796 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04840 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #15  05824 Mode  x- 
 04884 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04928 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 04972 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05016 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05060 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05104 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05148 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05192 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05236 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05280 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05324 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Pin #14  05826 Mode  x- 
 05368 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05412 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05456 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05500 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05544 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05588 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05632 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05676 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 05720 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 


LEGEND    X : fuse not blown 
          - : fuse blown 

===============================================================================
                                 Chip Diagram
===============================================================================

                               ______________
                              |    mem_v2    |
                      CLK x---|1           24|---x Vcc                      
                       RW x---|2           23|---x !OE                      
                      A15 x---|3           22|---x !WE                      
                      A14 x---|4           21|---x                          
                      A13 x---|5           20|---x                          
                      A12 x---|6           19|---x !CSRAM                   
                      A11 x---|7           18|---x !CSROM                   
                      A10 x---|8           17|---x !CS6522                  
                       A9 x---|9           16|---x !CS6551                  
                       A8 x---|10          15|---x A4                       
                       A7 x---|11          14|---x A5                       
                      GND x---|12          13|---x A6                       
                              |______________|

[cbscpe]

BigDumbDinosaur wrote:

cbscpe wrote:

No that's not the case here. WinCUPL knows that the the term

Code: Select all

CS6551 = address:[8010..801F];

is equivalent to A0..3 being don't cares (part of it's internal optimiziation). Either way using don't cares or a range that makes some address bits not required works.

Actually, that is not something upon which you can rely. I know from playing around with it that it will not function that way when programming a CPLD. Bits that are not assigned to a pin should always be 'X'ed out to assure the compiler understands they are "don't cares."

I always use ranges this way and never had any issues with CPLDs. The only thing I had issues with is that the number base indicator can be very important. That is I always explicitly set the base for any constants

Code: Select all

CSRAM  = address:['h'0000..7FFF];

[Shawn Odekirk]

Is there anything special about pin 13 on the ATF22V10C that could cause my address decoding to not work as I expect?
I just checked and I was getting the following outputs:

0000 - 7FFF: RAM selected
8000 - 800F: 6522 selected
8010 - 801F: 6551 selected
8020 - 802F: ROM selected
8030 - 803F: ROM selected
8040 - 804F: 6522 selected
8050 - 805F: 6551 selected
8060 - FFFF: ROM selected

These results look like A6 is being ignored, and A6 is assigned to pin 13.
I tried shifting the pin assignments for A6 through /CSRAM up one pin so I was no longer using pin 13, and it works the way I want it to, so it seems like I might be using pin 13 incorrectly.

[Shawn Odekirk]

Martin A wrote:

I'd advised checking the compiler options, it won't build on the default settings. Set minimization to Quinn-McCluskey, and it will build to:

Thanks for the advice! I enabled Quine-McCluskey minimization and it built.

[Chromatix]

I don't think there's anything special about pin 13, except that it physically comes in from the opposite side of the device from most of the dedicated inputs. The one I'd expect to see trouble from is pin 4, which can be a power-down control.

[Shawn Odekirk]

BigDumbDinosaur wrote:

That said, your memory map is unwieldy. It appears you are trying to maximize the amount of ROM visible to the MPU, which isn't going to work the way it would seem.

I have a 32K RAM chip, a 32K ROM chip. My memory map tries to make as much of each of them available as possible.
The microprocessor trainer board I built in college used a PLA for address decoding, so using a GAL seems natural. While it may be overkill and a waste to decode all the way down to A4, I like that I have almost no wasted addresses. If I was really OCD the unused addresses from $8014 - $801F would really bother me. As it is, they only slightly annoy me.

BigDumbDinosaur wrote:

The chip select may be at $8020, but as you will soon discover, unless ROM falls on a even block boundary, i.e., $8000, $A000, $C000, etc., you won't be able to access all of it. For example, in my POC V1.2 unit, I have a 32KB ROM mapped in at $00D000-$00FFFF (this is an '816, but the principle is the same). The first 1KB of the ROM is not accessible because it falls in the range $00C000-$00CFFF, an address range in which I/O hardware appears. This is an artifact of the way in which the ROM's address lines have to wired into the system. So when I burn a ROM I have to start at $1000 in it so code appears at $00D000. The most ROM I can access is 12KB, which is plenty.

I don't understand. Except for the trouble I am having with A6 and pin 13 (which I wouldn't have found except for your comment, which prompted me to check, thank you!), I am able to access all of the ROM from $8020 through $FFFF. Maybe I am misunderstanding what you are saying.
A future revision may have a completely different memory map, but for now, with the chips that I currently have, I am happy with my memory map.
I really appreciate everyone who takes the time to comment. I have a lot of respect for everyone here, and your comments really help.

[BigEd]

Glad you got to a successful build! And we've collected some useful tips for future reference too.

I think BDD's point might be that with your map, the first $20 bytes of the ROM are not accessible, and so you will need to assemble accordingly, with the first byte of the program at $8020 and falling into byte $20 of the ROM. That should be no bother at all, and barely a cause for confusion.

[Shawn Odekirk]

Shawn Odekirk wrote:

Is there anything special about pin 13 on the ATF22V10C that could cause my address decoding to not work as I expect?

I have done some more testing on my pin 13 problem and have boiled everything 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;

This gives me the following results.

Code: Select all

INPUT  | OUTPUTS
-------|---------|-------------
INP_A  |  OUT_A  |  OUT_A_INV
-------|---------|-------------
   0   |    0    |      1
-------|---------|-------------
   1   |    1    |      1
-------------------------------

INPUT  | OUTPUTS
-------|---------|-------------
INP_B  |  OUT_B  |  OUT_B_INV
-------|---------|-------------
   0   |    0    |      1
-------|---------|-------------
   1   |    1    |      0
-------------------------------

INP_B on pin 14 works the way I would expect. INP_A on pin 13 does not. I've tried using other pins and they all seem to work as I would expect. Only pin 13 seems to work differently.
I have found one web page that mentions that if one or more outputs utilize an OE control, pin 13 is the normal OE pin. Could I be somehow using pin 13 as the output enable input?
I've tried this with different chips with the same result. I only have one programmer, a TL866II Plus, so I can't rule it out as being the cause of the problem, but I have had no reason to suspect it so far. It is probably just me misunderstanding WinCupl or the PLD.
Any thoughts or suggestions will be greatly appreciated.

[BigEd]

What an extraordinary finding! Thanks for boiling it down to such a simple test case.

Two thoughts
- are there different versions of WinCupl or other ways to create a programming file?
- is there any possibility your test fixture is interfering, and it's not the device under test that's misbehaving?

[Dr Jefyll]

BigEd wrote:

Two thoughts

And here's a third (prompted by the mention of "OE").

Could it be that some of the 1's or some of the 0's you're seeing on the output pins are actually a high-impedance state? If you haven't already, maybe you should try the test again but with pullup resistors attached. Then with pulldown resistors.

-- Jeff

ps: agree -- nice job of boiling it down to a simple test case!

[Martin A]

Does changing the device name from g22v10 (GAL mode) to p22v10 (PAL mode) make any difference ?