PAL/GAL и все что с ними связано.

[OrionExt]

Угу. А это ничего, что все сигналы в матрицу заводятся как в прямом, так и в инверсном виде и закоммутировать можно любой из них?

Какой сигнал (прямой / инверсный) заведется в матрицу зависит от "прожигаемой" перемычки. Вы же не вручную собираетесь их прожигать

Я и спрашиваю, почему сделано так, а не иначе? Я, конечно, в любом месте выражения могу поставить инверсию. Вот доделаю тестер, чтобы не тумблерами щелкать, проверю, что вышло и подправлю так, как мне надо. Просто непонятно, почему этот ispLEVER Classic 1.8.00 сгенерил так, а не иначе?

Мне вот тоже не совсем нравится своеобразное поведение ispLEVER-а в привидении формул. Если вы не планируете по полной использовать весь потенциал языка Абель. Я бы порекомендовал WinCupl.

Проверять (симулировать) свои наработки можно Proteus-е.

[Advertiser]

[AFZ]

Какой сигнал (прямой / инверсный) заведется в матрицу зависит от "прожигаемой" перемычки. Вы же не вручную собираетесь их прожигать

Это был сарказм, если что.

Если вы не планируете по полной использовать весь потенциал языка Абель. Я бы порекомендовал WinCupl.

Весь потенциал языка Абель использовать поздно, он умер вместе с ГАЛками. Мне надо сочинить несколько прошивок для Галок и я выбрал Абель потому, что он показался мне более простым для освоения "с наскока", не особо вникая в подробности. И, в общем-то, я почти решил стоящую передо мной задачу - погоняю тесты, подправлю инверсии, где надо и все, можно забывать и Абель, и ГАЛки. Ну, не то, чтобы совсем забывать, но задвинуть в дальний угол...

А вопрос я задал потому, что, может быть, я, по незнанию, допустил какой-то грубый ляп, так более опытные товарищи поправят. Как было с регистровыми выходами: я про них, по-простому написал pin istype 'reg'; и удивился, почему мне ispLEVER вывали кучу предупреждений? Ладно, копнул чуть глубже, нашел, исправил на pin istype 'reg_D, buffer'; вот я и подумал, может я еще что-то забыл написать, объявить, подключить, и т.п.

Но, почему-то, оптимизатор заменил этот buffer на INVERT. И неясно, самоуправство это ispLEVER-а, или где-то там внутри ГАЛки присутствует еще какая-то инверсия, которую я недоглядел, и ispLEVER ее исправляет?

В общем, тест покажет.

Проверять (симулировать) свои наработки можно Proteus-е.

Тоже, конечно, вариант...

[OrionExt]

Весь потенциал языка Абель использовать поздно, он умер вместе с ГАЛками. Мне надо сочинить несколько прошивок для Галок и я выбрал Абель потому, что он показался мне более простым для освоения "с наскока", не особо вникая в подробности.

Вот по этому я и не вижу причины, на мой взгляд (после погружения в тему PAL) использовать такой софт как ispLEVER. И его мощный синтезатор и фитер для одной логической ячейки с двумя режимами работы и одной обратной связью.

Для чуть сложной задачи (хитрый счетчик или регистр) достаточно WinCupl с языком CUPL.

В данный момент остановился на двух бесплатных консольных утилитах с древнего пакета OPAL. Ничего лишнего. Попутно подсматривая в даташит на PAL. И моделируя свою простую писанину в Proteus-е (модель AM16V8 с загрузкой JEDEC файла). Мне пока хватает

- - - Добавлено - - -

Но, почему-то, оптимизатор заменил этот buffer на INVERT. И неясно, самоуправство это ispLEVER-а, или где-то там внутри ГАЛки присутствует еще какая-то инверсия, которую я недоглядел, и ispLEVER ее исправляет?

ispLEVER-у пофигу на вариации 'reg' или reg_D применительно к PAL. И видимо он прав, потому что существует всего одно решение.

buffer не применим к PAL, только invert (регистровый режим).

Достаточно написать pin Х istype 'reg' и не париться.

А так-то эта лишняя писанина в Абель только запутывает не окрепший ум юного PAL-кодера

[AFZ]

buffer не применим к PAL, только invert (регистровый режим).

Ясно.

Достаточно написать pin Х istype 'reg' и не париться.

Ни фига, ispLEVER вываливает кучу предупреждений.

Вот теперь понятно, надо писать pin Х istype 'reg, invert', учитывая реальный выход ГАЛки, а нужную полярность сигнала обеспечивать внутри, правильно расставляя инверсии входных и прочих сигналов.

У меня тут еще один вопрос есть, я еще с ним сам повоюю, а потом, если не выйдет, спрошу, ладно?

[OrionExt]

Вот теперь понятно, надо писать pin Х istype 'reg, invert', учитывая реальный выход ГАЛки, а нужную полярность сигнала обеспечивать внутри, правильно расставляя инверсии входных и прочих сигналов.

Поверьте на результат запись pin Х istype 'reg' или pin Х istype 'reg, invert' не как не повлияет, выход всегда будет инвертирован.

Не вы первый, не вы последний. Если программа начинает ругаться и вываливать кучу варнингов, значит, она пытается натянуть вашу функцию на логику PAL, приводя функцию к нужному виду. Вот и все. Если это возможно, результатом будет выходной файл JEDEC.

Как только вы выразите свои мысли в виде функции приемлемой для конкретной PAL, варнинги исчезнут.

Посмотрите как лаконично и стройно выглядит первая попавшая мне и вскрытая прошивка для PAL. По мне весь этот синтаксический "сахар" Абель даже вредит на первом этапе изучения. Начните с простого. Всмотритесь в структуру вашей конкретной PAL (она очень простая), потом поэтапно увеличивайте сложность вашей функции, описывая ее простым логическим языком не требуя больше того, на что способна эта достаточно простая логическая ячейка.

; JED2EQN -- JEDEC file to Boolean Equations disassembler (Version V063)
; Copyright (c) National Semiconductor Corporation 1990-1993
; Disassembled from tplus_u3.jed. Date: 2-4-119
;$GALMODE MEDIUM

chip tplus_u3 GAL16V8

nc1=1 i2=2 i3=3 i4=4 i5=5 i6=6 i7=7 i8=8 i9=9 GND=10 /i11=11 
o12=12 f13=13 f14=14 f15=15 o16=16 f17=17 o18=18 o19=19 VCC=20 

@ues 0000000000000000
@ptd unused

equations

/o19 = /i2 * /f17
o19.oe = vcc
/o18 = i2 * /f17
o18.oe = vcc
/f17 = /i6 * i7 * /f14 * i8
    + /i5 * i7 * /f14 * i8
f17.oe = vcc
o16 = i3 * i4 * /f15 * f13 * /i9 * /i11
    + i3 * /i4 * /f15 * f13 * /i9 * i11
    + /i3 * i4 * /f15 * /f13 * /i9 * /i11
    + /i3 * /i4 * /f15 * /f13 * /i9 * i11
o16.oe = vcc
f15 = gnd
f15.oe = gnd
f14 = gnd
f14.oe = gnd
f13 = gnd
f13.oe = gnd
o12 = gnd
o12.oe = gnd