artvvb

Technical Forum Moderator
  • Content count

    108
  • Joined

  • Last visited

  • Days Won

    7

artvvb last won the day on March 7

artvvb had the most liked content!

1 Follower

About artvvb

  • Rank
    Community Super-Star

Profile Information

  • Gender
    Male
  • Location
    Pullman, WA
  1. @mihai5 It also looks to me like the result port in your block design is only 1 bit wide? This seems very likely to be the cause of getting a 0 instead of 8. Hope this helps, Arthur
  2. The values that are read back over AXI are modified by changing what the "reg_data_out" register is set to. There should be a case statement in the IP wrapper that looks a little like this: 2'h0 : reg_data_out <= slv_reg0; 2'h1 : reg_data_out <= slv_reg1; 2'h2 : reg_data_out <= slv_reg2; 2'h3 : reg_data_out <= slv_reg3; This case statement needs to be modified so that on the appropriate read address, reg_data_out is set to your result. Hope this helps, Arthur
  3. @mihai5 If you are in Vivado 2016.1 or later, there is a fast workaround you can try. It's very much a hack, but you can connect inputs and outputs of a module in your block design to AXI GPIO controllers configured as all input or all output. This is more a way of quickly prototyping a design which you would be creating a full AXI IP for later, but does work. First, add your module written in HDL to the block design by right clicking and selecting "Add Module". Then add some number of AXI GPIO IP cores to your design, you can then customize their widths and input / output directions appropriately. After this, expand the GPIO Interface of each IP by clicking the plus button on the interface port in the block design screen. You can then do a click-drag connect to connect your module's inputs and outputs to the GPIO controllers. Picture attached shows an example of the results of this. As for actually creating a proper AXI interface, sending data back to PS is accomplished by setting the slave registers (slv_reg_#) of your choice, possibly changing other places that they are being set, it's been a little while since I created a full AXI core. Hope this helps, Arthur
  4. This makes sense and should be achievable, My recommendation would be to get PS-PL communication going first - try to display an ASCII character from PS on the LEDs of your board. The tutorial I linked above should help with with. You can find a fairly hack-ey verilog example that handle strings in the top file for the Genesys2 OLED Demo. This demo is more focused on transmitting bytes in order than with managing entire strings at once. But the code is decently readable (I hope). Hope this helps, Arthur
  5. @mihai5 You may want to review this tutorial on how to create a custom AXI IP core, as this is Vivado's preferred way of communicating between PS and PL. The actual string comparison is fairly straightforward to do in verilog/vhdl, as ascii bytes are just bytes. You will need to decide early whether you need the 128 bit data to be compared against to be able to be changed by PS, as this may change how you encode your AXI slave registers. I suppose the question is really: where are the data registers are being set from? Also, I love the picture, thank you. Hope this helps, Arthur
  6. What happens if you right click on the BSP and select "re-generate BSP sources"?
  7. @rpm886 These errors are occuring even when you Generate Bitstream -> Export to SDK -> Launch SDK in Vivado?
  8. rpm886, I am wondering if this is an OS related issue, I am running Windows 8.1, so this seems likely. Going to have a coworker with an ubuntu VM attempt to debug your issue further. Block design validation would only do anything after create_project has completed. With the submodule fully checked out, there shouldn't be any fundamental problems with missing source files, outside of vivado having trouble with Linux (ubuntu?) file paths, which I don't believe that it does. Are you able to launch Vivado SDK directly, rather than through Vivado? I am unsure how you would do this in linux... Arthur
  9. @rpm886 After running through generation of the project and reproducing what is likely your bug (picture attached), it looks like not all of the required files were included in the release zip archive for the project. You should be able to get the project running by cloning the hdmi project repository and using that to follow all steps of the tutorial after downloading and extracting the ZIP archive. Alternatively, the git submodule route I mentioned in the previous post may also work, as long as the git shell recognizes the extracted directory as a git repo. Sorry for the inconvenience... Arthur
  10. @rpm886 Could you provide a screenshot of the contents of your Arty-Z7-20-hdmi-in repo's /repo/ subdirectory? When you say that the clone of vivado-library failed, are you able to provide any more specific information on why or how, like specific error messages? You may need to run "git submodule init" then "git submodule update" in a Git shell within your Arty-Z7-20-hdmi-in repo directory rather than cloning vivado-library directly. This will effectively clone vivado-library into the proper place within the repo, I am not sure that this will work without knowing why directly cloning vivado-library failed. Attempting to run validation of the block design after create_project may also help show where the issues are (F6 keyboard shortcut). I will attempt to reproduce your bug and then get back to you, let me know if any of my suggestions uncover more information. Thanks, Arthur
  11. @rafauy That error is likely coming from "always@(posedge btnC)". Triggering logic on non-clock pins is generally considered a no-no, and the push buttons generate particularly noisy signals. Whenever you press or release the button, the signal will actually flip high and low a bunch of times before settling into the new state. A suggested way to fix your errors would be to use code with a structure like the following: always@(posedge clk) begin if (strobe_BtnC == 1) do stuff; end There are a few differences here, first, posedge clk. Logic should almost always be driven from a clock, you can likely find a number of other posts around the forums about why this better than the alternatives. Second, strobe_BtnC is a new signal that is being introduced. This signal should be high for only one clock cycle, and should only be high once per press of the center button. There are a few typical verilog patterns to look into here. A synchronizer will properly bring your button signal into your clock domain. A debouncer will remove the significant jittering of the button signal. An Edge Detection circuit (typically paired with your synchronizer, though not necessarily) will limit your counter to one increment per button press. Some possible reading material for you to check out: On clock domains at ASIC World. A decent description of why debouncers need to be used at fpga4fun. More description of synchronizers and edge detection at doulos.com. Hope this helps, Arthur
  12. @Pauld The Arty's Out of box demo can be found at this Avnet page, under Documents there is a download for the project and some documentation. This project is fairly old and not maintained by Digilent so I don't know if it has been updated for newer versions of Vivado or not. This demo is also an example of a microblaze system and may not fit your needs - if you want to show block design and C coding Vivado SDK, it may be helpful. A pure-HDL GPIO demo can be found on our wiki here, with the source code located on Github here. This implements some of the same features as the out of box, so it may also work for you. This demo has also been recently been updated to 2016.4, so it may be easier to get running, depending on the state of the Avnet demo. Hope this helps, Arthur
  13. @Tickstart Generally speaking, it's recommended to let Vivado handle the tricky bits and just describe the behavior from a higher level, unless you really need to do the tricky stuff for learning purposes. In this situation, you can get the same effect by shifting the input into a std_logic_vector and then using that vector to determine your outputs. Where are you coming from with this? Do you want to make something that works and is easy to read/maintain, or do you really need to dig heavily into the details? Thanks, Arthur
  14. @Tickstart The simulator can have issues with figuring out what a signal should be when it is derived from itself or another signal that is derived from the first signal. This is only a problem when the signal is not initially defined or all of the paths to derive it depend on it. I am more familiar with verilog, so take vhdl suggestions from me with that in mind, but the following is what I would suspect would help fix the problem. //file D_flipflop.v: //Verilog Before: `timescale 1ns / 1ps module dff ( input clk, input d, output reg q ); always@(posedge clk) q <= d; endmodule //Verilog After: `timescale 1ns / 1ps module dff ( input clk, input d, output reg q ); initial q <= 0; always@(posedge clk) q <= d; endmodule And my attempt at VHDL for the same thing: //File D_flipflop.vhd //Before: library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity D_flipflop is Port ( clk : in STD_LOGIC; d : in STD_LOGIC; q : out STD_LOGIC ); end D_flipflop; architecture Behavioral of D_flipflop is begin name: process (clk) begin if rising_edge(clk) then q <= d; end if; end process name; end Behavioral; //File D_flipflop.vhd //After addition of initial value: library IEEE; use IEEE.STD_LOGIC_1164.ALL; entity D_flipflop is Port ( clk : in STD_LOGIC; d : in STD_LOGIC; q : out STD_LOGIC := '0' ); end D_flipflop; architecture Behavioral of D_flipflop is begin name: process (clk) begin if rising_edge(clk) then q <= d; end if; end process name; end Behavioral; My other suggestion would be to take a look at the RTL Analysis -> Elaborated Design -> Schematic for your project, this tool is used to help figure out what the logical circuits that your design is being translated into are. I've attached the schematic I generated for your design. The important thing here is that looking at the I signal's paths, everything route from I to a 'd' pin goes through an AND gate. This means that if the other input to each gate is undefined, the output of that gate will be undefined. In short, this was just a long way of saying that you probably need to add ' := '0' ' to your D_flipflop file. Hope this helps, Arthur
  15. @tirotry First, mixing blocking and non-blocking assignment ('=' and '<=') can make weird things happen. Second, could you explain what line 47 is intended to do? That being: value = (result / 10) << 4; The value register is only 4 bits wide, and the following case statement only uses the lowest four bits of the value reg. Thanks, Arthur