| 6502.org http://forum.6502.org/ |
|
| WinCupl / 22V10 - Excessive Number of Product Terms http://forum.6502.org/viewtopic.php?f=10&t=6095 |
Page 1 of 2 |
| Author: | Shawn Odekirk [ Wed Apr 22, 2020 11:27 pm ] |
| Post subject: | WinCupl / 22V10 - Excessive Number of Product Terms |
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: 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: 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 |
|
| Author: | BigDumbDinosaur [ Thu Apr 23, 2020 1:17 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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: 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. |
|
| Author: | cbscpe [ Thu Apr 23, 2020 6:00 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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: 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: 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 |
|
| Author: | BigDumbDinosaur [ Thu Apr 23, 2020 6:49 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
cbscpe wrote: No that's not the case here. WinCUPL knows that the the term Code: 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." |
|
| Author: | Martin A [ Thu Apr 23, 2020 7:54 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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: *******************************************************************************
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 |______________| |
|
| Author: | cbscpe [ Thu Apr 23, 2020 11:29 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
BigDumbDinosaur wrote: cbscpe wrote: No that's not the case here. WinCUPL knows that the the term Code: 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: CSRAM = address:['h'0000..7FFF];
|
|
| Author: | Shawn Odekirk [ Thu Apr 23, 2020 11:37 pm ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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. |
|
| Author: | Shawn Odekirk [ Thu Apr 23, 2020 11:47 pm ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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. |
|
| Author: | Chromatix [ Fri Apr 24, 2020 12:25 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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. |
|
| Author: | Shawn Odekirk [ Fri Apr 24, 2020 1:25 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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. |
|
| Author: | BigEd [ Fri Apr 24, 2020 5:36 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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. |
|
| Author: | Shawn Odekirk [ Fri Apr 24, 2020 10:46 pm ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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: 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: 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. |
|
| Author: | BigEd [ Sat Apr 25, 2020 6:04 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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? |
|
| Author: | Dr Jefyll [ Sat Apr 25, 2020 6:30 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
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! |
|
| Author: | Martin A [ Sat Apr 25, 2020 8:22 am ] |
| Post subject: | Re: WinCupl / 22V10 - Excessive Number of Product Terms |
Does changing the device name from g22v10 (GAL mode) to p22v10 (PAL mode) make any difference ? |
|
| Page 1 of 2 | All times are UTC |
| Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |
|