• Content Count

  • Joined

  • Last visited

About maximb

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi, I recently discovered that the wrong scan codes are sent for certain keys. This is tested with my own PS2 keyboard controller, and the same behaviour is present with the official demo: I have tested two keyboards: One Logitech K120, and one Microsoft comfort curve 3000. The following behaviour is exhibited: Left arrow set 2 scancode should be: E0 6B / E0 F0 6B. Actual: 6B / F0 6B Up arrow set 2 scancode should be: E0 75 / E0 F0 75. Actual: 75 / F0 75 Down arrow set 2 scancode should be: E0 72 / E0 F0 72. Actual: 72 / F0 72 Curiously, the right arrow scancode is correct. Numpad division set 2 scancode should be: E0 4A / E0 F0 4A. Actual: 4A / F0 4A Can anyone confirm? Online Documentation for Altium Products - PS2 Keyboard Scan Codes - 2017-09-13.pdf
  2. Thank you all for your helpful comments, Indeed, on page 100 of UG 471: "7 Series SelectIO" I found the following table: It appears that 0.9V is the VREF configuration that should be used with SSTL18_II (be it INTERNAL or not).
  3. Hi, I am in the process of developing my own DDR2 controller as an exercise. Consequently, I'm trying to avoid using tools like MIG. Unfortunately I could not fully escape the clutches of automated tools, as in order to correctly configure the .xdc constraints file, I've had to have a peek at the following .prj file generated by the MIG in the official Digilent DDR2 Demo implementation: I interpret the following line: "<InternalVref>1</InternalVref>" as setting the INTERNAL_VREF property to 1V. Therefore, I add the following line in my .xdc file: set_property INTERNAL_VREF 1 [get_iobanks 34] However, this configuration fails to implement for the Nexys4 DDR chip with the following error: [DRC 23-20] Rule violation (IVREF-2) INTERNAL_VREF - Bank 34 has INTERNAL_VREF set to an unsupported value (1.000V). Supported VREF values for this part are: 0.600, 0.675, 0.750, 0.900. Which value should I choose to use?
  4. Hi, I am using Vivado 2016.4 to program the Nexys4 DDR 7-segment display. I have a very simple VHDL project, which works as follows: 100 MHz clock is used to increment an 8-bit counter when this counter overflows, it inverts the value of a local signal called "slowclk". Hence, "slowclk" is "clk" divided by 512. the "slowclk" is used to increment another 8-bit counter, the output of which is assigned to the 7-segment display segment selector pins on the board. Complete VHDL source: Note: I understand that given such division, the effect on the digit segments will still not be visible - I just want to demonstrate the timing problem. However, the design fails to meet timing constraints as follows in attached pictures: Timing constraint failures in more detail, including the full source VHDL: Clock routing on the FPGA: The following is the .xdc constraints file (commented-out definitions are omitted): From what little I know about FPGA clock routing and resources, I understand this to be due to the high-frequency clock and associated logic being in different regions to each other, thus requiring the implementation run to route the clock signal through awkward paths; as a consequence, the total signal propagation time is such, that before the logic relevant to the current clock pulse is evaluated, the next clock front is already present. Am I correct in this thinking? And in either case, how can I fix the timing issues that Vivado warns about?