• Content count

  • Joined

  • Last visited

  • Days Won


hamster last won the day on May 23

hamster had the most liked content!

About hamster

  • Rank
    Overly helpful
  • Birthday 08/23/1969

Contact Methods

  • Website URL

Profile Information

  • Gender
  • Location
    New Zealand
  • Interests
    Electronics, FPGAs, MtBiking, Road Cycling, Linux....

Recent Profile Visitors

4371 profile views
  1. hamster

    Problem simulating ISERDESE2

    Humm.... DATA_P and DATA_N are not mirrors of each other. You might also need to delay DATA_P and DATA_N with respect to the clock signal, so it samples in the middle of the bit.
  2. hamster

    Vivado - How to reflash HDL code quickly

    I know it sounds stupid,. But sorry, that is how long it takes. There is no short cut. For example, global optimization may cause logic to get 'thrown away', and that would need to get inserted back into the design somehow.
  3. hamster

    Basys3 & Pmods as XADC

    The pins have no ability to perform ADC - they are dedicated digital I/O. You could however get an ADC PMOD module, plug that in, and use that.
  4. hamster

    Theory of pipelining/paralellism

    I think it is best to view it as a car assembly line. The quickest way to assemble a car is for each team to do their step one after each other - a car will take the combined time of all operations, but you are only building one car at a time. Fine if you a build a single Mclaren F1 race car. The quickest way to assemble lots of cars is a production line. Each team does their step, and then the car moves on to the next team for the next process. Making the first car takes (number of steps) * (length of longest step). But once you have your first car you get another car every (length of longest step). But what if mounting a motor takes five minutes, and the next longest operation takes only three minutes? You can only make one car every five minutes, and the rest of the teams are idle for at least 40% of the time. The solution might be to split mounting the engine into two steps, each taking up to three minutes. Then you can make a car every three minutes. In FPGA-speak, this is pipelining to get the highest clock speed. Big gains are easy at first, but then it gets harder and harder to get any faster, as more parts of the design become critical to the timing of the overall pipeline. The other solution might be to combine pairs of the three minute steps so no step takes longer than 5 minutes. That way you only need half the resources, yet can still produce a car every five minutes... this is the "once you meet your FPGA's timing constraints, then re-balancing the pipeline can save you resources" strategy.
  5. hamster

    reset signal in rgb2dvi IP

    Oh, sorry - I forgot to answer. 2) This is a post-implementation view. So any optimizations that could be made have been made. I am guessing (and this is only guessing) that during the optimization thnigs have been pushed around. Are you displaying a full range of colours? or just a couple? The 24bit RGB seems to have been reduced to just a couple of bits. You can assign a "KEEP" attribute to the signals in the video generator block, and it should not optimize them away.
  6. hamster

    reset signal in rgb2dvi IP

    1) it is easier to explain why this is. An internal PLL had to lock on to the pixel clock. If it fails to lock (because the clock is out of range when it attempted to lock) or it becomes unlocked (e.g. the clock stops or changes frequency) it needs to be reset so it can start liocking back onto the now stable input clock again. I willwill answer (2) when I am not on my phone :-)
  7. hamster

    Vivado is bugged up the *** per usual (no, my bad)

    I don't think you have to keep it consistent within a module. but it makes sense to. Conventions I have seen and use are: signals are always "downto". This makes numbers make sense - e.g. "00110000"; sig_downto <= "00110000"; assigns binary 48 sig_to <= "00110000"; assigns binary 12; Arrays are always "to". This makes initialization make sense.- the first element in the list goes into slot zero. If you do want to flip bits, this can do it for you: out_sig(0) <= in_sig(2) when rev = '1' else in_sig(0); out_sig(1) <= in_sig(1) when rev = '1' else in_sig(1); out_sig(2) <= in_sig(0) when rev = '1' else in_sig(2);
  8. hamster

    Vivado is bugged up the *** per usual (no, my bad)

    I can't see what the issue is... can you describe exactly how are you expecting this to reverse the order of the bits? If your assignment into 'reverse_order_bits' does change the order, then when you assign that into 'out_sig' then that will also reverse the order. So if the output is always the input, then 'rev' (and that means 'SW[4]') also has no effect, and can be optimized out. And if the out_sig always equals in_sig, then your design does indeed contains no logic, just three connections from input pins to output pins. All seems consistent to me. Try it with explicitly reversing the order of the bits.
  9. hamster

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

    Hi, The common way would be to use slices of the std_logic_vector: signal seg : std_logic_vector(3 downto 0) := "0001"; ... if rising_edge(clk_240) then seg <= seg(2 downto 0) & seg(3); end if or the opposite way: if rising_edge(clk_240) then seg <= seg(0) & seg(3 downto 1); end if You most likely also want a concurrent statement to assign the value to the module's output, and allow for the fact that the display are usually active low (ii.e. digits are switched on when the output is 0). seg_output <= not seg; This also helps, because if 'seg'_output is declared as being "out" in the module definition you can't read it's value to update it (yes, a little bit silly for VHDL). VHDL does have ROL, ROR, SLA and SRL operators, but nobody uses them as far as I know.
  10. hamster

    Behavioral simulation ignores integer ranges.

    I believe you can set a simulation flag to enforce range bounds checking, and it will error if you end up with an out-of-range value. It is off by default. You got it lucky with your range testing on hardware - if you had a a range from 0 to 5, it would most likely still count through 6 and 7. The synthesis tools has this sort of internal dialog: - Hum, this is an integer will be used with values between 0 and 7, as that is what the HDL tells me. - I could replace it with a UNSIGNED that can hold values between 0 and 7, as it only needs positive numbers. - To hold the numbers between 0 and 7 I only need 3 bits. - Great! I will implement this signal as a 3-bit unsigned binary value - Because this is a 3-bit value I can update it with a 3-bit adder ... I doesn't statically inspect the rest of the code to enforce that you will only use numbers in the stated range. It also doesn't put any additional logic enforce the range as stated (e.g. clamping, or wrapping of results), you have to ensure that your design stays within the stated range. For this reason I prefer to use UNSIGNED(n downto 0 ), so I know exactly what the tools will produce. I am sure others will disagree, and prefer the higher level of abstraction, and finding ranges is very useful in simulation (as long as the "range check" option is turned on!). ... diversion... An important consideration for this is when inferring memory blocks. If you define a memory block that has 768 entries, you might end up with a physical memory block that has 1024 entries, 256 of which you might not be using. Or it might be made up of three blocks with 256 entries each, and the required logic to make it work as if it is a single memory block. So why is this important? Well, if you set the write address to an invalid index of 1023 or 768 (as only 0 to 767 are valid) you might find that you corrupt entry 511 or 256 by accident. Or maybe you won't today, depending on what the synthesis tools feel like doing and the address decode logic during the last build. The tools are designed to take as many shortcuts as possible to give you exactly what you asked for, no more and no less, with most optimized use of FPGA resources. Don't be surprised if unexpected inputs give unexpected outputs
  11. hamster

    Problems when 5v dc motor with nexys4 artix7 fpga board

    With a 10k resistance only 0.26mA will be flowing from the emiiter to the base of the transistor. Depending on the current gain of the transistor (maybe 100x) that still only gives 26mA to drive the motor. Use a 330 ohm resistor and see if that helps. That should allow allow around 10mA to pass through the base, allowing the transistor to switch around 1A. Also it is good practice to have a snubber diode over the motor, to prevent it damaging your FPGA board. You may also want to use a NPN transistor, allowing the emitter to be connected to ground, rather than the positive (regulated) power rail. This would be especially helpful if the motor is to be powered by a different supply.
  12. hamster

    Problems when 5v dc motor with nexys4 artix7 fpga board

    The PMOD connector pins are not able to provide much power - at best a few mA. You will need to add something to increase the power - either a transistor or MOSFET switch, or maybe a full H-bridge driver. Also, the voltage regulators on the FPGA is only engineered to power the FPGA and a few low power add-ons. So you will need an additional external power source to drive the motor.
  13. hamster

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

    In general the tools will let you try anything. If you want to "ski off piste" the let you. They may warn strongly against it, or might even need you to stamp your feet a little with directives and settings, but you might have a valid need to do what you are asking. They also can only control what you do inside the FPGA. For example, if you had "output_pins <= std_logic_vector(unsigned(input_pins)+1);" and wire your outputs and inputs together you will get exactly what you have inside the chip (but a little slower). If you work with software you should all be used to this. Take this small C program: $ cat div.c #include <stdlib.h> int main(int argv, char *argc[]) { return atoi(argc[1])/0; } $ gcc -o div div.c -Wall -pedantic -O4 div.c: In function ‘main’: div.c:3:23: warning: division by zero [-Wdiv-by-zero] return atoi(argc[1])/0; ^ $ ./div 123 Floating point exception (core dumped) $ Should divide by a constant zero be a critical error? How is the compiler supposed to know if you are really doing this by accident, or are writing a program to test the behavior of divide by zero? Part of the learning curve for FPGAs is to develop a feeling for what is the "safe area" to work in, and recognize when you are leaving wandering outside of it. It is a shame that in this case you stumbled into this by accident, but you get big bonus points from me for realizing that you were in a strange & weird place, and attempting to make some sense of it before moving on. (BTW, I like playing in these areas)
  14. hamster

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

    Sorry to have irritated you... Here is my example: - I used an unsigned datatype for the counter - I also had all bits used - the low 24 on the PMODS, the high 8 on the LEDs. - It was built for the Nexys2 board, using the latest version of ISE. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity btn_test is Port ( clk_100M : in STD_LOGIC; btnC : in STD_LOGIC; led : out STD_LOGIC_VECTOR( 7 downto 0); seg : out STD_LOGIC_VECTOR( 6 downto 0); an : out STD_LOGIC_VECTOR( 3 downto 0); dp : out STD_LOGIC; JA : out STD_LOGIC_VECTOR( 7 downto 0); JB : out STD_LOGIC_VECTOR( 7 downto 0); JC : out STD_LOGIC_VECTOR( 7 downto 0)); end btn_test; architecture Behavioral of btn_test is signal up_test : unsigned (31 downto 0) := (others => '0'); begin count_button_process_triggers: process(btnC) begin up_test <= up_test +1; end process; JA <= std_logic_vector(up_test( 7 DOWNTO 0)); JB <= std_logic_vector(up_test(15 DOWNTO 8)); JC <= std_logic_vector(up_test(23 DOWNTO 16)); led <= std_logic_vector(up_test(31 DOWNTO 24)); seg <= (others => '0'); an <= (others => '1'); dp <= '0'; end Behavioral; The constraints are almost the standard Nexys2 ones, so I won't include them. Although it produces a metric truckload of warning about combintatorial logic oops, it does produce a BIT file, and when programmed it does do as expected, but what it arguably shouldn't be doing. Without a change in state of btnC the counter is counting up. It cycles through all 32-bit values in about 5 seconds, so each addition is taking about 1.2ns (or is free-running at about 800 MHz, if you like). Or maybe it doesn't - maybe it skips some values and the lowest bits are not counting properly. But it looks as if it counts, without a clock or an event on btnC signal.
  15. hamster

    Ring oscillator with 5 Schmitt-Trigger in a loop

    I have actually done this, and the speed only partially depends on the device parameters, the biggest being propergation delay. Moving from a breadboard to hard-wired made dramatic changes in frequency (20%+) due to inductance and capacitance. Extra decoupling (which enhanced switching speed) also changed things. Supply voltage also made a big difference too.