Author Topic: altera cyclone problem in harware  (Read 245 times)

0 Members and 1 Guest are viewing this topic.

Offline electros6

  • Regular Contributor
  • *
  • Posts: 101
altera cyclone problem in harware
« on: December 04, 2017, 11:11:50 PM »
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 scope
 
          library 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 only
      serial : 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 changes
   constant T1H : integer := 35;
   constant T1L : integer := 28; -- compensate for state changes
   constant 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);

begin
   process
      variable 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 Blue
                                 x"00FF00", -- LED 1
                                 x"0000FF", -- LED 2
                                 x"FFFFFF", -- LED 3
                                 x"330000", -- LED 4
                                 x"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 15

   begin
      wait until rising_edge(clk);
   --   data <= GRB; -- temporary testing only
   
      case state is
          when load =>
                  GRB := LED(index);
                  bit_counter := 24;
                  state := sending;
         when sending =>
               if (bit_counter > 0) then
                  bit_counter := bit_counter - 1;
                  if GRB(bit_counter) = '1' then
                     delay_high_counter := T1H;
                     delay_low_counter := T1L;
                  else
                     delay_high_counter := T0H;
                     delay_low_counter := T0L;
                  end if;
                  state := send_bit;
               else
                  if (index < 15) then
                     index := index + 1;
                     state := load;
                  else
                     delay_low_counter := RES;
                     state := reset;
                  end if;
               end if;
         when send_bit =>
               if (delay_high_counter > 0) then
                  serial <= '1';
                  delay_high_counter := delay_high_counter - 1;
               elsif (delay_low_counter > 0) then
                     serial <= '0';
                     delay_low_counter := delay_low_counter - 1;
               else
                  state := sending;
               end if;
         when reset =>
               if (delay_low_counter > 0) then
                  serial <= '0';
                  delay_low_counter := delay_low_counter - 1;
               else
                  index := 0;
                  --state := possibly load new data for next cycle
               end if;
         when others => null;
      end case;
   end process;
end arch;
 

Offline Scrts

  • Frequent Contributor
  • **
  • Posts: 506
  • Country: lt
Re: altera cyclone problem in harware
« Reply #1 on: December 05, 2017, 03:17:03 AM »
1. Check your clock input.
2. Use SignalTap.
 

Offline Sparker

  • Contributor
  • Posts: 7
  • Country: ru
Re: altera cyclone problem in harware
« Reply #2 on: December 06, 2017, 10:48:48 AM »
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.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 1269
  • Country: nz
Re: altera cyclone problem in harware
« Reply #3 on: December 06, 2017, 05:01:21 PM »
It is always worthwhile to check the reports to see that the correct signal is associated with the desired pin and I/O settings.
 

Online tux75at

  • Contributor
  • Posts: 5
  • Country: at
Re: altera cyclone problem in harware
« Reply #4 on: December 10, 2017, 01:58:45 AM »
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 VHDL
This 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)
begin
  if (reset = '0') then   -- '0' or '1' depends if low or high active
    .... reset all signals here
  elsif 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 here
  end if;
end process p_process_name

The 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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf