Перейти к содержанию
    

=AK=

Свой
  • Постов

    3 299
  • Зарегистрирован

  • Посещение

  • Победитель дней

    7

Весь контент =AK=


  1. 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. Я это понимаю так, что квартусовский симулятор не компилирует исходники заново, а пользуется готовыми результатами "основного" компилятора. Что очень даже логично, т.к. независимый компилятор симулинка может выдавать существенно другие результаты, чем компилятор того же квартуса. Это довод в пользу полностью интегрированных систем.
  2. Basic Interpreter for AVR

    Это и/или 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.
  3. Basic Interpreter for AVR

    Это была цитата из Задорнова: "Дайте мне чернила для 6-го класса!" ©, что ассоциируется у меня с "бэйсик для AVR". Не имел намерения ни на что другое намекать. Пока все ориентированно на AVR, по этому пишется на Асме - соответственно платформа все таки целевая. Хотя, когда выработаются жесткие конструкции в голове, может быть можно будет говорить и о переносимости, хотя таковой цели я не ставлю Вопрос был о другом, не о переносимости. Интерпретатор находится а целевой платформе, т.е. на AVR. Вопрос в том где находится компилятор, тоже на AVR (резидентно) или на PC (кросс-компилятор). И тот и другой вариант возможны, но второй несравненно проще реализовать. Я понимаю, скажем, почему тот же Атари-бэйсик был полностью резидентным - в то время PC не существовало. И почему он был написан на ассемблере - не было C для 6502. Но сейчас-то зачем огонь трением добывать, из спортивного интереса?
  4. 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: "Суха теория, мой друг, а древо жизни зеленеет" © :)
  5. Это не аргумент. Чем раньше вылавливаются ошибки, тем лучше. Лучше выловить их на стадии функционального моделирования. Интересно. Ссылочку можете привести? Насколько я понимаяю, ни один компилятор достаточного сложного языка реально не соответствует стандарту. Возьмите С++, полного соответствия нет ни у мелкософта, ни у GCC, не говоря уж о прочих. Квартус о своем неполном соответствии пишет черным по белому. А главное - в чем все-таки преимущество такого запуска процесса строго по моему списку? Милливатт-часы? Вот это точно бред.
  6. Значит, чтобы сэкономить машинное время, я должен уметь безошибочно определять, какие сигналы в списке лишние, а какие нет? Что будет если я в список клок по ошибке не включу? Я предпочитаю чтобы компьютер экономил мое время :) Запускает. Иначе - беспредел. :) Наоборот, беспредел - это если он будет запускать по моему списку. Тогда я увижу не то, что произойдет на самом деле, а то, что я хочу увидеть. Весь смысл симуляции теряется.
  7. Basic Interpreter for AVR

    "Чернила для 6-го класса?" :) Разве что пустой причуды ради хотите написать его на ассемблере. Ресурсы по Бэйсику, http://www.nicholson.com/rhn/basic/ Сам интерпретатор может быть достаточно произвольным. Например, Атари Бэйсик компилировал бэйсик исходник в байт-код, который затем исполнялся виртуальной Форт-машиной. Все было написано на ассемблере 6502, но это когда ж было... У Вас компилятор и интерпретатор будут разделены, или же оба должны работать на целевой платформе?
  8. Я не пишу отдельно VHDL код для функциональной симуляции, пишу один код для всего проекта. Который используется и для функциональной симуляции (при отладке), и для живого кристалла, когда Квартус проверяет все времянки. Если Вы пишете другой код, поделитись, зачем это нужно, что при этом реально выигрывается, и как Вы потом разные коды сводите воедино? Неужели несколько долей секунды машинного времени, выигранные при функциональной симуляции, стоят траблов?
  9. Обычный 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-ов система команд тоже оптимизировалась для ассемблерного написания программ, а не для ЯВУ.
  10. Если честно, я точно не знаю, что конкретно считается при запуске процесса. Если думать, что считаются только сами изменения выходных сигналов, то можно и не включать. Однако как правило я думаю о людях лучше, чем они заслуживают, :) поэтому в качестве рабочей гипотезы я принимаю, что Квартус запускает процес не только для этого, но в том числе и для того, чтобы посчитать всевозможные нарушения времянок. Например, если сигналы cmd_gate и bit_cnt изменятся незадолго до или же сразу вслед за событием "rising_edge", то это будет нарушением оговоренных спецификаций железа (времена сетап и холд). "Лишний" запуск процесса в принципе позволяет это обнаружить, тогда как при настоятельно мне советуемом "избегании ненужных запусков" обнаружить этого будет нельзя. При условии, конечно, что Квартус и правда запускает процесс по указанному мной списку, в чем я лично сомневаюсь. Я подозреваю, что он достаточно умен, чтобы самому определить, когда запускать процесс, безотносительно к моему списку. А мой список использует только и исключительно для того, чтобы сравнить его с собственным списком (по которому процесс и будет запускаться на самом деле), и выдать ворнинг, мол, "что ж ты, блин, мне подсовываешь?" :)
  11. Basic Interpreter for AVR

    Примерно 2 кило на сях, см. http://sourceforge.net/projects/c-fvm Но это не полный Форт, а именно виртуальная Форт-машина, где компилятор кроссовый.
  12. Мне это вообще говря не важно. Сдвиговый регистр вводился для того, чтобы привести сигнал в другое временное пространство и прибить (возможную) метастабильность. Одного каскада достаточно, а будет два или три - все равно, не играет большой рояли. Используя переменные, я как раз пытаюсь исправить стиль. Раньше все делал сигналами, и это сильно раздражало. С позиций "обычного программирования", сигнал - это переменная с областью видимости для всего модуля, а переменная - соответствует локальной переменной функции (т.е. процесса). В программировании считается дурным стилем использовать переменные с большей чем необходимо областью видимости (как минимум, им приходится придумывать разные имена, а потом держать их в голове). Поэтому переменная предпочтительней сигнала во всех случаях, когда область ее видимости не должна выходить за пределы процесса. Читал, что есть и другое преимущество, а именно - на переменную тратится намного меньше 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 вела себя по-другому, а почему по-другому - я не понимаю.
  13. Нет, все-таки что-то не так... :( Пишу код типа 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:
  14. Когда-то я делал высоковольтные импульсные, 50 kV, 2mA. Основные проблемы были такие: -- для изоляции транс и выпрямитель надо было заливать, иначе корона все разъест (не знаю про 4kV, может и без заливки будет работать) -- для изоляции обмотки приходилось располaгать на разных стержнях П-образного сердечника, из-за этого получалась большая индуктивность рассеяния -- во вторичке много витков, емкость получается большой -- емкость вторички и индуктивность рассеяния создавали контур, резонирующий на довольно низкой частоте, поэтому приходилось использовать квазирезонансный преобразователь
  15. Яркость - это не мощность. Чтобы видимая яркость менялась линейно, мощность должна меняться примерно по экспоненте (там еще спектр меняется, но это уж здесь совсем неуместно обсуждать). Регулировка яркости при линейном изменении угла зажигания симистора весьма плавная и на глаз вполне "линейная" при изменении яркости от 0 до 50%, что при 50 Гц составляет от 9 мс до 5 мс соответственно. Последнюю миллисекунду использовать не удается, там мощность слишком мала, чтобы нить накала засветилась. А вот участок от 50% до 100% "линеаризовать" хорошо бы, хотя бы путем кусочно-линейной аппроксимации. Хорошо бы, но вовсе не обязательно, особенно для начинающих. Даже при линейном управлении фазой работает удовлетворительно. Кстати, первую 1мс тоже можно выбросить нафиг, т.к. никакой разницы на глаз нет, поджечь симистор сразу же после перехода через ноль, или подождать 1...1.5мс. Так что вполне можно для начала просто сделать добротное линейное управление углом поджига в диапазоне от 1мс до 9мс.
  16. Непонятно что автор подразумевал под словом "плавно". Может, не "равномерно", а "монотонно"? Может, у него яркость скачет? k почему-то меняется от 30 до 3500; скорость этого изменения (при нажатии на кнопку), похоже, велика; функция delay_us(1) дает непонятно какую задержку. При 50 Гц полупериод 10000 мкс, чтобы все работало монотонно delay_us(1) должна обеспечивать задержку не более 10000/3500=2.85 мкс. Если больше, то после минимальной яркости будет прыжок на максимальную. Если delay_us(1) дает 2.85мкс, то delay_us(30) даст задержку всего в 85.5мкс, и при нажатии на кнопку счетчик k установится в 3500 или отмотает в 30 примерно за 350 мс, считая что полный цикл выполнится примерно за 100мкс. Глазом не успеешь моргнуть. PS: На самом деле все гораздо хуже, т.к. прерывание не отдает управление сразу же, как должно было бы делать, а "держит" до тех пор пока не зажжет симистор. Поэтому время исполнения основного цикла зависит от угла поджига, чем меньше яркость - тем "инерционнее" становятся кнопки. Лучше бы так не делать.
  17. Логично :) | есть общеупотребительный знак для ИЛИ для всех, кто печатает на обычной ПК клаве, и это не связано ни с Верилогом, ни с Це. Бо более адекватного знака для И чем & на этой клаве нет. Иначе знаку V нет подходящего комплемента, ведь ни Л не подходит в качестве И, ни ^. Так что V в качестве ИЛИ только сбивает с толку :) Дело практики, имхо. На то и форум, чтоб спрашивать и получать разумные объяснения, чем долбаться в одиночку. Спасибо. :cheers:
  18. ARM за доллар

    Luminary Micro аннонсировал сверхдешевый маленький ARM, http://www.luminarymicro.com/ http://www.ktvotv3.com/Global/story.asp?S=4684621 Купить в штучных кол-вах за пару долларов можно в Маузере, http://www.mouser.com/index.cfm?&handler=d...d&N=0&crc=false
  19. Тестовый стенд, состоящий из ПК, стабильного (но не особо точного) источника калибровочного напряжения и точного цифрового вольтметра, подключенного к ПК по RS232 . Программа на ПК считывает показания калибруемого устр-ва и показания вольтметра, обрабатывает и записывает результаты в EEPROM калибруемого устр-ва. Стенд не "специальный калибровочный", а универсальный тестовый стенд выходного контроля. Кроме калибровки он заодно тестирует функциональность, присваивает серийный номер устройству, ведет журнал (базу данных), печатает сертификат, и пр.
  20. Интересно было бы найти объективное сравнение производительности разных 8-битных архитектур. Что-то вроде EEMBC Consumer Benchmark, которая для 32-битниых выглядит так: http://www.ptsc.com/images/performance_density.jpg Довольно очевидно, что 51-е ядро вряд ли будет даже в первой десятке, так же, впрочем, как PIC16, HC08 и пр. старые архитектуры. Ядро AVR вполне может оказаться среди лидеров, имхо, хотя тоже не все там идеально, поскольку RISC. Кстати, еще интересно где бы оказался Тесей при таком сравнении.
  21. Единица или нуль. Вот и я подумал, нафиг там 1.0 вольт? :) То есть, в более общепринятой нотации, подразумевалось 1|0 Потому что flt - переменная(а не сигнал!). И изменяясь в ходе процесса она сразу становится доступной дальнейшим операциям процесса. Поэтому последовательное присвоение flt[0]:=Rxd и дальнейший сдвиг целого flt на один разряд приводят к записи в flt[0] нуля(должно же там чтото появиться :) ), Почему 0, а не 1? :) В конечном счете все свелось к тому, как на самом деле работает оператор сдвига sll. По моему, совершенно не очевидно, что он вообще должен хоть что-то присваивать младшему разряду, будь то сигнал или переменная. Тем не менее, мне лучше было бы сдвиговый регистр прописывать одной командой, типа flt := flt(3 downto 0) & Rxd; Здесь нет возможностей для множественного толкования, как в случае с sll Что ж касается filtered, то, получается, вполне можно сделать его не сигналом, а локальной переменной. От этого ничего не должно измениться, только сдвиговый регистр shr надо делать так же, как flt
  22. Дык, какие могут быть проблемы? Неужто в Маузере нет ничего подходящего? Помнится, там было полно недорогих звуковых ОУ от NJR
  23. Нет мажоритарного голосования, я хотел получить триггер, который взводится по трем 1 и сбрасывается по трем 0. В списке должны быть все сигналы, изменение которых сказывается на процессе. Детское объяснение: иначе Квартус ругается :) Что такое 1V0? Почему присваивается flt[0]=0 ? Я не понял, почему это должно происходить?
  24. Пытаюсь делать тривиальный фильтрик на входе UART-а, чтобы короткие выбросы не вызывали ложного срабатывания. Фильтр делаю на сдвиговом регистре flt, первые два каскада используются для подавления метастабильности, последние 3 каскада сравниваю на все 0 или все 1 и, соответственно, взвожу или сбрасываю бит результата shr(0), который затем вдвигаю в другой сдвиговый регистр shr process(clk16x,Rxd) variable flt :unsigned(4 downto 0); variable shr :unsigned(3 downto 0)l begin if rising_edge(clk16x) then flt(0) := Rxd; flt := flt sll 1; if flt(4 downto 2) = "000" then shr(0) := '0'; elsif flt(4 downto 2) = "111" then shr(0) := '1'; end if; shr := shr sll 1; end if; end process; Проверяю на симуляторе - полные дрова, не работает, не фильтрует ни фига. Почему? Переделал подубовее, ввел внешний сигнал filtered, и во второй регистр вдвигаю уже его process(clk16x,Rxd, filtered) variable flt :unsigned(4 downto 0); variable shr :unsigned(3 downto 0)l begin if rising_edge(clk16x) then flt(0) := Rxd; flt := flt sll 1; if flt(4 downto 2) = "000" then filtered <= '0'; elsif flt(4 downto 2) = "111" then filtered <= '1'; end if; shr(0) := filtered; shr := shr sll 1; end if; end process; Проверил на симуляторе - все ОК, работает. Это я чего-то не понимаю, или симулятор глючит?
×
×
  • Создать...