Popular Content

Showing content with the highest reputation on 11/23/18 in all areas

  1. 1 point


    For the external memory controller using the hard IP in the Spartan 6 the recommendation is to have the DDR logic communicating with it to be at least 1/2 the DDR interface clock rate. This might be different for soft external memory controller implementations. Your other logic can run at any clock rate you want as long as you pay attention to clock domain crossing issues properly. This usually means dual clock FIFOs for the data paths. Latency in high speed data is always an issue which is why cache memory becomes important. Part of the design effort, and fun, is figuring out a system design that makes implementation reasonably simple but supports the needs of the overall project goals. I have a pretty old text from a guy named Dykstra titled ( something like ) "Data Structures Plus Algorithms Equals Software" The title routinely pops up in my mind when starting a new project. MIG IP projects are a real pain to deal with so I don't tend to create too many but prefer to reuse one generally useful but high enough performance IP when possible. My last Spartan 6 based project reuses an old MIG design that runs the DDR at 333 MHz though in theory 400 MHz is possible. My controller logic that connects to the hard controller runs a 100 MHz ( not 167.67 MHz and I get a paltry 148 MB/s or so transfer rate out of it. Latency is dealt with on a system design level. This is SOP. You might think that a MIG interface that earns a 'slacker' rep would be undesirable. What I get is much lower thermal byproduct to deal with and this can be an important consideration for the overall project objectives. If I need 800 MB/s then I need to do another MIG IP project.... but you'd be surprised at how useful a 'low performance' interface can be for most projects. Once in a while I have a board with a wide (32-bit or 72 bit) DDR external interface and it's worth the time to squeeze as much performance out of it as I think that I can get. BTW that Spartan 6 DDR controller has 4 32-bit read/write ports ( the DDR is a 16-bit device ) and I've used them all concurrently without issues.
  2. 1 point


    @oliviersohn, If you want to start simple, you might wish to try the tutorial I've been working on. I have several lessons yet to write, but you may find the first five valuable. They go over what it takes to make blinky, to make an LED "walk" back and forth, and then what it takes to get the LED to walk back and forth on request. The final lesson (currently) is a serial port lesson. My thought it to discuss how to get information from the FPGA in a next lesson. Dan
  3. 1 point


    Hi @Junior_jessy, Are you referring to the VHDL Pmod MIC3 project linked above done by @hamster? What range of acoustic sound were you testing? The Pmod MIC3 has a MEMS Microphone Knowles Acoustics SPA2410LR5H-B acoustic sensor and a Texas Instruments ADCS7476 ADC. I would guess the LEDs are staying the same due to the acoustic range you are testing. thank you, Jon
  4. 1 point
    OK thanks. Yes, updating that tutorial would save a lot of time and confusion. I later noticed that Xilinx's page for 2017.2 has a bit more description relating to free WebPACK than the page for 2017.3, though it's still not clear how to invoke the free aspect. Further confusion is added by the Xilinx page you arrive at from Vivado's License Manager, as that page omits the Activation-based licenses, and the licenses it does show include a Free one for pre-2015, as though you can't license 2016 and later for free. Evidently that doesn't mean you can't use 2016 and later, it means that no license is required, and you don't need to be using the License Manager at all!