xc6lx45

Members
  • Content Count

    596
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by xc6lx45

  1. I think it's Linux... Try the "dmesg" command immediately after plugging or unplugging. It should show some related events. The obvious, try with a different computer and a different cable. Especially cables fail often.
  2. You should maybe give more background. Otherwise the answers will be only as good as your question. C is faster because... C++ is faster because...
  3. Hi, you can find one possible answer from your course book on page 88 ("Glitches"), as seen on Google books preview. "So far we have discussed the case where a single input transition causes a single output transition. However, it is possible that a single input transition can cause multiple output transitions"... the short path... the critical path. This is the problematic combinational expression in the first example assign clkout = (q < (n>>1)); and registering it using <= avoids the issue, since the downstream signal is free of combinational logic (consider this digital forensics, not design advice, there's more to it in reality e.g. see Vivado's DONT_TOUCH attribute).
  4. Hi, >> I would like to learn to render 2D and 3D graphics >> some algorithms from the Graphics Gems (mainly 1 and 2) books, learn to draw lines, shapes, detect intersections and make a small game-like program to showcase. >> I also want to learn about using matrices for 2D and 3D transformations. When I get advanced enough for 3D I would like to learn how to make ray-traced, real-time scenes. My first thought is, "why not use a PC" or even a Raspberry Pi (it's no graphics miracle but good luck challenging one with an FPGA or whatever board) For example, double-buffering is one line away in a typical high level language.
  5. Yes, see above... in one line: don't mess with clock signals, use one single clock for your design (for a start). Divide and debug information signals, not clock signals. Unfortunately, a lot of textbooks and online material are misleading for FPGA. Same for hacker forums that make "complex things simple" 🙂
  6. Hi, the cheapest option is probably to buy a generic JTAG capable FTDI board such as this one (example for the "official" board, there are cheaper ones). However, this will not be supported by Xilinx tools and you need a 3rd party utility such as xc3sprog. For integration into Vivado, check the Digilent JTAG modules. A word of warning, I've had issues with cheap boards that were most likely PCB defects. Getting a new interface may not solve the issue for you.
  7. Hi, one opinion / alternative (for "looking to start with graphics programming", not "have to design a working product by day x"): Any FPGA can generate analog RGB VGA signals, either with a $10 resistive-divider add-on board or going with jumper wires straight to the VGA cable (it's ugly and slightly out of spec but works just fine). This means you are designing your own "graphics chip". Take it as a proposed lab exercise that requires minimal hardware investment. Get the cheapest board, consider it disposable and save the option of buying something better for long-term motivation or when you've reached the limits of what the small board can do ( ) Example for a minimum monochrome text-based VGA adapter: link comes with a default image, requires only input clock, HSYNC, VSYNC and R (or G or B ) outputs to get an image to the screen.
  8. Hi, a quick update: I released a new version 1.1 that supports variable address width in the protocol. Functionality is unchanged, but performance will improve for scattered writes and reads in the lower address range: 0x000000xx range saves 3 bytes per transaction, 0x0000xxxx 2 bytes and 0x00xxxxxx 1 byte. There was also a missing -datapath_only in the constraints, which made the timing report hard to read (the intention behind the set_max_delay constraint was simply "tool, don't make this path between clock domains any slower than x ns end-to-end").
  9. Hi, >> My intentions are to crypto currency mine a new FPGA algo called Odocrypt quick reality check: Bitcoin mining is a professional business run by professionals. You may read between the lines. Then between the lines between the lines (disregarding the formerly mentioned lines between the lines) If cryptocurrency motivates anybody to get into modern digital design - great. Chances are high that it'll eventually lead to a technical qualification that'll earn a very decent, sustainable income. Just be aware that it's one game for all and the "pros" understand (even if only statistically) the "rules between the rules between the rules"... so maybe I keep it in the back of my head that for the sake of cryptocurrency alone it's a "high-risk venture" (euphemism).
  10. xc6lx45

    fpga kit

    >> is this can be used for controlling of power switches like MOSFET ,IGBT? "yes but" Electronics 101 applies (look at the data sheet of your component: E.g. how much Vds remains with Vgs=3.3 V given the switched current?) You might want to use some intermediate driver circuit for the simple reason of protecting the FPGA against magic-smoke incidents in the power side. For e.g. a traffic light demo, a 10k series resistor to the gate will prevent the worst but this wrecks the switching speed for e.g. PWM.
  11. Hi, I think you can get the resource utilization from the wizard, and you don't need hardware to synthesize a test design. My guess is it'll fit into the smallest Artix (e.g. CMOD A7) but ultimately you have to check for yourself. I'd reserve 1 MBit (65k x 16) BRAM for data storage - it's too much hassle with an external memory chip, if avoidable. There's a speed-area trade-off in FFT. I guess you'll manage to make it work with realistic settings, but better check with the IP wizard yourself. If you go for XADC, double-check that the two ADC inputs you intend to use form a pair for phase-synchronous sampling (e.g. the CMOD A7 schematic shows the correct AD channel offset, I think it was 8).
  12. OK I remember there were some recent posts on the topic I think Digilent has ported some of the code to FPGA using HLS (e.g. search for openCV, HLS).
  13. you might have a look at the HLS (high level synthesis) toolkit. Pay attention to tool license issues / cost.
  14. I have used openCl only on GPUs but the first search turned up a link with this: >> Specifically, we use Intel FPGA SDK for OpenCL that allows modern Intel FPGAs to be programmed as an accelerator, similar to GPUs I suspect this architecture may not mix too well with network data processing: The architectural paradigm on GPUs is "one control path, many data paths" but I think you will need many parallel, independent control paths. GPUs win by massive parallelism / memory bandwidth via bitwidth. The clock speed is fairly low (=> higher end-to-end latency). Just like on FPGAs. You may be able to find a simple example on the web looking for the following functions: clCreateProgramWithSource clBuildProgram clCreateKernel clSetKernelArg. In principle, a complete example can fit into one screen length but some "simple" things like take the maximum of a vector (reduction operations) turn out to be not simple at all... If anybody has experience with openCl specifically on FPGAs, please feel free to correct me...
  15. >> new to fpga and zybo >> i want to use open cv but i dont know where to start from Just thinking aloud: Independently of making hardware work, it might be a good idea to forget everything about hardware and video. Spend some time with openCv and offline bitmap examples on a standard Linux machine, say a virtual Linux box or a Raspberry Pi. Can speak only for myself, but I rather fight my dragons one at a time, not all at once
  16. It may be a good idea to get the cheapest FPGA board (e.g. CMOD A7 just to name one) - don't even bother with Ethernet, just use e.g. UARTs, to get a feeling for the technology. The problem I see is >> I am brand new to FPGA topic Maybe you can find an example project that needs only minor modifications. But even so, you may find out that the obviously shortest route leads through the deepest swamp... Example, my "minor modifications" cause the project to fail timing closure. What then? It's probably worse / "deeper swamp" than the same thing happening on my own design which I know line-by-line. Don't let it discourage you, take it merely as hints so that when you run into something red and flashy in your project planning you recognize it as a warning light 🙂
  17. Hi, I can tell you this much that estimating required FPGA size is a challenging topic in general. Chances are high that an abstract analysis that's not based on experience will completely miss the point. For the PC, I think you are describing operating system overhead, not hardware limitations. Before I'd consider FPGA, I'd have a look at a bare-metal implementation, which can probably be approximated by editing the network card driver in a linux distribution (e.g. use one CPU core per inbound card and keep it in a spinlock waiting for data to avoid the slow context switch etc on interrupt). If your code runs otherwise from cache, a modern e.g. 5 GHz CPU is a force to be reckoned with.
  18. Hi, you may have some luck with this. It may reach 30 MBit/s, which is the limit for one channel of the FTDI chip. It uses the MPSSE mode instead of UART to overcome the abovementioned UART limits using a dedicated clock signal. busbridge3 link I've used it for real-time data acquisition, in one case using 900+ kSPS for dual-channel 12 bit ADC data (which is about 24 MBit/s with some other overhead on the interface). However, writing "proper" code to shuffle the data from FIFO to PC is not completely trivial. One solution goes like this: - assuming the "busbridge3" interface, 32-bit address/data bus on the FPGA side - design a FIFO that collects the real time data - put a read-sensitive status "register" on the bus e.g. 0x80000000 that queries the fill level of the FIFO. On a read event, the same value is copied to a hidden register "A" - put a "FIFO pop" register on the bus e.g. 0x80000001 with this function: - - if A is non-zero, decrease A and pop a value from the FIFO to the bus - - otherwise, keep A at zero and return dummy data Your software then does this: - queue a single-word read from 0x80000000 - queue an arbitrary length block read e.g. 100 times from 0x80000001 (with address increment 0 - reading the same address over and over) - fire the USB transaction - from the result, the first value is the number of valid words (from "A") - use as many data values from the readback block and discard the rest (dummy data) - as an optimization, you may read 0x80000000 again at the end of the block to know whether there is leftover data that would require a larger block size in the next round. This can make a huge difference in avoiding dropouts if your PC isn't tuned for real-time-ish operation. If you pack two consecutive 12 bit ADC frames into one 24-bit word, you don't waste capacity on padding (busbridge3 allows 8/16/24/32 bit data width).
  19. xc6lx45

    Board for OpenCL

    Have you considered a graphics card? For getting started, even built-in graphics acceleration can be useful with limitations (e.g. no double precision). You can also run openCL code on a standard PC. Performance won't be as wild as on dedicated hardware but functionality is the same (e.g. as "software rendering" fallback option)
  20. Maybe one comment: In the ASIC world, "floorplanning" is an essential design phase, where you slice and dice the predicted silicon area and give each design team their own little box. The blocks are designed and simulated independently, and come together only at a fairly late phase. ASIC differs from FPGA in some major ways: - ASIC IOs have a physical placement e.g. along the pad ring. We don't want to run sensitive signals across the chip, need to minimize coupling for mixed-signal etc. In comparison, FPGAs are probably more robust (a complex design will definitely consider the layout, especially on larger devices. But on smaller eval boards, the first restrictions I'll probably run into are logical e.g. which clock is available where, not geometrical). - For ASICs, we need the floorplan to design the power distribution network as an own sub-project (and many a bright-eyed startup has learned electromigration the hard way). - In the ASIC world, we need to worry about wide and fast data paths both regarding power and area - transistors are tiny but metal wires are not. You might have a look at "partial reconfiguration", here the geometry of the layout plays some role.
  21. Hi, reading between the lines of your post, you're just "stepping up" one level in FPGA design. I don't do long answers but here's my pick on the "important stuff" - Before, take one step back from the timing report and fix asynchronous inputs and outputs (e.g. LEDs and switches). Throw in a bunch of extra registers, or even "false-path" them. The problem (assuming this "beginner mistake") is that the design tries to sample them at the high clock rate. Which creates a near-impossible problem. Don't move further before this is understood, fixed and verified. - speaking of "verified": Read the detailed timing analysis and understand it. It'll take a few working hours to make sense of it but this is where a large part of "serious" design work happens. - Once the obvious problems are fixed, I need to understand what is the so-called "critical path" in the design and improve it. For a feedforward-style design (no feedback loops) this can be systematically done by inserting delay registers. The output is generated e.g. one clock cycle later but the design is able to run at a higher clock so overall performance improves. - Don't worry about floorplanning yet (if ever) - this comes in when the "automatic" intelligence of the tools fails. But, they are very good. - Do not optimize on a P&R result that fails timing catastrophically (as in your example - there are almost 2000 paths that fail). It can lead into a "rabbit's hole" where you optimize non-critical paths (which is usually a bad idea for long-term maintenance) - You may adjust your coding style based on the observations, e.g. throw in extra registers where they will "probably" make sense (even if those paths don't show up in the timing analysis, the extra registers allow the tools to essentially disregard them in optimization to focus on what is important) - There are a few tricks like forcing redundant registers to remain separate. Example, I have a dozen identical blocks that run on a common, fast 32-bit system clock and are critical to timing. Step 1, I sample the clock into a 32-bit register at each block's input to relax timing, and step 2) I declare these register as DONT_TOUCH because the tools would otherwise notice they are logically equivalent and try to use one shared instance. This as an example. - For BRAMs and DSP blocks, check the documentation where extra registers are needed (that get absorbed into the BRAM or DSP using a dedicated hardware register). This is the only way to reach the device's specified memory or DSP performance. - Read the warnings. Many relate to timing, e.g. when the design forces a BRAM or DSP to bypass a hardware register. - Finally, 260 MHz on Artix is already much harder than 130 MHz (very generally speaking). Usually feasible but you need to pay attention to what you're doing and design for it (e.g. a Microblaze with the wrong settings will most likely not make it through timing). - You might also have a look at the options ("strategy") but don't expect any miracles on a bad design. Ooops, this almost qualifies as "long" answer ...
  22. Hi, you might look at the open-source xc3sprog utility, it shows how it's done. Nevermind the name, it works also with 7 series with minor modifications (such as IDCODE and flash ID). I remember there is some header in the .bit file that is quite obviously for documentation purposes (open in text editor). But then, AFAIK it does no harm since the FPGA looks for some "magic" 32-bit word to recognize the start of the binary block. That is at least for JTAG-based upload (not sure about flash, I guess it's the same but I don't know). You might have a quick look into the configuration guide https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf if it says anything about preparing a bitstream for flash.
  23. Hi, not sure if I understand this correctly but are you sure this can be done with this chip? It sounds like functionality internal to the microchip firmware.
  24. Hi, just a thought, looking at your diagram from a large distance. Most likely you have some power supplies with two pins (non-grounded). The problem is that the output is floating at half the mains voltage, set by a high resistance (megaohms) voltage divider. Ironically, this is to protect the power supply against ESD / charge buildup on the secondary side that could break the transformer's insulation. With such a supply, if you accidentally disconnect the ground connection to your circuit, you have half the AC voltage on the supply pin. I'd double-check all involved power supplies and make sure your connection scheme has a well-established ground even if some random cable comes loose.