• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by D@n

  1. @macellan, I'd want to read from the flash myself to know what was going on. For example, was the image actually written properly to the flash? Does the flash require a QSPI enable, or is it being asked to start the design in QSPI mode without first having the QSPI mode enabled? Some flashes also don't reset fully either. When using one of those flashes, you'd want to attempt a full power down reset (to make certain the flash is properly reset) before restarting the design. My recommendation would be to pull up the data sheet, and read the various control registers from the flash to see what's going on. There's also a boot status register in the FPGA that you can use to find out error codes from the last time it tried to configure itself. Check out the ICAPE2 port for access to that, to see what's going on there. Dan
  2. @apchar, I recently had an opportunity to do some gateway defined radio work with an iCE40 Ultra 5LP, a digilent MIC3 MEMS microphone PMod, and a SX1257-Pmod for a radio. Hardware wise, the set up was really easy to do--and so I'd recommend it to you at all if you are interested. You can find my project, source code and references to hardware, here. Dan
  3. D@n

    PmodSD on CMOD A7

    @PTSmith, This matches my own experience. Just don't ask me to explain it to you, 'cause I'm not sure I understand what's really going on either. Dan
  4. @yongseok, Slow down, start from the top: What's in your design, what's your design doing, what inputs are you feeding it, etc. Debugging an FFT is just like any other engineering task: split the design into parts, and separate what's going into the FFT from its surroundings, then test each individually. With the information you've given above, it would be hard to know where to start breaking down the problem. Dan
  5. @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.
  6. @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
  7. @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. @satvik, I'd like to help, but my system doesn't seem to know how to open your archive file. Can you just attach your AXI slave IP by itself? The Verilog (or VHDL) file? Thanks! Dan
  9. @RCB, Did you notice the glitch in your source signal in the second plot? It's in both data[] and frame_data. You'll want to chase down where that glitch is coming from. After looking at that source signal, I noticed that the incoming frequency of your first image didn't match the 1MHz frequency you described. At 1MHz, you should have one wavelength inside of 1us. In your first plot, it appears that one wavelength fits in 20us, for a frequency of closer to 50kHz? Further, I don't get your comment about holding config_tvalid = 1. If you have created an FFT that isn't configurable ... then why are you configuring it? It's been a while since I've read the book on the configuration --- did you hard code the scaling schedule into the FFT, or are you configuring that in real time? I can't tell from what you are showing. You also weren't clear about what config_tdata is. Was that the all zeros value you were sending? Finally, the difference you are seeing between natural order and bit-reversed order is not explained by the simple difference between the two orderings. There's something else going on in your design. Dan
  10. @xc6lx45, Thank you for pointing that out. That explains some things I've seen on a recent design of mine. Here I just thought it was because I was cascading so many PLL's together--you know, typical Voodoo design methodologies ... Dan
  11. @Sid Price, Oops ... this is the scopes and instrumentation forum and not one of the FPGA forums, isn't it? Ok, then your request makes more sense. I'm sure @attila will have a comment for you then--he's been very diligent about answering and resolving AD2 requests. Me? I'd probably build a basic Octave script to do what I described above with a data capture. I'd first run everything through a filter, as discussed above. I think Octave has a "conv" (or is it "convolve"?) function that can apply the filter. Remember--the filter isn't a rectangle, but a pair of rectangles with opposite polarity. I'd then make a copy and calculate something like X(t-T/2)*x(t+T/2), where s(t) is the filtered sample stream and T is the number of samples per doublet. If you filter that new stream narrowly around your sample rate, perhaps even via an FFT based filter, you should find a maximum at the mid-point of every sample. That would save you the hassle of needing to run the PLL--something not nearly as appropriate on sampled data. Once you know where to sample, you should then be able to just take a threshold to get each individual bit. It's easy once you've done it once or twice, although I can understand why you might think of it as black magic if you'd never done it before. Dan
  12. @Sid Price, Do you really need a custom decoder? Manchester is pretty easy to decode. There's lots of ways to do it too. I'd be tempted to apply a matched filter to the doublet, and then treat the signal as BPSK. That'd be the "optimal" solution, but often you don't need the "optimal" solution so a lot of other ways exist to do it as well. Let's see ... you can find an example filter here that might work well, and here's an example PLL you could use too. You could even get fancy, given that you are only ever "multiplying" by one or negative one, and so remove all the multiplies from the filter as well. You could go even fancier and adjust this symmetric filter for this purpose too ... Indeed, there's lots of options. What more do you need? Dan
  13. @HasanWAVE, Might it be because your Zynq design only supports AXI3 and not AXI4? The maximum AXI3 burst length is only 16 beats. Which board are you using? Also, this really belongs in the FPGA/embedded forum, not the microcontroller forum. Dan
  14. @bitstre@m, It sounds like you are working with a MicroBlaze based design, since you mentioned a .mcs file above. Xilinx provides an AXI QSPI core that you can use for this purpose. I've personally used my own QSPI driver, and my own CPU. You can find my CMod S6 project here. Perhaps it might serve as an example. To use the QSPI flash, I had one design that I used to program the QSPI flash device on my CMod S6 with (whatever), and then a second design that would use the flash within the design. Sadly, the S6 is such a small device, that you really need to be careful with the logic you try to place onto it. I was pleased to be able to get a "multi-tasking O/S" running on it, although it was only the barest minimal one. Storing instructions on the flash was key to the success of that project. You can read about the instruction fetch that I ended up using here if you would like. Dan
  15. @Dan Lyle, I assume this is your post on Reddit as well? Rather than answering twice, I'll let you find my answer there. Dan
  16. @rddlr, It doesn't look like you've done anything to debounce those buttons. Check out the diagrams here for example waveforms of what a single button press (or release) might look like without debouncing. Indeed, some of those waveforms (not all) were even made with an Arty FPGA board. Looking over your code, I don't see anything in what you've written that will take care of button bounces. You might find this article gives the instruction you need to deal with them. Both of them are part of a series I wrote some time ago on debouncing buttons. Dan
  17. @weilai, Both Digilent and Xilinx provide training materials for how to use the SDRAM on the Arty board. These materials all involve using the schematic based board design. I have not used this board design, as my own approach is an all Verilog approach. If this is the approach you are interested in, than I would not recommend an SDRAM as your next project. I would instead recommend a next project that you could use as a spring-board for other things--a project where you learn how to command/control your design externally, and to debug the design from within. Only after you've learned these lessons will you be ready to go after the SDRAM. These are all things I discuss on my blog. Once you are ready to go after the SDRAM, there are a couple of approaches. My own approach, and the one I use with my Arty board, is to instantiate Xilinx's controller via their Memory Interface Generator. I then interact with this controller using a Wishbone bus structure common to all of my designs. A Wishbone to AXI bridge renders this controller available to me. I also use a UART to Wishbone converter, which then makes reading and writing peripherals within my design from a serial port fairly easy to do. This, of course, is all before I get to the SDRAM--and becomes the infrastructure I use to figure out what is (or is not) going on when I build an SDRAM controller. In other words, if you don't want to use a canned solution, then take a deep breath, slow down, and get there methodically. Dan
  18. @HasanWAVE, You don't. You can't set a submodule's register from the top level. Verilog provides access to this register for verification purposes only, but it's not available otherwise. Dan
  19. @weilai, The .prj file @JColvin refers to is an XML (i.e. text) file. I was able to use it to create this UCF file. That's going to be the least of your problems. See my answers in the other thread for more of what you'll need to deal with. Dan
  20. Weilai, Okay, trying to build your own DDR3 SDRAM controller ... and not sure what you are getting into, yet, okay ... Dynamic RAM is not like static RAM. It's built out of capacitors, rather than FF's, so it needs periodic refreshing as the capacitors drain their charge over time. Synchronous Dynamic RAMs (SDRAMs) are typically organized into banks of memory, where each bank has a special row that may be "activated" and placed into FF memory. Only the activated row may be read or written at any given time It takes some time to activate a row, some time to deactivate it (called pre-charging), and some time to get the memory from the active row. This all requires clock ticks. The DDR3 SDRAM's use a very fast memory clock--typically 4x faster than your logic. It's also 90 degrees offset from the logic as well. Since most SDRAM's work based upon commands given to them, you'll need to examine and get familiar with the command set--there are also very strict requirements between commands too--for example, all banks must be precharged before issuing refresh commands, rows must be activated before access, etc. You'll need an OSERDES of some type to issue these commands. The data wires are the tricky part of the interface. In general, the outgoing signals can be created with an 8:1 DDR IOSERDES. That's not the hard part. The hard part is on receive, where the "clock" for a given byte is returned in a data strobe wire. This clock is discontinuous and only activated when return data is incoming. Indeed, this was such a challenging part of the protocol to handle that Xilinx created special hard-IP blocks in most FPGAs for this purpose--the IOPLL, PHASER, and ... there's an I/O FIFO block of some type as well to handle the asynchronous clock rate conversion--since the DSTB return clock, while at the same frequency as the master clock, will have an uncontrolled phase difference to it. To make matters worse, the key details of these components have been kept Xilinx proprietary, and so they are undocumented. This is all covered by the JESD79-3E specification. If you really want to interface with the SDRAM, you'll need to do some reading. (JEDEC charges a small fee for a copy.) You can read about my own attempts to build an open source DDR3 SDRAM controller here. The code is still public. I think I got all the logic right, up until the required Xilinx primitives and particularly the incoming DSTB logic. Of course, since it has never been successfully demonstrated on real hardware you can just about rest assured that it's broken. There is an open source DDR3 SDRAM driver that has been demonstrated. I haven't used it myself, although I have browsed through the code. It's not simple to do. So, that said, let me ask, are you sure this is what you want to do? Dan
  21. @weilai, I'm a bit confused. 1) I don't have MS, so I can't read your PPT image, 2) I don't remember RAM pins like WE, RE, or ADDR[2:0] on the top of the ARTY schematic, 3) you seem to have a RAM module within your code as well that, 4) checks for re && !we ... so let's back up a bit. Which board are you working with? Is it the Arty A7-35T board? Are you trying to connect with any chips which are off of the board, or are you attempting to connect to components within your design, or the DDR3 SDRAM chip on the board? If the latter, your interface is ... nowhere near the correct one. Have you simulated your design? I discuss how to go about simulating a serial port design very similar to this one in my tutorial. Have you formally verified your design? Also discussed in my tutorial. Dan
  22. @Burak Maden, That looks like an awesome example! Unless I've misread it (which is quite likely), it looks like you should be able to just modify the constraint file to match the Basys3 board and then use it. Are you expecting more trouble than that? Dan
  23. @Burak Maden, How different do you expect the two to be? Dan
  24. @globieai, Octave isn't much of a "simulation tool". It's more of an ad-hoc scripting tool that looks and feels very similar to matlab. It works well for verifying that the output of a simulation is the output it should be. For simulation tools, let me encourage you to look into ghdl (and open source simulator) in addition to xsim (Vivado's simulator). Dan
  25. @Burak Maden, I believe you can find 7-segment display code here, together with some explanation. I've never tried it myself, so I have no idea if it works or not. Dan