Така е, вижда се отдалеко. Затова ни и харесва тук, банда лунатици намерили клуба си

@tgi, то такова нещо като от веднъж да стане няма, все ще има учене, но като гледам няма да ти е проблем за часове да напишеш прости програмки - да речем за 7 сегметна динамична индикация със зареждане на стойности по паралелна шина с адресиране на клетките ти трябват 6-7 часа учене на езика и 3-4 часа псуване на синтезатора. примера който ти казвам плаши повечето хора, но какво ли се чудя - тях и един брояч + дешифратор ги стряска (пише се по-малко от 2 часа за четене + писане) . така че за седмица ще можеш да си вършиш сравнително лесни задачи. виж, за по сложните вече си иска писане и опити, но ако се заемеш не вярвам да ти се опре а и винаги е полезно да можеш да си свършиш някоя дреболия в проект сам - като в CPLD, т.е. няма да ти навреди да научиш вхдл или верилог (виждам че си любител на друг стил работа, но miro_atc е прав - истината е в HDL - езиците).

колкото до руутването на ръка след синтезиса - да, изглежда с webpack на xilinx ISE може да се направи - поне за FPGA има "FPGA Editor" , обаче пак ти казвам - това го могат единици хора. познавам пишещи на верилог, които за толкова много години и доста сериозни проекти не са си позволили да правят такива неща, то не е човешко. макар че блазни да се опита за спорта колкото до това дали има същият едитор за сплд-та не съм пробвал, ще опитам и ще ти кажа резултата

ако имаш желание да го учиш - до колкото можем - ще помагаме, заслужава си знанието

Извинявай за закъснението с отговора - успях да избягам в гората за ден та погледнах, но едитор на ниско ниво за CPLD не виждам, т.е. няма го онова нещо както за FPGA Editor. може би има някакъв тул, който да не ми е известен, а може и да смятат че средата им е достатъчно добра и за CPLD-та няма нужда от оптимизация ръчно.

Благодаря за проверката, head_up . Липсата на ниско ниво прави избора в случая лесен,
явно verilog/vhdl са пуснати за cpld-та колкото да ги има, затова поддържат още и
абел, той ще свърши работата тоя път.

Абе абел да .. ама vhdl / verilog няма ли да ти спестят не малко главоблъсканица. От друга страна продуктите които правиш, поне за които знам не струват 5-10 лв, там дали ще сложиш 64 или 128 клетки силикон едва ли ще промени стойността значително, та се чудя това оптимизиране до дупка за спорта ли го правиш, или просто си е навик на работа.

Пестя време най-вече. Ква главоблъсканица с едно CPLD, някой-друг брояч, шифт регистър
и т.н. Неща от размера на това, дето го постнах като пример, ми отнемат някой-друг час до първата
версия, след това в комбинация със софтуера може да има промени и след месеци, разбира се.
Аз съм израсъл с логики, колко по-сложни неща от 128 клетково cpld съм правил с TTL-и... .

Пестиш глупости...
Ако искаш да се правиш на интересен, програмирай директно фюзовете! Но не се надявай че като работиш с ABEL ще работиш на по-ниско ниво или че ще постигнеш по-добри резултати....

Имам над 4 години опит с ABEL, при това професионален опит в чужбина. Тогава нямахме избор, щото hdl-те не бяха достъпни, но сега да бачкаш на ABEL е висша форма на мазохизъм...

@tgi, ти си динозавър в добрия смисъл на думата. радваш ме как дълбаеш в нещата с някакви оптимизации на ум, не са останали много като теб, сега им дай ако може есе да напишат пък синтезатора да си направи своето!!! обаче не ми изглежда ефективно да шляпаш цплд-та по този старомоден начин (абел) при все, че има такива прекрасни езици (верилог/вхдл) и толкова евтина логика пробвай някой от тях, няма да ти е във вреда, пак казвам.

А, не е така. Webpack първо транслира абела към vhdl и след това работи с него. Та не очаквай по-голяма свобода, няма как да стане. След оптимизацията крайният резултат има малко общо с каквото си пожелал на абел.

А леле мале. А бе знаех си аз (от 20 години насам), че нищо свястно не мога да
очаквам от xilinx. Ще ми създадат проблем явно. Демек няма начин да предскажа от
сорса кой бушон ще бъде програмиран? Оптимизацията им не може да се изключи?

Преди 20-ина години след едноседмични борби с един (нямащ общо с xilinx) "cupl"
като го хванах, че греши (най брутално, игнорираше едни поляритети) логиката написах
първия си логически компилатор. Сега я нямам тая опция (имах я с филипс и го направих
на времето, за жалост тия превзеха coolrunner-а и го покриха) и нямам време за
reverse engineering, не и в рамките на тоя проект.
Ще падне още чудене - още не съм сглобил платката, пипна ме някаква хрема и трети
ден не ставам за нищо.

Директно не можеш. Обаче като кажеш, че искаш еди кой си изход да е бавен 2.5V CMOS с пулъп на еди кой си пин - то ще ги програмира както си му казал. На практика не съм видял възможност на чипа дето е описана в спесификацията да не може да се поиска през абела или в user constraints файла. Ама да задаваш състояние на всеки бушон поотделно - това само с текстов редактор в JED файла. Сега гледам, че 256-цата има над 100 000 фюзи, това на ръка как се прави?



Те оптимизациите са две. Една при компилирането докато ти сдъвче логиката, втора при имплементирането в конкретния чип. Не могат да се изключват, можеш донякъде да ги контролираш. Отделно, в сорса можеш да укажеш за които искаш сигнали да не ги пипа при оптимизирането. Не съм проверявал дали го спазва.
А за бъговете - Webpack-а два пъти съм го хващал в крачка, и двата пъти си намерих заобиколен път преди да го фикснат в следваща версия. Та не му се шашкай предварително.
Иначе според мен се държи прилично, не разхищава ресурси от чипа.

Не ща да програмирам 100к бушони на ръка - обаче ще ми трябва (след тоя проект)
вариант да видя кой бушон какво прави. Не е толкова голяма задача, (имам доста голяма
част от данните), но някои работи трябва да ги видя, за да мога да подкарам в моя
компилатор и тия coolrunner-и.
Та главно затова ми трябва да мога да изключвам оптимизациите - и с тия ограничения
вероятно ще стане. С phdl-а беше лесно, той правеше 1:1 каквото му каже човек....

Ами и аз съм свикнал с ТТЛ да работя, не съм правил много неща на логика, но преди време имах едно не много сложно изделийце, повече от половината го надрасках като схема директно, със сигурност стана по бързо от колкот щях да го напиша. Но остана и една част която пък на Verilog стана доста по ясна и разбираема.

Да постна и края на историята (май често забравяме за тая част а пък не е голяма работа).

След еднодневни мъки с webpack 11 и разните им редактори на схеми и глупости се бях
бая притеснил, че имам проблем. Нищо не работеше по очевидния начин, така и не разбрах
как да му нацъкам с мишката на тъпата схема кой сигнал на кой крак да отиде.

И добре, че не успях.

Като видях какъв бозьоч е цялата им работа взех да се оглеждам и намерих на *диска си*
един webpack 6.3, който преди около година бях получил от един съфорумец и забравил.

Е тоя си работеше с Abel, който се оказа почти същото като PHDL-а, и за по-малко от ден
свърших работата (проста, но не чак толкова - към 400 реда abel, където аз не ползвам
други оператори освен тия налични в хардуера, т.е. and, or, not, и разните опции за
макроклетките).
Веднъж стигнало до jedec го поех в DPS-a и оттам програмирането на чипа (ползвайки
данни, дето ги имам под NDA от Xilinx) работата стана с лекота.
В крайна сметка загубих не много време, половината от което докато открия, че
новите им webpack-ове просто не работят за CPLD-тата (поне не с abel, който е
най-близко до самото CPLD като идея).

Хубаво щеше да е ако такива истории нямаха продължение ама обикновено имат.

Та потрябва по-голяма част от въпросния чип (следваща версия на продукта) и я добавих - още 20-ина клетки.

И не му стигнаха.

Бе взех да гледам и да броя, поне 1/3 трябва да е свободна. Разрових се по-надълбоко и
кво да видя - ами вместо по една клетка на сигнал слага по две, и това на 48 сигнала поне.
Е как ще стигнат.

И не мога да накарам тъпото нещо да престане. Дано тук някой знае нещо и да е възможна
операцията, че нямам време да подкарвам моя компилатор и за тоя силиций (ако и да открих
данните, нужни ми за целта).

Кво правя:
декларирам сигналите като istype 'reg buffer';
слагам им .OE=0 ;
слагам им .CLK= някой от глобалните клоци;

и им слагам .d (или с =, или без .d с :=, все му е тая) някаква логика, за която отиват два
product term-а (едно "или" има само, не може да се минимизира, да можех да му изключа оптимизатора
поне него да не го мисля ама не може).

Е и кво прави това - вместо да използва клетката, дето съм я и дефинирал и всичко,
слага друга клетка за целта, взимайки я от неизползваните. Е така доникъде няма да стигне,
то е ясно.
Що не ще тая тъпотия? Просто искам в матрицата да влизат и сигналите от краката,
и от клетката - правил съм го безборй пъти със старите coolrunner-и с моя си компилатор и
при тия новите от архитектурата изглежда, че няма проблем да се прави.

Дано някой може да помогне някак.