D@n

Members
  • Content Count

    1954
  • Joined

  • Last visited

  • Days Won

    136

Reputation Activity

  1. Like
    D@n got a reaction from JColvin in Problems FFT IP CORE v 9.0   
    @Kenny,
    If you are an FPGA beginner, then ... I would start somewhere else.  I would recommend starting by learning how to debug FPGA designs.
    The problem with FPGA development is that, unlike software, you have little to no insight into what's going on within the FPGA.  There are a couple keys to success:
    Being able to insure your design works as intended before placing it onto the FPGA.  Simulation and formal methods work wonders for this task.  Unlike debugging on hardware, both of these approaches to debugging offer you the ability to investigate every wire/signal/connection within your design for bugs.  If you are unfamiliar with these tools, then I would recommend my own tutorial on the topic. Being able to debug your design once it gets to hardware.  This should be a last resort since its so painful to do, but it is a needed resort.  To do this, it helps to be able to give the hardware commands and see responses.  It helps to be able to get traces from within the design showing how it is (or isn't) working.  I discuss this sort of thing at length on my blog under the topic of the "debugging bus (links to articles here)", although others have used Xilinx's ILA + MicroBlaze for some of these tasks. Either way, welcome to the journey!
    Dan
  2. Like
    D@n got a reaction from Tejna in Hi everyone!   
    @Tejna,
    Welcome to the forums!  I'm an FPGA blogger, and so I'd invite you to check out any of the articles I've written.
    </shameless plug>
    Dan
  3. Like
    D@n got a reaction from ekazemi in dynamic phase configuration on arty s7   
    @ekazemi
    What frequency rates are you trying to achieve?  This method will get you user-controlled phase to within about 1ns or so, and it works nicely for sending something off-chip.
    But to your question, I have yet to try the dynamic interface of any clock management hard-cores.  I've looked them over a couple of times, but ... not actually tried any.
    Dan
  4. Like
    D@n reacted to xc6lx45 in I bricked my CMOD-A7   
    Thinking aloud: Is it even possible to "brick" an Artix from Flash? On Zynq it is if the FSBL breaks JTAG, and the solution to the problem without boot mode jumpers is to short one of the flash pins to GND via a paper-clip at power-up. But on Artix? Can't remember having seen such a thing. Through EFUSE, yes, but that's a different story.
    If you like, you can try this if it's a 35T (use ADC capture at 700 k, it stresses the JTAG port to capacity). For example, it might give an FTDI error. Or if it works, you know that JTAG is OK.
     
  5. Like
    D@n got a reaction from rivermoon in How can I send data from one board to another using LWIP (tcp)?   
    @rivermoon,
    Go for it, and good luck!
    I've found that wireshark was very useful when debugging network interactions.  Let me take a moment and suggest you look into it and try it out.  Also, I'd love to hear back from you regarding your success when everything works like it should.  So often these forum posts only discuss problems and we never hear successes here.  That said, it's your call what you want to share.
    Dan
  6. Like
    D@n reacted to Bianca in Internet (no wifi available) connection to Arty A7 board   
    Hi @josejose,
    There is a Digilent Design Contest project, the winners from this year. They made a project that controlled a Zybo Z7 over Internet. It was a platform for students to prototipe and test their HDL design. The project it's a bit more complex; they segmented the memory and allowed multiple users to access different peripherals of the board at the same time. It's very well documented so you might find some things to help you there. The project works and you can contact them over github if something is unclear. Here is the git repo  and here is the documentation.
    Maybe it can help you. 
    Bianca
  7. Like
    D@n got a reaction from AVA in Help needed using micro SD card in Nexys 4   
    @Roberto_UDC,
    Fair enough, that's your call.  I notice the core you referenced doesn't have a bus interface at all, nor does it necessarily have a command interface.  That'll make some of this more interesting to work through, but so be it.  Let's work through the startup commands.  In my examples, I start up at a 400kHz clock.  Then ...
    The first command that needs to be sent to the card is a command zero.  CS should start out inactive (high), and go active (low) at the beginning of this command.  This should put the card into SPI mode in the first place. (Incidentally, did you check the pin-outs?  That should be checked first ...) The next command that needs to be sent to the card is CMD1.  In the CMD1 you send, are you indicating a support for high capacity cards?  (Data field = 32'h4000_0000 ?) Only then is the CMD 8 sent.  In this case, you need to send an appropriate interface condition.  I send 32'h01a5.  Can you check what you are sending? We can also check CRC's if necessary, but I'd like to believe that the core you are using sets the CRC's properly ... (Perhaps not ...) Dan
  8. Like
    D@n got a reaction from Ahmed Alfadhel in Verilog Simulator   
    @xc6lx45,
    This is a valid question, and a common response I get when recommending Verilator.  Let's examine a couple of points here.
    Verilog is a very large language, consisting of both synthesizable and non-synthesizable subsets.  I've seen more than one student get these two subsets mixed up, using constructs like "always @* clk <= #4 !clk;" and struggling to figure out why their design either doesn't work or fails to synthesize. I've seen a lot of student/beginners try to use these non-synthesizable constructs to generate "programs" rather than "designs".  Things like "if (reset) for(k=0; k<MEMSIZE; k=k+1) mem[k] = 0;", or "always @(*) sum = 0; @(posedge clk) if (A[0]) sum = B; @(posedge clk) if (A[1]) sum = sum + (B<<1)", etc. Since verilator doesn't support #delay's, nor does it support 'x values, in many ways it does a better job matching what the synthesizer and the hardware will do together, leaving less room for confusion. C++ Verilator based wrappers can be used just as easily as Verilog for bench testing components.  That said, ... The Verilog simulation language is a fairly poor scripting language for finding bugs in a module when compared to formal methods.  There's been more than once that I've been deceived into thinking my design works, only to find a couple cases (or twenty) once I get to hardware where it didn't work.  Indeed, both Xilinx and Intel messed up their AXI demonstration designs--designs that passed simulation but not a formal verification check.  As a result, many individuals have posted unsolved bugs on the forums, complained about design quality, etc.  (Xilinx has been deleting posts that aren't flattering to their methodology.  I'm not yet sure about Intel in this regard)  Formal methods tend not to have this problem.  Why waste a student's time teaching a broken design methodology? So, if you aren't using Verilog for your bench test, then what other simulation based testing do you need?  Integration testing where all the modules come together to interact with the hardware in some (potentially) very complex ways.  At this point, you need hardware emulation, and Verilator provides a much better environment for integrating C/C++ hardware emulators into your design. My favorite example of this is building a VGA.  VGA's are classically debugged using a scope and a probe since the definition of "working" tends to be "what my monitor will accept."  The problem with this is that you lose access to all of the internal signals when abandoning your simulation environment.  On one project I was working on, this one for the Basys3 where there was a paucity of memory for a video framebuffer, I chose to use the flash and to place prior compressed frames onto the flash.  I would then decompress these frames on the fly as they were being displayed.  My struggle was then how to debug decompression failures, since I could only "see" them when the design ran from hardware.  Verilator fixes this, by allowing you to integrate a display emulator with your design making it easier to find where in the VCD/trace output file the bug lies.
    Another example would be a flash simulation.  Most of my designs include a 16MB flash emulation as part of their simulation.  This allows me to debug flash interactions in a way that I doubt you could using iverilog.  This allows me to simulate things like reading from flash, erasing and programming flash--even before I ever get to actual hardware, or perhaps after I've taken my design to hardware and then discovered a nasty bug.  More than once is the time where I've found a bug after reading through all 16MB of flash memory, or in the middle of programming and something doesn't read back properly.  I'm not sure how I would do debug this with iverilog.
    A third example would be SD-card simulation.  I'm currently working with a Nexys Video design with an integrated SD card.  It's not a challenge to create a 32GB FAT based image on my hard drive and then serve sectors from it to my running Verilator simulation, but I'm not sure how I would do this from iverilog.  So far in this project, I've been able to demonstrate an ability to read a file from the SD card--FAT system and all, and my next step will be writing data files to it via the FATFS library.  I find this to be an important simulation requirement, something provided by Verilator and quite valuable.
    Finally, I tend to interact with many of my designs over the serial port.  I find it valuable to interact with the simulation in (roughly) the same way as with hardware, and so I use a program to forward the serial port over a TCP/IP link.  I can do the same from Verilator (try that with iverilog), and so all of the programs that interact with my designs can do so in the same fashion regardless of whether the design is running in simulation or in hardware.
    Yes, there are downsides to using Verilator.
    It doesn't support non-synthesizable parts of the language.  This is the price you pay for getting access to the fastest simulator on the market--even beating out the various commercial simulators out there. Verilator is an open source simulator, and so it doesn't have the encryption keys necessary to run encrypted designs--such as the Vivado's FFT or even the FIFO generator that's a core component of their S2MM, MM2S, and their interconnect ... and probably quite a few other components as well.  This is one of the reasons why I've written alternative, open source designs to many of these common components. [FFT, S2MM, MM2S, AXI interconect, etc.]  As to which components are "better", it's a mixed bag--but that's another longer story for another day. Verilator does not support sub-clock timing simulations, although it can support multi-clock simulations.  At the same time, most students don't need to know the details of sub-clock timing in their first course.  (I'm not referring to clock-domain crossing issues here, since those are rarely simulated properly anyway.) Still, I find Verilator to be quite a valuable choice and one I highly recommend learning early on in the learning process.  This is the reason why my beginners Verilog tutorial centers around using both Verilator and SymbiYosys.
    Dan
  9. Like
    D@n got a reaction from Ahmed Alfadhel in Verilog Simulator   
    @Ahmed Alfadhel,
    Don't put spaces between the "-" and "Wall", or between the "-" and the "cc" and you'll do better,
    Dan
  10. Like
    D@n got a reaction from Ahmed Alfadhel in Verilog Simulator   
    @Ahmed Alfadhel,
    I put instructions together for that some time ago.
    Let me know if they need to be updated any.
    Dan
  11. Like
    D@n got a reaction from Ahmed Alfadhel in Verilog   
    @Ahmed Alfadhel,
    Perhaps the most complete tutorial out there is asic-world's tutorial.  You might also find it the most vacuous, since although it tells you all the details of the language it doesn't really give you the practice or the tools to move forward from there.  There's also a litexsoc (IIRC) by enjoy-digital that I've heard about, but never looked into
    An alternative might be my own tutorial.  Admittedly, it's only a beginner's tutorial.  It'll only get you from blinky to a serial port with an attached FIFO.  That said, it does go over a lot of FPGA Verilog design practice and principles.  It also integrates learning how to use a simulator, in this case Verilator, and a formal verification tool, such as SymbiYosys, into your design process so that you can start learning how to build designs that work the first time they meet hardware.
    I'm also in the process of working to prepare an intermediate tutorial.  For now, if you are interested, you'd need to find most of the information that would be in such a tutorial on my blog.  (It's not all there ... yet, although there are articles on how to create AXI peripherals ..)
    Feel free to check it out.  Let me know what you think,
    Dan
  12. Like
    D@n reacted to vicentiu in Does the GPIOs in Digilent boards length matched?   
    Thanks for pointing that out. That does make it pretty confusing.
    I'll contact the forum developers to see if there are options we can tweak to turn that off.
  13. Like
    D@n got a reaction from ManserDimor in Does the GPIOs in Digilent boards length matched?   
    @ManserDimor,
    You'll need something that is voltage agile if you want to do LVDS.  Most of the I/O on Digilent boards is fixed at 3.3V, so check your reference manual and your schematic to make sure that you can use the voltages available to you.
    Dan
  14. Like
    D@n reacted to zygot in Does the GPIOs in Digilent boards length matched?   
    I own three of FMC equipped boards that  you mention and frequently use at least one on a regular basis. Just for arguments sake; lets say that I want to design my own FMC mezzanine card using all of those differential pairs. Where do I find the trace routing report letting me know what the trace lengths are for the Genesys2, Nexys Video and Zedboard?
     
  15. Like
    D@n reacted to Commanderfranz in Why Kaitlyn stopped doing humorous videos on YouTube?   
    Hey Paolo,
    I'm glad you found my videos helpful! I've been working on other projects, but if you have any other ideas for videos that you would find helpful let me know. 
     
    Kaitlyn
  16. Like
    D@n reacted to zygot in Is it possible to use the Cmod A7 and/or Cmod S6 as a SPI master (mosi and miso)?   
    @Takemasa Tamanuki
    If you intend to use the the CMDO A7 as a standalone component you need to carefully read the reference manual and schematic. This module is meant to be powered by the same USB connector that provides JTAG configuration and UART communications. It has a FLASH device capable of configuring the FPGA and a power input pin so it is entirely possible to use the module without USB connectivity.
    When I develop an interface using a standard like SPI I don't write HDL that supports all of the possible modes that might exist in every device. I design a minimal interface that supports a particular device. I'm sure that there is good IP for SPI masters out there but I've never used one so I have no suggestions. If you can do Verilog or VHDL development and understand how the SPI devices that you are working with operate it is a rather easy and straight forward effort.
    I advise against expecting that adding an FPGA board with generic "code" could be an easy and quick solution to any existing problem.
  17. Like
    D@n reacted to PaulW in I2C SCL line remains low on Cora Z7 board   
    This has helped my problem:  https://forums.xilinx.com/t5/UltraScale-Architecture/I2C-through-EMIO/td-p/984165
    particularly:  " 
    As would be expected this turned out to be something very simple. For I2C not only is the SDA bi-directional but SCL is also, but I had not set up the return path for SCL. So the controller was always waiting to see the SCL line high before starting anything and that's why both SDA and SCL showed no activity even on the ILA.
    In the vhdl wrapper for the block design just the second line below was the fix:
    <SCL I/O pin name> <= I2C1_scl_out when (I2C1_scl_tristate = '0') else 'Z';
    I2C1_scl_in <= <SCL I/O pin name>; -- <- This was the missing vhdl line that I needed to add in the wrapper vhdl file
    <SDA I/O pin name> <= I2C1_sda_out when (I2C1_sda_tristate = '0') else 'Z';
    I2C1_sda_in <= <SDA I/O pin name>;
     
    Thanks for the help on this.
  18. Like
    D@n got a reaction from Chirag in Basys 3 implemented design   
    @Chirag,
    What you are looking at is an image of the underlying silicon die within the chip, showing the layout of the various parts physically.
    The six big squares are clock regions IIRC.  You can save some power and some wires if you can restrict a clock to a given region.  That said, I tend to run all my designs with one giant system clock, so this hasn't helped me much. In your example above, the LUTs being used are in the middle row and colored light blue.  There's more there than just LUTs, but that's where the LUTs are.  What more is there?  I can't be certain, but examples might be memory and DSP slices.  If you zoom in on this area you'll see sub-pictures showing four LUTs to a slice, the FFs in the slice, and possibly the various mux-7 and mux-8 components as well.  (It's been a while since I've done so) The I/O banks are all on the edges of the design.  You can use them via the various IBUF, OBUF, IOBUF, IDDR, ODDR, ISERDESE, OSERDESE, etc. primitives.  A wire going to or from an I/O port will naturally use one of these, or they can be manually instantiated as well for more control of what takes place. Yes, you can change cell locations manually, but knowing what you are doing enough to be successful doing so can be a real challenge.  I know some folks who have hand placed their designs to great effect.  I also know of at least one open source project to do the same.  Indeed, at one time I tried to build a placer to map logic to FPGA elements--my efforts didn't work out so well.  That said, I know my own limits and don't try to move components around myself. Dan
  19. Like
    D@n got a reaction from saif91 in FPGA Altera how to convert image to .hex or .mif   
    @saif91,
    In general, it's bad practice and frowned upon to ask a question about a product in their competitors forum. 
    Hex file generation is pretty easy.  You can see a discussion of how to do it in lesson 8 of my tutorial, the lesson on memory.  You may struggle to build a big enough memory on-chip to hold such an image, though.  If you are writing NiOS code, you might find it easier to create a C-array containing the image into your C code.  Otherwise, you might wish to consider writing it to your flash yourself, and then copying it to whatever video memory you might have available to you: SDRAM, DDR3 SDRAM, SRAM, etc.
    Dan
  20. Like
    D@n got a reaction from chaitusvk in Amplitude modulation with DDS generator   
    @chaitusvk,
    I notice that the on and off periods are ... not on an obvious integer spacing.  Is there some greatest common sublength that all of the bits are described with?  Is the carrier a multiple of this subwidth?
    Your goal is to create this signal, right?  I think my goal would follow @xc6lx45's approach: create some form of NCO for the carrier, and then use multiples of it (if possible) for handling bit periods.  You might find this article, or even this one, valuable back-reading on the topic.
    Dan
  21. Like
    D@n got a reaction from openhacker in JTAG-HS3 connection with API (DmgrOpen)   
    @Assane,
    As I recall, there's an action required by the udev subsystem when you insert a USB Xilinx into your system.  Without the udev action, it will show under lsusb (which I think is what you meant earlier, not libusb, right?), but nothing will recognize it.
    Getting the udev action to take place when you plug in your device requires installing the Xilinx device drivers as root.  Basically, Xilinx and Digilent want to install two separate files into /etc/udev/rules.d/. 
    Just to see if these files have been installed, can you "ls" this directory for me?  You are looking for files "52-xilinx-digilent-usb.rules" and "52-xilinx-pcusb.rules".
    Thanks,
    Dan
  22. Like
    D@n got a reaction from chaitusvk in Amplitude modulation with DDS generator   
    The carrier phase alignment question is pretty important.
    What carrier frequency is this thing supposed to be operating at?  And ... is it in the range of what an FPGA can create?
    Dan
  23. Like
    D@n got a reaction from sgandhi in FAT32 with Zybo Z7   
    @sgandhi,
    Welcome to data processing.  The sad reality is that text files aren't good for this kind of thing.  It's not an FPGA particular thing, but rather a basic reality.  1) Text files tend to take up too much space, and 2) they require processing to get the data into a format usable by an algorithm.
    One way to solve this problem, which I've done in the past with great success, is to rearrange the file so that's it's a binary file containing a large homogeneous area of elements all of the same type.  In my case, I wanted a file that could be easily ingested (or produced) by MATLAB.  I chose a binary format that had a header, followed by an NxM dimensional matrix of all single-precision floats.  (You can choose whatever base type you want, but single-precision floats were useful for my application.)  The header started with three fields: 1) First, there was a short marker to declare that this was the file type.  I used 4-capital text letters for this marker.  That was then followed by the 2) number of columns in the table, and then 3) the offset to the start of the table.  This allowed me to place information about the data in further header fields, while still allowing the processor to skip directly from the beginning header to the data in question.  Further, because the data was all of the same type, I could just about copy it directly into memory without doing any transformations, and to then operate on it there.
    It did help that the data was produced on a system with the same endianness as the system it was read from ...
    Dan
     
  24. Like
    D@n got a reaction from jpeyron in FAT32 with Zybo Z7   
    @sgandhi,
    Welcome to data processing.  The sad reality is that text files aren't good for this kind of thing.  It's not an FPGA particular thing, but rather a basic reality.  1) Text files tend to take up too much space, and 2) they require processing to get the data into a format usable by an algorithm.
    One way to solve this problem, which I've done in the past with great success, is to rearrange the file so that's it's a binary file containing a large homogeneous area of elements all of the same type.  In my case, I wanted a file that could be easily ingested (or produced) by MATLAB.  I chose a binary format that had a header, followed by an NxM dimensional matrix of all single-precision floats.  (You can choose whatever base type you want, but single-precision floats were useful for my application.)  The header started with three fields: 1) First, there was a short marker to declare that this was the file type.  I used 4-capital text letters for this marker.  That was then followed by the 2) number of columns in the table, and then 3) the offset to the start of the table.  This allowed me to place information about the data in further header fields, while still allowing the processor to skip directly from the beginning header to the data in question.  Further, because the data was all of the same type, I could just about copy it directly into memory without doing any transformations, and to then operate on it there.
    It did help that the data was produced on a system with the same endianness as the system it was read from ...
    Dan
     
  25. Like
    D@n got a reaction from cepwin in GPS Pmod   
    @cepwin,
    There's a real easy way to debug whether or not you are getting a fix or not.  Remove the FPGA design, and replace it with a pass through from the GPS UART transmit pin to the FT2232 UART RX transmit pin.  You can then use your favorite terminal program, mine is minicom some like teraterm, to examine the NEMA stream produced by the GPS device.  It's typically 9600 Baud, 8 data bits, no parity and one stop bit.  It's also pseudo-human readable--line upon line of CSVs--you should then be able to tell if you are getting lock or not.
    I see no reason why you wouldn't be getting lock from your upstairs bedroom.
    Also, for your security, you probably don't want to paste the NEMA stream coming out of the device here for discussion--since it may well reveal the coordinates of your bedroom.
    Dan