All Activity

This stream auto-updates     

  1. Past hour
  2. Hi @Iceman2020, You are correct. I have edited the original posting to now contain this correction. Thank you, JColvin
  3. I am trying to compile the Cmod-S7-25-XADC Example Version 2020.1-1 with Vivado 2020.1. The readme says: 4. In the toolbar at the top of the Vivado window, select **File -> Export -> Export Hardware**. Select **\<Local to Project\>** as the Exported Location and make sure that the **Include bitstream** box is checked, then click **OK**. But when I execute "Export Hardware" there is the error message: Cannot write hardware definition file as there are no generated IPI blocks The next step says: 5. In the toolbar at the top of the Vivado window, select **File -> Launch SDK**. But there is no such option. It looks like the readme is still for Vivado 2018. Is there an updated readme available ? How can I use this example for 2020.1 ? I am using Webback Version. Do I need a full license ?
  4. Today
  5. I'm a Patterns newbie. I'm trying to produce a stable clock output that is steady, in free-running mode. Presently I'm not using any triggering, simply setting up a single DIO line to be type Clock, PP output, Continuous mode. What I'm getting is a square wave output that is not stable - it 'shifts' periodically as if Patterns is outputting an expected sequence of nice clean square waves, then resetting, and then outputting another good sequence of square waves. How do I set this up to produce output that is totally stable, without the periodic 'hiccups'? My goal is to produce a digital pattern consisting of 8 channels, each as PP output, each executing at its own specific frequency, and synchronized to line 1 as the clock line. And without any instability in any of the outputs. If this needs to be done in some mode other than free-running, with the use of a trigger input, that's ok. But the tutorials and manuals don't seem to cover what I'm trying to do in enough detail.
  6. If you can wait a few months to make a purchase and can get an academic discount that's obviously the cheaper way to go. Even at $1K per pop the Genesys2 is a fantastic value and heavily subsidized by Xilinx. If you doubt this then, while you're at the distributor's site do a search for the XC7K325TFFG900C-2 part and compare the price. Note the lead times. If you think that you're at the wrong distributor then try Avnet or one of the bigger distributors. It's unfortunate but Xilinx seems to have moved on to other newer families for scheduling fab orders. I don't know of anything close to the Genesys2 on the market at the normal retail level. Kintex and UltraScale Kintex are great niches in the FPGA marketplace... if only small developers could buy them and make a profit selling Kintex based products... I wonder if Xilinx regrets going fabless, yet...
  7. Hello @tuskiomi (and other curious readers on this thread), I confirmed with our Sales Manager that Digi-Key does not do any academic discounts (and for reference, very few distributors will do academic discounts; the only one that I am aware of is Trenz Electronics, but that is only for German customers. But I don't think they have any Genesys 2's in stock even if you do happen to be based in Germany). I am waiting for confirmation our FPGA Product Manager that the timeline listed on the Genesys 2 store page, i.e. boards slated to be shipping again from the Digilent store directly in September 2020, is the most up to date information. Edit: got confirmation that the September 2020 date on the store page is still accurate. Thank you, JColvin
  8. Good to see that I'm starting with the trivial implementation.
  9. I think I see where this is heading ... there are essentially two design corners: a completely systolic, one-cycle-per-operation architecture, and a CPU-based architecture where everything is funneled through a single ALU. Both extremes are fairly trivial to implement, the former going through the roof with its resource usage and you will have a hard time feeding data in to actually use it. The latter (=run C code) having its lunch eaten by any "hard" CPU core on the same technology node. The design space in-between is where it gets interesting for FPGA, but also much more challenging.
  10. Didn't consider this but even more reason to send an email to @JColvinor someone else... gee I think that I just did it for you.
  11. I should also point out that the Genesys2 has a very nice HPC FMC connector so you can add a USB 3.0 interface if you need to transfer large amounts of data between your FPGA platform and a PC. More information to process. You won't find an FPGA board with more FPGA resources than the Genesys2 for anything even close to the 'poor slob highest price' point.
  12. Indeed, you are correct.
  13. He's probably talking about academic discounts, not license vouchers.
  14. About PCIe FPGA boards. I should point out that PCIe boards are detected during BIOS boot so you can't re-configure the entire FPGA from a PC application and keep running... you have to reconfigure and reboot. For a price you can do partial reconfiguration on the fly though and have a true application accelerator. It's just something to know about before jumping on board.
  15. I'm pretty sure that you can get a license voucher from Digilent even if you purchase the board from a distributor.. get an answer from Digilent to verify.
  16. But it's so satisfying! No really, the unnamed company in question is a study in how companies suffer from their own scorch and burn competitive strategies. Really, competition is good for everyone, including those who have an affinity toward monopolistic control over an industry. It's unfortunate that we've reverted back to the bad old 19th century as a society. When I make my cheap shots I take it seriously. Know you history future tech overlords! Now to you other application. The perfect board for you might be the Terasic C5P or as it's now know the OpenVino start platform. It's designed to be a PCIe PC board and the GT version has 4 lanes of Gen2 PCIe so it's more of an extension to your PC. Your neural network application is precisely what the board is designed to do. I'm no expert in neural networks but my impression is that the typical FPGA isn't ideal for applications though might be swell as a platform for exploring ways to speed up the process. The board is relatively cheap and has good Linux and Windows driver support. The Cyclone V isn't up there with the Kintex 325T in resources but you should at least check it out. If only there was a similar board for us Xilinx users....
  17. Does digikey honor digilent academic discounts
  18. It's in stock at Digikey right now.
  19. Okay, processor company jabbing aside ;-), I'd like to introduce my other application. Years ago I created a program which takes trained neural networks, and exports them to HDL -like formats (think lots of LUTs). Eventually, I'd like to take these neural networks, and if resources allow, place them directly into the fpga, which would allow a trained network to be executed in just a small number of clock cycles, instead of multiple hundreds. Trouble is, neural networks require lots of resources. One neuron will take up 8 LUT inputs, which is silly when you have thousands of neurons, and then you need to consider a memory loader, etc. In any case, lots of LUTs are preferred, and I think the genesys 2 is my board. Trouble is waiting.
  20. If you've been using this IP for your project then check out the improvement here: https://forum.digilentinc.com/topic/20479-inter-board-data-transfer-project/
  21. @falcon98, Check out this project: https://forum.digilentinc.com/topic/20479-inter-board-data-transfer-project/ It is not a complete answer to your problem, yet... but might be helpful. The project has been in the works for some time but your question prompted me to look at a medium performance solution to it.
  22. @shlomishab, Absolutely! This is the job of the engineer, to know how to break a project up into subcomponents and measure which of those subcomponents are at fault. This is also what makes FPGA design difficult: because it is a challenge to debug designs after they are placed on a circuit board. Indeed, debugging FPGAs is perhaps the hardest part of the job. It requires a methodology and discipline that isn't necessarily carried over when coming to FPGA design from other fields. Why? Because you can't "see" into the FPGA. Unlike software, where you can stop it with a debugger at every step and examine every variable, you can't do that with an FPGA. (You can do it with simulation ...) Worse, it's hard to even examine variables from within an FPGA at all. Here are some good rules of thumb: Your first step to debugging is what's known as "static" checking, sometimes called "linting" in the software world. I like to use "verilator -Wall" for this--but that only works with Verilog modules. Vivado will also present warnings to you when it synthesizes your designs. (Verilator's warnings are more usable ...) When things aren't working, look over the warnings. It might save you hours of debugging. *EVERY* module within a design should have a "bench test" of some type, some way of determining that it works before it ever moves forward. In the larger companies that I've counseled over the years, a bug "escaping from unit test" is a *BIG* deal that gets a lot of engineering attention. It happens, but your goal should be to keep it from happening--it just "costs" a lot more work to find a bug after a module has left unit test. I do most of my bench testing using formal methods. Others set up rather elaborate simulation scripts to find bugs in individual modules. The difficult part of building simulation scripts is that ... you can't always predict everything that will go wrong. Formal methods often help you pick out things that might go wrong. When you purchase IP from someone else, or otherwise acquire it, look for this bench test. Vivado tries to make this easier by building a simulation script for you when you choose to create a custom IP. I don't use this script. I don't trust it. Their simulation script misses too many bugs. For example, I know (and have blogged about) bugs in every one of their AXI slave examples--both AXI and AXI-lite, and their AXI-stream master is also broken. These bugs don't show up under their simulations, but they do show up under a formal methods check. SymbioticEDA makes a product called SymbiYosys which you can use to formally verify Verilog designs. They sell a SymbioticEDA Suite for handling SystemVerilog and VHDL designs. They've also posted a similar product called mcy (mutation coverage with Yosys) which can be used to determine if your test bench is good enough or not. That is, if some piece of logic gets mutated (i.e. broken), can your test bench catch it? Evaluating your test bench to determine if it is "good enough", therefore, is the purpose of mcy. Once *EVERY* component has been formally verified (or otherwise bench tested), and only then, should your methodology move on to an integrated test. Integrated tests are still simulation tests. &nbsp;Why? &nbsp;Because, in simulation, you can see every variable, every value, at every time step. Sure, it's slow. Sure, it's clunky. However, it's much easier to figure out what's going right or wrong from simulation than it is from hardware. Only after your hardware passes an integrated simulation test should you ever move forwards onto real hardware. In the digital design field, this usually means FPGAs. For some of us, the design work stops at the FPGA level. For others, it goes on from FPGAs to ASICs, but FPGAs are usually a good first step before ASICs. Debugging a design within an FPGA is usually much harder than in simulation, but with the tradeoff that the FPGA can run at full speed (or close to it), whereas the simulation cannot. In order to debug a design from within an FPGA, you'll need a special piece of FPGA logic sometimes called an In-circuit Logic Analyzer (ILA). I like to call them "internal scopes". This will cost you logic and block RAM resources within your FPGA. Using a "scope" you can capture a limited number of values from within your design. As an example, I might capture 32-bits for 1024 clock cycles and read them back later. Inside a devices with thousands of flip-flops and millions of clock cycles per second, this is like trying to drink the ocean through a straw. There's an art an science to getting the right values, and to capturing them at the right time. Sometimes even the scope fails. In these cases, I like to use LEDs to try to debug what's going on. Using an LED, you can often debug missing clock problems, problems with clock not locking, and more. Sometimes a scope helps, and Digilent's Digital Discovery has been invaluable to me. Returning to the idea of using graphics on an FPGA, feel free to check out my own video simulation here. Since that article was posted, I've written AXI versions of the various demonstrators. Once you can run your design in simulation, then feel free to try running it in actual hardware. Then, when/if it dosn't work, feel free to write back telling us what piece isn't working, whether it's not working in simulation or in hardware, and be specific--isolate the problem as much as you can, so we can then help you. Or if you can't isolate it, tell us what you've tried, and we might be able to offer suggestions--similar to those above. Dan
  23. Great! When you figure this all out I know of a former world leader in CPUs that can't figure out how to optimize a 40 year old architecture without introducing horrible security loopholes. After compensating with myriads of software bandages all of the magic disappears. It can't be fun working at a company that used to kick the competition around for fun and now is getting sand kicked into its face by the one survivor. The Genesys2, when it becomes available again, is a nice platform for the price with lot's of capability. If you can afford it my view is that it's a better deal than the Nexys Video.
  24. Hi @wpless If you just want to run it and make no changes to it you can use Digilents releases for it. Here: https://github.com/Digilent/Eclypse-Z7/releases v0.2 is the latest and it will contain and .img file which you can flash to your SDcard and have everything set up for you. Digilent, as far as I know, doesn't provide SDcards with the Eclypse-Z7 "box" but you can have a fully functional debian running on the board, without rebuild, with the above link. -Ciprian
  25. hola, gracias, i saw already dds compiler guide...but i don't know really.... that's why i'm asking you because as following page 16 formulas (i cannot know what phase increment to use .) if i say clk =100 Mhz B=16 Fout =27.5 Hz then the phase increment comes out to be 0.018. so the only way to do it is reduce clock speed to 100khz . is it right? But also, in this case frequency resolution would be a mere 1.52 hz which is not really good actually , and to make it better i would have to higher the bits number of at least 1 bit.. so i still cannot see a way out
  26. and that is what you call "out-of-the-box"? This starts with a 144 pg document that I have to go through (UG1144), which in turn has some links to follow and some lengthy software installations. Guess, you guys have a lot of fun, when writing those datasheets :-). Thanks (for almost nothing), Wilfried
  1. Load more activity