• Content Count

    2164
  • Joined

  • Last visited

About [email protected]

  • Rank
    Prolific Poster

Contact Methods

  • Website URL
    http://zipcpu.com

Profile Information

  • Gender
    Not Telling
  • Interests
    Building a resource efficient CPU, the ZipCPU!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. @jean, That might make the task *much* easier. Consider (instead) building your signal of interest at 50MHz (or so), and then multiplying by a sine wave whose wavelength is an integer multiple of your oversample factor. For example, if you are oversampling by 32:1, multiply by a sine wave with four periods per every sample. That'll get you up to speed. Smaller frequency offsets can be handled in your original 50Msps domain if necessary. This operation will also introduce some aliasing products, just not from the sinwave. Whether or not those aliasing products are material to you
  2. @jean, The answer to this question really depends upon your application. What kind of waveform will you be sending? What is its bandwidth? Do you just intend to transmit a narrowband tone? A carefully crafted pulse? A narrowband (<100MHz) communications signal? Or an ultra-wideband signal? Each application needs a different answer, and has a different associated cost. Dan
  3. @jean, If this is the kit, then it advertises eight 6.554Gsps 14-bit DACs. Assuming you can get the outputs up and running at that speed (there should be a demo of this to get you going), you'll probably want more than just a table lookup for the sin/cos generation. A table lookup is good for about 8-bits or so. I like using linear interpolation to get more than 8-bits. You'll want to calculate multiple sinewaves at once, each at a lower rate, and then output all of these in series when sending to the DAC. To do this, you could either use the DDS compiler or build it yourself. O
  4. @jean, Let's start with the DAC then. What's the maximum sample rate, based upon its data sheet, that it can produce? Second question would be, how many bits wide is it? That should settle a lot of our questions. Dan
  5. @zygot, I ran a quick search for what frequencies a Xilinx FPGA might support. The MPSOC manual I have suggests support for 100GHz outputs. While this seems far fetched for me, I haven't dug into the statement to see either how they are managing it or how to set up that speed under the hood. If 100GHz is doable, surely 2.6GHz is as well. Now, 2.6GHz into an 8-12bit A/D? That'd be more challenging--but I noted that above. Perhaps that's not required--that'd be determined by his specification--which he hasn't (yet) shared. Not having a specific FPGA to have a discussion with or about
  6. @zygot, One other thought ... back in my service days, I remember a contractor presenting us with a proposal to build a receiver that would sample data at 8GHz and then bring that data into an FPGA. My point is: I think it's doable, but as I said above, I wouldn't recommend this problem to a beginner. Of course, we also had a separate problem with the whole concept: suppose you swallow 8Gsps of data into an FPGA ... what do you do next with it? Kind of like the picture below, no? Just because you can get an 8Gsps signal into an FPGA doesn't mean you're ready to do anythi
  7. @zygot, I haven't mentioned you or your comments yet in this thread because I felt they were right on and didn't need any more mention. I have had no disagreements with what you've had to say so far. I still don't. I've spoken from a generic standpoint--if you want to go faster, you need to parallelize things. There's nothing rocket science about this, but there are costs to doing so. The links I've posted discuss how to handle the task in general, from which you would need to build parallel logic to handle things. Here, again, you have said things well. This was why I was t
  8. @jean, Help me out here, what is "the IP DDC DUC from xilinx"? and ... Why is it that it cannot help you? Dan
  9. @jean, This is the perfect place to start a journey. Just be prepared to make a lot of mistakes along the way. I've certainly enjoyed my own journey so far. One of my FPGA mentors once told me: Pick a frequency, and build everything for that frequency. I have chosen 100MHz on a Basys3 (series-7 Xilinx FPGA), and so everything I tend to build runs at that frequency. This translates to (roughly) 80MHz on a Spartan 6, 50 MHz on an iCE40 HP*, 25MHz on an iCE40 LP*, and perhaps 140MHz+ on a Kintex. With a little work, I can build a design for a Xilinx FPGA at 200MHz, but it'd be a
  10. @jean, This article might give you some things to think about. But as @zygot hinted, you are getting at a very hardware dependent portion of the design space. You are also getting towards the limits of what the FPGA can accomplish in the first place. There will be a lot of tricks required to design a system like this properly. If this is your first design, you should probably think about doing something simpler and working towards something this complex. Dan
  11. @jean, Might depend upon how much quality you need in that 2.6GHz output, and how you intend to output it. Most FPGA I/O's won't work at that speed. Keeping multiple I/O's together, so as to drive a high quality A/D, might also be a challenge. Just outputting a signal that toggles at that speed--not nearly as much of a challenge. Dan
  12. @tcmichals, Thank you. That's news for me, I'll have to check out those links. Dan
  13. @amenah89, FPGAs are not computers in general. They don't run software, and so they aren't programmed. They can be configured with a hardware design. This is done using Vivado. If your chosen hardware design uses a CPU, such as a MicroBlaze CPU, then you can program that CPU within your design. This is now done with Vitis, not Vivado, but you will need a CPU design within your FPGA design to do it. That said, CPU's are notoriously slow for processing video, so I don't think you would want to do that at all. The first problem you need to solve is to answer the question of how yo
  14. @HAMZA, I'm not sure why you are yelling (all caps). It's generally not a good way to encourage someone you don't know to help you out. That said, @hamster posted the link for his work above. I found the edge filter within it without any problems. Dan
  15. @newkid_old, @tcmichals, There is no ARM processor on the Artix-7. The ARM processor is a piece of physical real-estate that is present within a Zynq FPGA, but not within an Artix-7 FPGA. The Arty-A7 boards are built around the Artix-A7 FPGA's, and so the processor isn't present to be configured in the first place. The ARM processor is very different from a MicroBlaze processor. The MicroBlaze processor may be built out of the fabric of an FPGA--out of look-up-tables and flip-flops. Unlike MicroBlaze, the ARM processor is built onto the chip itself--if it is present at all.