6502.org • View topic - WinCUPL out of product terms with Address Decoder GAL

View unanswered posts | View active topics

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

WinCUPL out of product terms with Address Decoder GAL

Page 1 of 3

[ 41 posts ]

Go to page 1, 2, 3 Next

Print view

Previous topic | Next topic

Author

Message

banedon

Post subject: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 5:45 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

Has anyone got any ideas to get around the 'Excessive number of product terms' error that WinCUPL gives me for the following.
It refers to 'S3' which is pin 18 - RAM_SEL (ram select).

I've tried to get around it but I think the TABLE is not going to allow it and I have a horrible feeling that I just cannot get what I'm after result-wise.
What I have is:
0000-7FFF enables RAM
8100-81FF enables VIA#1
8200-82FF enables VIA#2
8300-83FF enables VIA#3
8400-84FF enables VIA#4
8500-85FF enables ACIA

All standard stuff. The next bit is the issue. I have a line coming in (romEN - pin 14) which, if enabled/low, will mean that the ROM is used between 8600-FFFF.
If disabled/high then access to 8600-FFFF goes to the RAM.
All works fine until I add a final line which is designed to enable the RAM instead of the ROM if cpuRW (pin 2 - 6502's R/W line) is low (write mode).
If I add that line I then get the product term errors. I moved the RAM select to pin 18 which has the most product terms for a Lattice 22V10B (16 terms). Makes no difference.
The line design to allow writing to RAM when 8600-FFF is access with cpuRW low is :

Code:

   [86..FF] => 'b'0001000 & !cpuRW;        /* ROM WRITE --- but write to RAM instead */

The main code:

Code:

Pin 1 = phi2;
Pin 2 = cpuRW;
Pin [3..10] = [A7..0];
Pin 14 = romEN;

/*
 * Outputs
 */

Pin [15..21] = ![S0..6];

Pin 22 = !aWR;
Pin 23 = aRD;

aRD = !cpuRW;
aWR = !cpuRW & phi2;

/*
 * Main
 */

FIELD AddressBus = [A7..0];
FIELD Selects = [S6..0];

TABLE AddressBus => Selects {
   [00..7F] => 'b'0001000;   /* RAM   */
   [81..81] => 'b'0100000;   /* VIA#1 */
   [82..82] => 'b'0000100;   /* VIA#2 */
   [83..83] => 'b'0000010;   /* VIA#3 */
   [84..84] => 'b'0000001;   /* VIA#4 */
   [85..85] => 'b'0010000;   /* ACIA  */
   [86..FF] => 'b'0001000 & !cpuRW;        /* ROM WRITE --- but write to RAM instead */
   [86..FF] => 'b'1000000 & cpuRW & !romEN; /* ROM READ ---- fine. */
   [86..FF] => 'b'0001000 & romEN;       /* ROM READ, but ROM enable is disabled ---- READ from RAM instead */
}

Top

BigEd

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 6:02 pm

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10802
Location: England

Just a guess, but 86..FF is quite a range which needs to check a lot of bits. Is it any better if it's say 90..FF? Or even, for experimentation purposes, C0..FF?

Top

cbscpe

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 7:28 pm

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 485
Location: Switzerland

hi banedon,

make sure that you have selected to create the equations in the doc file (Options->Compiler) in WinCUPL and then have a look at the .doc file. Here you see what equations your table is translated to. And as BigEd says 'h'86..'h'FF translates in many product terms (one for 86..87, 88..8F, 90..9F, A0..BF, C0..FF). Although not too many for the middle 2 outputs of a GAL22V10. Did you tell WinCupl it is a G22V10? Can you post the complete design file (incl. header) as well, then I could give it a try. Also when dealing with addresses it is easier to have the correct suffixes

Code:

Pin [3..10] = [A15..8];

FIELD AddressBus = [A15..0];

TABLE AddressBus => Selects {
   [0000..7FFF] => 'b'0001000;   /* RAM   */
   [81XX] => 'b'0100000;   /* VIA#1 */
   [82XX] => 'b'0000100;   /* VIA#2 */
   [83XX] => 'b'0000010;   /* VIA#3 */

If the equations do not really make use of A0..A7 then WinCupl does not care that there is no inputs for A0..A7. This makes your design files much easier to read and understand.

Peter

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 7:41 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

Thanks for the advice guys - should have thought about the number of bits. Doh.

I've changed the start the ROM range back to $9000 and (for the moment) allowed 8700-8FFF to be used for RAM.

Here's the entire code:

Code:

Name       AddressDecoder1;
Partno     Lattice22V10B;
Date       11/07/15;
Revision   01;
Designer   shalewyn.com;
Company    shalewyn.com;
Assembly   1;
Location   1;
Device     g22v10;

/*
 * Lattice GAL 22V10B pinout, DIP, top view
 *
 * I/CLK.[ 1     24 ].VCC
 *     I.[ 2     23 ].I/O/Q
 *     I.[ 3     22 ].I/O/Q
 *     I.[ 4     21 ].I/O/Q
 *     I.[ 5     20 ].I/O/Q
 *     I.[ 6     19 ].I/O/Q
 *     I [ 7     18 ].I/O/Q
 *     I [ 8     17 ].I/O/Q
 *     I [ 9     16 ].I/O/Q
 *     I [ 10    15 ].I/O/Q
 *     I [ 11    14 ].I/O/Q
 *   GND.[ 12    13 ].I
 *
 */


/*
 * Inputs
 */

Pin 1 = phi2;
Pin 2 = cpuRW;
Pin [3..10] = [A15..8];
Pin 14 = romEN;

/*
 * Outputs
 */

Pin [15..21] = ![S0..6];

Pin 22 = !aWR;
Pin 23 = aRD;

aRD = !cpuRW;
aWR = !cpuRW & phi2;

/*
 * Main
 */

FIELD AddressBus = [A15..0];
FIELD Selects = [S6..0];

TABLE AddressBus => Selects {
   [00xx..7Fxx] => 'b'0001000;   /* RAM   */
   [81xx..81xx] => 'b'0100000;   /* VIA#1 */
   [82xx..82xx] => 'b'0000100;   /* VIA#2 */
   [83xx..83xx] => 'b'0000010;   /* VIA#3 */
   [84xx..84xx] => 'b'0000001;   /* VIA#4 */
   [85xx..85xx] => 'b'0010000;   /* ACIA  */
   [86xx..8Fxx] => 'b'0001000;   /* RAM   */
   [90xx..FFxx] => 'b'0001000 & !cpuRW;           /* ROM WRITE --- but write to RAM instead */
   [90xx..FFxx] => 'b'1000000 & cpuRW & !romEN; /* ROM READ ---- fine. */
   [90xx..FFxx] => 'b'0001000 & romEN;         /* ROM READ, but ROM enable is disabled ---- READ from RAM instead */
}

Peter, I've taken your suggestion on-board and implemented it, although for me it makes no difference. However, I do see what you mean with regard to readability for others.

One of these days I'll move on to CPLDs so things are no so restricted - when I have the money, of course

Top

BigDumbDinosaur

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 7:47 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8190
Location: Midwestern USA

banedon wrote:

Thanks for the advice guys - should have thought about the number of bits. Doh.

I've changed the start the ROM range back to $9000 and (for the moment) allowed 8700-8FFF to be used for RAM.

How big is this ROM? Also, why place the I/O hardware smack in the middle of the map? Just curious.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 9:01 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

BigDumbDinosaur wrote:

banedon wrote:

Thanks for the advice guys - should have thought about the number of bits. Doh.

I've changed the start the ROM range back to $9000 and (for the moment) allowed 8700-8FFF to be used for RAM.

How big is this ROM? Also, why place the I/O hardware smack in the middle of the map? Just curious.

Hi BigD

I probably won't leave the I/O where it is. Originally the memory map was: RAM, small air gap to protect against RAM write over runs into I/O area, I/O area, ROM.
I'll probably end up moving that small (new) section of RAM down and the I/O up, but may use it for other I/O - not sure. So far the design has 1x ACIA, 4x VIAs. Not sure it needs much more to be fair though

.

ROM size wise; I've left plenty of space for work. I may end up shrinking it as needed, although in a way this might not matter as the boot code will do the following (hopefully!):

RESET vector
Usual flag initialisation
Copy OS from ROM to RAM by simply reading the ROM and writing it back to the same place.
Use one of the VIAs or a latch to change romEN line to high (disabled) so that ROM is switched off and RAM is enabled.

The design incorporates the CPU (RDY) circuit found elsewhere on these forums for accessing the ROM so that higher speeds can be used - especially when the ROM has been disabled and the RAM can go full speed.

Top

GARTHWILSON

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Sun Apr 10, 2016 9:41 pm

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8440
Location: Southern California

I don't speak WinCupl (meaning I don't totally understand everything above), but I will comment that since the VIA and ACIA have two select inputs each, your PLD only needs one I/O-select output to cover all the I/O devices. Then connect the remaining select input of each I/O IC to one of the address lines. For example:

Code:

hex range   binary                purpose
8000-FFFF   1xxx xxxx xxxx xxxx   ROM  (No logic necessary for this, except to invert A15.)
7E10-7EFF   0111 111x xxxx xxxx   I/O block, going to CS2\ of each I/O IC
7E10-7E1F   0111 1110 0001 xxxx   I/O IC #1, going to its CS1
7E20-7E2F   0111 1110 0010 xxxx   I/O IC #2, going to its CS1
7E40-7E4F   0111 1110 0100 xxxx   I/O IC #3, going to its CS1
7E80-7E8F   0111 1110 1000 xxxx   I/O IC #4, going to its CS1
7F00-7F0F   0111 1111 0000 xxxx   I/O IC #5, going to its CS1
(remainder)                       RAM

You'll get repeated ranges, but it's ok. I've been using this kind of thing for 23 years with no problem. There may be the slight advantage that if you want to set up two I/O ICs identically, or start timers simultaneously, you can write to more than one IC at a time. I've never done it accidentally though. The address-decoding chapter of the 6502 primer covers this.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Mon Apr 11, 2016 8:57 am

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

I had considered this and it's something that I may well do as it does free up 4 address decoder pins out of 5. However, it would mean that I would not have complete freedom to put the I/O where I want at the post design/fab stage as the GAL would not entirely determine the map. However, this would be a small issue really and gaining those pins might save me an IC... Food for thought

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Mon Apr 11, 2016 9:02 am

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

[quote="cbscpe"]make sure that you have selected to create the equations in the doc file (Options->Compiler) in WinCUPL...[code]

Thanks for this tip, Peter. I didn't know about it and it's quite interesting seeing the product terms.

Top

cbscpe

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Mon Apr 11, 2016 7:47 pm

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 485
Location: Switzerland

Actually all your GAL designs you posted in this thread compile without any error, I'm asking what did you do that your first solution returned 'Excessive number of product terms'

banedon wrote:

One of these days I'll move on to CPLDs so things are no so restricted - when I have the money, of course

Entering the world of CPLDs was actually one of the cheapest addition to my hobby. All you need is a ATDH1150USB-K. The official price is 60USD and it let's you program all Atmel CPDLs via ISP. The key here is ISP, so you only have 32 Pins on a ATF1504AS-10AU44 (TQFP-44) or -10JU44 (PLCC-44) and must not use the ISP pins as IO. But I managed to squeeze almost the complete GLUE logic of a Apple IIE in a ATF1504AS. I can only recommend using CPLDs. Nice thing about ISP is it is in circuit, you just need to add a ISP header to your board.

I also recommend you to take the advice of Garth. You could also mix his advice with your design, e.g. you could have two /CS created by your GAL for two 256 byte IO 'pages'. Then you can have 8 65xx peripherals grouped into two ranges of 256bytes and each 'page' can be allocated at a different address.

Another thing you can do with FIELDS is the following

Code:

VIA1   =  ADDRESS:[81XX]; /* VIA#1 or using Garth's advice this is VIA#1 at $811X, VIA#2 at $812X, VIA#3 at $814X, VIA#4 at $818X*/

or

VIA1   =  ADDRESS:[8100..81FF]; /* VIA#1 or using Garth's advice this is VIA#1 at $811X, VIA#2 at $812X, VIA#3 at $814X, VIA#4 at $818X*/

I use it more often than tables.

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Mon Apr 11, 2016 8:29 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

That code was the post-fix version. Here's the pre-fix one.
Checking the .doc file, it shows 25 product terms listed for S3 (RAM select) lol.

Code:

Name       AddressDecoder1;
Partno     Lattice22V10B;
Date       11/07/15;
Revision   01;
Designer   shalewyn.com;
Company    shalewyn.com;
Assembly   1;
Location   1;
Device     g22v10;

/*
 * Lattice GAL 22V10B pinout, DIP, top view
 *
 * I/CLK.[ 1     24 ].VCC
 *     I.[ 2     23 ].I/O/Q
 *     I.[ 3     22 ].I/O/Q
 *     I.[ 4     21 ].I/O/Q
 *     I.[ 5     20 ].I/O/Q
 *     I.[ 6     19 ].I/O/Q
 *     I [ 7     18 ].I/O/Q
 *     I [ 8     17 ].I/O/Q
 *     I [ 9     16 ].I/O/Q
 *     I [ 10    15 ].I/O/Q
 *     I [ 11    14 ].I/O/Q
 *   GND.[ 12    13 ].I
 *
 */


/*
 * Inputs
 */

Pin 1 = phi2;
Pin 2 = cpuRW;
Pin [3..10] = [A7..0];
Pin 14 = romEN;

/*
 * Outputs
 */

Pin [15..21] = ![S0..6];

Pin 22 = !aWR;
Pin 23 = aRD;

aRD = !cpuRW;
aWR = !cpuRW & phi2;

/*
 * Main
 */

FIELD AddressBus = [A7..0];
FIELD Selects = [S6..0];

TABLE AddressBus => Selects {
   [00..7F] => 'b'0001000;   /* RAM   */
   [81..81] => 'b'0100000;   /* VIA#1 */
   [82..82] => 'b'0000100;   /* VIA#2 */
   [83..83] => 'b'0000010;   /* VIA#3 */
   [84..84] => 'b'0000001;   /* VIA#4 */
   [85..85] => 'b'0010000;   /* ACIA  */
   [86..FF] => 'b'0001000 & !cpuRW;           /* ROM WRITE --- but write to RAM instead */
   [86..FF] => 'b'1000000 & cpuRW & !romEN; /* ROM READ ---- fine. */
   [86..FF] => 'b'0001000 & romEN;         /* ROM READ, but ROM enable is disabled ---- READ from RAM instead */
}

Top

BigDumbDinosaur

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Mon Apr 11, 2016 9:19 pm

Joined: Thu May 28, 2009 9:46 pm
Posts: 8190
Location: Midwestern USA

banedon wrote:

One of these days I'll move on to CPLDs so things are no so restricted - when I have the money, of course

I have a standing offer to program Atmel CPLDs for those who don't have programming hardware. You can jam a lot of logic into an ATF1504AS and you have 32 uncommitted I/O pins to play with.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Tue Apr 12, 2016 9:50 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

BigDumbDinosaur wrote:

banedon wrote:

One of these days I'll move on to CPLDs so things are no so restricted - when I have the money, of course

I have a standing offer to program Atmel CPLDs for those who don't have programming hardware. You can jam a lot of logic into an ATF1504AS and you have 32 uncommitted I/O pins to play with.

I haven't forgotten and the offer is definitely appreciated

. However, I'd really like to get my hands on a programmer and give programming CPLDs a go any way even if I wasn't planning to use them in my 6502GPDv2 project. Give it another month and I should have enough money to make a purchase. I can then rip out what remains of my hair trying to get it to work

Top

banedon

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Wed Apr 13, 2016 10:11 pm

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England

Ok. I've ordered the USB programmer from Kanda.com and 4x ATF1504AS-10JU44 from Mouser. Just got to wait for them to turn up. I'm really looking forward to being able to use all the extra I/O pins and product terms

.
Which software do you guys (who use these CPLDs) use? I think BigD uses WinCUPL (correct me if I'm wrong), but what do you use, Peter?

Top

BigDumbDinosaur

Post subject: Re: WinCUPL out of product terms with Address Decoder GAL

Posted: Thu Apr 14, 2016 2:56 am

Joined: Thu May 28, 2009 9:46 pm
Posts: 8190
Location: Midwestern USA

banedon wrote:

.
Which software do you guys (who use these CPLDs) use? I think BigD uses WinCUPL (correct me if I'm wrong), but what do you use, Peter?

WinCUPL is the "official" development software and is free for the downloading from Atmel's site. In theory, any logic development software that can generate a proper JEDEC fuse map will work. However, Atmel's CPLDs have some useful proprietary features (e.g., logic doubling) that only their software would know about. No reason to not use it.

_________________
x86? We ain't got no x86. We don't NEED no stinking x86!

Top

Page 1 of 3

[ 41 posts ]

Go to page 1, 2, 3 Next

Board index » 6502.org Users Forum » Programmable Logic

All times are UTC

Who is online

Users browsing this forum: No registered users and 2 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