Popular Content

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

  1. 1 point

    compiling for arduino board

    Hi J. Colvin. Thank you for that information. I am delighted to say it worked. I cleared the two libraries and started everything the sketch on a new version and then downloaded the libraries again, loaded the sketch manually as it is a short program and it is working fine now. Thank you again for directing me where to look for the solution.
  2. 1 point

    Pmod DA4 Stopped Working

    Hi @mladenik, I'm sorry your PMOD failed, It's a very long shot to get it work again since it's only one chip and doesn't have extra things. Most likely something wend wrong it it, either from an ESD event or some kind of short circuit. If you can, you can at least exclude a short circuit by measuring the impedance between VCC /DATA pins and GND. If you don't have power at all, if you don't have the 3V3, it can be either that it's a short circuit on one of the capacitors or that something went wrong with the chip. If it's a capacitor, you take it down, and it might have a small chance to work again. Normally a burned capacitor can be visible optically. If the filtering capacitors are fine, then you should think give up on the PMOD if you are not willing to replace the DAC. Best regards, Bianca
  3. 1 point

    FFT output result using Xilinx FFT core (v9.0)

    @RCB, Why are you converting things to sign magnitude form, vs just leaving them in twos complement again? I'm not certain what's going on. Were this my own project, I'd use an FFT I'd be able to "see" inside of so that I might debug the problem. Specifically, I'd look for overflow problems within the FFT--at least that's the only thing I can think of that might cause the bug you are referencing above. It doesn't make sense, though, that you'd have overflow with one FFT and not with an identical FFT that only differed in output ordering. You might wish to compare the .xml files of the two FFT's to see if they are truly the same as you believe. You might also wish to try dropping the amplitude by a factor of 4x or perhaps even 64x to see if that makes a difference. It might be that you have the scaling schedule messed up and that things are overflowing within. It might also be that you aren't looking at all of the output bits with your bit-cut selection above--I can't tell by just looking at it from here. Dan P.S. I don't work for Digilent, and do not get paid for answering forum posts.
  4. 1 point

    JTAG-HS3 warm, locks up system

    @Don Koch Excessive heat suggests that there may be a damaged component on the board. The reset line is active low and is driven by an open drain buffer that has a 100 ohm series resistor between it and pin 14 of the JTAG connector. There is no onboard pull-up on the reset line and it is assumed that the host board will pull the line to the inactive state (high). When you say reset is not being asserted, do you mean it's always high or always low? Does your board have any push-pull buffers that drive the reset line? When you say remove power do you mean remove the USB cable or remove VREF from pin 2 of the JTAG header? The onboard buffers will tri-state when they aren't powered. However, the output buffers are powered from the VREF pin of the JTAG header, while the USB controller, which drives the inputs of the output buffers is powered from USB VBUS. If VREF is present but USB power isn't then the buffers will be powered but they should still be held in tri-state because the output enable pin is pulled to ground through a resistor. I don't think you will need to insert extra buffers between TMS, TCK, and TDI. Thanks, Michael
  5. 1 point

    Cora Z7-0S AXI for external DAC

    @satvik, I'm not seeing any bugs in TestDAC3_v1_0.v. If there are any there, they aren't standing out to me. Dan
  6. 1 point

    Cora Z7-0S AXI for external DAC

    @D@n, as usual provides some valuable insight that most people would have missed. My first comment has to do with using the AVI-Lite bus. I agree with Dan that AXI busses, even the 'lite' ones are overly complicated for most PS-PL designs. If you are going to use a standard bus then you have to understand how it works.. before designing with it. Bussing signals doesn't have to be complicated. If you want to have IP ownership over a technology then you embed lots of functionality into your bus standard and it becomes complicated. In general I avoid Wishbone, AXI and other similar bus standards to the extent possible. It's horrifying that an FPGA vendor would promote and propagate bad design habits to their customers. One way to side-step using a bus with complications that you don't want to deal with or complexity that you don't need is to not expose the bus to IO pins in your board design schematic. The dual-port BRAM controller is one interface that I've used; exposing the signals on side to external pins in the board design. Once I've generated the board design I always have Vivado generate and HDL wrapper, that I, not Vivado, controls and use that wrapper as an instantiated design element in my own toplevel design file. I can then instantiate any number of additional components into my toplevel design as if it were an all HDL project. I have to take care of more details this way but I've found this to be a lot more manageable and a lot less frustrating way to do ZYNQ designs. My second comment has to do with Dan's discussion about the flaws in Vivado generated code. I'm all in favor of using a tool to identify bad code, when it's available. Everyone, regardless of experience, writes poor code at some point or another; if you have access to a "brain-fart" checker then why not use it? As long as it doesn't automatically change your source, the way that a spell checker does I don't see a downside. In the case of the if-the-else structure you have to make sure that all possible conditions and all possible states for those conditions are handled. This is not always easy to do. Even evaluating the output of such logic isn't always straight forward. Nested if-then-else structures can have multiple combinatorial logic levels and unpredictable delays and behavior. Understand the implications that come with using a particular coding structure when doing synthesis for logic design. There are two types of resets, synchronous and asynchronous. You can have both types in your process statements. Be aware that the concept of logic reset isn't nearly as simple as one would assume.
  7. 1 point

    Cora Z7-0S AXI for external DAC

    @satvik, Nevermind--I figured out how to open your archive. Here are some of the things I discovered while looking at the file testDAC3_v1_0_S00_AXI.v: You are using Xilinx's IP packager's code to start out. You should be aware that this logic is broken, and will likely cause your design to lock up eventually. It makes one of the more common AXI mistakes within it. The design has now been broken for about 4 yrs, and its a shame Xilinx has yet to publish an errata to Vivado for it. You can find an alternative implementation here. I'd recommend formally verifying your AXI-lite IP before trying to place it onto hardware. It's fast, and fairly painless, but will also find these bugs for you. I recommend to all that they start any design file with "`default_nettype none" and then, before running Vivado to try to synthesize the design, that they run "verilator -Wall -cc file.v". You'll find a lot of bugs this way, and you'll find them much faster than it takes Vivado to even start considering your files. If you can get Verilator to pass your design without warnings, chances are your bug will be fixed. (In this case, and having looked at your code, I'm pretty well convinced this would be so.) You have declared cnt as a value with 33 bits in it, but are then only operating on 32 of them. This appears to be an error, although not yet the error you are struggling with. You'll also find it's easier to compare against 32'd_100_000_000 than the binary value you have. Even 32'h05f5e100 would be easier to follow. led0 isn't used. This plus cnt are probably removed from your design by the optimizer. Your commented assign, "assign led=Led;" would fail with the symptoms you've described above, simply because Led is never assign in your IP. Verilator would've caught this for you. Hope that helps, Dan
  8. 1 point
    Hello @Hos Sam97, Nexys A7 have the same UCF file as Nexys 4 DDR. You can download the UCF file from here. The UCF file contains the constrains for all the Onboard I/O.