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

[AFZ]

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

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

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

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

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

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

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

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

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

[Advertiser]

[AFZ]

Потому что в случае некоторых микросхем используемый Вами stSEL.FB равен !stSEL.Q. Почему софт делает замену? Не знаю. Может как раз потому что .Q оно всегда однозначно. А вот .FB может быть как равно .Q, так и инверсно.

Поразглядывал ДШ. Страница 4, Registered Mode. Да, в матрицу заворачивается инверсный выход триггера, выходной драйвер подключен к прямому выходу, но он тоже инвертирующий. То есть, получается, за основное состояние они (создатели ispLEVER) посчитали истинное состояние триггера, тогда все сходится. Хотя я в исходнике прилепил свое символическое наменование на PIN, а не на триггер... Ладно, тест покажет.

[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

[AFZ]

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

Не только. Если указать pin X istype 'reg'; то ispLEVER предупреждает, что я не указал ни buffer, ни invert и поэтому он применил buffer. И так по каждой регистровой ноге.

По мне весь этот синтаксический "сахар" Абель даже вредит на первом этапе изучения.

Да нет, я, вроде-бы, уже въехал в Абель. Просто не совсем ясно с теми самыми инверсиями, но, вроде-бы, просвет уже виден.

Код:

А это на CUPL'е, да?

[OrionExt]

А это на CUPL'е, да?

Нет, это скармливается EQN2JED.EXE из пакета OPAL. Но переделать этот код под ABEL, CUPL и т.д. не займет много времени.

[AFZ]

в Proteus-е (модель AM16V8 с загрузкой JEDEC файла)

Поиграл в Протеусе, по поведению прошитой 16V8 обнаружил пару ошибок в логике, исправил, вроде все сходится. Получается, что зря Абель в отчете (.rpt) рисует все выходы инверсными, на самом деле они такие, как я написал в своем коде.

Да, Протеус показал, что вход OE прямой, т.е. выходы открываются при высоком уровне на нем. Хотя в ДШ Галки он нарисован инверсным. Это особенность AM16V8, или глюк Протеуса? Или у Галки ОЕ тоже высокий? И воообще, раз моя прошивка правильно ведет себя в модели AM16V8, могу я быть уверенным, что моя реальная ГАЛка будет вести себя точно так же?

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

И еще одна непонятка. На схеме макроячейки (стр 4 ДШ, Combinatorial Configuration for Registered Mode) нарисован буфер с тремя состояниями, точно такой же, как и в Registered Configuration (выше). Однако, модельная 16V8 при низком уровне на OE отключает только регистровые выходы, а комбинационные оставляет включенными. Опять же, что это такое? Фича AM16V8 или глюк Протеуса?

[OrionExt]

Поиграл в Протеусе, по поведению прошитой 16V8 обнаружил пару ошибок в логике, исправил, вроде все сходится. Получается, что зря Абель в отчете (.rpt) рисует все выходы инверсными, на самом деле они такие, как я написал в своем коде.

Тут не совсем согласен. Это тонкая игра ножек, сигналов, т.д. к которой надо привыкнуть, принять и понять. Все там правильно.

Да, Протеус показал, что вход OE прямой, т.е. выходы открываются при высоком уровне на нем. Хотя в ДШ Галки он нарисован инверсным. Это особенность AM16V8, или глюк Протеуса? Или у Галки ОЕ тоже высокий? И воообще, раз моя прошивка правильно ведет себя в модели AM16V8, могу я быть уверенным, что моя реальная ГАЛка будет вести себя точно так же?

Та же фигня. Похоже, это фирменный глюк (фича) модели, которую никто исправлять не собирается. Далеко не первая в моделях и не последняя у Proteus-а. Реальная ножка с активным низким уровнем.

И еще одна непонятка. На схеме макроячейки (стр 4 ДШ, Combinatorial Configuration for Registered Mode) нарисован буфер с тремя состояниями, точно такой же, как и в Registered Configuration (выше). Однако, модельная 16V8 при низком уровне на OE отключает только регистровые выходы, а комбинационные оставляет включенными. Опять же, что это такое? Фича AM16V8 или глюк Протеуса?

При включении регистрового режима физ. ножка /OE намертво прибивается к управлению выходом регистра. Для комбинаторного режима OЕ сигналом можно рулить от других входов (или выходов) или даже своей логикой. Или не рулить вообще. Вроде так.

Еще обратите внимание, что на некоторых логических ячейках (всего их 8) не все входные (выходные) ножки (сигналы) доступны в разных сочетаниях режимов работы. Как-то хитро завернул, подробнее в даташите

[AFZ]

Сочиняю бластер. ATFblast не поддерживает GAL6001, а хотелось бы поиграть и с ними. GALblast не поддерживает АТФ-ки, а их тоже хотелось бы.

Так, у GAL- и у ATF-бластеров все совпадает, кроме рулёжки напряжением EDIT - программа ATF-бластера рулит переключением "Чтение/прошивка" сигналом AutoLF с порта LPT, а программа GALblast этим сигналом записывает код напряжения в DAC, что делать совершенно не хочется - меня вполне устраивает 13.5В, при котором нормально шьются мои ГАЛки (проверено на TL866, наоборот, при 16В, которые этот 866-й предложил, появляются ошибки записи), если же кому-то понадобится другое напряжение - подкручу.

Так вот, вопрос: чем рулить переключением "Чтение-прошивка" из программы GALblast?