• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by hamster

  1. I case you haven't heard it already check out an interview with Clint Cole (one of Digilent's founders) on The Amp Hour. http://www.theamphour.com/302-an-interview-with-clint-cole-of-digilent/ The company history sounds very different than I imagined it was...
  2. Hi, Your problem is that you can (in general) only have one test for a clock signal in a process. You are after a structure more like: process(reset, your_clock) begin if reset = '1' then loop_counter <= to_unsigned(0,10); elsif rising_edge(your_clock) then if loop_counter < to_unsigned(999,10) then .... do something once... loop_counter <= loop_counter+1; else .... what to do once finished ... end if; end if; end process That will result in something happening 1000 times, each time reset signal is released.
  3. On second glance you are setting INDEX back to zero, just not where I expected in the "IF (TX_FLG='0' AND START = '1') THEN" block.
  4. Hi, I think I see your problem.... do you ever set INDEX back to zero? It might be easier initially to send additional 1 bits after the data to simplify things.... e.g. 0,a,b,c,d,e,f,g,h,1 and then 22 '1's (where the letters are your data bitsfrom the switches), and just repeat that over and over. Just have INDEX counting from 0 to 31, You can then enhance that only send when the key is pushed (e.g not rolling from 31 back to 0 unless KEY='1', and then speed it up by sending fewer extra bits, until you are running at full speed.
  5. Hi, If that is a RGMII, that pin should be an output not an input. The best reference I have found for RGMII is http://www.hp.com/rnd/pdfs/RGMIIv1_3.pdf Rather than muck about (or maybe more accurately "rather than actually learn") how output delays work, for my design, I generate it using a DDR register that is fed with a clock that is at 90 degrees to the main design's clock. Some PHYs have the option to introduce a skew into the transmit clock,, and some designs achieve this though using a longer trace length for the clock line (this seems a bit dumb to me, but if needs must). Mike
  6. Hi Iwan! That is a far better video than I can make with my cell phone. Hope you don't mind if I share it on Twitter. @Dan - yes, every pixel is calculated on the fly, requiring 255 complex FMACs per pixel,and some other stuff (or about 192,000,000,000 operations per second). Mike
  7. You want to use TMDS_33 - for example: set_property -dict { PACKAGE_PIN Y1 IOSTANDARD TMDS_33 } [get_ports { hdmi_tx_n[0] }]; set_property -dict { PACKAGE_PIN W1 IOSTANDARD TMDS_33 } [get_ports { hdmi_tx_p[0] }]; set_property -dict { PACKAGE_PIN AB1 IOSTANDARD TMDS_33 } [get_ports { hdmi_tx_n[1] }]; set_property -dict { PACKAGE_PIN AA1 IOSTANDARD TMDS_33 } [get_ports { hdmi_tx_p[1] }]; set_property -dict { PACKAGE_PIN AB2 IOSTANDARD TMDS_33 } [get_ports { hdmi_tx_n[2] }]; set_property -dict { PACKAGE_PIN AB3 IOSTANDARD TMDS_33 } [get_ports { hdmi_tx_p[2] }]; (this is from an Artix 7 project for the Nexys Video, so you will have different pin locations - but you get the gist - it is TMDS_33)
  8. If I get a chance I'll simulate it this weekend.... but chances are that it is the mismatch of the DAC output impedance and the speaker impedance. The speaker is 4 ohm, and the DAC is for driving 10k ohm loads. Have you got some powered speakers you can test with? For an un-amplifed speaker you might want to use PMOD-AMP3 ( http://store.digilentinc.com/pmodamp3-stereo-power-amplifier ) which is also I2S. As it is a bridged class-D amplifier you can't connect a PMOD-AMP3 to an external power amp but it is ideally suited to to the 4 ohm speaker. Also, sending the clock directly to a pin isn't best practices (but should work for this application). Have a look for "clock forwarding" in http://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf at around page 128.
  9. Have you explored using the FMC connector? I had a look at the .xdc file and it seems to have at least 66 IP pins... It would need a custom PCB however (unless somebody makes an FMC adapter board)
  10. Following on from playing with Arty's 10/100 Ethernet Interface, I've got a Gigabit PHY working over the RGMII interface. It is really rough, as it doesn't yet handle the slower speeds correctly, but it is able to send 979 Mb/s to my laptop (not that my Laptop can keep up with it! http://hamsterworks.co.nz/mediawiki/index.php/GigabitTX Hopefully it will be of help to somebody who wants to get a lot of data off of their FPGA board without having the overhead of a CPU and full TCP/IP stack.
  11. hamster

    3 bit output

    Hi, Also, rather than assigning "---" or "XXX" when an unknown switch setting is selected, why not just assign a constant value. Assigning "don't care" or "unknown" all seems a bit none-deterministic me, and open to simulation/implementation mismatches - and those sort of bugs really hurt when they bite. Mike
  12. I've now added the checksum calculations, and going "full noise" it sends 130,000 packets per second
  13. hamster


    Hi again, I just tried this out on an Basys3 - (Artix7-35 grade 1C) and it meets timing just - 0.008 ns slack at 3.3ns clock. The limiting thing was the length of the carry chain in the 20-bit adder. That can be broken into two shorter adders, that run faster. However, it is pretty hard to do it without getting bugs - hopefully I've got it right here: library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity Generic_PWM_x1 is port( clk: in std_logic; pwm_var: in std_logic_vector(19 downto 0); pwm_out: out std_logic ); end Generic_PWM_x1; architecture Behavioral of Generic_PWM_x1 is signal counter : unsigned(19 downto 0):= (others=>'0'); signal pwm_latch : unsigned(19 downto 0):= (others=>'0'); constant max_counter: unsigned(19 downto 0):= (others=>'1'); signal carry_next : std_logic := '0'; begin process(clk) begin if rising_edge(clk) then ------------------------------------------- -- Drop the output when the counter = PWM level -- Enable the output when count is zero -- Note the special ordering to ensure always off when pwm_var = 0 -- Use only absolute comparisons so no math is involved. ------------------------------------------- if counter = pwm_latch then pwm_out<='0'; elsif counter = 0 then pwm_out<='1'; end if; ------------------------------------------- -- Update the counter, but splitting the carry chain -- into an 11-bit and 9-bit adder ---------------------------------------------------- if counter=max_counter then counter <=(others=>'0'); carry_next <= '0'; pwm_latch <= unsigned(pwm_var); else counter(10 downto 0) <= counter(10 downto 0)+1; if carry_next = '1' then counter(19 downto 11) <= counter(19 downto 11) + 1; end if; if counter(10 downto 0) = "11111111110" then carry_next <= '1'; else carry_next <= '0'; end if; end if; end if; end process; end Behavioral; That just meets timing at 333 MHz (3.0 ns).
  14. hamster


    What have you constrained the clock to? The more it is constrained the harder the tools will work to give you a faster design. What timing are you getting? Sorry about the missing 'then' in the code above too!
  15. hamster


    Oh, the other option is to use a DDR output, and generate two output bits per cycle, allowing a 150 MHz design can generate 300 Mb/s. This is a pretty generic technique - using the serializers you can generate about 1Gb/s running the design on a 125 MHz clock!
  16. hamster


    Hi, This might give you some ideas, it should be about the fastest you can achieve.. begin if rising_edge(clk) then ------------------------------------------- -- Drop the output when the conter = PWM level -- Enable the output when count is zero -- Note the special ordering to ensure always off when pwm_var = 0 -- Use only absolute comparisons so no math is involved. ------------------------------------------- if counter = pwm_var then pwm_out<='0'; elsif counter = 0 pwm_out<='1'; end if; ------------------------------------------- -- Update the counter ------------------------------------------- if counter=max_counter then counter<=(others=>'0'); else counter <= std_logic_vector( unsigned(counter) + 1 ); end if; end if; end process; In general, if you want to generate an 'always on' output when pwm_var is all ones, then max_counter = has to be initialized to "(0=>'0', others => '1')" .e.g. "11111110" for an 8-bit counter. Oh, and things can go wrong if pwm_var is changed at the wrong time - best of to latch it into a local signal at the same time that max_counter is reset back to zeros.
  17. Hi, I've got my Arty sending out UDP packets to my laptop, without any soft CPU involvement. I've still got to add checksums and so on, but at least it works! http://hamsterworks.co.nz/mediawiki/index.php/ArtyEthernet
  18. Hi! That sounds really odd - if it was broken I would expect something other than almost 3V exactly What test point / pin are you measuring on? Do you have anything connected to the board? I'll measure it on my Arty at home....
  19. Hi! The problem is this: ERROR: [DRC 23-20] Rule violation (UCIO-1) Unconstrained Logical Port - 1 out of 5 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined. To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: CLK. You have not defined which pin the CLK signal is being supplied on. If you add that to your .constraints ("xdc") file you should have more luck. Mike
  20. hamster

    verilog UART

    Hi SAYALI, The warning is there for exactly the reason they state: The code assigns a value to these signals, but the values they hold are never used. The fix would be to decide if they really are needed at all, and if not then remove the two signals (and all assignments to them). Mike
  21. Hi Manu, Without the code I can't offer any advice apart from maybe you should copy the serial port output to a pin on a PMOD and look at it with a scope or logic analyser. That way you can at least be sure that the input to your logic is correct or not. However, it is more than likely some subtle timing issue going on. If you are really stuck, post your code and I'll have a look at it.... Mike
  22. Well, for a start, nothing in there looks to be clocked at all. Without using a clock somewhere, you can't update any internal state.
  23. Oh, and in the test bench this looks a little off: constant clock_period : time := 40 ns; --50MHz 40 ns isn't 50 MHz
  24. Hi Jaiko07 What is specification for your output that you are aiming for? It is is a 50% duty cycle, 200Hz signal then this might be a better pattern to follow for your process: countClock: process(clock,clear) begin if (clear = '1') then adjfreq <= "000000000000000000"; elsif(clock'event and clock = '1') then -- Flip a the output once every 125,000 cycles (400Hz) -- to give a 200Hz output with 50% duty cycle if (adjfreq = "011110100001001000") then adjfreq <= "000000000000000000"; adjclock <= not adjclock; else adjfreq <= adjfreq+1; end if; end if; end process; I haven't compiled it or tested it, but the intent should be clear - you are counting the cycles between the transitions, then flipping the output.
  25. Hi Shruthi, 1) check http://www.xilinx.com/support/documentation/user_guides/ug480_7Series_XADC.pdf page 60 - table 4-4. The channel numbering is a little bit odd. 2) Not sure, as XADC is only available on 7-Series FPGAs. I guess it is for future chips, and I guess it only matters for simulation. 3) If you want to only read channel 6, yes. See figure 3-1 on page 36. Mike