hamster

Members
  • Content count

    426
  • Joined

  • Last visited

  • Days Won

    71

hamster last won the day on September 25 2017

hamster had the most liked content!

About hamster

  • Rank
    Overly helpful
  • Birthday 08/23/1969

Contact Methods

  • Website URL
    http://hamsterworks.co.nz

Profile Information

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

Recent Profile Visitors

3805 profile views
  1. Issue with DVI to RGB and non integer (1.001) frame rates

    It seems easy on the surface of it, but - The different channels have different guard band values - You need to work out what blanking and sync signals you need to assert during the guard bands and data packet guard bands - The HDMI pixel data might be in "Studio level" (16-239) rather than full range (0-255) - The video data might be in YCrCb 444 rather than RGB 444 format. (The RGB 444 means that for each four pixels there are 4 R values, 4 G values and 4 B values) - The video data might be in YCrCb 422, where you have 12-bit values, and you get four Y (brghtness) but only two Cr or Cb values per for pixels. (which is more like TV video formats) I made an attempt at decoding this, and it seems to work ok. You might be able to find any hints you need at my project: https://github.com/hamsternz/Artix-7-HDMI-processing/blob/master/src/hdmi_input.vhd but the source for all knowledge is the HDMI specification - find it by searching for "hdmi specification 1.2a filetype:pdf" or "hdmi specification 1.4 filetype:pdf" - e.g. http://read.pudn.com/downloads72/doc/261979/HDMI_Specification_1.2a.pdf
  2. Issue with DVI to RGB and non integer (1.001) frame rates

    It is most likely the souce defaults to HDMI mode if it can not get the EDID data from the FPGA when it detects a cable hot-plug...
  3. Issue with DVI to RGB and non integer (1.001) frame rates

    Those extra blocks looks like HDMI data islands. The shouldn't be there on a true DVI signal. If this is so, the active lines will also have a two-byte guard band at the start too. (So 1920 pixels will be 1922 bytes with a constant two byte preamble). I and not sure that DVI2RGB is ddesigned to receive and filter RGB - guessing not from this trace.
  4. Hi, Once you get the feel for how FPGAs work, have a good look at the Vivado Synthesis Guide ( https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_1/ug901-vivado-synthesis.pdf ). It has lots of design patterns for how to describe the sorts of structures you might want to use -without reaching for the library of primitives. It covers things like memories, DSP blocks, shift registers, fifos and so on - without using the IP generator. It can be a great technique to use, as: - it does not tie your logic designs to a vendor's IP libraries & licensing - it allowing others to use your designs on different FPGA tools - is more flexible than using IP blocks - you don't need to regenerate IP blocks to make small changes - Easier to integrate into source control systems like Git, compared with IP blocks You might need to flick between other user guides (such as https://www.xilinx.com/support/documentation/user_guides/ug473_7Series_Memory_Resources.pdf for memories), but I am ure you will find it interesting.
  5. Invalid value for CLKIN1_PERIOD in PLLE2_BASE

    The is from memory, and I am on a phone, so don't be surprised if it is wrong... The PLL and the MMCM blocks have different max/min clock frequencies. I am pretty sure you will need to use the MMCM. CAn you check the datasheet and add an update to this post? "Artix 7 switching characteristics" should find it the correct PDF file quickly.
  6. Hi, A bit of background.... The transmitter uses the EDID ROM in the receiver (eg monitor or FPGA board) to see what formats the device can receive. If it identifies as DVI-D, then the source can only support picture data. IIfit identifies as HDMI then it can support pictures and audio. Here is what I think is going on. If you plug in the audio extractor by itself (or without the design running in the FPGA, the audio extractor says it supports HDMI, so audio is sent. When the FPGA design is loaded the splitter passes through the capabilities of the FPGA design in gn, which only supports DVI. So you get picture but no audio. The solution would be to have a full HDMI receiver in the FPGA (and then you might not require the audio splitter anyway.
  7. Last night I measured the speed of RF waves in a generic 10m TV coax using the AD2, a socket and two resistors Why?: I'm trying to build a cheap colinear antenna for receiving 1090MHz plane broadcasts. To do this I need to know the "velocity factor" of a cable. The setup: Connect the AD2 wave output and the input of the first scope channel (the reference channel) to one end of a 330 ohm resistor, Connect the other end of the 330 Ohm resistor, the second scope channel, and one end of the 100 Ohm resistor to the center pin on the socket. Connect the other end of the 100 Ohm resistor plus the AD2's ground connection to the shell/ground connection of the socket. Running the test: Without the cable plugged into the connector, run the Network Analyzer, from 1 MHz to 10 Mhz - it should be a pretty much flat line. Then connect the cable and test again. There will be a 'dip' somewhere 5 or 6 MHz. What is going on: The 330Ohm+100Ohm resistor acts as a signal divider, and has an AC impedance of about 75 ohm, matching that of the Coax cable. Because the cable has an open end, it is acting as an 'open stub' and any signal that is injected into the cable reaches the end of the cable and is reflected. The source and reflected signal interfere with each other, and where the signal is destructively interferes with the source signal the "dip" is seen. The bottom of this dip is when the cable is 1/4th the wavelength of the RF signal - so if the driving signal is at 90 degrees, the reflection is at 270 degrees, making the measured signal much weaker. Results: For a 10m (30 ft?) cable the dip was at 5.634MHz. That makes a full wavelength 40m long. That gives a speed of propagation of 5.634MHz * 40m = 225,360,000 m/second - about 75% the speed of light in a vacuum.
  8. One-hot encoding mystery

    The "sensitivity list" is the list of signals that will cause the body of the process to be evaluated when their values change. It can be also thought of the list of all asynchronous inputs and any clock signals used in the process. For hardware, usually the synthesis tool will generate the correct hardware anyway, regardless of any errors or omissions. For simulation they need to have all the required signals, as otherwise they body of the process won't be evaluated when it should be. For clocked processes, it should usually just be the clock signal and any async reset signal (which shouldn't really be used in FPGAs anyway!) For unclocked processes (asynchronous logic), it should be any signal that is used within the process. A template for a clocked process is this: process_name: process(clk, async_reset) begin if async_reset = '1' then x <= whatever_the_reset_state_is; elsif rising_edge(clk) then -- all your usual stuff if a = '1' then x <= b AND c; end if; end if; end process; In this case, if a = '1', b ='1' and then c changes the output x doesn't change - it only changes when the clk rises or if reset is asserted, which is why a,b and c are not needed on the sensitivity list. A template for an unclocked ("async") process is this: process_name: process(a,b,c) begin if a = '1' then x <= b AND c; end if; end process; if a = '1' and b = 'a' the process needs to be evaluated every time 'c' changes, so 'c' has to be on the sensitivity list. Likewise the output might change if a or b changes value, depending on the values of the other inputs, so they have to be there too. Having additional signals that aren't needed to the sensitivity list doesn't break anything, but it can waste time in simulation as the process triggers but nothing changes. You can do other things like "wait until rising_edge(clk);", which avoids the "if rising_edge() then" and nesting, but that is not "the done thing", and considered being a bit of a smarty-pants.
  9. One-hot encoding mystery

    I know I am completely off topic, and being no help at all, but.... IMO an FSM is the wrong tool for the job, and that why it seems odd. This is a pretty standard "build an FSM" assignment, but it involves creating a state machine where none is really needed. All you need to know is the state of the input during the previous clock cycle. if rising_edge(clk) then if my_signal_last = '0' and my_signal = '1' then my_signal_rising_edge <= '1'; else my_signal_rising_edge <= '0'; end if; my_signal_last <= my_signal; end if; or -- concurrently detect the rising edge of my_signal. -- It will be asserted when my_signal transitions from -- zero to one. -- -- You better make sure that my_signal is synchronised -- to the clock for this to work correctly! -- my_signal_rising_edge <= my_signal and not my_signal_last; process(clk) begin if rising_edge(clk) then my_signal_last <= my_signal; end if; end if; And as for "dividing the clock a few times", I shudder a little. Far better to keep everything in one clock domain, signal clock_enable_shift_register := std_logic_vector(7 downto 0) := "10000000"; generate_clock_enable_process: process(clk) begin if rising_edge(clk) then clock_enable <= clock_enable_shift_register(0); clock_enable_shift_register <=clock_enable_shift_register(0) & clock_enable_shift_register(clock_enable_shift_register'high downto 1); end if; end process; do_stuff_slowly_process: process(clk) begin if rising_edge(clk) then if clock_enable = '1' then ... do stuff once in a while end if end if; end process;
  10. Artix-A7 non-GUI development

    Most of the FPGA pins can be used for multiple things - inputs, outputs, global clocks, configuration, XADC, DDR memory.... as long as the pin can do what you want it to do you can the you are OK to ignore the other features (as long as you don't need to use the other feature!) This is one of the differences between Xilinx and Altera FPGAs - Altera FPGAs usually have input-only pins, and high speed/low speed banks, making pin planning much more important for Altera.
  11. DVI to RGB IP Core - problems with resolutions above 720p

    Hey there! For the standard I/O pins on 7-series FPGA are only rated to 1250 Mb/s or 950Gb/s depending on speed grade, so pixel clocks > 125MHz are very much out of spec. Also the ability to tune the capture phase (using IDELAY2 primitive) does not have enough resolution align clock edges at 148.6MHz pixel clocks, so it is somewhat hit and miss. However, If you use the high speed transceivers for HDMI, anything is possible :-)
  12. Artix-A7 non-GUI development

    This might be of interest to you https://www.xilinx.com/video/hardware/using-the-non-project-batch-flow.html (regarding none-GUI builds) XDC files are a mystery, but here goes. - Both lines are comments - they begin with hashs - The second line is the true 'human readable' comment - the "Sch=" is the net naming in the schematic. . The IO_L8N... is the pin name on the FPGA package, It is in IO bank 35, it is the negative connection for LVDS pair 8 ("L8N"), and looks to also be the Negative input for XADC pair 14 ("AD14N"). Given the context it is pin M3 on the package being used. So if you removed the first '#' on the first line, this is what is going on. It applies the following settings: PACKAGE_PIN attribute is set to M3 IOSTANDARD attribute is set to LVCMOS33 to the list of external connection that match those found by "get_ports" looking for things that match "pio[01]".
  13. CMOD A7 Type of USB Micro Connector

    It is a Micro-B socket based on this picture - https://en.wikipedia.org/wiki/USB#/media/File:USB_konektory.png
  14. Using the Rj45 and Ethernet controller

    Hi, I haven't looked at the board's specs, but you can find examples at https://github.com/hamsternz/ArtyEtherentTX (100BaseT on the Arty board) https://github.com/hamsternz/FPGA_GigabitTx (1000BaseT on the Nexys Video board). They should be helpful to you.
  15. Dividing by 10....

    Sort of pen-and-papered it. 0xCCCCCCCD is 0.8*2^32, so it is d = i * (4/5*2^32) / 2^32 which reduces to d = i/10 expecting that I would have to do a fixup to pick up rounding errors, but then found it wasn't needed. It turns out that GCC does this optimization by default, but uses a 32-bit multiply that splits the result across two registers (EDX:EAX), but the above method doesn't touch EDX so leaves a register free, and can be a tad quicker.