• Content count

  • Joined

  • Last visited

  • Days Won


zygot last won the day on March 13

zygot had the most liked content!

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

3311 profile views
  1. zygot

    FT2232HQ Digilent firmware

    @mishu, FTDI has quite a few application notes that should help.
  2. zygot

    nexys 4 ddr UART

    This depends on what you are trying to do. As I understand it what you want to do is get data from your FPGA board into a PC. On the PC side I doubt that you'll find anything close to 12 Mbaud as a supported COM port data rate. ( I don't use Win10 and for Win7 device manager 128000 is the highest baud rate that you can set a COM port to). But how are you going to read your data? Windows makes serial port applications very difficult. Python is nice and works for both Windows and Linux but I doubt that interpreted Python code will support anything close to that rate. Perhaps compiled Python executables might... Maximum data date also depends on how much data you want to transfer at a time. Understand that your OS is task switching and may not be interested in running your application long enough to support really large continuous data transfers even though the rate is slow compared to the processor clock. I have used interpreted Python applications and 921600 without flow control to transfer 500K+ bytes to an FPGA board though a USB COM port and WIn7. As to whether you need a processor operating the UART in your FPGA the answer is definitely NO. You can control the UART better and easier in logic. There are UART logic implementations available in your favourite HDL. If you decide that flow control is a good idea ( hint hint.... ) then you can buy a cheap TTL USB UART cable or breakout board using the same or similar FTDI part and have flow control. This is my preferred way to connect an FPGA to a PC ( if I'm using a UART ). I have also connected FPGA boards to SBCs like the Minnowboard and UP^2 board at higher data rates using MRAA. I would make the pitch that trying to calculate maximum data rates is not as straight forward as you might want to think it is, especially if you don't have a lot of experience experimenting in how to achieve it... and an understanding of software ( especially OS layers of software ) behaviour. What might work most of the time for short data transfers might be less reliable for large, uninterrupted, streams of data. The FPGA end should be the simplest part and certainly the most straightforward to analyse I didn't get the part of your question about RS-485. I can say that once you abandon the realm of digital logic and go to RS-232 or RS-485 levels you cannot expect data rates much above 1 Mbaud as the voltage swings are considerably larger than 3.3V logic.
  3. zygot

    Adept DPTI support

    No. Please re-read this thread starting at the initial post. As to the DPTI driver I haven't looked to see what the latest version is. The one that I've used, when I don't use my own interface, has some issues. You'd get the impression from the code and documentation that what Digilent provides supports both the Nexys Video and Genesys2. Obviously, the third party who did the design never actually tried using it with the Genesys2. The first problem is that reset input. Again comments already in this thread point out the issue. You will have to make modifications for the Genesys2. Another issue with the DPTI interface is that is seems to claim that it can operate in either synchronous or asynchronous modes. Perhaps this is a semantic problem but unless you are willing to reprogram the FTDI eeprom to do "synchronous 245" mode you cannot achieve the maximum data transfer rates. I did that for my Nexys Video board. Please note: Digilent highly discourages users from reprogramming the FPDI eeprom as it is possible to brick your interface. Having said all of that, I have used the (modified in the case of Genesys2 ) DPTI HDL for both the Nexys Video and Genesys2 successfully. I encourage simulating the provided code. I also highly encourage experimentation with the interface to develop a feel for what it's capabilities are in real world applications. Lastly, if you want to transfer large amounts of data a very high rates both boards sport an FMC connector allowing you to add a USB 3.0 interface. Cheap development kits are available from both FTDI and Cypress Semiconductor to try out this option. Regardless of what USB interface you use it is necessary to be somewhat knowledgeable about how USB works and pay attention to details like always sending data in native packet sizes to achieve desired data rates.
  4. zygot


    @DigitalConfig, I don't know what FPGA board you are using but I can think of a few ways to get better than 16KB/s data transfer from most FPGA boards. First of all, if you have 2 spare IO pins you can use a TTL compatible USB Serial cable ( or similar USB UART board ) to get at least 921600 baud to a PC. In theory, most of the FTDI USB devices on the typical FPGA board can to 3 Mbps/s but you might find that challenging on a Windows PC. Usually the same device on Digilent FPGA boards that do configuration via USB also have a UART functionality that will easily support the 921600 baud rate. On the PC end Python can handle this as well. If you need more than about 100KB/s data rates you'll have to experiment for yourself using your platforms. Adafruit and Sparkfun have cheap USB UART boards or cables and they are a good tool to have lying around. If you have an FPGA board supporting the Adept DPTI parallel data USB 2.0 interface you can achieve up to 30 MB/s for large data transfers. Be aware the data rates for USB are highly dependent on data size even if you don't make any silly mistakes. Finally, and let this be a secret between you and I, the Ethernet port can be used as a data hose ( no MAC in the FPGA logic so no processor either...) connecting two FPGA boards or an FPGA board and a PC. A problem with doing the FPGA board to PC things is that you are dependent on layers of drivers and code to do the heavy lifting ( unless of course you are prepared to write your own driver and your OS cooperates ) even if you use non-standard packet structures. Doing this isn't a weekend project for very many folks so expect to do a lot of experimentation as there isn't a lot of information about how to do this out there. If you take some time to peruse the Digilent Project Vault you can find a few projects with code samples that will help you along the trek. Oh, I almost forgot to reply to your original question. Yes, in VHDL I've used GENERATE to create an array of processes though there are some subtleties to get right.
  5. zygot

    Measuring time using a Zynq Processor

    @Notarobot, I've got no disagreement with your advice. B-u-t, ( isn't there always a but in technical guidance? ) I'll point out that once you build your first Verilog or VHDL time measuring modules/components and verified that they work as designed you will have a more adaptable and capable plug-in to any FPGA design. I haven't had many instances where 10 ns resolution wasn't overkill as far as that goes. Admittedly, I have a preference for doing things in hardware (logic), especially when it simplifies or eliminates software design, and particularly if it eliminates interrupts or task management.
  6. zygot

    How to add my own blocks with Vivado IP Integrator?

    It seems that the tutorial I was using was from the Xilinx University support page but is no longer available. If you google "creating Vivado IP tutorial" you might come up with something reasonably recent and useful. Best of luck.
  7. zygot

    ISE and Atlys on Linux

    @dag1, Since you've brought up the topic of typos... I heartedly suggest double-checking pin assignments with the ATLYS (board) schematics. The schematics are the gold standard. I do this as a habit every time I create a new design for any FPGA board. Personally, I don't like giving ISE, Vivado or Quartus control over my constraints files. I do this manually and prevent the tools from changing them. If I can't figure out the proper syntax for a particular constraint I use a test project to learn it. I don't recommend that you do this; I just mention it as a thought from an experienced user of FPGA toolsets. One thing that you can't do is let the tools manage the constraint files and also edit them yourself.
  8. zygot

    How to add my own blocks with Vivado IP Integrator?

    @Jan Kok, If you feel comfortable using the approach that you have started with then I certainly don't want to discourage you from plugging ahead. The first place to look for information is to fire up the Xilinx Documentation Navigator application installed with Vivado and look for application notes, User Guides and Tutorials. There are certainly a few describing how to create you own IP such as UG1118, UG1119, and UG896. It's been a while... but I did go through a 4 part lab series on creating IP but I haven't yet found them in my archives. I want to think that Digilent provided them.... but it may have been a distributor... Zedboard.org might be a place to go for step-by step tutorials. There is also a Xilinx user community forum. If I come across what I used I'll post a link to it here... though it might be pretty dated by now. I get the allure of having a compact schematic picture of your system. I just don't feel the love or commitment from Vivado for my older IP design efforts... so, for the time being I'll hone my HDL speed-reading skills. Slogging though Xilinx script sourced HDL is certainly a daunting task... but once you develop a knack for figuring out how to locate the lines of interest it turns into a valuable skill. You'll have to trust me on this.
  9. zygot

    How to add my own blocks with Vivado IP Integrator?

    Another approach that I generally favor is to add a few standard GPIO and or dual-port BRAM interfaces connected to IO in the board design and then have Vivado create an HDL for the whole board design. This HDL can then be instantiated as a component or module in a top level HDL of you own design. Adding additional functionality to the new top level is then ( more or less ) trivial. I'm not a fan of the IP integrator flow but I have created my own IP, mostly as an exercise in seeing what the costs are. Generally, I've found the effort to be more work than it's worth; and then there are Vivado version issues... With the ZYNQ the board design flow is unavoidable but I've found that for me using the approach that I've just described reduces the anguish and frustration to manageable levels.
  10. zygot

    Measuring time using a Zynq Processor

    @smit, The first question that spring to mind is this: do you want to measure absolute or relative time? Relative time would certainly be easier and is usually sufficient. One way to do this would be to have a free-running counter in the logic. A 64-bit counter clocked at 100 MHz would provide 10 ns resolution ( not precision or accuracy ) for a very long time before you'd have to be concerned with wrap-around issues. Whenever an event occurs you could save the value of the free-running counter to a register as a "timestamp". Of course the logic gets a bit more complicated if you want to save time deltas between events for multiple event domains. I do this all the time as part of normal debug data capture to measure performance criteria for most of my designs. I'd suggest that you create logic to do most of the work and make the processor's chore as simple as possible. You'd just need to provide the ARM a way to read registers in the PL. Absolute time gets a bit more complicated, especially if you need a very high degree of precision.
  11. zygot

    Verilog coding format used by ZipCPU.

    @imc_user1, Your question about the ZipCPU source and simulating it works as a pretty good cautionary tale. Open source is only truly open if users can both (effectively) use and understand the source with the tools that one is familiar or if one is willing to learn how to use the tools that the source is dependent on. Either way, I suspect that in the case of a veteran Verilog user and the this particular project, at least some design choices, strategies, and concepts can be gleaned. The essential problem with using some one else's design and source is that a lot of work generally has to be done to decide if what you have been provided will make a suitable base for making your own customizable version for some application given the effort involved. The calculus isn't usually an easy one to make and experience spanning many years helps one quickly pursue or abandon such "starter" projects with minimal effort. Nothing is free. Personally, as far as the HDL goes, it's an easy decision for me if I can't simulate the source using the tools provided by the FPGA vendor. Being able to simulate source certainly makes the process of understanding the source easier and quicker ( assuming that you have developed an expertise in simulation.. another subject worth discussion ). The problem for someone like @D@n who wants to provide a alternate softcore platform that will be adopted widely is this: does he use an arcane toolset that he is familiar and comfortable with to develop his project or does he use a more standard toolchain that his potential "customers" are familiar with. From past conversations and experience I know that Dan isn't a believer in the idea that simulation is a necessary part of the design process. The ZipCPU has many admirable goals. Perhaps the best one is allowing use of the GCC toolchain for software development. I personally have no need or interest in the overhead involved in a softcore processor for FPGA development except in very rare cases. For those rare times when it makes sense I'd use a something like an open source HDL softcore that is compatible with a vendor's ( such as Atmel ) software toolchain. But I'd only do this if I had to use a particular FPGA device without an embedded hard core and the software was minimal. For projects requiring an FPGA and and substantial and ongoing software capability it's hard to pass on a ZYNQ. I don't see having a hard ARM CPU as a convenience because there just isn't a lot of things that I can't do with less hassle using an HDL without a software toolchain tied to the FPGA development. I'd rather do my software on a PC. I really don't buy the idea that hardware ( FPGA ) development requires a CPU, or that it is easier with one for 90% of potential applications.
  12. zygot


    @sourav, All of the FMC LAxxx signals can be inputs. The two FMC_CLKx signal pairs can also be inputs though they are intended for clock inputs. 68 pins spread across 40 ADCs implies that you want to have less than 2 pins per ADC interface. I don't know of any ADC devices with one interface pin. I suppose that if your ADCs have 1 CLK input and 1 data output you could multiplex the pins or try to drive multiple ADC CLKs from 1 FPGA pin. 40 loads on a clock source is going to be problematic even if you have excellent PCB signal integrity. The bigger problem is that you will have to make up some kind of custom FMC mezzanine board to connect all of those ADCs. If I had to do that I'd just design my own 40 channel ADC board. Making such a board in quantities of one or two won't be cheap. The FMC connectors aren't cheap either and can't be hand soldered as they are all SMT form factors.
  13. zygot

    FPGA - Cyclone V GX - DAC

    @Ouss06, We're crossing wires between this thread and our direct emails.. so let's stick to this thread. So, ( and everything that I have to say here is based on assumptions about the lab set up ) the first thing to figure out is what the scope of your works is. Are you supposed to modify a pre-existing Quartus project to operate the CODEC? Are you supposed to create you own Quartus project from scratch? Are you supposed to use a NIOS soft processor? These are important to know in order decide if I can help you at all. If you have VHDL specific questions, then this might be a place to get guidance. The reason why I ask these questions is that your instructor should have a path in mind for you to achieve your goals in a reasonable time frame and without the proper context my advice might send you down a path that involves more work than the lab intends. Your instructor is the only one with this information. Based on the "switch up" comment I'm guessing that you should be starting with a working design and have minimal changes to make for the lab work. Your FPGA design will need to control the SSM2306 CODEC regardless of where the samples originate from. If the CODEC DAC samples come through the FPGA ( I'm guessing that this is true for your assignment ) then you will likely have a block ram containing waveform samples in your FPGA design. I'm guessing that you are using an FPGA board made by Terasic ( perhaps the Cyclone V GX Starter Board ? ) there should be demo projects available from Terasic to help you figure out what has to be done to control the CODEC. Unfortunately, I have no idea what design methodology your instructor wants you to use. At some point in the lab it sounds as if there is another source for the EGC samples. I have no idea if these come through an analog input to the CODEC or through the FPGA using Ethernet or a UART or other interface. This really isn't a very good place to get advice about Quartus specific design methodologies ( as opposed to VHDL only designs ) or Altera specific questions.
  14. zygot

    FPGA - Cyclone V GX - DAC

    So your title for this thread is Cyclone V GX.. implying that this is an FPGA project. Using Matlab, OCTAVE, or even Excel to create sine wave samples is a fine exercise. I don't know what "C5G" is though I assume that it is a reference to an FPGA board. I get the sense that the "C5G" is already configured with a bitstream (completed design) and that you are not actually using Quartus to develop the logic for your application. If this is true then I can't really help you. I do know that with Quartus you can create special block memories in the FPGA that will allow the Quartus memory editor to read from or write to that special memory after configuration. Xilinx doesn't offer an equivalent to the Quartus memory editor. If you are using Verilog or VHDL to drive the SSM2603 CODEC than I might have some guidance to offer specific to your logic design. If you are using an FPGA board with a fixed logic design and access to only a SOF file then I don't have the information you are looking for. If all you need to do is create a simple repeating signal generator ( in your case a normal repeating ECG signal or test sine wave) then using an approach like the memory editor is useful. Regardless of whether the CODEC output is coming from the CODEC input or from an FPGA internal memory you need to modify the CODEC control registers using the I2S serial interface. D@N's an extremely helpful guy so if what he pointed you to isn't making sense then this probably isn't a good place to look for help.
  15. zygot

    FPGA - Cyclone V GX - DAC

    @Ouss06, I have to admit that I missed the part of your question in the quote above when I first read your question. This suggests to me that your use of an FPGA board is more as an appliance than an FPGA development project. I've used the Altera tools supporting Matlab but not for many years. I have no experience with Matlab tools for Xilinx. Digilent doesn't sell Matlab or support it for FPGA development so its forums may not be the best place for that form of development. Are you writing HDL source or limited to Matlab HDL writing the code?