Значи на платката има инсталирани 50 и 133 MHz осцилатори, предполагам ще започна първо от 50. Този дето е 133 е на цокъл, така, че може да се втъкне и по-голям.
Пиновете, на които са свързани, са специализирани за клок, тип GCLK. Има обаче още един тип - RHCLK. Каква е разликата между двата?

Не съм чувал за RHCLK по Спартанците, да не е нещо по самата платка?

По повод на изписаното дотук - не ползвай схематика, че доколкото съм чувал ISE-то нещо не я дъвче много добре. Пиновете си ги опиши в UCF файл или използвай GUI-то "Constraints нещоси" да ти ги намятка то след много цъкане с плъха .

Ето ти проста мигалка на Verilog със синхронен брояч:

За твоя радост с default параметрите ще ти сложи BUFG, IBUF и OBUF. След синтез си разгледай "RTL Viewer" да видиш какво е разбрало. А ако си много смел и напреднал - "Technology Viewer".

За UCF пробвай това като си попълниш правилните пинове на мястото на многоточията:

Периодът е зададен като за 50 MHz. Ако махнеш първите два реда ще ти каже макс. честота на работа.


EDIT: Проверих го тоя RHCLK - клок с който можеш да храниш дясната част на чипа, т.е. два квадранта. Май нямаше такова в Спартан-3, може би е нововъведение в Спартан-3E. Хващай датачаршафите и дерзай.

Ами първо мисля да свикна със схематиката и когато съм готов да мина към нещо по-сложно, тогава ще разучавам и как се кодира.
Имам поредния въпрос - изходите на схемата Q[7:0] как да ги разделя на отделни жици?

Малко неясен въпрос.

Q[0], Q[1] ... Q[7]?

Не се спирай на схематика и не свиквай с него, кодирането е истината.

А изходите на вектора Q[7:0] ги задай в .ucf файла:
например:
...
NET "Q<0>" LOC = "a13" | IOSTANDARD = LVCMOS33 ;
NET "Q<1>" LOC = "b14" | IOSTANDARD = LVCMOS33 ;
...
NET "Q<7>" LOC = "b15" | IOSTANDARD = LVCMOS33 ;
...
а13, b14, b15 са означенията на изводите за конкретния чип/корпус.

Мисля че Реконструктора имаше впредвид как да ги ползва като отделни сигнали в схемата. Свързването трябва да стане по име. Там където ти трябва именуваш жицата Q[0] например и така я имаш свързана към сигнал [0] от Q[7..0].

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

Toни, аз също съм начинаещ.
Преди половин година отиде един месец време за да разбера как работи тази прословута логика CPLD/FPGA.
Започвайки да уча се хванах за схематика и си казвах точно така, само него да науча и всичко ще ми бъде лесно
В един момент след като една простичка схема започнеш да я развиваш, тя да нараства, да правиш корекции, започва да се вижда как ужким тези прости действия убиват много време.
И се стига до момента когато колкото и сложни да изглеждат VHDL/Verilog ще трябва да се преодолеят. Поне някакви начални стъпки с които да видя, че нещата не са толкова невъзможни.
Помъчих се с няколко симулатора и по простички неща, видях как мъглата започна да се прояснява и едно по едно да сработват дреболии, и повече не си и помислям да ползвам схематика.
Не знам за какви корекции пишеш, не съм синтезирал схеми с ТТЛ-ки, но след като завърших един по голям проект,като видях схемата която ми генерира RTL view-ра, прости ми се отщя да се занимавам със схематика, такава сложност не съм си и представял, докато Verilog кодът ми изглеждаше по-лесен за дописване и корекции.

Аз в никакъвслучай не казвам че човек трябва да работи със схематик, от един момент нататък това е просто невъзможно, но човек трябва да разбере как работи логиката, защотот това си е точно логика, това не е контролер. Иначе да се правят чудесаот храброст няма нужда, Veriloga е елементарен, точно както е елементарно и С-то, или да речем не елементарен, но много по удобен, в него няма нищо сложно по принцип. Но за човек който не разбира от схематика, може да му се струва неясен, объркан и сложен, а Veriloga сам по себе си както и HDL / VHDL са езици описателни, създадени са да описват точно и еднозначно както схеми, така и процеси, но са правени за хора които разбират схемата и процеса, и просто искат да си улеснят живота, или по скоро когато е поръчан от пентагона идеята е била да има унифициран метод за описание на всички контрактори.
Иначе аз имам система за контрол и управление на ММ, реализирана само на TTL, разбира се до прототип не се стигна, всичко остана на ниво схемотехника и ПП, но ми е напълно ясно какви схеми се генерират, а и когато съм позлвал логика винаги съм гледал какво ми генерира.
А за корекциите за кото говоря, ами нещо което може да не го видиш във кода, а може да го пропуснеш и във симулацията е конкуренцията на сигнали, погледната схемата много лесно може да се намери подобно нещо, разбира се зависи от сложността но според мен подобни грешки особенно в началото са лесно откриваеми като се гледа схематиката. В крайна сметка не може да разчиташ да направиш нещо описвайки логически връзки, без да можеш да си го представиш как се реализира.

Значи, LED-овете на тая платка са разхвърляни по различни портове. И не става просто да го вържа към порт. Трябва изхода да го разделя на отделни жици и всяка да я свържа със съответния пин.

Порта си е порт, не ти пречи.
В UCF файла си ги разписваш пин по пин.

Ами аз нямам такъв файл в проекта?

Ами създай си Може да го напишеш и в Notepad. Може и самата среда да го изгенерира. Ники беше дал пример по-горе.
След това трябва да укажеш на средата да го използва. Не помня вече къде беше точно.
Другият вариант както казаха по-горе е да имаш т.нар. constrains във VHDL файла.
Ако ползваш схема няма ли начин в properties на пина да го заковеш на точно определено място?
Освен това трябва да имаш още един начин с някакъв "pin asignment editor" на самото IDE.
Опита ми е със Xilinx WebPack и от няколко години не го ползвам щото се прехвърлих на ALTERA.
Навремето графичния редактор на WebPack беше много тегав и затова започнах с VDHL, но в един момент осъзнах че за CPLD ми е по-удобно да работя със схема. Дори имаше един момент когато най-горното йерархично ниво го чертаех в OrCAD, отделните блокчета ги пишех на VHDL. После от там го експортирах във VHDL и го включвах в проекта.
Т.е. работех с комбинация от VHDL и схема. Винаги можеш да направиш експорт към VHDL на схема и обратно да разгледаш в RTL viewer-a каква схема си сътворил в VHDL. RTL viewer-a чертае ужасни схеми, няма спор, но това не означава че работата в схематичен вид е по-сложна и объркваща. От моя личен опит накрая стигнах до извода че за CPLD ми е много по-удобно да работя в схема отколкото да пиша VHDL. Доста време затрих в експерименти върху един кит с XPLA3 в началото когато не знаех кое как се имплементва. Винаги гледах какво е надробил компилатора + оптимизатора като логически уравнения във fiter report-a.
Тука малко ще коригирам miro_atc, щото ми се е случвало оптимизатора с дефоулт настройките за синтезис и фит да не може да ми побере проект в CPLD на което ползвам под 75%. Разбира се ако той си определя кой пин къде да ходи успяваше накрая след около 30 минути компилации и оптимизации да го събере. Но се наложи да експериментирам с опциите и на фитера и на синтезатора докато накрая все пак успя да го събере и то с моя ucf файл.
Спомням си че тогава магическата дума беше KEEP. Имах един сигнал от адресен дешифратор който участваше почти навсякъде като enable. Оптимизатора беше размил дешифрацията по целия дизайн. В резултат в логическите уравнения на почти всеки изходен сигнал ми участваше и цялата адресна шина. Т.е. опитвал се е да я рутира из целия чип. Когато изхода от дешифратора го заковах да не се оптимизира му оставаше да рутира само този сигнал.
Така че оптимизатора не винаги е перфектен. Има стратегии за скорост за площ и т.н. но освен това както в моя случай се наложи да задам constrain на самия сигнал.