GAL 16v8 - wincupl TABLE compile error

[Lathe_Biosas]

Hi

With a GAL 16v8 I would like to programm some kind of decoder (8
inputs, 7 outputs) with the following code:


TABLE input => output {
'b'00000000 => 'b'1010000;
..
..
..
'b'111111111=>'b'1010000;
}

the 7 output values are defined in [40 .. 80] and the inputs in [0 ..
255]


When compiling with wincupl I get the following error:
-excessive number of product tems: a1, a2, a3

a0-a6: are the outputs coded to pins 12-18 respective

Is there some type of limitation that using TABLE does not aloud 255
values to be coded?
Any hint how to solve the problem?

Best Regards

 

[Andrew Holme]

Hi

With a GAL 16v8 I would like to programm some kind of decoder (8
inputs, 7 outputs) with the following code:


TABLE input => output {
'b'00000000 => 'b'1010000;
.
.
.
'b'111111111=>'b'1010000;
}

the 7 output values are defined in [40 .. 80] and the inputs in [0 ..
255]


When compiling with wincupl I get the following error:
-excessive number of product tems: a1, a2, a3

a0-a6: are the outputs coded to pins 12-18 respective

Is there some type of limitation that using TABLE does not aloud 255
values to be coded?

Yes. A 16V8 is not 256x8 ROM. It can only recognise a limited number of
input pattterns (7 or 8 per output). You should study the datasheet.

What do your inputs and outputs signify? Can you post the full table? You
might be able to use the spare macrocell as an intermediate result, to make
the design fit.

 

[petrus bitbyter]

Hi

With a GAL 16v8 I would like to programm some kind of decoder (8
inputs, 7 outputs) with the following code:


TABLE input => output {
'b'00000000 => 'b'1010000;
.
.
.
'b'111111111=>'b'1010000;
}

the 7 output values are defined in [40 .. 80] and the inputs in [0 ..
255]


When compiling with wincupl I get the following error:
-excessive number of product tems: a1, a2, a3

a0-a6: are the outputs coded to pins 12-18 respective

Is there some type of limitation that using TABLE does not aloud 255
values to be coded?

Yes, a GAL16V8 has eight product terms/ouputpin and apparently your table
requires much more.

Any hint how to solve the problem?

Yes, an oldfashioned EPROM will fullfill your needs unless you require a
real high speed. I'm not up to date but I remember 50ns EPROMS. Made by AMD
if memory serves. Lower speeds were widely available at the time. Still have
a box of pulled 2764 in various tastes, brands and speeds.

Best Regards

petrus bitbyter