6502.org Forum Projects Code Documents Tools Forum
It is currently Sun Nov 24, 2024 8:14 pm

View unanswered posts | View active topics


Board index » 6502.org Users Forum » Programmable Logic

All times are UTC




Post new topic Reply to topic  Page 1 of 2
  [ 19 posts ]  Go to page 1, 2  Next
  Print view Previous topic | Next topic 
Author Message
Shawn Odekirk
PostPosted: Wed Apr 22, 2020 11:27 pm 
Offline
User avatar

Joined: Mon Mar 23, 2020 4:02 pm
Posts: 52
Location: Parker, CO
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
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Apr 23, 2020 1:17 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
cbscpe
PostPosted: Thu Apr 23, 2020 6:00 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
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
Top
 Profile  
Reply with quote  
BigDumbDinosaur
PostPosted: Thu Apr 23, 2020 6:49 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
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."

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!
Top
 Profile  
Reply with quote  
Martin A
PostPosted: Thu Apr 23, 2020 7:54 am 
Offline

Joined: Sat Jan 02, 2016 10:22 am
Posts: 197
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                       
                              |______________|
Top
 Profile  
Reply with quote  
cbscpe
PostPosted: Thu Apr 23, 2020 11:29 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
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];
Top
 Profile  
Reply with quote  
Shawn Odekirk
PostPosted: Thu Apr 23, 2020 11:37 pm 
Offline
User avatar

Joined: Mon Mar 23, 2020 4:02 pm
Posts: 52
Location: Parker, CO
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.
Top
 Profile  
Reply with quote  
Shawn Odekirk
PostPosted: Thu Apr 23, 2020 11:47 pm 
Offline
User avatar

Joined: Mon Mar 23, 2020 4:02 pm
Posts: 52
Location: Parker, CO
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.
Top
 Profile  
Reply with quote  
Chromatix
PostPosted: Fri Apr 24, 2020 12:25 am 
Offline

Joined: Mon May 21, 2018 8:09 pm
Posts: 1462
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.
Top
 Profile  
Reply with quote  
Shawn Odekirk
PostPosted: Fri Apr 24, 2020 1:25 am 
Offline
User avatar

Joined: Mon Mar 23, 2020 4:02 pm
Posts: 52
Location: Parker, CO
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.
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Fri Apr 24, 2020 5:36 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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.
Top
 Profile  
Reply with quote  
Shawn Odekirk
PostPosted: Fri Apr 24, 2020 10:46 pm 
Offline
User avatar

Joined: Mon Mar 23, 2020 4:02 pm
Posts: 52
Location: Parker, CO
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.
Top
 Profile  
Reply with quote  
BigEd
PostPosted: Sat Apr 25, 2020 6:04 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
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?
Top
 Profile  
Reply with quote  
Dr Jefyll
PostPosted: Sat Apr 25, 2020 6:30 am 
Offline
User avatar

Joined: Fri Dec 11, 2009 3:50 pm
Posts: 3367
Location: Ontario, Canada
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!

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html
Top
 Profile  
Reply with quote  
Martin A
PostPosted: Sat Apr 25, 2020 8:22 am 
Offline

Joined: Sat Jan 02, 2016 10:22 am
Posts: 197
Does changing the device name from g22v10 (GAL mode) to p22v10 (PAL mode) make any difference ?
Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  Page 1 of 2
  [ 19 posts ]  Go to page 1, 2  Next

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC


Who is online

Users browsing this forum: No registered users and 8 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
6502.org is an ongoing project by Mike Naberezny and contributors.