altera cyclone problem in harware - Page 1
Forum section: electronics / general

author: electros6
author_rank: Regular Contributor
timestamp: December 04, 2017, 12:11:50 pm
content: HI guys,I found the code for ws2812 in online it works in xlinx in both simulation and hardware but in altera cyclone it works in simulation but nit in hardware . I posted the code I set the pin in pin planner but after programing no waveform in the output I checked with scopelibrary ieee;use ieee.std_logic_1164.all;use ieee.numeric_std.all;entity clock is--generic (-- clock_frequency : integer := 50_000_000 -- Hertz--);port (clk : in std_logic;-- data : out std_logic_vector(23 downto 0); -- for testbench validation onlyserial : out std_logic);end entity clock;architecture arch of clock is-- constant T0H : integer := (350 * clock_frequency) / 1_000_000_000;-- constant T0L : integer := (800 * clock_frequency) / 1_000_000_000;-- constant T1H : integer := (700 * clock_frequency) / 1_000_000_000;-- constant T1L : integer := (600 * clock_frequency) / 1_000_000_000;-- constant RES : integer := (50000 * clock_frequency) / 1_000_000_000;constant T0H : integer := 17;constant T0L : integer := 38; -- compensate for state changesconstant T1H : integer := 35;constant T1L : integer := 28; -- compensate for state changesconstant RES : integer := 2500;type LED_ring is array (0 to 5) of std_logic_vector(23 downto 0);type state_machine is (load, sending, send_bit, reset);beginprocessvariable state : state_machine := load;variable GRB : std_logic_vector(23 downto 0) := x"000000";variable delay_high_counter : integer := 0;variable delay_low_counter : integer := 0;variable index : integer := 0;variable bit_counter : integer := 0;variable LED : LED_ring := (x"FF0000", -- LED 0, Green Red Bluex"00FF00", -- LED 1x"0000FF", -- LED 2x"FFFFFF", -- LED 3x"330000", -- LED 4x"003300"); -- LED 5--x"000033", -- LED 6--x"660000", -- LED 7--x"006600", -- LED 8yi--x"000066", -- LED 9--x"AA0000", -- LED 10--x"00AA00"); -- LED 11--x"0000AA", -- LED 12-- x"333333", -- LED 13-- x"666666", -- LED 14-- x"AAAAAA"); -- LED 15beginwait until rising_edge(clk);-- data <= GRB; -- temporary testing onlycase state iswhen load =>GRB := LED(index);bit_counter := 24;state := sending;when sending =>if (bit_counter > 0) thenbit_counter := bit_counter - 1;if GRB(bit_counter) = '1' thendelay_high_counter := T1H;delay_low_counter := T1L;elsedelay_high_counter := T0H;delay_low_counter := T0L;end if;state := send_bit;elseif (index < 15) thenindex := index + 1;state := load;elsedelay_low_counter := RES;state := reset;end if;end if;when send_bit =>if (delay_high_counter > 0) thenserial <= '1';delay_high_counter := delay_high_counter - 1;elsif (delay_low_counter > 0) thenserial <= '0';delay_low_counter := delay_low_counter - 1;elsestate := sending;end if;when reset =>if (delay_low_counter > 0) thenserial <= '0';delay_low_counter := delay_low_counter - 1;elseindex := 0;--state := possibly load new data for next cycleend if;when others => null;end case;end process;end arch;

author: Scrts
author_rank: Frequent Contributor
timestamp: December 04, 2017, 04:17:03 pm
content: 1. Check your clock input.2. Use SignalTap.

author: Sparker
author_rank: Regular Contributor
timestamp: December 05, 2017, 11:48:48 pm
content: Although quite unprobable at such clock rate, I've learned(the bad way) that it's always worth declaring clock networks and their frequencies. Especially if you're going to put a signalTap into your device.In quartus it's done through TimeQuest.

author: hamster_nz
author_rank: Super Contributor
timestamp: December 06, 2017, 06:01:21 am
content: It is always worthwhile to check the reports to see that the correct signal is associated with the desired pin and I/O settings.

author: tux75at
author_rank: Newbie
timestamp: December 09, 2017, 02:58:45 pm
content: I see some problems with the code also, but that should be in the report.1.) check the resource usage ... is there anything used at all?2.) coding style for VHDLThis code looks more like a testbench for me than any synthesizeable code."wait until rising_edge" even if its only used once in the process and it would be able to make this process sensitive to the clock "clk" its not an usual way to write VHDL code.process should be written as:p_process_name : process (clk, reset)beginif (reset = '0') then -- '0' or '1' depends if low or high active.... reset all signals hereelsif clk'event and clk = '1' then -- this is for rising edge triggered process use "clk = '0'" for falling edge, might be usefull sometime but only special cases... do your stuff hereend if;end process p_process_nameThe process name is not needed, but makes code better readable, after process the signals in brackets are the signalls where the process is sensitive on (your process is not sensitive to any signal)variables ... sholdnt be used too much, you wont see them in simulation AND these are updated instant not like signals on the next clock edge, which confuses (specially beginners).index ... count allways down and compare to zero, this uses much less resources (ok, for this not important, but using this many times on small devices and you might see what i mean)LED(index) ... you count the index up to 15? but your LED array has only 6 entries? this sould give a big warning. You dont know what this realy does in the end. Simulation might look good, but the implementation is sometimes totaly random, but with 6 i see a big problem and specially the values 7 will be random, the values 8 to 15 might repeat starting with 0. The index range is not reduced to the needed range.I am not digging deeper as i would just rewrite the code and i am pretty sure that the problem is on the implementation, either the clock rate is a problem, but 50 MHz is not that much or altera does not like the coding style. (xilinx and altery use different synthesis programms for implementation).First thing to check would be the pinout of the implementation, the "serial" output might not be shown at all.