hamster

Members
  • Content Count

    515
  • Joined

  • Last visited

  • Days Won

    79

Everything posted by hamster

  1. As the high speed Transceivers are not available on the Arty, your maximum per-pin bandwidth is about 1Gb/s, which will be too slow for a high speed JESD204B interface.
  2. Hi FlyingBlindOnARocketCycle, You design might be the wrong way for an efficient hardware implementation, but fixed point is definitely the best way. That way, if you are using a 100MHz clock, the math will be something like: reset_count = (100000000/n)-1; Integer division can be converted directly to hardware. An efficient hardware implementation (from a hardware resources point of view) might be a pre-calculated lookup table. If you include the 24 bits for the reset count, and 21 bits for the seven segment patterns. A 256 x 45-bit lookup table will fit in one block RAM, and will pretty much remove the need for any complex logic. Oh, and make sure that your counter counts down, rather than up. if counter = 0 then counter <= reset_count_table(to_integer(unsigned(freqency_index))); -- then do the stuff you want to do every so many cycles. else counter <= counter-1; end if; If you count up, it is very easy for errors to creep in, giving runt pulses, long gaps or other odd behavior.
  3. hamster

    Arty: Output Frequency

    The high speed PMODs can go very fast, but you have to work the way high speed signals work, taking great care. That may mean differential signalling, correct termination and careful PCB layout. I have been able to get 500Mb/s to work, but that also included a good bit of luck. With single ended signalling you will have very poor results.
  4. Hi! From the data sheet,OSERDES supports LVDS data rates at up to 1250Gb/s (grades -2 & -3). (Table 15 of http://www.xilinx.com/support/documentation/data_sheets/ds181_Artix_7_Data_Sheet.pdf). However, I can confirm that at least my board Nexys Video works fine at 1.475 Gb/s, with a few timing warnings on the IO clocking networks.
  5. I have had the same behaviour on a very full design. I put it down to drawing too much power from the power supplies causing the FPGA to reset. Not sure if this is 100% what is going on, but a smaller design worked fine.
  6. hamster

    PLL Clocks on Arty

    Oh, and to go along with Dan's answer... The more recent versions of Vivado seem to have become much more picky about the use of clock buffers, throwing errors if you don't include them. Here's one example of using global clock buffers: library IEEE; use IEEE.STD_LOGIC_1164.ALL; library UNISIM; use UNISIM.VComponents.all; entity clocking is Port ( clk100MHz : in STD_LOGIC; clk125MHz : out STD_LOGIC; clk125MHz90 : out STD_LOGIC); end clocking; architecture Behavioral of clocking is signal clk100MHz_buffered : std_logic := '0'; signal clkfb : std_logic := '0'; signal clk125MHz_unbuffered : STD_LOGIC; signal clk125MHz90_unbuffered : STD_LOGIC; begin bufg_100: BUFG port map ( i => clk100MHz, o => clk100MHz_buffered ); ------------------------------------------------------- -- Generate a 125MHz clock from the 100MHz -- system clock ------------------------------------------------------- pll_clocking : PLLE2_BASE generic map ( BANDWIDTH => "OPTIMIZED", CLKFBOUT_MULT => 10, CLKFBOUT_PHASE => 0.0, CLKIN1_PERIOD => 10.0, -- CLKOUT0_DIVIDE - CLKOUT5_DIVIDE: Divide amount for each CLKOUT (1-128) CLKOUT0_DIVIDE => 8, CLKOUT1_DIVIDE => 20, CLKOUT2_DIVIDE => 40, CLKOUT3_DIVIDE => 8, CLKOUT4_DIVIDE => 16, CLKOUT5_DIVIDE => 16, -- CLKOUT0_DUTY_CYCLE - CLKOUT5_DUTY_CYCLE: Duty cycle for each CLKOUT (0.001-0.999). CLKOUT0_DUTY_CYCLE => 0.5, CLKOUT1_DUTY_CYCLE => 0.5, CLKOUT2_DUTY_CYCLE => 0.5, CLKOUT3_DUTY_CYCLE => 0.5, CLKOUT4_DUTY_CYCLE => 0.5, CLKOUT5_DUTY_CYCLE => 0.5, -- CLKOUT0_PHASE - CLKOUT5_PHASE: Phase offset for each CLKOUT (-360.000-360.000). CLKOUT0_PHASE => 0.0, CLKOUT1_PHASE => 0.0, CLKOUT2_PHASE => 0.0, CLKOUT3_PHASE => -270.0, CLKOUT4_PHASE => 0.0, CLKOUT5_PHASE => 0.0, DIVCLK_DIVIDE => 1, REF_JITTER1 => 0.0, STARTUP_WAIT => "FALSE" ) port map ( CLKIN1 => CLK100MHz_buffered, CLKOUT0 => CLK125MHz_unbuffered, CLKOUT1 => open, CLKOUT2 => open, CLKOUT3 => CLK125MHz90_unbuffered, CLKOUT4 => open, CLKOUT5 => open, LOCKED => open, PWRDWN => '0', RST => '0', CLKFBOUT => clkfb, CLKFBIN => clkfb ); bufg_125Mhz: BUFG port map ( i => clk125MHz_unbuffered, o => clk125MHz ); bufg_125Mhz90: BUFG port map ( i => clk125MHz90_unbuffered, o => clk125MHz90 ); end Behavioral;
  7. It is called 'CPU affinity' - Google that and you should get an answer (or use 'man taskset' IIRC)
  8. If you were to use the Xilinx licensed HDMI IP block this would be possible, and there are a few projects out on the web that include sound in their non-IP based HDMI implementation (e.g. https://github.com/charcole/NeoGeoHDMI)
  9. Hi, In the HDMI specs the minimum resolution of 640x480 @ 60Hz, which has a pixel clock frequency is of about 25MHz (25.175 MHz IIRC) - see http://www.microprocessor.org/HDMISpecification13a.pdf If your pixel clock is lower than this you will have to add a scan-line doubler, and send each pixel twice (to make each pixel into a 2x2 square).
  10. I've been beavering away on a large project, but ended up thinking about how small a Serial TX module could be. While out splitting firewood stumbled over the idea that takes it down top 12 LUTs and 11 flip-flops library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity tiny_rs232_tx is Port ( clk : in STD_LOGIC; bit_tick : in STD_LOGIC; data : in STD_LOGIC_VECTOR(7 downto 0); data_enable : in STD_LOGIC; tx : out STD_LOGIC := '1'; busy : out STD_LOGIC ); end tiny_rs232_tx; architecture Behavioral of tiny_rs232_tx is signal shift_reg : std_logic_vector(9 downto 0) := (others => '1'); signal i_busy : std_logic; begin busy <= i_busy; with shift_reg select i_busy <= '0' when "0000000000", '1' when others; clk_proc: process(clk) begin if rising_edge(clk) then if i_busy = '0' and data_enable = '1' then shift_reg <= '1' & data & '0'; end if; if bit_tick = '1' then if i_busy = '1' then tx <= shift_reg(0); shift_reg <= '0' & shift_reg(9 downto 1); end if; end if; end if; end process; end Behavioral;
  11. hamster

    Connect HDMI to ZedBoard

    Hi Rohit, That project was indeed done in ISE (as it supports Zynq). If you send me a few personal messages (or email) I could most likely help you out. Mike
  12. Oh, one thing to be careful of is that I2S samples are signed, so don't test with alternating between 0x0000 and 0xFFFF (0 and -1) as it will be very quiet, 0xC000 and 0x4000 are a better option for first tests. These values do however these values make perfect test values for verifying the alignment of the data vs the LR clock And why we are on the subject, I2S comes with a few different options for the alignment of the first bit of the same to the edge of the LR clock, and the justification of the samples within the frame (e.g. does the padding proceed or follow the sample values). I've got something that generates a valid I2S stream here: http://hamsterworks.co.nz/mediawiki/index.php/PMODamp3 - you might want to simulate it and see if it matches your implementation.
  13. I tried really hard to avoid coding it for you, but here is code that has the spirit of what you need to do. I haven't tried to compile or debug it, but it should provide a framework that will guide you.... ... the headers and top of the module.... SIGNAL COUNT : INTEGER:=0; SIGNAL I : integer range 0 to 2000; BEGIN -------------------------------------------------------------------------------------- -- I am pretty sure that this will divide the clock by four -------------------------------------------------------------------------------------- PROCESS(CLK, RESET) BEGIN IF RESET='1' THEN COUNT<=0; TEMP<='0'; ELSIF RISING_EDGE(CLOCK_50) THEN COUNT<=COUNT+1; IF COUNT=1 THEN TEMP<=NOT TEMP; COUNT<=0; END IF; END IF; CLK_OUT<=TEMP; END PROCESS; PROCESS(CLK,RESET) BEGIN IF RESET='1' THEN I <=0; ELSIF RISING_EDGE(CLOCK_50) THEN IF I < 5 THEN IF(KEY(0)='1' AND TX_BUSY='0') THEN TX_DATA<=SW(7 DOWNTO 0); TX_START<='1'; I <= I+1; ELSE TX_START<='0'; END IF; END IF; END IF; END PROCESS; ... the rest of the code....
  14. In most cases a loop can not be mapped to digital logic, so it can not be implemented within an FPGA. For most designs the looping is implicit in the event that triggers a process to be invoked (e.g. the ticking of a clock signal). Try rewriting it to avoid loops completely. ...
  15. Hi Adam, The schematics for the Basys3 are at https://reference.digilentinc.com/_media/basys3:basys3_sch.pdf - have a look at IC7E on page 6. But to answer you questions directly: 1) No - none of the Transceivers are exposed on the PMOD connectors. 2) Clock capable pins are exposed on PMOD JC. However, if you were able to use the transceivers I'm pretty sure you would want to be using one of the MGTREFCLK pins. It is not recommended to clock transceivers from the FPGA's clocking networks (so much so that you can't do it with the IP generator). As far as I can tel, if you want to use the high speed transceivers, then you will be looking for an board with an FMC connector, as the PMOD connectors are not designed for very high speed signals.
  16. 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...
  17. 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.
  18. 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.
  19. 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.
  20. 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
  21. 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
  22. 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)
  23. 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.
  24. 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)
  25. 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.