Page 1 of 2
WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Wed Apr 22, 2020 11:27 pm
by 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.
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
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 1:17 am
by BigDumbDinosaur
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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 6:00 am
by cbscpe
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
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
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
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 6:49 am
by BigDumbDinosaur
No that's not the case here. WinCUPL knows that the the term
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."
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 7:54 am
by 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
|______________|
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 11:29 am
by cbscpe
No that's not the case here. WinCUPL knows that the the term
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
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 11:37 pm
by 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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Thu Apr 23, 2020 11:47 pm
by Shawn Odekirk
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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Fri Apr 24, 2020 12:25 am
by 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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Fri Apr 24, 2020 1:25 am
by Shawn Odekirk
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.
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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Fri Apr 24, 2020 5:36 am
by 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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Fri Apr 24, 2020 10:46 pm
by 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 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.
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Sat Apr 25, 2020 6:04 am
by 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?
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Sat Apr 25, 2020 6:30 am
by Dr Jefyll
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 pull
down resistors.
-- Jeff
ps: agree -- nice job of boiling it down to a simple test case!
Re: WinCupl / 22V10 - Excessive Number of Product Terms
Posted: Sat Apr 25, 2020 8:22 am
by Martin A
Does changing the device name from g22v10 (GAL mode) to p22v10 (PAL mode) make any difference ?