D@n got a reaction from JColvin in write and read data with DDR3 SDRAM Arty-7-35T
The .prj file @JColvin refers to is an XML (i.e. text) file. I was able to use it to create this UCF file.
That's going to be the least of your problems. See my answers in the other thread for more of what you'll need to deal with.
D@n reacted to zygot in Lowpass Audio Filter
Don't really have much to add to what @D@nhas mentioned so far. It's been an enjoyable and enlightening read. OCTAVE is a good tool for prototyping and verification. The logic simulator is for RTL and timing verification.
For a project like yours I'd start with writing an OCTAVE script that accomplishes what you want to do. The prototype has to be written to represent the algorithm that you intend to implement with digital logic. This means not using keywords that do all of the magic behind the scenes. ( Well, actually a first cut script might do that just to prove the concept..). Before writing the HDL the prototype will reflect your design choices; i.e. data structures and algorithms. Once the prototype is satisfactory you write the HDL implementation. This gets verified with the Vivado Simulator. Be warned that Vivado will be happy to simulate your design using the toplevel entity as the toplevel simulation entity. The result is worthless. You need to write a testbench to exercise your toplevel HDL to test the behaviors that you think need to be tested; that is in simulation your testbench is the toplevel entity.. Testbench code is normally quite different than HDL code meant for synthesis, though it instantiates HDL entities and models written for synthesis. I have written simple behavioral models for external devices as if they were to be synthesized but that another discussion. Your testbench can write output data to a file so that you can compare results to your OCTAVE prototype output. Likely, you are using integer math but often signal processing application use fixed point. Either can suitably be processed with a verification OCTAVE script. If everything has gone right your simulation output, hardware output, and prototype will agree, within reason, with each other.
And that's the short course in doing complex programmable logic project for digital, analog or mixed applications.
 I forgot to mention that ModelSim or ISIM will let you view std_logic_vectors as analog signals in the waveform viewer if that's appropriate. In theory, I suppose, it would be possible to do all of the steps that I've mentioned in your HDL except for rendering signals, which is a strong part of OCTAVE or SCILAB. Does anyone really want to write their own simulator? I have used the parallel USB interface on my Genesys2, ATLAS, etc. to capture signals from working hardware, using my own C++ application with Digilent Adept API that then writes OCTAVE or SCILAB formatted data files that can then be read into an OCTAVE script for analysis. It's all really quite satisfying.... though if I had the gumption to figure out how to write the rendering part I wouldn't need all of those steps.. perhaps....
[edit1] Yeah, I'm having difficulties letting this go... If anyone from Digilent is reading this thread you should understand that one of the reasons why you've been able to sell me boards is by putting decent PC interfaces on them with useful API libraries for application development. For a number of reasons Ethernet isn't ideal, though I do use a PCIe, FPGA Ethernet PHY equipped board as an alternate route for communications. If all of your boards are going to be ZYNQ based then, unless they have a PCIe or FPGA USB interface directly connected to the logic fabric (USB 3.0 would be nice ) they won't be suitable for my typical development flow.
D@n got a reaction from youngpark in making differential output Clock
The CmodS7 has only 3.3V I/O banks. You will not be able to generate anything other than 3.3V outputs. I took a quick glance at the schematic and didn't see any length matched GPIO pairs. Depending upon the performance you need, this is often a requirement. You might still be able to break the rules and create two LVCMOS3V3 digital outputs, each opposite each other, to make this happen but it doesn't appear as though the board was designed to support such a requirement. If you choose to do that, then let me recommend you use two ODDR primitives, each with opposite polarity, to try to make this work. That'll at least help you get the timing right.
D@n got a reaction from youngpark in making differential output Clock
Can you share what board you are using? Some boards are voltage agile, some are not. You are also posting in the MicroController section, usually reserved for PIC based boards, and getting FPGA answers. Was this your intent?
D@n got a reaction from DanK in Genesys 2 SD card slot
I've been using this code for working with SD Cards recently. So far, I've been successful reading and writing files.
While I've used the reset, and while I start the design with the SD card in reset, I'm not quite certain that it actually resets the card like it's supposed to. I had some test failures along the way to getting this working that suggest that the reset didn't truly pull power from the card as well as removing the card from the board did.
D@n got a reaction from JColvin in Problems FFT IP CORE v 9.0
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!
D@n got a reaction from ekazemi in dynamic phase configuration on arty s7
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.
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.
D@n got a reaction from rivermoon in How can I send data from one board to another using LWIP (tcp)?
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.
D@n reacted to Bianca in Internet (no wifi available) connection to Arty A7 board
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.
D@n got a reaction from AVA in Help needed using micro SD card in Nexys 4
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
D@n got a reaction from Ahmed Alfadhel in Verilog Simulator
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) sum = B; @(posedge clk) if (A) 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.
D@n got a reaction from Ahmed Alfadhel in Verilog
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,
D@n got a reaction from ManserDimor in Does the GPIOs in Digilent boards length matched?
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.
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?
D@n reacted to Commanderfranz in Why Kaitlyn stopped doing humorous videos on YouTube?
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.
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)?
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.
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
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.
D@n got a reaction from Chirag in Basys 3 implemented design
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
D@n got a reaction from saif91 in FPGA Altera how to convert image to .hex or .mif
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.