zygot

Members
  • Content Count

    748
  • Joined

  • Last visited

  • Days Won

    35

zygot last won the day on April 20

zygot had the most liked content!

4 Followers

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

4724 profile views
  1. @sbellamy Why yes, there is a document that indicates Xilinx pin naming conventions: UG475 7 Series packaging and Pinout Product Specification User's Guide, see Table 1-12. This is one of the many valuable documents that is required reading for the FPGA developer. Use the Document Navigator. Download all relevant documents for your device as your personal library. Check often for updates. I realize that there is a ton of stuff to read but learn how to find answers to your questions. Xilinx doesn't always make it easy to find specific information which is why it's important to get familiar with what's available and where specific information might be.Your question is a very good one and I'm surprised that it hasn't shown up before ( well as long as I've been using this forum...). [edit] A peculiar thing about the Zynq family is that Xilinx seems to treat it like an ARM product even though different versions have a PL based on different Xilinx FPGA families. This means extra work for the customer. The pin name conventions work for Zynq PL pins and all other Xilinx FPGA families.
  2. zygot

    PCIE on CMOD-A735T

    In general the T designator for Xilinx devices indicates that it has transceivers which are required for PCIe. This doesn't imply that all boards using a transceiver equipped part can implement PCIe or even use the transceivers. The CMOD products are not suitable for doing transceiver based designs. I have the Diligent Genesys board that has a Virtex 5 FPGA device with transceivers and they are unusable for a variety of reasons. You should read the reference manuals for Xilinx PCIe as well as the application notes and other information that they provide to learn about FPGA based PCIe.
  3. @mikeWylie The DAC that you want to use is an older device and uses a DDR interface, so there's hope. I've posted on this type of question numerous times in answer to numerous questions similar to yours. You can see my list of EVM's that I've found useful in the Technical Off-Topic Useful EVMs for FPGA Development Boards post that I started ( I'll update or respond to posts to queries on that post as needed ). I've posted more specific guidance in answering other similar questions but don't have the time top track them all down.... unfortunately, it's difficult to steer people toward a previous post that might answer their questions. The short answer is that you have to trace though all of the signals from the EVM through any adapter boards and through the FPGA development board that you are using to make sure of connectivity. When there are no SERDES involved things are easier and more likely to be possible from a clocking point of view but you still need to make sure that your IO pins have compatible standards. The adapter will complicate timing closure, and depending on signal routing might make an interface much more complicated. Make sure to trace though all power and ground pin assignments. Lastly, and most importantly, make sure that clock signals into or out of your FPGA are assigned to clock capable pins. This commentary is not exhaustive. If you really need one or two channels of high speed DAC or ADC and don't have a big budget to work with I suggest looking a Cyclone based FPGA board with HSMC connectors. Terasic is a good place to look. Opal Kelly has a few Syzygy options for high speed ADC/DAC applications. Otherwise, options are bleak. Trust me that I'm always on the lookout for high sampling rate ( > 10 MHz ) analog <--> digital development platform options. In my post for using EVMs with FPGA development boards I mention the Terasic De0 Nano/LTC1668 board combo that I've found to be useful. Just because a mezzanine card uses an FMC connector that doesn;t mean that it's usable with any FPGA board having an FMC connector. There are two possibilities here that will work: Read the schematics and work out all of the details for yourself before buying anyting Use the advice of a trusted source who has successfully done what you want to do and then do option 1 anyway. You are ultimately responsible for everything. Keep in mind that since the FMC is a high speed interface there's no safety net for boo-boos.... you get it right or the odds are very high that you will destroy your FPGA board.
  4. @Reggs Glad to hear that you got things working. I also really appreciate your background story; thanks for taking the time to share! ISE 14.7 is the last version of ISE and I believe that you can still download it as Vivado doesn't support the older FPGA families. I still use ISE on a regular basis with WIN7. I do have a laptop with WIN10 but I don't consider WIN10 to be a real OS so I've never tried doing development on it; in fact I will never put any significant development on WIN10 as it ( or the company that makes it ) just isn't reliable enough to risk losing years ( or even a few days ) of work. I have installed Digilent tools and ported a few of my own PC FPGA applications to WIN10 so that I can use the laptop with some dedicated FPGA hardware projects that I need from time to time. So now you know what I know. You can make very useful debugging tools that are often better than what is provided by tool vendors. Keep on Truckin'!
  5. @Boris_S Since you are using Windows it might be worth your time to try an experiment. xc6lx45 has posted his awesome busbridge3 demo in the Project Vault. I have created an executable that runs on my WIn7 computer using the source code and SharpDevelop compiler. If, as I suspect, the issue is completely a hardware one then you shouldn't be able to run the code and configure your board. I made slight modifications to the source so that I could confirm the configuration step. Read the project postings. Once I resolved some basic C# issues I had no problem running the executable with either of my two boards ( again, I've not had issues programming them ). This project does not require a separate JTAG FPGA configuration application to be running. Download the project and read through the source code just because it's a great tutorial for anyone who hasn't tried creating a PC application that configures and interacts with an FPGA board before. When I first ran into the problem it certainly 'smelled' like a software or driver issue; Vivado Hardware Manager doesn't play nice with other applications, including the Adept tool for Windows which I generally favor for configuring Xilinx FPGA boards. Since I've been able to use my boards with a simple work-around I haven't allocated the time to doing what Digilent should have done and resolved long ago; that is fix this once and for all. The FTDI JTAG and UART should be enumerated as separate endpoints and not interfere with each other. I don't have a USB bus analyzer ( Digilent most certainly has no excuse for not investing in one ) so ferreting out the source of OS disconnects is more work than I want to do. FTDI doesn't provide the level of debugging support that Cypress does for their USB devices so tracking down issues involving a lot of software and hardware elements is non-trivial. Even so, there's simply no excuse for these reoccurring customer complaints not being aggressively addressed and resolved by the vendor.
  6. @Boris_S I've written about this so much that I've been avoiding responding to posts such as yours any more. I decided to add my 2 cents to your thread because your experience is very similar to mine. For my older 2 CMOD-A35T boards I've never had an issue configuring the CMOD-A35T but do have USB disconnect issues with Vivado Hardware Manager if I try to use the ILA for some time. I have a drawer full of cables and none of them make a difference. I find the board useful if I use an external TTL USB UART attached to 2 IO pins. You obviously can't do that if you can't even configure the FPGA device. Digilent is set on blaming the problem on cables... yet they don't sell the board with any or guarantee operation with any known vendors cable even after a few years of complaints. You are correct that this is the only FPGA board that Digilent ( or anyone else that I know of ) makes with this problem; and Digilent has made a lot of boards with roughly the same programming interface over the past 5 years or so. My personal suspicion is that the particular FTDI device used on this board ( the newer cheaper ones have fewer power and ground pins), pcb layout decisions, and possibly the way that whatever makes their interface proprietary is different for this board is causing the issue but I can't prove that and frankly it's not worth my time to try. Neither you nor I can make Digilent take any particular action with regard to these boards but it is clearly not doing anything positive for their reputation ( I sometimes wonder if they even care about reputation ). Since they are cheap, if I were the vendor, I'd re-spin the board, test the JTAG interface exhaustively, and sell the modules with a mated cable. I suspect that the board needs a different stackup and less component density and a JTAG re-design. Making customers eat the cost of a poor design just isn't good business if you want to engender good will. There have been customers that support Digilent's claim that a different USB cable makes the problems disappear but, as you and I know, not all of us customers can verify this. I happen to think that if a customer can't use a new board with known design problems a more liberal replacement policy should be in order... the vendor can figure out what's going on working with the returns. It's problematic that the same board and cut & paste copies of newer versions are being sold without a fix. Perhaps Digilent doesn't think that the cost merits testing product but for their customers the cost is signifiant, especially when the board is unusable. I know what I do when a vendor has a habit of not treating me well... I use a different vendor. The Terasic DE0 Nano is about the same cost but comes with a USB cable and has more IO pins in a slightly larger form factor but is still quite usable for attaching to a custom board that I design. It doesn't use an Artix device but for what these embeddable modules are good at has served me quite well. I've designed a few dozen boards that have integrated either the 2 CMOD-A735T or the DE0-Nano as a component over the past couple of years. If Digilent were willing to replace your board, given the known issues, then I'd try that for the modest cost of shipping but if not I certainly wouldn't throw more money at a different one hoping for a different outcome. There are a few vendors offering similar modules but I only have experience with the two that I've mentioned. Trenz makes a few similar FPGA boards but I've never used any so I can't offer any opinions about them.
  7. Let me offer a suggestion to all newbies, regardless of how smart you are, before trying to do FPGA development. Read all of the user guides for the FPGA device resources that you are likely to be using. These will include the SelectIO, Clocking, CLB , and memory guides at a minimum. [edit] also read the AC switching part of the device data sheet. Like it or not what you are doing in FPGA development is digital design and you need to have a sense of how design decisions affect timing. Read the Vivado user guides for design entry, constraints, simulation, timing closure, and debugging. Understand that even though various Zynq devices are based on certain FPGA families the documentation tends to be unique for these devices. You will be overwhelmed with all of the 'basic' information. Spend a week or so running though all of the basic documentation, spending more time on specific topics each read-through. The object isn't to memorize or understand everything but to get a general feel for how Xilinx presents its information. You can also learn stuff that you will miss in specific IP documentation by using the simulation, but only if you are careful to read all of the simulator messages. This is complicated stuff and the tools, even when they behave as described in the reference material is even more complicated. The purpose of doing this is to get a general feel for how the devices work and specific use limitations and how the tools work. It will take a year or so before you start becoming competent at it if you are a normal human.
  8. @askhunter Tip if you want to notify someone that you are responding to a post type @and the first few letters of their username. A selection of usernames will appear in a popup window to choose from. If you just type @ and the whole name you won't get the desired result. I confess that I'm not an expert on using the features of this site but I did figure out this one. As to understanding all of the Xilinx documentation what yo are doing is correct. Speed-read though a document to get a general sense of what's being presented and don't worry about the things that you don't grasp. Just being familiar with what information is where will help with a specific question later. The DSP48E is a very complicated piece of hardware. You only understand how complicated by trying to instantiate it as a UNISIM component to implement a particular algorithm. I've done this and it take time. You understand by doing; one step at a time. In your case I'm assuming that you are starting with someone else's code and trying to modify it. This approach takes a difficult task and turns it into an extremely difficult task. [edit] Vivado uses the multipliers in a seamless way when you specify a multiply in your HDL code. It takes care of a lot of little details, such as that the multipliers are signed 18-bit. There are a LOT of options with the DSP48E blocks. Once you start making decisions for Vivado, by say, using the use_dsp attribute in your code you are taking on responsibility for more of those details... so you had better understand how the DSP48E blocks work. Trust me, even after you have figured out all of the necessary behaviors of the DSP48E blocks it doesn't get easier as you will have to contend with routing issues that might dramatically reduce your data rates. This is a general rule for using FPGA device resources. You can use the IP wizards to help construct a component that's useful for your needs or do it yourself in HDL code and assume the responsibility for getting all of the details and constraints right.
  9. @askhunter I suggest that you read UG479 to see what the DSP48E blocks do. Then read UG901 to see what the use_dsp attributes do. Reading the recipe doesn't always help improve the cooking but it never hurts. A long time ago having signed multipliers in hardware was a big deal for FPGA developers. For the past decade or so these have become integrated into more complicated and useful 'DSP' blocks. The DSP nomenclature is a holdover from the days, long before IEEE floating point hardware was available, when having a fast multiplier in hardware meant that you could do some fun stuff in a micro-controller that you couldn't do with software routines. These days the lines are blurry. Most FPGA devices have some really fast hardware features, block ram and DSP blocks ( depending on how they are used ) being the most useful for grinding out mathematical algorithms. By the way, the DSP blocks can be useful for more than multiply-add operations.
  10. @SGY What you will get is a pretty nice, somewhat elderly but very useful FPGA development hardware. You also get the Zedboard community and all of its postings. There are numerous tutorials written expressly for a version of this board. I highlighted 'a version' because you need to know that there were a few important hardware changes in the life of the board. Because it's older most of the tutorials were written for long gone versions of ISE or Vivado and might be difficult to follow as the Vivado user experience changes with every new version. As to RTL code you can find some but since this is a ZYNQ product the emphasis is on the ARM development. I've had the C version of the board for quite a while and still make use of it when I need a Zynq solution. The Zedboard contributions are at this time mostly old at this time so you will have to learn the whole Zynq development ecosystem. Once you've done a few PL designs it will get easier. Zygot's hint for the day is to let Vivado create a Zynq HDL toplevel source file in a project that you, not Vivado, manage. You can instantiate that into your own toplevel design with all of the PL magic that you can conjure up. You'll have to trust me that this is the far easier way to go if you want to do FPGA development with ARM support. Your opinion is more important (to you) than mine however...
  11. @Reggs Thanks for posting your question. My first suggestion is that you figure out how to use the testbench in Vivado. You can create a special Vivado project using just the UART_DEBUGGER,vhd and YASUTX.vhd source files. It doesn't matter what device you use. Just make sure to add the T_* testbench files as simulation sources after the project has been created. Both Vivado and ISE mark source files as implementation or simulation or both and it's important that VIvado knows which are which. All of this was easier in ISE. ( in a lot of ways Vivado is a really badly conceived software application ) In Vivado Simulation Settings you can select which of the testbenches you want to simulate. I strongly suggest that you get to know how to do simulation in Vivado or ISE ( simulation is actually easier in ISE ). None of the code uses a particular feature of any particular FPGA device so you could use the free version of ModelSim that comes with Quartus to run the simulations as well. If you really can't get the simulation running let's work on that first. Once you have the simulator working it will, by default, show you the toplevel (in this case the testbench) signals. You can then add any or all of the lower level code in the hierarchy to the simulation waveform viewer. Just understand that the more signal you show and the finer the time resolution the longer the simulation takes. For this code what takes time is the slow uart output. You did read the commentary at the top of the source files, right? You should be able to use a 50 MHz clk and get out a message at a 115200 baud rate. I've used this component often and with a few baud rates ( I haven't tested it exhaustively at lots of different baud rates ). The idea is to send a string of hex numbers in ascii form so that you can read the value of a register in your code at a particular event or time. This particular tool isn't meant to send text, only hex numbers in ascii format. The number of hex digits displayed in the terminal should match your DATA_CHARS assignment. Are you sure that the clock that drives the UART_DEBUGGER matches the generic CLK_RATE? From what you depict as your output it looks as though your problem is not with baud rates ( clearly there are recognizable characters being printed ) but in using the data_write_stb and busy signals. data_write_stb should not be asserted until after busy is de-asserted (low). The busy signal indicates that the YASUTX transmitter is in the process of sending a set of characters and not ready for another set. Make sure to strobe data_write_stb for only 1 'clk' clock period. In your code you will decide what conditions or event starts a message. It should be obvious that any baud rate is going to be pretty slow relative to whatever is going on in your design at 50 MHz so you need to make logic to select the instant where your data is captured and sent. By the way you can capture multiple data states in successive clocks by putting a fifo between your data and the UART_DEBUGGER; that way you can feed say, 1000, snapshots of your data to the fifo and let the UART_DEBUGGER read them at its own slow uart time frame. I have an example of this lying around somewhere around here... Oh, if you look at S3_PGMR_D.vhd in the S3_PROGRAMMER_R1.zip source in the S3 Starter Board Programmer project that I've posted here in the Project Vault you can see an example of using a FIFO with UART_DEBUGGER. You may wonder why you'd want to print out data faster than you can read it but if your use Putty as your terminal it can be set up to fork all incoming and outgoing text to a file so that you can read it later... how cool is that? Once you get the code simulated you will quickly figure out what's going on. Hopefully, you will be encouraged to start on creating your own debugging IP. You can, with a bit of skill and practice make better and more useful debugging tools than Vivado provides. [edit] Xilinx has a number of helpful guides to using the Vivado simulator in tutorial, reference manual or user guide formats. There's a lot of information about the devices and tools to digest but you don't have to understand everything in order to learn enough to do a specific thing. Being able to use the Documentation Navigator and material is key to success with FPGA development.
  12. Thanks @xc6lx45for forcing me to re-read the original post. Slow is such an objective assessment. Brewing beer is slow if you intend to start drinking now... Some things just take time. I hate waiting as much as anyone else so I just do something else while the tools are doing their job. Usually, I spend the time thinking about what needs to be done next or assessing what has already been designed. What I read into your post is focussed on 'I have to'. Perhaps this is the crux of the problem. Doing something enjoyable and intellectually challenging is a good antidote for being bored waiting. Simulation is not a way to speed up chores. When I have to do chores that I'd rather not do I've figured out ways to make the time less onerous. By the way; if you ever do this for a living for a company that does a significant amount of FPGA development your simulation will include the analysis and place and route steps. There is behavioral simulation for the logic and there is timing simulation that attempts to verify how your design bitstream will perform.
  13. I've got nothing against using an automated tool to do formal verification. For many environments it's a necessity. I'm going to suggest however that you learn how to use the 'classic' simulator tools first. This would be the one that comes with Vivado or ModelSim for Quartus. For those learning the nuances of logic design with an FPGA the old 'use your brain' approach has some advantages. I'll offer the analogy of flying a commercial airliner as an example. Flying a plane that 99% of the time is so automated that it doesn't need a pilot is easier than flying a single engine prop plane with a stick control. The reason why you need to have hundreds of hours of experience flying planes that are cruder than a 747 or fighter jet before you are allowed to fly one is for that other 1 percent of the flying experience. In the case of a plane you need to be able to know what to do, calmly and in a controlled manner, when flight conditions are beyond the capabilities of the automated systems; or heavens forbid when the automated systems are failing and doing something that imperils of the craft. In the case of logic simulation it is very instructive and important for development that you gain insight into all of the myriad issues and conditions in your design, and there are a lot of them. Trusting in a software approach to 'fix' your design flaws is not so instructive for the beginner. Few, if any, of the designs that you will do as a novice or for your Basys3 board will need formal verification. Training your mind to improve your design methodology and awareness is an essential part of skill development. Designing a test bench is not easy and that in itself is, similar to flying a Cessna at night in storm conditions, is part of progressing with your design skill. Once your are good enough to do FPGA development where formal verification is a requirement those tools will augment your mental preparation. It is unfortunate that this part of the trade dosn't have as many texts and examples to help those who have to learn it by themselves. Being able to use formal verification tools is nice but I'd never hire anyone do to commercial FPGA development who first didn't develop the basic skills, awareness, and testbench acumen using mental understanding and thought processes are that part of competent design. You won't get a gig as captain for a major airline based solely on hours of flight-sim experience. If Uber ever owns an airline I'll stop boarding planes for related though less obvious reasons.
  14. zygot

    AXI4 and Vivado ILA

    No, you should be able to use any of the PL input pins for your own logic or and ILA. You might have to create copies of output signals.
  15. So you already understand the 'prime directive' of FPGA design, that is ask "Why...", even if the question seems to be silly. Your question is basic but not silly. Welcome to digital logic design. You are correct that it takes time for data to change values. This is true for clocked data or combinatorial data. There are also delays for both clock and data signals to propagate along wires outside the FPGA device and from one area of the FPGA to another area. Sometimes the logic at the sink end of a signal will be clocked by the same edge as the source end... often it will be clocked by a later ( in time ) edge. If you have a wide clocked bus of signals it is possible for some of the signals to be clocked at different edges than the others.Sometimes it doesn't matter which edge but often it matters a lot. To further complicate matters your clock edges are not exactly one clock period apart due to jitter and drift. And then delays are temperature dependent. What's important for clocked logic are setup and hold times relative to the clock edge when logic clocks a signal. It doesn't matter if the signal was created by a clock or combinatorial logic. Things get really tricky when you have multiple clocks and want to pass information between these clock domains. If the clocks are unrelated ( that is one was not derived from the other and has a relatively fixed phase relationship ) things get even more tricky. You can read about AC switching characteristics for the FPGA on your board in the datasheet. Even if you don't understand all of the parameters this is good reading for all FPGA developers. You need to have a reasonable grasp of the fundamental concepts of digital design if you want to have success with and HDL. It is quite possible to have fun with only the most basic concepts in mind as you develop skill with your HDL but as your designs get more complicated your understanding of digital logic design will have to grow as well. There is no arriving at a destination, just asking questions and gaining knowledge and insight and hopefully skill.