Popular Content

Showing content with the highest reputation since 06/04/20 in all areas

  1. 2 points
    Hi, as a simple (oversimplified?) answer, designing for higher clock speed requires higher effort (possibly "much" higher effort), and the resulting optimizations make the code harder to work with. Using the clocking wizard to generate a 500 MHz PLL is easy (try it). But writing logic at those frequencies is a different story (e.g. try to implement a conventional counter that divides down to 1 Hz. Why do all those XYX_CARRY signals show up in the timing report already at synthesis?). You also need to distinguish between what is feasible in plain logic fabric, and what can be done with dedicated "hard-macro" IP blocks such as SERDES.
  2. 1 point

    Video RAM in DDR

    @Dannny, Hey, for what it's worth you've taught me something about the Mig that I haven't found out for myself yet. I guess that's the utility of having a forum where people can ask questions and get nswers from a variety of perspectives is all about. Everyone can learn things and get a little seed of inquiry implanted into the back of their minds. You never know what can happen.
  3. 1 point

    Video RAM in DDR

    Thanks all of you. I was hoping that I can live without VDMA, but it seems that I have to do it anyway. The main reason for this exercise is to have fun and to learn something new. I found basic blocks for the embedded linux on github or opencores and I already tested some of them. So, I'm getting more and more units to work :-)... But the Video RAM is first "blocker" on the way. I'll look into other examples as well. If any of you have some other ideas, don't hesitate to share them :-)... Thanks.
  4. 1 point

    Video RAM in DDR

    @Ciprian, I understand why there's a desire to stuff Linux into some FPGA designs. In fact you've fleshed out a few of the difficult problems that someone taking the HDL flow must solve on their own quite well for me. @Dannny has discovered one of the other conundrums which is trying to fit an idea into an FPGA platform as opposed to choosing an FPGA platform appropriate to your idea. Sometimes the choice of external memory designed into a board limits comes with unforeseen restrictions. You've also nicely exposed another problem in that even if you can get a non-ZYNQ platform running some form of Linux that doesn't necessarily resolve your problems. Furthermore, using the limited IP available with the MiccroBlaze comes with a problem that only appears after many weeks of work. What if you need your DDR video buffer to work differently or better? Then what? Likely, you have to do all of the stuff that you correctly point out is very hard to do. I don't know what the purpose of the design exercise is. If I had to execute a design that leveraged open source Linux source material I'd certainly want to do it on a ZYNQ platform. But the typical Z7000 family FPGA board is not a wonderful Linux platform if you need performance. Creating a custom Linux build reasonably scaled to the resources of you FPGA platform is not easy. If you are trying to work out how a processor driven DDR video frame buffer might be implemented you will end up knowing a lot more doing it yourself then relying on IP that you don't understand or can't easily modify. There's nothing wrong with slapping together a quick MicroBlaze design using available IP from your FPGA vendor, if learning how to do that flow is the goal or if all you want to do is get to a point where you've accomplished something. Having something that you can adapt to any FPGA platform or project is a different matter. Developing something that you can easily rework or improve is another matter, except that you don't realize it until you've invested a lot of time into getting to the point of having a design that you hope can be a springboard into something better. Hopefully, having some idea of the obstacles that lie ahead will help make for good early design decisions. I know, it's complicated.
  5. 1 point

    Zybo z7 evaluation

    Hi Pier, I'm a bit confused, where do the signals come from? Do you have two external sources or do you generate them in the FPGA? Similarly, do you want to a analog output of the resulting signal or do you only need the samples? -Ciprian
  6. 1 point
    Ana-Maria Balas

    PMOD I2S2 IP

    Yes, I've already give him the link with some Reference projects which contains also pdf files with documentation for each project, and it explains very well the Uart component which is used with the PmodRS232 (in Interface Reference Component from the Reference projects). The info is there... https://reference.digilentinc.com/reference/pmod/pmodrs232/start?&_ga=2.200020910.1057145837.1593523143-180711290.1584371590#reference_projects
  7. 1 point

    Open Logger : Function Gen issue ..

    Hi @Raghunathan, Could you attach a picture of your settings? I was unable to replicate the situation regarding the peak to peak voltage (my screenshot is using 50 Hz, but 60 Hz did the same as well). With regards to the square wave appearing curved, I was only able to see this when I zoomed in so that the time base was at 2 uS/division or less but at that point you are just viewing the output settling time of the requested change which should be about 580 nS as noted on slide 91 on the detailed Microchip Masters Presentation. Thanks, JColvin
  8. 1 point
    Ana-Maria Balas

    pmod AD1 or DA1 digilent

    Hello @farzan, 1. The first critical messages doesn't affect your project. It means that the IP was tested with a project that was created with a different board than yours,but this doesn't have any impact on your project, because it is a generic IP that can be used with all Digilent boards. 2. Because you have errors, then the SDK project cannot be build and therefore you cannot program the FPGA. You have to solve the errors first. The error say that the project you created overflowed the maximum capacity of your allocated BRAM memory with 92408 bytes. This means that you didn't allocate enough internal BRAM memory for the Microblaze processor. You must go back to Vivado project, select the Address Editor tab, then increase the microblaze_0_local_memory for Data and for Instruction to maximum I think 1MB should work. Rerun the generation of bitstream and update the Linker Script (right click on the project name in SDK and Generate Linker Script )
  9. 1 point
    I've got a little update on this project. I managed to get this thing running, by using modified register settings from raspiraw repository on github. So it is definitely possible to use this camera with Zybo Z7-20 board. However I did this with my own MIPI receiver, didn't check compatibility with Xilinx IP-core. Following image is only with white balance correction.
  10. 1 point

    new Nexys Video example designs

    @amb5l, You might want to consider posting this to the Digilent Project Vault, where it belongs. By posting it to where lots of FPGA related questions are posted every day your visibility will disappear making it invisible to most visitors. Just a thought.
  11. 1 point

    Many dozens of signals to monitor.

    Thank you.
  12. 1 point
    Hello @macellan, That's because you've already added one. I can see it under the XADC System monitor.
  13. 1 point
    I think of std_logic_vector the same way I would think of digits in a number... the rightmost digit is digit zero. It most likely isn't the best way set things up for this example, but it avoids the need to swap the bit ordering in the ASCII characters. Oh, for the button synchronization... signals take time to get across the chip (speed of light, capacitance and so on), so different parts of the design can see different values for the same signal as it change unless. As you can't control when the user might press the button you have to sample the value of the input signal on the clock edge, holding that in a register. That registered value is then used drive the rest of your logic. There is a slight complication - If the signal from the button changes state *exactly* on the clock edge, the flipflop might not be able to correctly register as a 1 or a 0, but could be in some weird "metastable" state that takes a short while to become either a 1 or a 0. To stop this causing bugs in the operation of the logic deeper in the deign, the output of that fliplfop is then sampled a second time to get a "known good, either 1 or 0" signal, that can get to where it needs to within a clock cycle. Hence the design pattern... btn gets sampled into btn_metastable (which is a bit dodgy if you use it), and then btn_metastable gets sampled into btn_synchronized, which is then used by the rest of the logic.
  14. 1 point

    Microblaze issues for a beginner

    Hi @macellan, Could you attach a picture of your block design? The description of your steps sound correct (and the running connection automation can add some more items depending on when individual pieces of the block diagram was added and when connection automation was run). As for when different pieces were added to the block diagram, it can make a difference, but really only during the Connection Automation and Block Automation when you tell Vivado what sort of connections you would like it to make. Otherwise, the 2018.2 guide should work fine for 2019.1. Thanks, JColvin
  15. 1 point

    Microblaze issues for a beginner

    Hi, >> but I feel like lost in documents Welcome to FPGAs. This is pretty much the name of the game (but it also makes the struggle worthwhile - if it were easy, everybody would do it 🙂 ). As a general direction, a solid (basic) tutorial is good but don't expect to be led by the hand all the way. The constant version changes make this quite difficult (good news: it means there is technological progress ... well at least in theory but the guys from the marketing department said so and they'll surely know ...). More specific directions: Have a look at Microblaze MCS. It's fairly simple - set up the most basic system with some BRAM (=memory "internal" to the FPGA fabric) and one UART. Once you've got that printing "Hello World" - which is mostly a question of baud rates and not mixing Tx/Rx pins, you can add features one by one and the sky is the limit. Well, at least until the little girl next door pulls out her Raspberry Pi, running four cores at 10x the clock frequency - don't complain no one told you: by absolute standards, the performance of any softcore CPU is pathetic, compared to a regular ASIC CPU on the same technology node. So eventually you'll have to move into FPGA territory, or it makes little sense except as a learning exercise.
  16. 1 point

    UART in Zedboard

    Hi @Shivani, I would recommend taking a look at these threads on our forum for some additional details on your endeavor: Thanks, JColvin
  17. 1 point
    Thank you Attila, Now we have time stamps on start with every data packages so that we can calculate delay time between commands and commands. Nice to have time stamps on stops hence we can calculate actual clock rate of each I2C and SPI data frame. Thank you and Best regards, Wayne Chen 06/20/2020
  18. 1 point
    Had a hack at it... tested working on BASYS3 library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity msg_repeater is Port ( clk : in STD_LOGIC; btn : in STD_LOGIC; tx : out STD_LOGIC; led : out STD_LOGIC_VECTOR (3 DOWNTO 0)); end msg_repeater; architecture Behavioral of msg_repeater is constant char_t : std_logic_vector (7 downto 0) := "01010100"; constant char_e : std_logic_vector (7 downto 0) := "01000101"; constant char_s : std_logic_vector (7 downto 0) := "01010011"; constant char_space : std_logic_vector (7 downto 0) := "00100000"; -- Note message is sent from bit 0 to the highest signal msg : std_logic_vector (49 downto 0) := char_space & "0" & -- Character 4, with start bit "1" & char_t & "0" & -- Character 3, wrapped in start and stop bit "1" & char_s & "0" & -- Character 2, wrapped in start and stop bit "1" & char_e & "0" & -- Character 1, wrapped in start and stop bit "1" & char_t & "0" & -- Character 0, wrapped in start and stop bit "1"; -- Idle symbol and stop bit of the last character signal msg_index : unsigned( 7 downto 0) := (others =>'0'); -- Should we send a message? signal triggered : std_logic := '0'; -- for generating the baud tick rate constant clock_rate : natural := 100000000; constant baud_rate : natural := 9600; signal baud_counter : unsigned(27 downto 0) := (others => '0'); signal baud_tick : std_logic := '0'; -- For the button synchonizer signal btn_synchronized : std_logic := '0'; signal btn_metastable : std_logic := '0'; begin process(clk) begin if rising_edge(clk) then -- Set the serial output bit tx <= msg(to_integer(msg_index)); led <= "0001"; -- Controlling the message index if baud_tick = '1' then if msg_index = 0 then -- We are waiting to be triggered if triggered = '1' then msg_index <= msg_index + 1; end if; elsif msg_index = msg'high then -- We have finished the message msg_index <= (others => '0'); triggered <= '0'; else -- We are sending bits msg_index <= msg_index + 1; end if; end if; -- Generating the baud tick if baud_counter < baud_rate then baud_tick <= '1'; baud_counter <= baud_counter - baud_rate + clock_rate; else baud_tick <= '0'; baud_counter <= baud_counter - baud_rate; end if; -- Seeing if we are triggered if btn_synchronized = '1' then triggered <= '1'; end if; -- Synchronize the button with the clock domain btn_metastable <= btn; btn_synchronized <= btn_metastable; end if; end process; end Behavioral;
  19. 1 point
    @attila, I just received the replacement probes from DigiKey. They work as expected, so, you suspicion that the other probes were faulty was correct. Thanks for the help!
  20. 1 point

    AD2 Data loss

    Hi @Wayne Chen For higher sample rate I would no rely purely on the USB rate since the bulk transfer have no guaranteed bandwidth, so without suffice buffering it may lead to data loss. The AD can use data compression in Logic Analyzer recording and the Protocol tool also uses compression. With this you can capture high frequency bursts, which are typically used in communications. With long busts (>16kb device buffer limit) or high average bit rates (>1Mbps usb transfer) the device buffer can overflow.
  21. 1 point
    Hi @Wayne Chen You can find message view and time stamps in the Protocol tool.
  22. 1 point

    USB104 A7 + ZMOD ADC1410

    Hi @shra1201, I apologize for the delay; I should have clarified that you needed to download the .zip from the release tab: https://github.com/Digilent/USB104A7-ZmodADC/releases. More details with specific instructions are available in the readme, available both in the downloaded zipfolder and on the Github page. Let me know if you have questions about this. Thanks, JColvin
  23. 1 point
    Hi, If anyone is interested in retro systems I've started on a port of the Multicomp system. I have a 6502 with basic up and running, you need a pmodps2 to use a keyboard (must be a proper ps2 keyboard). SD Card, Serial access, Z80 and 6809 to follow. https://github.com/mattuna15/zed-multicomp Enjoy
  24. 1 point

    HDMI directly into FPGA

    Carefully evaluate your system requirements (resolution, link rate) and do board-level simulation on the TMDS signals. FPGA user I/O pins have considerable capacitance and might close your signal eye too much. Buffers like the TMDS141 help with decoupling cable segment from the PCB, making longer PCB traces possible. Our development boards are not HDMI-certified, but buffers might make passing electrical certification easier.
  25. 1 point

    Electronics Explorer Troubleshooting

    Thanks @attila, that was fast! I'm back up and running.
  26. 1 point
    Thanks. That makes sense. In the case of how the tutorial is configured up until 6.4, the only path to the cellular ram is via M_AXI_DP. they (meaning whomever developed the tutorial) could not also connect M_AXI_IP to the same AXI Interconnect, so they added a second AXI interconnect ( and used the two cached connections) - but didn't put that in the instructions. (As a guess, it was a case of originally having used just the local memory connect with an earlier release of lwip, but then lwip got bigger / had more buffers by default, so it was changed, but not entirely consistently). I want to emphasize how extremely helpful you have been. Every step of the way you have provided guidance which has increased my understanding of how this is all put together -- and not at all in a condescending way. I will remember that, and continue speak highly of Digilent. I have learned a lot - including what the AXI interconnect is really all about, which is a good thing, because that seems to be the right way for me to interface the rest of my project with the MicroBlaze. Just in case you are curious, here is a link to my project. (I expect to use the MicroBlaze to support an Ethernet connection to a PC to provide the blinken lights and switches. If it doesn't fit on the Nexys4, then one of the newer boards from you guys will be in order. Before learning about MicroBlaze I had supposed I would use SPI or i2c over to a separate microcontroller board. This way I ought to be able to fit it all on the one board. https://www.computercollection.net/index.php/ibm-1410-fpga-implementation/
  27. 1 point
    Microblaze has: AXI4 (M_AXI_DP) data side interface, AXI4 (M_AXI_IP) instruction side interface, AXI4 (M_AXI_DC) protocol for D-Cache, AXI4 (M_AXI_IC) protocol for I-Cache. The address editor should show EMC under the Instruction section if the EMC IP has a path to M_AXI_IP or M_AXI_IC. However, it is best to keep things simple: connect external memory to IC and DC, while keeping all the rest on DP.
  28. 1 point
  29. 1 point
    @attila, @MarceloNotThePLCguy was unable to check on this during the last few days because we were operating. He's currently out of the office for a bit. We will have an opportunity in the coming weeks to try some of your recommendations. Thanks for your help! We'll keep you posted.
  30. 1 point

    AD2: ERC: 0x2 with Raspberry Pi 4

    Congrats @attila, you fixed it! Many thanks for your work! It now works perfectly
  31. 1 point
    Hi @Wayne Chen For such message decoding you can use the Protocol tool, SPI, Spy. If you need under View menu you can increase the Max lines. If you are interested on data of one channel (mosi or miso) you can use Three-wire Mode.
  32. 1 point
    Right click the linker script, choose “Generate linker script” and you will have an easier option to link all sections to a different memory.
  33. 1 point
    Macro constants with XPAR_ prefix are automatically generated by the BSP for the hardware platform and written to xparameters.h. Open the header file and look for the interrupt definition. It should reflect the block design names and connections.
  34. 1 point

    AD2: ERC: 0x2 with Raspberry Pi 4

    I've started running a test on Ubuntu 16.4 amd64
  35. 1 point

    Arty Z7 peripheral connections

    @bobsmith The Arty Z7's Reference Manual (Basic I/O and Shield Connector sections) and Schematic (sheets 1, 2, and 9) have information on how these components are connected. All four buttons are connected to pins on FPGA Bank 35 with resistors to pull down the pin while the button is open, and protect the FPGA pin from the voltage rail while the button is closed. IO pins 0-13 are connected to FPGA Bank 34 via current limiting resistors. The buttons can be noisy, so it may be worthwhile to debounce their signals, if you are not doing so already. Checking the debouncer output on an LED, or creating a simple toggle circuit to control an LED from a button could also be useful in figuring out if the buttons states are being captured as you expect. Edit: a coworker pointed out this Xilinx forum thread: https://forums.xilinx.com/t5/Implementation/Poor-placement-for-routing-between-an-IO-pin-and-BUFG/td-p/784930 There is some additional information in there about what the warning related to BUFG is about. Some pin may be being misinterpreted as a clock or a reset by the tools, which is causing the poor placement. I'd recommend checking your design's edge sensitivities - in Verilog, [email protected](..., posedge btn) would be bad, for example. Hope this helps, Arthur
  36. 1 point
    Hi @m72 The source of the problem is that the actual generator rate is not 176kHz but 176,056Hz (100MHz/568) For this the run time should be 22.72us (4/(100e6/568)) The WF app in the auto run calculation takes in account the desired rate... I will fix it now Thank you for the observation.
  37. 1 point
    Thank you for your advise, Attila. I can get good reconstructed I2S signals with the newly GUI ver 3.13.18 now. Wayne Chen 06/05/2020
  38. 1 point
    Hi @Wayne Chen The data is Two's complement.
  39. 1 point


    Hi @Steven McClain The last beta version adds the following Compare tool under Workspace menu: https://forum.digilentinc.com/topic/8908-waveforms-beta-download/ The duplicate Save Device (serial numbers of the device when the project was saved) are highlighted It is also highlighted when Scope Data (SN of the capture device) does not match the save device or captures with multiple devices are present. The table can be selected and copy-pasted to spreadsheet editors.
  40. 1 point
    Hi @Wayne Chen Probably the data format is the commonly used Two's complement signed. The simple Signed format refers to MSB sign | value. Could you attach or send to me a workspace with captured data? The latest beta version fixes the zigzag in analog curve for signed formats: https://forum.digilentinc.com/topic/8908-waveforms-beta-download/
  41. 1 point
    Thank you. It works. 😅
  42. 1 point
    Hi @Wayne Chen In order to capture the highest frequency signal you need at least double of capture sample rate. If your bit clock is 3.072MHz (32bit word * 2 * 48kHz) you will need at least 6.25MHz sample rate. At such high continuous signal rate the AD2 can only be used in Repeated mode. The Record mode needs to stream data over USB and it can do at most at 1-2MHz continuous signal rate. For burst signals (UART,SPI...) the data compression helps to be able to record at higher rates, but not in case of continuous I2S stream. In device manager you can select the 4th device configuration to have more device buffer for Logic Analyzer.
  43. 1 point
    Stay tuned to the Project Vault forum. Now that Digilent lets me play with well designed modules that do conversion between the analog and digital realms with a reasonable bandwidth on Xilinx hardware there are all sorts of fun ideas to explore.
  44. 1 point


    Hi @Steven McClain Extract the workspace, open the config.ini look for device.sn key [General] saveacquisitions=1 device.id=3 device.config=0 device.sn=SN:210321A680EF device.name=Discovery2 It is a 'custom compression' based on: https://doc.qt.io/qt-5/qbytearray.html#qCompress
  45. 1 point
    You linked to the Vivado project the Petalinux project uses as a hardware platform. The Petalinux repo that has OV5640 support is https://github.com/Digilent/Petalinux-Zybo-Z7-20. Commits https://github.com/Digilent/Petalinux-Zybo-Z7-20/commit/9dea683ef76fa7e3cc22dc0d6038e2a4c9bf3cb7 and https://github.com/Digilent/Petalinux-Zybo-Z7-20/commit/9dea683ef76fa7e3cc22dc0d6038e2a4c9bf3cb7 introduce Pcam 5C support. Try following the build instructions in that repo and report back with your findings.
  46. 1 point
    Hey Paolo, I'm glad you found my videos helpful! I've been working on other projects, but if you have any other ideas for videos that you would find helpful let me know. Kaitlyn
  47. 1 point

    Arty7 xemacp undeclared

    Hi @zthom, Glad that replacing the xadapter.c fixed the issue. Thank you for sharing what you did. cheers, Jon
  48. 1 point

    Arty7 xemacp undeclared

    Thank you, it works now. It only needed to replace xadapter.c
  49. 1 point

    Arty7 xemacp undeclared

    Hi @zthom, I got the same issue in Vivado/SDK using 2018.2. I did not get these issues using Vivado/SDK 2017.4. It looks like an issue with Vivado/SDK 2018.2 as @Darryl Ring states in the above post. thank you, Jon
  50. 1 point
    Darryl Ring

    Arty7 xemacp undeclared

    This appears to be a known issue in 2018.2: https://www.xilinx.com/support/answers/71330.html. It appears that support for the emaclite driver got missed in a change (https://github.com/Xilinx/embeddedsw/commit/16c05f56fcb860513d34b83a1a301fa185e06316). Their patch can't actually be applied to Xilinx/SDK/2018.2/data/embeddedsw, but the changes are small and easy to make. I've attached the file here. It should replace ThirdParty/sw_services/lwip202_v1_1/src/contrib/ports/xilinx/netif/xadapter.c. Then you can regenerate the BSP sources and it will compile. xadapter.c