=AK=

Два последовательно соединенных резистора, к средней точке которых подключены два диода: один на питание, второй на землю.

Начинать всегда надо с Гугла :) http://www.lirc.org/ LIRC is a package that allows you to decode and send infra-red signals of many (but not all) commonly used remote controls. http://irstudio.chat.ru/ Программа для считывания ИК-пультов бытовой теле/видео/аудиоаппаратуры и их воспроизведения

Конечно. Хотя бы тем, что операция чтения из памяти как минимум требует одного такта (хотя в действительности может быть больше). В то время как регистры могут быть непосредственно подключены к входам и выходу АЛУ. Для выполнения такой команды потребуется на мой взгляд как минимум 4 цикла обращения к памяти (хотя может быть и больше). Не согласен. Регистры принципиально ничем от памяти не отличаются. Память - это просто регулярный массив регистров. Из экономических соображений "обычная" память делается как можно проще, поэтому ее возможности более ограничены по сравнению с регистрами. По условию задачи у меня этого ограничения нет, я могу прокладывать сколько угодно шин и подключать память к АЛУ как мне заблагорассудится. Без конвейера, который ставится опять-таки только лишь из экономии, чтобы можно было использовать более медленную (по сравнению с регистрами) память. Представляю еще один вариант воплощения, в котором используется строго 128-битная шина данных. Каждая 128-битная ячейка памяти имеет ассоциированный с ней умножитель 128х128. Например, старшее 128-битное слово результата с выхода умножителя прописывается назад в саму ячейку, младшее 128-битное слово прописываеется в соседнюю с ней ячейку. Для чего между всеми соседними парами ячеек проложен свой специальный 128-битный пук проводов, и к каждой ячейке добавлен еще мультиплексор. То есть, под эту конкретную команду у меня кусочек АЛУ встроен прямо в каждую ячейку памяти, но при этом память осталась регулярным массивом, как ей дОлжно быть. Расточительно? Конечно. Однако технически реализуемо? Несомненно. За 1 такт. Безо всяких конвейеров.

Распишите (хотя бы для себя на листочке) по шагам как должно быть построено железо, чтобы сделать за 1 такт команду: например, чтение (пусть будет 128-битного, хотя здесь неважно пусть разрядность будет равна разрядности шины данных) слова из памяти, умножение на слово в регистре и запись удвоенного по разрядности результата обратно в память. (для CISC такая команда вполне возможна). Это чем-то отличается от команды умножения с операндами в регистрах? То есть, по-вашему, регистры чем-то принципиально отличаются от памяти? Так же точно и сделаю за один такт, как делается на регистрах. Гарвардская архитектура, слова в памяти данных 256-разрядные, шина данных тоже, обращение возможно к половине слова (128 разрядов) или к целому слову. Для чистоты мысленного эксперимента при этом регистров как таковых вообще не буду иметь, и при этом пусть любая ячейка памяти может использоваться так же, как в привычных нам процах используется аккумулятор. Чтоб совсем не было сомнений, что это CISC, вместо умножения предлагаю сделать команду извлечения квадратного корня. Для простоты и устрашения, делать буду табличным методом, для 256-разрядных операндов. Раззудись плечо, размахнись рука, ресурсы-то по условию задачи даны немеряные! :)

Сложные команды нельзя выполнять за один такт? Обоснование не представите? За один такт можно выполнять сколь угодно сложные команды, это не вопрос. Вопрос состоит только и исключительно в том, что неэкономно тратить железо на то, чтобы воплотить все сложные команды за один такт. Поскольку в средней программе они встречаются относительно редко, а кремния требуют относительно много. Экономнее выполнить их за несколько тактов (что часто делается в CISC, а также в некоторых недо-RISC-ах), или вообще их не иметь в системе команд (что характерно не только для RISC, но и для таких "экономических" CISC-ов, как, например, 51-й) . Конвеер равно фиолетово относится как к CISC-ам, так и к RISC-ам. То есть, и там и там он может быть или не быть. В RISC-ах конвеер встречается чаще. Неплохая статья: http://arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html 1. RISC was not a specific technology as much as it was a design strategy that developed in reaction to a particular school of thought in computer design. It was a rebellion against prevailing norms--norms that no longer prevail in today's world. 2. "CISC" was invented retroactively as a catch-all term for the type of thinking against which RISC was a reaction. 3. We now live in a "post-RISC" world, where the terms RISC and CISC have lost their relevance (except to marketing departments and platform advocates). In a post-RISC world, each architecture and implementation must be judged on its own merits, and not in terms of a narrow, bipolar, compartmentalized worldview that tries to cram all designs into one of two "camps."

Неубедительно. CISC не обязан иметь длинные команды в системе команд. Некоторые CISC-и имеют такие команды, другие - нет. CISC, выполняющий любые команды за 1 такт, не станет от этого RISC-ом. Это не решение. Оно годится только для очень простых приложений, где количество задач у уровней вложения прерывания ограничено каким-то смешным минимумом, обязательно статическим. Для динамически создаваемых задач этот довод вообще не в кассу. В общем случае решение есть только одно - сливать регистры в стек. И здесь RISC-и ковыляют далеко позади многих других.

Я думаю, что всем людям свойственно ошибаться, а монополией на истину никто не обладает. На вопрос, котрый я задал (почему в железе "исчез" сигнал, который имелся при симуляции), я получил такой ответ: "Я бы посоветовал иногда заглядывать в сгенеренную по коду схематику...", "(просмотр схематики) помогает разобраться во что будет синтезирован код, обнаружить неточности в описании(появление нежелательных латчей, укорочение сдвиговых регистров". Ваше объяснение "у меня к сожлению нет времени для достаточно полного анализа почему синтезатор убирает сигнал RwWr_done вообще, но предположу что так как shr[2] упрощается сигнал RdWr_done ~ cmd_gate" совершенно неудовлетворительно. Я не вижу причин, почему бы он вообще должен быть сокращен, тем более что симулятор его не сократил. Зато вместо ответа на поставленный вопрос меня стали ретиво поучать, что я в список чувствительности процесса вставляю "слишком много сигналов". Что, с моей точки зрения, ни к заданному вопросу никакого отношения не имеет (по крайней мере, для квартуса), ни само по себе пользы не приносит. При этом мне "наиподробнейшим образом" объяснили, почему с процессом и со списком должно происходить "именно так а не иначе". Однако выяснилось, что на самом деле в квартусе происходит совсем не так, как мне объясняли. Неправда. Все три человека не на ошибку указывают, а советуют мне делать нечто, прямо противоположное тому, что рекомендует документация квартуса. Они мне рекомендуют исключить из списка чувствительности "ненужные сигналы", тогда как квартус черным по белому пишет, что я этого делать не должен, что это вредно и может привести к ошибкам. Рекомендация квартуса при этом полностью соответствует моему пониманию хода вещей. При этом very_hard единственный, кто, помимо собственного мнения по этому вопросу, привел объективную информацию, указав на стандарт, а также запустив симулинк и описав результаты. В результате я стал лучше понимать его резоны, потому как симулинк, как выяснилось, ведет себя иначе, чем симулятор квартуса. А также лучше стал понимать, почему квартус так настоятельно советует держать этот список в порядке, несмотря на то, что сам он пользуется своим собственным списком. Вы же вместо доводов выплескиваете на меня ваши дурные эмоции, зачем? других аргументов нет? Чрезмерная раздраженность никак не может служить подкреплением мнения, скорее наоборот, дискредитирует его. "Quartus II Integrated Synthesis", "вы английским хорошо владеете?" (с) Это не фрагмент руководства. Это фрагмент контекстно-чувствительной подсказки, объясняющей предупреждение, возникающее, когда в списке чувствительности процесса отсутствует один из сигналов, влияющий на процесс. При всей своей "чувствительности к контексту" эта подсказка одна. Она выдается как в случае, когда недостача сигнала в "комбинаторном" процессе превращает его в защелку, так и во всех остальных случаях, в том числе и для тактируемых процессов. Повторяю еще раз: квартус выдает это предупреждение в любом случае, когда в теле процесса есть сигнал, стоящий в правой части оператора, но этот сигнал отсутствует в списке чувствительности процесса. Подсказка на это предупреждение одна, объяснение одно (на комбинаторном примере), рекомендация одна: ввести в список процесса указанный сигнал. Не выбросить сигнал из списка "за ненадобностью", как мне тут наперебой советуют, а ввести его в список. "вы не понимаете в чём разница? или это намереная спекуляция?" © Не надо передергивать, это неприлично. В моем случае "ошибки пользователя" скорее всего не было, это подтверждается тем, что симулятор отработал сигналы правильно, как ожидалось. И это уж точно никак не было связано с кажущимися вам "лишними" сигналами в списке, поскольку в исходном случае использовалась переменная, а не сигнал. Я тоже считаю, что лучше всё-таки придерживаться установленных правил. Квартус диктует свои правила и дает свои рекомендации, прямо противоположные вашим советам. И мне хорошо понятно, почему квартус в этом вопросе ведет себя именно так, требуя формально правильного списка. Тогда как польза от вашего совета выбросить "лишние" сигналы мне не видна. Впредь, работая с другими компиляторами, я тоже не буду следовать вашим вредным советам. Я предпочту продолжать иметь список чувствительности, однозначно и формально соответствующий телу процесса, как того требует квартус. Только это хоть как-то гарантирует переносимость проекта, предсказуемость и однозначность результата, независимо от особенностей поведения того или иного компилятора и симулятора. Прикиньте, приходит в бухгалтерию ревизия. Бухгалтер выкладывает на стол две тоненькие папочки и говорит: "Вот это проверяйте, а остальное не надо проверять, у меня там ни ошибок нет, ни мухлежа". И убирает всю остальную документацию в сейф.

Вопрос был как дешевле реализовать, а не как быстрее. Еще DALI можно помянуть, тоже открытый коллектор. 1200 бод на 300м, зато на любом кабеле и при любой топологии, без терминаторов. C-Bus 5 кбод на 1 км, свободная топология на любой неэкранированной витой паре. А эти "50 раз быстрее", небось, требуют экранированный кабель с контролируемым волновым сопротивлением, терминаторы с обоих концов и малое кол-во узлов с макс. отводами сантиметров по 10?

LIN работает при помощи открытых коллекторов, т.е. по монтажному ИЛИ. При 20 кбод на 40 м работает. Далласовский 1-wire тоже использует открытые коллекторы. Даллас пишет - то 700 м.

В качестве контраргумента: набор команд PIC намного проще и меньше, чем у 51-го, и все равно микрочип называет его "недо-RISC". Если следовать Вашей логике, это дает основания называть 51-й "недо-недо-RISC", или, что короче, "не-RISC". :) Однако спорить на таком уровне аргументации я могу разве что для смеха. Я уже указывал, что, с моей точки зрения, для RISC-а важной являеется цель, ради которой его система команд "уменьшена", а не само по себе количество команд. И для RISC цель эта одна: переложить заботы "микропрограммирования" сложных команд на компилятор ЯВУ. У 51-го же набор команд оптимизировался совсем не для этого. Еще пример, процессор Ignite фирмы PTSC. У него код команд вообще 6-битный (или даже 5-битный, запамятовал). И что, кто-нибудь называет его RISC-ом? Ни в коем случае, под определение RISC он не подходит, цели преследовались другие. Этот процессор относится к классу MISC - "компьютер с минимальным набором команд", но никак не RISC. Цель, поставленная при проектировании, а также совокупность использованных приемов, вот что главное. Приколотил, скажем, Лютер к двери церкви свои 10 (или сколько там) тезисов, каждый сам по себе возражений ни у кого не вызовет, так что - на этом основании всех надо записать лютеранами? :) Название RISC, к сожалению, выбрано неудачно. Оно производит ложное впечатление, что в сокращении набора команд и состоит сущность RISC, что стоит чуть уменьшить число команд - и проц можно записывать в RISC-и. Отсюда и рождаются подобные высказывания. Но это неверно. Ну никаким боком это к RISC-ам не относится, совершенно ортогональное свойство. Cтоит заметить, что RISC-и вообще говоря как раз медленно реагируют на прерывания, поскольку должны сохранять в стеке свои здоровенные регистровые файлы, а потом восстанавливать их. Лучше всего на прерывания реагируют стековые процессоры определенного вида, т.к. им для сохранения-восстановления контекста вообще ничего делать не надо. Потому что банки эти - вовсе не прерогатива RISC-ов, а как раз-таки наоборот, вовсю использовались именно в CISC-ах, в том числе в таком типичном CISC-е как 51-й :)

Simulation Mode: Allows you to specify the type of simulation you want to run. The Quartus II Simulator can perform the following types of simulation: * Functional—Simulates the behavior of flattened netlists extracted from the design files. Generate Functional Simulation Netlist: Generates the functional simulation netlist required for functional simulation. The flattened functional simulation netlist extracted from the design files does not contain timing information. Я это понимаю так, что квартусовский симулятор не компилирует исходники заново, а пользуется готовыми результатами "основного" компилятора. Что очень даже логично, т.к. независимый компилятор симулинка может выдавать существенно другие результаты, чем компилятор того же квартуса. Это довод в пользу полностью интегрированных систем.

Это и/или bison смотреть обязательно. Вне зависимости будет в конце-концов синтаксис бейсика или нет. Это нужно только профессиональным писателям компиляторов, и то в основном для образования, остальным без надобности. Гораздо практичнее использовать не полуфабрикат тридцатилетней давности, а современную готовую систему, например http://www.devincook.com/goldparser/ GOLD is a free parsing system that you can use to develop your own programming languages, scripting languages and interpreters. It strives to be a development tool that can be used with numerous programming languages and on multiple platforms.

Это была цитата из Задорнова: "Дайте мне чернила для 6-го класса!" ©, что ассоциируется у меня с "бэйсик для AVR". Не имел намерения ни на что другое намекать. Пока все ориентированно на AVR, по этому пишется на Асме - соответственно платформа все таки целевая. Хотя, когда выработаются жесткие конструкции в голове, может быть можно будет говорить и о переносимости, хотя таковой цели я не ставлю Вопрос был о другом, не о переносимости. Интерпретатор находится а целевой платформе, т.е. на AVR. Вопрос в том где находится компилятор, тоже на AVR (резидентно) или на PC (кросс-компилятор). И тот и другой вариант возможны, но второй несравненно проще реализовать. Я понимаю, скажем, почему тот же Атари-бэйсик был полностью резидентным - в то время PC не существовало. И почему он был написан на ассемблере - не было C для 6502. Но сейчас-то зачем огонь трением добывать, из спортивного интереса?

VHDL Process Statement warning at <location>: signal "<name>" is read inside the Process Statement but isn't in the Process Statement's sensivitity list ... During simulation, the Process Statement updates the value of signal o whenever signal a changes value. However, changes to the value of signal b do not trigger the execution of the Process Statement, and thus signal o behaves as a pseudo-latch, that is, it retains its value, whenever signal b alone changes value. Quartus II Integrated Synthesis ignores the pseudo-latch behavior implied by the incomplete sensitivity list in the example above. It generates logic as if the sensitivity list were complete, and therefore implements purely combinational logic for signal o. ACTION: To avoid receiving this message in the future, and to avoid potential mismatches between simulation and the synthesized logic, add the specified signal to the sensitivity list. ... Про синтезатор сказано яснее ясного: ему мой список по барабану. Однако про симулятор вроде бы говорится, что он и на самом деле им руководствуется, что, с моей точки зрения было бы крайней глупостью. Проверяем, как на самом деле ведет себя симулятор, если ему подсунуть неправильный список чувствительности. Создаем модуль: LIBRARY ieee; USE ieee.std_logic_1164.all; USE ieee.numeric_std.all; USE ieee.std_logic_unsigned.all; ------------------------------------------------------------ ENTITY Sim_Test IS -- {{ALTERA_IO_BEGIN}} DO NOT REMOVE THIS LINE! PORT ( Clk : IN STD_LOGIC; Rst : IN STD_LOGIC; InData : IN STD_LOGIC; Out1 : OUT STD_LOGIC; Out2 : OUT STD_LOGIC; OutCnt : OUT STD_LOGIC_VECTOR(3 downto 0) ); -- {{ALTERA_IO_END}} DO NOT REMOVE THIS LINE! END Sim_Test; ------------------------------------------------------------ ARCHITECTURE Sim_Test_architecture OF Sim_Test IS signal cnt,shr : unsigned(3 downto 0); signal dummy : std_logic; BEGIN process(dummy) -- по-вашему, он вообще запускаться не будет?;) begin if Rst='1' then cnt <= (others => '0'); shr <= (others => '0'); elsif rising_edge(Clk) then cnt <= cnt + X"1"; shr <= shr(2 downto 0) & InData; OutCnt <= std_logic_vector(cnt); Out1 <= std_logic(shr(3)); end if; Out2 <= std_logic(shr(1)); end process; ------------------------------------------------------------ END Sim_Test_architecture; Запускаем симулятор и видим, что он тоже, как и синтезатор, видал этот мой липовый спиcок в белых тапочках: Что и следовало ожидать Усложняем задачу. Вводим липовый клок Clk101 частотой 101MHz с начальным смещением 3.33ns, и в списке чувствительности вместо dummy использум Clk101. Запускаем симулятор. Ничего не изменилось :laugh: "Суха теория, мой друг, а древо жизни зеленеет" © :)

Это не аргумент. Чем раньше вылавливаются ошибки, тем лучше. Лучше выловить их на стадии функционального моделирования. Интересно. Ссылочку можете привести? Насколько я понимаяю, ни один компилятор достаточного сложного языка реально не соответствует стандарту. Возьмите С++, полного соответствия нет ни у мелкософта, ни у GCC, не говоря уж о прочих. Квартус о своем неполном соответствии пишет черным по белому. А главное - в чем все-таки преимущество такого запуска процесса строго по моему списку? Милливатт-часы? Вот это точно бред.

Значит, чтобы сэкономить машинное время, я должен уметь безошибочно определять, какие сигналы в списке лишние, а какие нет? Что будет если я в список клок по ошибке не включу? Я предпочитаю чтобы компьютер экономил мое время :) Запускает. Иначе - беспредел. :) Наоборот, беспредел - это если он будет запускать по моему списку. Тогда я увижу не то, что произойдет на самом деле, а то, что я хочу увидеть. Весь смысл симуляции теряется.

"Чернила для 6-го класса?" :) Разве что пустой причуды ради хотите написать его на ассемблере. Ресурсы по Бэйсику, http://www.nicholson.com/rhn/basic/ Сам интерпретатор может быть достаточно произвольным. Например, Атари Бэйсик компилировал бэйсик исходник в байт-код, который затем исполнялся виртуальной Форт-машиной. Все было написано на ассемблере 6502, но это когда ж было... У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?

Я не пишу отдельно VHDL код для функциональной симуляции, пишу один код для всего проекта. Который используется и для функциональной симуляции (при отладке), и для живого кристалла, когда Квартус проверяет все времянки. Если Вы пишете другой код, поделитись, зачем это нужно, что при этом реально выигрывается, и как Вы потом разные коды сводите воедино? Неужели несколько долей секунды машинного времени, выигранные при функциональной симуляции, стоят траблов?

Обычный RISC. Тут дело не в длине команды. load/store и работа с памятью напрямую - это одно и тоже. Не могу согласиться. Архитектура 51-го никаким боком не подходит под RISC. Даже Мелкочип свои PIC-и осторожно называл RISC-like. Вот не самое плохое определение RISC: (Reduced Instruction Set Computer) A computer architecture that reduces chip complexity by using simpler instructions. RISC compilers have to generate software routines to perform complex instructions that were previously done in hardware by CISC computers. In RISC, the microcode layer and associated overhead is eliminated. RISC keeps instruction size constant, bans the indirect addressing mode and retains only those instructions that can be overlapped and made to execute in one machine cycle or less. The RISC chip is faster than its CISC counterpart and is designed and built more economically. Проверяем 51-й: -- Проще набор инструкций. Соглашаться или нет - дело вкуса, однако по здравому размышлению я бы соглашаться не стал. Инструкций в 51-м много, и они сильно разномастные, неструктурированные. Просто из "большого набора" возможных CISC-инструкций выбраны те, которые наиболее употребительны в embedded-приложениях, чтобы общее количество не превышало 256 (один байт кода команд). Что явно не RISC. Про AJMP размусоливать не буду, на мой взгляд, это явный ляп разработчиков, ненужная по жизни команда, которая зазря съедает множество кодов. Здесь я бы добавил такой характерный признак: из набора RISC команд выброшены те, которые удобны для программирования на ассемблере, но неудобны при написании компиляторов ЯВУ. При таком уточнении 51-й - совершенно точно не RISC, его система команд явно создавалась с заботой об ассеблерщиках. Для настоящего RISC-а писать программы на ассемблере должно быть мучением и мазохизмом. В идеале - брэйнфак с одной командой. :) Для 51-го это условие не выполняется, для него вполне приятно на ассемблере писать. -- Отсутствует микрокодирование команд. Насколько мне известно, в оригинальном 51-м оно имело место быть. По крайней мере, когда я пытался заказать в МЭП-е советский клон i8044 (это 51-й с SDLC), разработчики сразу же сказали что будут делать с микрокодом, да еще хотели растактовку сделать не на 12 клоков, а на 16 :) -- Постоянный размер команд. В 51-м этот наиболее характерный признак RISC отсутствует, размер команд переменный. -- Нет косвенной адресации. На мой взгляд, не самый важный признак, но все же: в 51-м она есть, однако... -- В определении об этом забыли, но вообще-то RISC должен любую команду выполнять за 1 такт, что неверно для 51-го. Имхо, поэтому PIC и не называли настоящим RISC-ом, хотя по другим признакам он подходит. Еще у старых PIC-ов система команд тоже оптимизировалась для ассемблерного написания программ, а не для ЯВУ.

Если честно, я точно не знаю, что конкретно считается при запуске процесса. Если думать, что считаются только сами изменения выходных сигналов, то можно и не включать. Однако как правило я думаю о людях лучше, чем они заслуживают, :) поэтому в качестве рабочей гипотезы я принимаю, что Квартус запускает процес не только для этого, но в том числе и для того, чтобы посчитать всевозможные нарушения времянок. Например, если сигналы cmd_gate и bit_cnt изменятся незадолго до или же сразу вслед за событием "rising_edge", то это будет нарушением оговоренных спецификаций железа (времена сетап и холд). "Лишний" запуск процесса в принципе позволяет это обнаружить, тогда как при настоятельно мне советуемом "избегании ненужных запусков" обнаружить этого будет нельзя. При условии, конечно, что Квартус и правда запускает процесс по указанному мной списку, в чем я лично сомневаюсь. Я подозреваю, что он достаточно умен, чтобы самому определить, когда запускать процесс, безотносительно к моему списку. А мой список использует только и исключительно для того, чтобы сравнить его с собственным списком (по которому процесс и будет запускаться на самом деле), и выдать ворнинг, мол, "что ж ты, блин, мне подсовываешь?" :)

Примерно 2 кило на сях, см. http://sourceforge.net/projects/c-fvm Но это не полный Форт, а именно виртуальная Форт-машина, где компилятор кроссовый.

Мне это вообще говря не важно. Сдвиговый регистр вводился для того, чтобы привести сигнал в другое временное пространство и прибить (возможную) метастабильность. Одного каскада достаточно, а будет два или три - все равно, не играет большой рояли. Используя переменные, я как раз пытаюсь исправить стиль. Раньше все делал сигналами, и это сильно раздражало. С позиций "обычного программирования", сигнал - это переменная с областью видимости для всего модуля, а переменная - соответствует локальной переменной функции (т.е. процесса). В программировании считается дурным стилем использовать переменные с большей чем необходимо областью видимости (как минимум, им приходится придумывать разные имена, а потом держать их в голове). Поэтому переменная предпочтительней сигнала во всех случаях, когда область ее видимости не должна выходить за пределы процесса. Читал, что есть и другое преимущество, а именно - на переменную тратится намного меньше PC-шных ресурсов при компиляции и симуляции. Однако крайне неприятно что переменная по поведению отличается от сигнала, это по сути просто дрова какие-то. Не понимаю причин, нафиг именно так сделано. Если можете подсказать как в VHDL сделать "локальный сигнал" без переменных, буду благодарен, я этого не умею. Они сгруппированы не по времени, а по функциональности. Сначала я делаю некие действия, затем рассовываю почти неизмененные результаты в другие временные пространства. Ну как же так? К bit_cnt чувствителен вот этот оператор bit_cnt <= bit_cnt + "001"; -- count SCLK pulses А к cmd_gate чувствителен вот этот RdWr_done <= shr(2) and (not cmd_gate); В обоих случаях указанные сигналы находятся в правой части выражений, так что процесс обязан быть пересчитан заново, как только они изменились. Вот если бы я сделал bit_cnt переменной, то указывать его в списке чувствительности не надо было бы. Но главный вопрос остался открытым: симулятор показал одно (именно так, как я и представлял себе поведение этого кода), а на самом деле FPGA вела себя по-другому, а почему по-другому - я не понимаю.

Нет, все-таки что-то не так... :( Пишу код типа process(Reset, CSn,SCLKin,CLK48,bit_cnt,cmd_gate) variable pulse5 :std_logic; variable shr : unsigned(2 downto 0); begin if (Reset='1') or (CSn='1') then bit_cnt <= "000"; elsif rising_edge(SCLKin) then bit_cnt <= bit_cnt + "001"; -- count SCLK pulses if (bit_cnt = "101") then pulse5 := '1'; else pulse5 := '0'; end if; end if; if rising_edge(CLK48) then shr := shr(1 downto 0) & pulse5; RdWr_done <= shr(2) and (not cmd_gate); end if; end process; Проверяю модуль на симуляторе, все чудно работает, диаграмки соответствуют ожидаемым. Компилирую весь проект - полные дрова, не пашет. Начинаю разбираться и вижу, что сигнала RdWr_done на выходе модуля на самом деле нет (он всегда 0), а симулятор, стало быть, врет. Убираю переменную shr, делаю ее сигналом - вуаля, все работает. :blink:

Когда-то я делал высоковольтные импульсные, 50 kV, 2mA. Основные проблемы были такие: -- для изоляции транс и выпрямитель надо было заливать, иначе корона все разъест (не знаю про 4kV, может и без заливки будет работать) -- для изоляции обмотки приходилось располaгать на разных стержнях П-образного сердечника, из-за этого получалась большая индуктивность рассеяния -- во вторичке много витков, емкость получается большой -- емкость вторички и индуктивность рассеяния создавали контур, резонирующий на довольно низкой частоте, поэтому приходилось использовать квазирезонансный преобразователь

Яркость - это не мощность. Чтобы видимая яркость менялась линейно, мощность должна меняться примерно по экспоненте (там еще спектр меняется, но это уж здесь совсем неуместно обсуждать). Регулировка яркости при линейном изменении угла зажигания симистора весьма плавная и на глаз вполне "линейная" при изменении яркости от 0 до 50%, что при 50 Гц составляет от 9 мс до 5 мс соответственно. Последнюю миллисекунду использовать не удается, там мощность слишком мала, чтобы нить накала засветилась. А вот участок от 50% до 100% "линеаризовать" хорошо бы, хотя бы путем кусочно-линейной аппроксимации. Хорошо бы, но вовсе не обязательно, особенно для начинающих. Даже при линейном управлении фазой работает удовлетворительно. Кстати, первую 1мс тоже можно выбросить нафиг, т.к. никакой разницы на глаз нет, поджечь симистор сразу же после перехода через ноль, или подождать 1...1.5мс. Так что вполне можно для начала просто сделать добротное линейное управление углом поджига в диапазоне от 1мс до 9мс.