FlyingBlindOnARocketCycle

Members
  • Content count

    38
  • Joined

  • Last visited

About FlyingBlindOnARocketCycle

  • Rank
    Frequent Visitor

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. FlyingBlindOnARocketCycle

    Walking a 1 through a vector, which logic is better?

    To control the 4 digit seven segment LED's on the Basys3 I need to mux the data by controlling the anode signal. I made a counter: (possibly a terrible resource hungry counter) seg_mux_clk: process(clk_240)--cycle through the 4 sev seg displays begin if rising_edge(clk_240) then cnt <= (cnt + 1)mod 4; end if; end process; next I have my one hot logic which I have recently decided to change. I have nothing to back this up but I suspect that the FPGA can more easily handle shifting a bit than it could handle multiplying a number. Believing the shift requires less logic also makes me think its overall better for timing. What you do you guys think? old version: an_i <= not std_logic_vector(to_unsigned(2 ** cnt,an_i'length)); New version: an_i <= not std_logic_vector(shift_left(to_unsigned(1,an_i'length) ,cnt)); PS if you are wondering why I don't just have a process that uses cnt as an unsigned, set cnt to 1 and mulitply it by 2 each clock cycle (1,2,4,8,1,2,4,8,....) , its because my displayed data is an array. This keeps my data and the proper seven segment in sync. seven_seg_out_reg: process(clk_240) begin if rising_edge (clk_240) then seg <= display(cnt); an <= an_i; end if; end process;
  2. FlyingBlindOnARocketCycle

    Behavioral simulation ignores integer ranges.

    Hamster for the win! .... again! When I picked range 0 to 7 for my little test, I did so because I believed the tools would set a binary digit limit that is required for the range. A 0 to 7 range would set a "roll over" but now I see your suggestion of a range 0 to 5 would have also verified the performance of a 0 to 7 output and with more clarity what the tools are doing. Like you pointed out nothing will enforce the range, but a range of some sort will get enforced by the binary digit limit, dictated by the range. You would think that sort of check would be on by default in simulation. Your answer was very educational. Thanks.
  3. FlyingBlindOnARocketCycle

    Behavioral simulation ignores integer ranges.

    on a simple design that adds or subtracts button presses on a basys3, I have the counter signal set as an integer from 0 to 7. When implementing this design it performs as expected. When counting up or down the 7 segment display goes from 7 back to 0 or from 0 to 7 when exceeding the integer range of the counter. When running this design in the behavioral simulation, the range is ignored. Counting from 0 to (-1) does not show a value of 7 but that of a 32 bit vector of all 1's. (negative 1) Thoughts?
  4. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    Notarobot: I don't understand why you say this is a latch? Is it because the logic would not allow for the detection of a button that was being held down vs pressed and released? I have the one time event because I only want to register a single event per button press. For what its worth, this one-shot debounce hdl was provided by the Vivado 2017.4 language template library. I've been told that I should not trust the language template as a source. I find that disappointing. Maybe Xilinx should stop including it if its not good code. xc6lx45: Is there a rule of thumb on how clock cycles should be observed to eliminate debounce? If there is, would it need to be a function of the clock rate? Assuming some kind of normalized average for button (type, quality, construction,...) it would seem that the faster the clock the worse the potential for false hits on the button. I wonder if I should drop this debounce topic to leave the thread focused on process sensitivity....
  5. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    Thats interesting that you got the timing loop error. I have also seen that before and failed to create a bit stream. I wonder why hamster and I have been able to get this to build? Do you have any kind of one-shot debounce on your button input? I am using a 5 bit version of the Vivado template below for all 5 buttons on the Basys3. Do you think that might appease Vivado's timing loop fury down to a mild discontent? -- Provides a one-shot pulse from a non-clock input, with reset --**Insert the following between the 'architecture' and ---'begin' keywords** signal Q1, Q2, Q3 : std_logic; --**Insert the following after the 'begin' keyword** process(<clock>) begin if (<clock>'event and <clock> = '1') then if (<reset> = '1') then Q1 <= '0'; Q2 <= '0'; Q3 <= '0'; else Q1 <= D_IN; Q2 <= Q1; Q3 <= Q2; end if; end if; end process; Q_OUT <= Q1 and Q2 and (not Q3);
  6. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    This has inspired me to attempt some changes to a division module I made. The module takes two std_logic_vector inputs, and provides the quotient and remainder. The catch is, the results will take a set number of clock cycles (input vector width + 2 ) before being available. I am thinking that I could possibly change some things around so my inputs are registered into the module, have the division "free running" and after completion register the output and a ready bit to get back to synchronous. The process would no longer be deterministic but it should be complete faster than (the bitwidth of the input +2) x clock rate. Probably much faster.
  7. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    That's interesting Hamster. Does Zygot's posted error message about the combinatorial loop point out that up_test is getting added into the sensitivity list by the Xilinx IDE? When it says "The cells in the loop are: JA_OBUF[0]_inst_i_7" the only loop that I see possible is the fact that JA is driven by up_test. Does the error message actually point out that up_test is added to sensitivity list of the count button process like you suggest? Also I find it super interesting that the message suggests that "If the loop is known and understood, this DRC can be bypassed by.." Does that indicate that, if you know what you are doing and WANT the FPGA to do something at the speed of (whatever the logic can support), then the Xilinx tools will allow you to do that? Yes it would be asynchronous but fast.
  8. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    It turns out the code I posted above wants the When others => case utilized. process(clk) begin if rising_edge(clk) then cnt <= next_cnt; button <= next_button; end if; end process; process(button, cnt) begin case button is when "00010" => --up next_cnt <= cnt + 1; when "00100" => --down next_cnt <= cnt - 1; when "00001" => --center next_cnt <= TO_UNSIGNED(0,8); when others => end case; end process; If I add next_cnt <= cnt; to the otheres case, this works as expected. I guess that makes sense but I thought that next_cnt would retain its value if nothing else was writing to it. I bet if this case process was a clocked process, next_cnt would indeed register a value. I wonder what it driving next_cnt low when its not being driving by a clocked in value?
  9. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    Maybe Hamster is still watching.... What about this? My counter "cnt" returns to 0 after 1 clock. I don't see why. What Im trying to do here is easily accomplished with a clocked process but I want to understand why this doesn't work. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity FSM_ila_test_top is Port ( clk : in STD_LOGIC; btn : in STD_LOGIC_VECTOR (4 downto 0) ); end FSM_ila_test_top; architecture Behavioral of FSM_ila_test_top is signal button : std_logic_vector(4 downto 0); signal next_button : std_logic_vector(4 downto 0); signal cnt : unsigned(7 downto 0) := "00000000"; signal next_cnt : unsigned(7 downto 0) := "00000000"; signal cnt_delay : unsigned(7 downto 0) := "00000000"; signal Q1, Q2, Q3 : STD_LOGIC_VECTOR(4 downto 0) := "00000"; COMPONENT button_ila PORT ( clk : IN STD_LOGIC; probe0 : IN STD_LOGIC_VECTOR(4 DOWNTO 0); probe1 : IN STD_LOGIC_VECTOR(4 DOWNTO 0); probe2 : IN STD_LOGIC_VECTOR(7 DOWNTO 0); probe3 : IN STD_LOGIC_VECTOR(7 DOWNTO 0) ); END COMPONENT ; begin process(clk) begin if rising_edge(clk) then Q1 <= btn; Q2 <= Q1; Q3 <= Q2; end if; end process; next_button <= Q1 and Q2 and (not Q3); process(clk) begin if rising_edge(clk) then cnt <= next_cnt; button <= next_button; end if; end process; process(button, cnt) begin case button is when "00010" => --up next_cnt <= cnt + 1; when "00100" => --down next_cnt <= cnt - 1; when "00001" => --center next_cnt <= TO_UNSIGNED(0,8); when others => end case; end process; button_press : button_ila PORT MAP ( clk => clk, probe0 => next_button, probe1 => button, probe2 => std_logic_vector(next_cnt), probe3 => std_logic_vector(cnt) ); end Behavioral;
  10. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    @xc6lx45 That's a very good suggestion. Master a format and reduce surprises in behavior. I believe I will add that concept to my tool box and years from now, take credit for the idea like it was mine.
  11. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    @hamster Hamster you are a true credit to this forum. Thank you so much.
  12. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    No worries guys. When I said FSM that's what I meant to say. I'm not implying that the example in this thread is representing a FSM. I do admit that I always thought of combinatorial logic to be logic that is used outside of a process and from the statements made here, that may not always be the case? I have personally never used a sensitivity list for anything other than a FSM, preferring all processes to be rising edge clocked. But again, I have very limited experience. Thanks again
  13. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    WHAAAAA!!! I didn't realize that Vivado was adding the signal to the sensitivity list for me. That explains everything. I'm not insane after all... just naive. I always understood why inputs to a FSM needed to be in the sensitivity list but thought I could get away with things like the code in this discussion. I think I need to find some in depth tutorials on FSM's Thanks so much for the help
  14. FlyingBlindOnARocketCycle

    Why is my Process getting triggered with no change to the sensitivity

    First of all, thank you all for time and help. Indeed this HDL performs as I expect in simulation yet the signal runs away when implemented on the chip. Please note that this design serves the sole purpose of proving a point to me so I could know for sure that I designed a bad process. The fact that I would experience switch bounce and other issues was ignored in an attempt to trim this problem example down to the least possible parts. I would like to understand all the advice I've received on this thread. So going in order... @hamster Yes sir you and zygot are correct in stating that I get warnings. I get several warnings in synthesis, NO warnings or errors in Implementation, and 2 DRC warnings. All "regular" warnings I get are understood signal 'up_test' is read in the process but is not in the sensitivity list , numerous warnings about driving a port with a constant (driving led's off as I'm not using them) What I don't know how to interpret is the Critical warning from synthesis. Vivado says it found a timing loop and points to the entity btn_test declaration as the location of there error. There are also a lot of errors in the out of context module run for the ila which I have no idea what to do with. The 2 DRC are I have are, no CFGBVS value set, and the others are to do with the ila. I agree with zygot's statement that a clocked process would work around my issues here, I had actually done that and seen it work before posting my question but, as you mentioned, the process shouldn't get triggered when btn never changes and I want understand why this bad process is bad rather than continue in my ignorance. I don't understand what you mean by Also, btn is a std_logic_vector(4 downto 0) how would a rising_edge(btn) work? At the end of the day my major concern is my inability to build a finite state machine because the simple concept of a sensitivity list appears to be over my head. I still don't comprehend why the process is triggering.
  15. I have built a very simple test case, built for a Basys3, in an effort to isolate my mental error. In the VHDL below I am expecting that the process(btn) will only be triggered when the input "btn" changes. The ila I have in place shows that the process is running continuously. Well at least that is what I think it is showing me. The ila shows "btn" signal remains at zero while the up_test is increasing at a rate that appears to be free running. I must have some horrible misunderstanding about the behavior of a process with respect to its sensitivity list. Please set me straight. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use ieee.numeric_std.all; entity btn_test is Port ( clk_100M : in STD_LOGIC; btn : in STD_LOGIC_VECTOR (4 downto 0); led : out STD_LOGIC_VECTOR (15 downto 0); seg : out STD_LOGIC_VECTOR (6 downto 0); an : out STD_LOGIC_VECTOR (3 downto 0); dp : out STD_LOGIC ); end btn_test; architecture Behavioral of btn_test is signal up_test : natural := 0; signal up_test_i : std_logic_vector (31 downto 0); COMPONENT ila_0 PORT ( clk : IN STD_LOGIC; probe0 : IN STD_LOGIC_VECTOR(31 DOWNTO 0); probe1 : IN STD_LOGIC_VECTOR(4 DOWNTO 0) ); END COMPONENT ; begin up_test_i <= std_logic_vector(to_unsigned(up_test,32)); up_test_ila : ila_0 PORT MAP ( clk => clk_100M, probe0 => up_test_i, probe1 => btn ); count_button_process_triggers: process(btn) begin up_test <= up_test +1; end process; led <= (others => '0'); seg <= (others => '0'); an <= (others => '1'); dp <= '0'; end Behavioral;