Leaderboard


Popular Content

Showing content with the highest reputation since 06/11/20 in Posts

  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
    JColvin

    Arty A7 flash clock

    Hi @[email protected] and @zygot, I apologize for the long delay. The pin is indeed still present on L16 on page 6 of the schematic and is almost certainly the intended use of that pin. I'm not sure why it's not the .xdc (or if it ever was, since realistically the .xdc was copied over from the original Arty .xdc before a bunch of other Arty branded boards were introduced), so I'm working to confirm that there isn't some reason that the pin should not be in the .xdc and then we get it added in. Thanks, JColvin
  3. 1 point
    attila

    How to Find Trigger Rate?

    Hi @jpaulus There is no dedicated trigger frequency measurement available. It was supported very long time ago, but it was not too popular. It was removed and the device resource reused for other features. Now you could use the following setup to measure the trigger rate: 1. You can connect Trigger 1 to DIO 0 wire. 2. Configure Settings/ Device Manager/ Trigger 1 = Scope Detector. 3. In Logic Analyzer configure Sync capture with Clock on DIO 0 4. Use a Script to measure the time it takes to have certain amount of triggers. var t = Date.now() Logic.single() Logic.wait() t = 0.001*(Date.now()-t) // milliseconds to seconds print(Logic.Time.Samples.value/t) // rate = trigger count / time
  4. 1 point
    Ok, found the problem after reading this post, which described sort-of similar problems: https://forum.digilentinc.com/topic/19306-digital-discovery-spi-repeating-trigger-problem/ If I install the latest beta version (3.13.22 beta) the DD devices work as expected (generated frequency within ~ 10 ppm). Also, the input side (sampling an externally generated clock) is much more stable. So it seems to be a firmware bug in the current 'official' release which is fixed in the beta. Hopefully a new official release will be out soon.
  5. 1 point
    JColvin

    Pmod I2S2

    It looks like I was looking at the output sample rates rather than the input sample rates on that same page; I have adjusted the reference manual to only reflect the lone single speed sample rate. Thank you for pointing out this error.
  6. 1 point
    JColvin

    Pmod I2S2

    Hi @Rainer, I'll look into this some more. The CS5343 datasheet on page 9 does explicitly list both of these two sample rates, though I'm not sure of the difference between them as of yet. Thanks, JColvin
  7. 1 point
    ssm

    ADC bits and resolution

    got the answer here: thanks anyway
  8. 1 point
    Hi @m72 You could use "Not Ends with" or "Not Contains", Filter: "K"
  9. 1 point
    Hi all, I've developed a few audio and video example designs for the Nexys Video in VHDL and posted them here: https://github.com/amb5l/tyto_project I am planning to expand on the HDMI IP to make it more general purpose, and add DisplayPort eventually. There is more stuff in the pipeline. Grateful for any feedback.
  10. 1 point
    @[email protected] @zygot Quick update: the Xilinx clock domain crossing macros work fine and I have eliminated the timing exceptions. Thanks for your input.
  11. 1 point
    zygot

    Video RAM in DDR

    On a slightly higher level of conceptualization, for something like a video buffer. I do want to point out that a lot of solutions to FPGA design problems have nothing to do with programmable logic or HDL or development flow. While being given a relatively easy path to constructing complex structures may get you so far... they also only get you so far, and are limited in how you can use a very limited set of structures. Better to learn about video, and older ways of implementing video and constructing those structures. There's a danger to having a false sense of accomplishment and thinking that you've overcome a particular design obstacle, when in fact you've just used a borrowed toy that you can't keep. Like most things in life, the quality and usefulness of things that you acquire are directly tied to the amount of work and effort put into obtaining them. Perhpas. one day, the only source flow for FPGA development will be an AI that you say " Hey Vivi, I'd like to do.....". I for one, am not waiting with eager anticipation for such a day when man is dumber than his robotic creations or can't imagine without them.
  12. 1 point
    zygot

    Video RAM in DDR

    @Ciprian, I'm glad that you decided to add a bit more shading to a very important philosophical concept. It's hard to capture all of the important facets in one post reply. While you are correct that I do advocate for what is a harder, slower and more demanding design source choice in going all HDL, I do understand that there are projects and people for whom that might not be the best choice. No one know how hard it is to maintain a demo so that customers can replicate a project over the course of even a few Vivado revisions than the fine people at Digilent. A high percentage of posts to the FPGA forum revolve around user's inability to merely build demos created in older versions of Vivado. What I can say with certainty on that subject is that I have HDL code that I wrote 20 years ago, not even for a Xilinx target device, that I can still use today. No hassle, just add the source to my current project. True, some use basic resources like block memory or clock generators that are implemented differently from device family to device family or vendor to vendor, but even those are pretty simple to change. A recent version of Vivado broke all HDL source code using its own basic resource IP. But fixing the issue isn't a major headache. As long as I record notes about the design process and document my code well I never lose the IP that I write, nor the understanding of how to address a design problem. If your design relied on IP that was free and was changed to requiring a license there's only only one option, which is to keep an older version of Vivado around to use the 'free' IP. The quotes around free are there because free always has a cost in one form or another. The 'free' IP and board design flow can certainly produce a result in a short period of time but it also comes with not so obvious strings attached. Some of these strings you've pointed out. The truth is that it takes time and commitment to get to the point where anyone can master FPGA development to the point where you can have the confidence to tackle complicated projects with all HDL source code. My argument is that the board design approach entices novices into thinking that you can do substantial FPGA development without the HDL skills. I say, after you have the skills then perhaps you are in a position to evaluate whether or not the 'free' IP is worth the cost. I liken the board design flow to a walled garden, but perhaps a sandbox is a more appropriate analogy. Sure, there are things that you can do without much knowledge or hassle in the sandbox but eventually you will get bored with the limited toys available to you and need to add your own HDL anyway. And no one like having their limited selection of toy taken away form them once they are relied on. To my way of thinking, the hard arduous path to working with programmable devices is the inevitable path if you are going to keep doing FPGA design for any length of time. If you have any interest of doing FPGA development professionally, then you have better have the skills and experience in figuring out how to find your own conceptual design solutions and strategies for debugging designs and verifying designs. The board design approach provides little or no support for the really important skills needed to be self-sufficient. I completely agree with the premise that it is up individuals to decide what design source flow is best for them or their project. And considering all points of view and the experiences of others is an important part of that decision making process.
  13. 1 point
    elodg

    cmod S7 zyboZ7 connection

    UART over Pmod.
  14. 1 point
    zygot

    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.
  15. 1 point
    Dannny

    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.
  16. 1 point
    zygot

    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.
  17. 1 point
    Ciprian

    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
  18. 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
  19. 1 point
    JColvin

    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
  20. 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 )
  21. 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.
  22. 1 point
    I've developed a few audio and video example designs for the Nexys Video in VHDL and posted them here: https://github.com/amb5l/tyto_project I am planning to expand on the HDMI IP to make it more general purpose, and add DisplayPort eventually. There is more stuff in the pipeline.
  23. 1 point
    zygot

    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.
  24. 1 point
    NightTrain

    Many dozens of signals to monitor.

    Thank you.
  25. 1 point
    Hello @macellan, That's because you've already added one. I can see it under the XADC System monitor.
  26. 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.
  27. 1 point
    JColvin

    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
  28. 1 point
    xc6lx45

    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.
  29. 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
  30. 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;
  31. 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!
  32. 1 point
    What will manage access to your SDCARD? Do you realy whant to share data via SDCARD? https://github.com/OpenAMP/open-amp#example-to-compile-openamp-for-communication-between-linux-processes Why not use shared memory? https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_1/ug1186-zynq-openamp-gsg.pdf https://github.com/OpenAMP/libmetal https://github.com/OpenAMP/libmetal#shmem
  33. 1 point
    attila

    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.
  34. 1 point
    Hi @Wayne Chen You can find message view and time stamps in the Protocol tool.
  35. 1 point
    JColvin

    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
  36. 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
  37. 1 point
    elodg

    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.
  38. 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/
  39. 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.
  40. 1 point
  41. 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.
  42. 1 point
    Jonas

    AD2: ERC: 0x2 with Raspberry Pi 4

    Congrats @attila, you fixed it! Many thanks for your work! It now works perfectly
  43. 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.
  44. 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.
  45. 1 point
    Step “11. Verify Linker Script File for Memory Region Mapping“ of the guide calls for linking the whole application to the cellular ram, which is easier than trying to make it fit in the BRAM.
  46. 1 point
    Hi @STEAMClown, I apologize for the delay. I did some digging since I've personally never even heard of this board before, and while I was not able to find any written documentation (I suspect there isn't any to be found), I was able to locate the schematics for this board which I have attached, though it doesn't look like there are any hidden gems with this board. Let me know if you have any questions. Thanks, JColvin LIN sch.pdf
  47. 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.
  48. 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.
  49. 1 point
    JColvin

    Xc9536 jtag

    Hi @Jpyro1, In general, the Digilent programming cables are not compatible with the 9500 series CLPDs. There is one comment from another user on our Forum here, https://forum.digilentinc.com/topic/3607-jtag-usb-programming-xilinx-9536-with-impact/?do=findComment&comment=13548, that says they were able to program a 9536 CPLD by creating an SVF file with iMPACT and then program the device through Adept. I do want to clarify that those of us here at Digilent have not attempted this though, so I can't vouch for this method. Let me know if you have any questions about this. Thanks, JColvin
  50. 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