hamster

Members
  • Content Count

    515
  • Joined

  • Last visited

  • Days Won

    79

Everything posted by hamster

  1. If you haven't already done an RMA, now that the cable drivers are installed can you remove the mouse device while the CMOD ins't plugged in, then plug it in so it can detect it again? To do this Start a CMD prompt as administrator, run: SET DEVMGR_SHOW_NONPRESENT_DEVICES=1 DEVMGMT.MSC Then in device manager select the "View/Show hidden devices" menu item. You should then be able to remove the mouse device. Then plug the CMOD in and see what happens. This will allow the driver autodetect to run while the new cable drivers are installed. (see http://www.thewindowsclub.com/show-non-present-devices-windows for a better walkthrough of the process) It is also a way you can get rid of all the old USB COM ports that are left behind by DevBoards past... and disk devices from old USB drivers.
  2. Something like this maybe? (I don't use Verilog)... if(clk_cnt[ divider_i] == 1'b1) clk_o_s <= 1'b1; else clk_o_s <= 1'b0; ;
  3. I had the same problem. You should find the answer here:
  4. You can use any signal you like as a clock, so make a counter/divider to divide down a faster clock, and then use that a clock signal The other option is to have a faster clock, but use a "clock enable" to one do work one cycle in every 'n'.cycles e.g. if rising_edge(clk) and clock_enable = '1' then
  5. A lot of the unanswered questions are around what you are trying to do. Glancing through the datasheet (http://www.mouser.com/ds/2/256/MAX11300-335894.pdf), the ADC is fairly complex, and could require quite a bit of setup to get it configured and delivering sample data. There looks to be more than a handful of registers that need to be set. This makes me think that a micro-controller with a SPI peripheral or a soft CPU will be a good idea to use. The device also has a lot of channels, how many will you be using? What do you want to do with the samples once you get the data?
  6. Hi! I am not familiar with your ADC, but this is using SPI to read a different ADC: http://hamsterworks.co.nz/mediawiki/index.php/SPI_ADC
  7. There are a few issues with Vivado on Ubuntu - for example: https://forums.xilinx.com/t5/Embedded-Development-Tools/Vivado-2016-1-SDK-launch-problem/td-p/693615 I've also heard that it is sensitive to library versions - something to do with the tools calling "setenv(NULL);" (which should not be done), and is handled differently in different versions.
  8. I've had some trouble with Vivado Cable drivers under Windows 10 - Hardware Manager fails to detect hardware and the log says "warning: cannot find symbol ftdimgr_lock in library dpcomm.dll, frequently used Digilent JTAG cables cannot be supported" To fix this open a windows command problem, but use "Run as Administrator". Then reinstall the cable drivers with the following commands. cd \Xilinx\Vivado\2016.4\data\xicom\cable_drivers\nt64 install_drivers_wrapper.bat \Xilinx\Vivado\2016.4\data\xicom\cable_drivers\nt64 c:\Xilinx\Vivado\2016.4\install.log c:\Xilinx\Vivado\2016.4\ this error is also referenced in
  9. It's pretty simple, When adding 3 to a 3-bit counter, it will 'roll over' 3 times every 8 (or 2^3) cycles. And 40 MHz * 3/8 = 15 MHz If it was a 5=bit counter it would roll over 3 times every 32 (2^5) cycles, so it would give 40MHz * 3/32 = 3.75 MHz
  10. @zygot... I got a little bit of code working last night... - Test pattern generator, which counts 0 to 2^n-1, and then sends a few sync patterns - 4-bit to 5-bit symbol conversion, that also looks up a symbol's parity count. This only generates symbols with positive disparity - Disparity balancing - if the running disparity is negative it inverts the symbol and subtracts the current symbol's disparity, otherwise it it just added the current symbol's disparity to the running total - A 5:1 serializer to output the bits towards the PMOD connector I've also got a plan together for the RX side of the link... especially about recovering framing and how to detect the sync pattern. It is coming together quite nicely! Using three data pairs and sending 20-bit values is just awkward. If not, I might send 21-bit values (about 5% less efficient) but I can then send one number using 7 data bits on each of three pairs... is that still valid for the challenge? Mike
  11. @zygot, you have a strange turn of phrase... passively aggressive and paternal at the same time, and with all the taste and nutrition of a fine Belgian chocolate. Thinking/design is important than code, as the HDL is the expression of your thoughts and ideas - without good ideas you end up with hollow and unimaginative code. Not having a clock input isn't a grand problem, you can always hook things though a BUFG and onto the clocking networks, and deskew in a PLL by creeping the phase if you really have to because you can't get it to lock. I have to get a grips on how to do this for my HDMI input project, because the current way I do it by looking for symbol errors sucks big-time. For my testing I was going to do it for real - between two different 7-series boards (e.g. from an Arty to a Basys3 or similar). Looping back to the same chip (sharing references and so on) is a bit of a cheat. Also place and route times are much quicker on the smaller chips. You can hold your breath if you like, but it might take me a while - most likely after Christmas. Work is busy before a the change freeze, I have an existing software project I'm working on and then I'm away camping for two weeks holiday. But you can be assured that I will be doing some more thinking.
  12. I've been thinking, and I'm going to try this coding.... Bit 0 - Invert / non-invert Bit 1 - Data bit 0 Bit 2 - Data bit 1 Bit 3 - Data bit 2 Bit 4 - Data bit 3 Symbols are inverted to preserve DC balance & minimize running disparity. This coding will also still work if the + and - signals get swapped.So the next issue is how to synchronize the symbols. We have a problem though ...00000111110000011111... is ambiguous 0 0 0 0 0 - 1 1 1 1 1 - 0 0 0 0 0 - 1 1 1 1 1 is a stream of zeros. 0 0 0 0 1 - 1 1 1 1 0 - 0 0 0 0 1 - 1 1 1 1 0 is a stream of ones. 0 0 0 1 1 - 1 1 1 0 0 - 0 0 0 1 1 - 1 1 1 0 0 is a stream of threes. 0 0 1 1 1 - 1 1 0 0 0 - 0 0 1 1 1 - 1 1 0 0 0 is a stream of seven. 0 1 1 1 1 - 1 0 0 0 0 - 0 1 1 1 1 - 1 0 0 0 0 is a stream of hexadecimal Fs. It needs some way to recover the synchronization. Within a data sequences "00000000001111111111" or "11111111110000000000" should never be seen within a data sequence as it takes the running disparity to far out of wack. I can then use the center transition to recover the framing. This has a crufty feel to it, but should work. Good points: - Coding overhead is 25% vs 100% for something like Differential Manchester encoding or Biphase Mark Code. - DC neutral. - run length limited to 15 bits, Bad points: - Framing isn't too efficient or effective - No effective way to detect errors (e.g all codes are valid), other than running disparity goes out of wack - RF/EMI is most likely very poor - sending repeating patterns is very easy to do - could be improved by scrambling data before sending. The need for the RX to oversample the input to recover the clock can be removed if one pair sends the clock, leaving three pairs to take data. At 100MB/s over the remaining three pairs the clock rate needs to be 33.3 MHz, and a bit rate of 333Mb/s per pair. Using only DDR registers the RX and TX can run at 166 MHz, which is pretty achievable.Using SERDES at 5:1 it only needs to run at 66MHz. How does that sound as a plan? Sounds reasonably workable...
  13. Dan meant a 'three bit' counter (that counts from zero to seven). when you adding 3 each cycle the counter will run as follows: 0, 3, 6, 1, 4, 7, 2, 5, 0, 3, 6, 1, 4, 7, 2, 5... And the most significant bit of the counter will be: 0, 0, 1, 0, 1, 1, 0 ,1, 0, 0, 1, 0, 1, 1, 0 ,1... That gives three 0-to-1 transitions every eight clock ticks, for a total of 15,000,000 every second if you are using a 40MHz clock. You can do the same thing with a shift register, avoiding addition completely: shift_reg : std_logic_vector(7 downto 0) := "00001111"; if rising_edge(clk) then output_signal <= shift_reg(7); shift_reg <= shift_reg(4 downto 0) & shift_reg(7 downto 5); end if; You can do a little bit better than this using a DDR register to halve the phase noise on the output, but it is still very poor compared with using a PLL or MMCM.
  14. Hi! It looks like you problem is that you are using the "non-clock" pin (the button) as a clocking signal. This confuses the tools. You have a few options. 1. Use an actual, stable,clock and then increase the count when your design sees the rising edge on the signal if rising_edge(clk) then if sw_in = '1' and sw_last = '0' then ... increment the count here ... end if; sw_last = sw_in; end if; 2. send the signal through a clock buffer, forcing it onto the clocking networks. library UNISIM; use UNISIM.VComponents.all; ..... clk_buffer: BUFG PORT MAP ( I => sw_in, O => sw_buffered); (just remember to use the then you can use if rising_edge(swtich_buffered) then ... increment the count here ... end if; 3. You can add constraints or implementation options to allow you to ignore the errors. However these solutions have issues due to switch bounce, and/or the need to correctly synchronize the input signal to the local clock domain. Option 1 is the best pattern to follow to eventually end up with a working design.
  15. Oh, XAPP585 ( https://www.xilinx.com/support/documentation/application_notes/xapp585-lvds-source-synch-serdes-clock-multiplication.pdf ) hints at this design.
  16. Somebody recently told me something that others might find helpful. When you use ISERDES in master/slave configuration to receive bits, you don't have a phase detector, or any other way to work out if you are sampling at the optimal time. However, if you don't use a master/slave configuration, you can use two ISERDES blocks to sample the same incoming signals - each with their own separately adjustable IDELAY block. You can then adjust the input delay to identify where the transitions signal are. The downside is that you can't process larger symbols - if you want to process 10-bit symbols you need to make a 'gear box' to accept ten 8-bit works, and emits eigth 10-bit words to the rest of the design. I might give this a test on my HDMI design when I get some free time...
  17. I'm late to the party, but... ...given that the Nexys Video can transmit at 435 MB/s (for 1080p video) using the standard SERDES pins, 4MB should take about 9.6ms - this is using three data pairs plus a clock pair. Sending the clock to the sink would be the way to go, as it avoids the need for clock recovery, (where you really need to use the transceivers) However, PMOD connectors are not very good for very high frequency signals - I once managed to get 500Mb/s through 0.1" connector and 200mm jumper wires, but it wasn't really a properly engineered solution. You would be very, really lucky to get 50MB/s through each pair.
  18. hamster

    Luigi Sabatini

    Hi! I have a Genesys2, and have never needed to use Adept. I design in Vivado and use the Vivado suit to program the FPGA (the JTAG interface has native support), The J15 USB<->UART bridge uses the standard FTDI drivers to implement the virtual serial port.
  19. Hi! The top-level signal spi_ss_io has not been given a because it has already been taken by something else. Something to do with "shield_dp0_dp19" at a guess. Mike
  20. Have you ever thought about adding PMOD which has I2S input? Or maybe input and output using something like http://www.nxp.com/products/media-and-audio-processing/data-converters/audio-converters/audio-codec/ultra-low-power-audio-codec:SGTL5000
  21. Hi Megaxoplasma, To control the LED intensity you only switch it on part of the time, using a technique called Pulse Width Modulation (a.k.a. PWM) If you switch the LED on and off quick enough, you are only able to see the average intensity. To avoid flicker you need to switch it at least on and off at least 50 times per second.
  22. hamster

    Nexys Video

    Hi! I've worked with the DisplayPort output on the Nexys Video. . The Nexys Video only has a mini DisplayPort Output so can't be used to receive data. It really is configured only for sending data at 2.70Gb/s (20x the reference clock of 135 MHz) The page 47 of the transceiver user guide (https://www.xilinx.com/support/documentation/user_guides/ug476_7Series_Transceivers.pdf) indicates that: PLLfreq = Refclock * N1 * N2 / M, ...and that the PLL frequency must be between 1.6 and 3.3 GHz. The line rate is: LineRate = PLLFreq 2 * / D. With N1 = 5, N2 = 5, M=2 the PLL Freq will be 1687.5 MHz, and with a D of 1, the data rate will be 3375, which is just out of spec, but might just work Hey! Wow! I've just seen how you can run the DisplayPort interface at 1.62 Gb/s, reference clock of 135, with N1 of 3, N2 of 4 gives a PLL frequency of 1620 GHz, so with a D value of 2, you get 1.62Gb/s.... sweet!
  23. hamster

    ISE for Arty board

    Sadly the documentation is accurate - only a selected few 7-series devices are supported in ISE - see https://www.xilinx.com/publications/matrix/Software_matrix.pdf If you really want to make a rod for your own back, nothing stops you from using ISE to generate HDL files that you then include in a Vivado project... Vivado does have a block diagram mode, that is sort of schematic capture, allowing you to connect IP blocks together, maybe that will meet your needs?
  24. Yes, you need to set CLOCK_DEDICATED_ROUTE = FALSE in your constraints file, which allows the tools to run clock signals over the connections that usually transfer data signals.
  25. Hi! I don't have ISE installed at the moment but have looked at the code.... I see you have the clocks buffered with BUFG - great stuff! The most likely problem is this: JA1 <= ClkOut80; JA2 <= ClkOut80P180; It trys to take the signals from the clocking network and send them through the data output, which are designed to generic take data signals from the FPGA fabric. There is an easy solution to this - use a DDR output buffer to output a '0' through the first half of the cycle and a '1' through the second half (or the other way around for the P180 signal): JA1_out_ddr: ODDR2 generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") port map (C0 => ClkOut80, C1 => ClkOut80P180, CE => '1', R => '0', S => '0', D0 => '0', D1 => '1', Q => JA1); JA2_out_ddr: ODDR2 generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") port map (C0 => ClkOut80P180, C1 => ClkOut80, CE => '1', R => '0', S => '0', D0 => '0', D1 => '1', Q => JA2); or if you want to avoid using the P180 clock (to save resources): JA1_out_ddr: ODDR2 generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") port map (C0 => ClkOut80, C1 => not ClkOut80, CE => '1', R => '0', S => '0', D0 => '0', D1 => '1', Q => JA1); JA2_out_ddr: ODDR2 generic map(DDR_ALIGNMENT => "C0", INIT => '0', SRTYPE => "ASYNC") port map (C0 => not ClkOut80, C1 => ClkOut80, CE => '1', R => '0', S => '0', D0 => '0', D1 => '1', Q => JA2); (Or you can swap D0 => '1', D1 => '0' for the second DDR, keeping C0 => ClkOut80, C1 => not ClkOut80) Like I said, I don't have ISE in so can't test at the moment, so this might have some silly errors in it You can avoid the "COMPONENT" declarations for primitives by using the library, which can avoid some errors... library UNISIM; use UNISIM.VComponents.all;