• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by zygot

  1. @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.
  2. 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.
  3. @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.
  4. @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.
  5. @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...
  6. @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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. @bhclowers Feel free to let me know if I'm being unhelpful.... From your original post I think that your question is a bit more complicated than you let on. I have never used the Pynq though I did look at it carefully when it was introduced. My understanding of the Pynq1 concept is that it provides a sort of "walled garden" approach to using an FPGA; that is it promises a 'friendlier' user interface if you stick to the scripts, third-party software, and community support arena. I mention. this because a more general question that I think you are trying to ask is if an FPGA board can do what you want. If you implement everything in and HDL the answer is sure. I assume, but aren't sure from what I've read about Pynq is that it should be possible to use the board without the normal supporting software, that is as a regular FPGA board. I have no idea how difficult this would be. If you wer to use, say the ATLYS, with its parallel ADEPT USB 2.0 interface and audio codec, and wrote everything in VHDL or Verilog then it shoudl be straightforward. Not necessarily easy, but straightforward. You custom waveforms would be prototyped in OCTAVE and implemented in HDL. This approach requires you to do all of the heavy lifting but also gives you total control. If your sampling rates are fixed then things are a lot easier. As you have no doubt found out, the cost for convenience, is a significant probability that you can't to home plate.
  12. Using unconstrained arrays is generally a bad idea for synthesis. Even when you expect to constrain it later when using frame_type don't assume that your synthesis tool will close the loop. Refer to UG901 for Vivado VHDL support and coding guidelines. There are differences between synthesis tools from various vendors in how and the order of when code is evaluated.
  13. Look around this Digilent's site for information for clues on how to do what you want to do. There have been a few responses to related questions on the FPGA forum.
  14. They don't drive your uart do they? What is your uart connected to? Is the problem hardware or software or SDK related? A known good design that uses a uart will help confirm your assumptions or make you reassess your situation.
  15. @hello.parth Trying to make your own FPGA board by copying someone else's work without understanding why they made the decisions that they made is just silly. If you can't read datasheets and do the analysis yourself then you need to hire someone who can.
  16. @aeon20 There are a lot of possibilities. It is also possible to use a terminal in the SDK to capture USB UART data. I haven't done this on Linux. It's difficult trying to follow a tutorial when most of the instructions don't work with your set up. The same thing happens when newer versions of the tool don't work the same as the version that the tutorial was written for. I suggest trying to separate your Linux COM port issues from your Vivado/SDK issues. Try to make sure that you can work a serial interface terminal program with *something* so that it isn't part of your debugging. When you have the possibility of a lot of parts not working you need to start establishing that each of the parts work separately one by one. Perhaps you can find a known good configuration file for your FPGA board that continually sends out text to the UART when button is pressed.. or similar action happens.
  17. @JColvin I think that this would be great. Over the years I keep seeing a repeat of the same questions and clearly most users are unable to find a direct line to past responses. Once a few months have past even I ( yeah, I see the irony in those last two words ) have a hard time finding posts that I want to refer to. Some easy way to get to those mostly timeless hints and tips would be helpful to many of us including newbies.
  18. @aeon20 I posted this answer a while ago: Here is an edited example session telling me to use Putty with ttyUSB0: In a Linux Terminal window type: lsusb Bus 005 Device 003: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port In a Linux Terminal window type: dmesg | grep tty console [tty0] enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:0b: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A usb 5-2.1: pl2303 converter now attached to ttyUSB0 If you do a search for 'lsusb' in the site search tool above you can find the full post It would be nice if someone at Digilent created a "HowTo" section to make it easier for new users to find tips and hints.... just a suggestion.
  19. I really don't know where to put this so I decided to ask myself a question and then propose an answer. Perhaps there needs to be a new home for basic assistance for users. A frequent question for beginners and even experienced people resolves around how to select an FPGA development board. The answer depends on what you want to do with it. The analysis can be anywhere from simple to complex. But there are three issues to resolve that will simplify the process of making a selection. Three questions that only you can answer are: What do you want to do with the hardware ? What is your budget ? What is your experience level ? For our context I'll be ignoring a 4th question, which might be the real driver for your interest. That question is: "What are your goals?". If you are just curious then that's different than if you want to add marketable skills to your resume. Also, you might perceive knowing how to develop with a particular device, such as Zynq, as an over-arching motivation. My view is that the Zynq is a great solution for a number of problems for a competent FPGA developer but except for running Ubuntu almost anything that I can do in software can be done with logic resources in an FPGA. On the theory that goals tend to change with experience and knowledge I'm going to proceed without answering that question. So let's group some possible answers to the responses to the previously listed questions and provide a bit of guidance. Case 1: 1) $0 OR 2) either "I don't know" or "I just want to learn how to use an FPGA". OR 3) None If you don't have a specific hardware project requiring an FPGA you don't need to spend anything to learn or develop FPGA applications and I suggest that you don't. Just get the latest version of Vivado or ISE. You can do everything except spend time debugging hardware with nothing more than Vivado or ISE. If you have no experience with VHDL or Verilog then I strongly suggest buying a used textbook but this is not a requirement. Xilinx provides information about how to use its devices and tools but assumes that you know enough about an HDL to accomplish synthesis or simulation for a project. Learning an HDL in the context of a directed or group setting is easier than teaching yourself, but not necessary. FPGA devices are complex and the tools are complex and no one is going to spend a Saturday afternoon reading the Xilinx literature and being a competent FPGA developer by Sunday. Understand that FPGA development is really just digital logic development. So if you come from a software background you might have to re-wire your brain a bit to grasp the basic concepts. Learn the basic concepts, how to be fluent in an HDL for both synthesis and simulation and how to know how to simulate effectively. You simply can't do competent FPGA development unless you know how to write a testbench in your HDL and perform effective simulation. You don't need to read the vendor manuals for the resources in any particular FPGA device but having an understanding of what and FPGA is certainly can't hurt. Case 2: 1) "not much" AND 2) "Nothing in particular but simple logic designs" AND 3) I'm competent using an HDL, simulator tools, and Vivado or ISE If these are your answers then the advice for case 1 might still be valid. It's true that most of us need some form of positive feedback to motivate us to do hard work. An FPGA development board might just do the trick. So my advice is simple. Spend the least amount possible. There are decent boards with a JTAG programming and minimal interface resources available such as the CMOD or DE0-NANO for < $100. Aside from the motivation factor you still don't need hardware to accomplish even complicated designs so why spend money until you know what to spend you money on? If you are determined to spend your allowance then start off with the least expensive and least expensive to replace board. The buttons, LEDs and switches can all be simulated. For basic HDL designs you can use global clock buffers and not worry about anything except pin location constraints. Case 3: 1) "not much" AND 2) "I want to use and FPGA to build a variety of hardware prototypes that don't require using advanced FPGA IO features" AND 3) "I'm competent using an HDL, simulator tools, and Vivado or ISE plus I'm reasonably competent designing with digital, analog or mixed-signal devices." For this case there are a number of inexpensive modules that offer 30 or more GPIO and basic functionally, but more importantly have the IO on headers that are easy to connect to a PCB of your own design that performs a specific function. In this case the FPGA development board is more of a component and might be dedicated to one prototype. There are a number of inexpensive modules from Digilent, Terasic and other vendors that might be ideal. You can make some pretty useful things with one of these modules and PCB vendors offering free layout and design tools like ExpressPCB. Here are some specific considerations in making a choice: What kind of documentation is provided? What kind of customer support is available? What kinds of demo projects are available and can I actually build them with my tool version Now of course merely understanding the manuals for clocking, IO, and other resources of a particular device isn't sufficient. You need to be able to make use of the device datasheet, especially the AC specifications. To give you an idea here is a table of useful switching specifications for a number of Digilent boards that I own ( the CMOD-A7 is an Artix-1 device ). Nexys Video Genesys2 ATLAS Artix(-1) Kintex(-2) Spartan6(LX-3) DS181 DS182 DS162 ----------- ----------- -------------- Fmax_bufg 464 710 400 Fmax_bufh 464 710 - Fmax_bufr 315 540 - Fmax_bufio 600 800 - Fmax_bufio2 - - 525 Fmax_buffpll - - 1050 Fmax_buffgmux - - 400 PLL_Finmax 800 933 525 PLL_Finmin 19 19 19 PLL_Foutmax 800 933 1050 PLL_Finmain 6.25 6.25 3.125 PLL_vcomax 1600 1866 1050 MMCM_Finmax 800 933 - MMCM_Finmin 10 10 - MMCM_Foutmax 800 933 - MMCM_Finmain 4.69 4.69 - Fmax_bram_xxx 297-388** 427-544** 280 Fmax_fifo 388* 544* - Fmax_dsp48e 177-464** 249-650** - Fmax_dsp48a - - 333** All values in MHz - not applicable * non-ECC mode ** depends on modes used You also need to understand thermal management. Some of these boards don't have much copper mass and do have a lot of heat dissipating components in a very small area. It is likely that you will have issues trying to push these modules to the extreme limits for an application even with their limited power supply resources. If what you need is for some custom logic and <100 MHz switching and a few are output pins then you aren't likely to have problems, assuming that you properly terminate your IO signals. Since you are competent doing digital and analog design you know the differences between a .1" header and and HSMC or FMC connector as far as signal integrity characteristics are concerned. You also understand from the FPGA vendor's literature the termination requirements for all supported logic standards and clocking limitations. Case 5: 1) "Less than $2000" AND 2) "I want to experiment with using advanced IO resources" AND 3) "I'm competent using an HDL, simulator tools, and Vivado or ISE plus I'm reasonably competent designing with digital, analog or mixed-signal devices." In order to get experience using the advanced IO features or transceivers available in current generation FPGA devices you need a board that is designed to allow you to use these features. I bought a Genesys2 primarily because the way that they implemented mDP allowed me to experiment with multi-lane transceiver designs. The HPC FMC connector was a bonus but you have to do your homework if you plan on using a mezzanine board and the FMC connector. In particular, there are a lot of "FMC" mezzanine cards that aren't necessarily suitable for the Genesys2 FMC implementation or are even particularly VITA-57 compliant. Usually, this has to do with clocking and IO bank pin assignments. If you want to use a particular FPGA carrier board with a particular FMC type mezzanine card you have to trace through all of the pin assignments to make sure of compatibility. This is particularly true for differential LVDS IOSERDIES2 applications. In general it's easier to find an HSMC mezzanine card FPGA carrier board combination but you still have to do your homework as there are differences between differential signal pairs routed as differential pairs and differential signal pairs simply having matched trace lengths. If you have a bus of differential signals trace length matching across pairs is important. I've used the Nexys Video and Genesys2 boards for a number of projects using the FMC mezzanine cards with complete success. I've not been able to use either of those boards to connect every FMC card that I wanted to use. It is unlikely that you will find an FMC mezzanine card designed to work with an Intel based FPGA board that can be used on a Xilinx based FPGA board. It all has to do with pin assignments. This isn't a deficiency of the FMC implementation of the Digilent boards are even of the mezzanine boards, just an incompatibility for particular FPGA device pin locations and signal assignments. If you only get one takeaway from this thread this is it... just because it's on an FMC or HSMC connector doesn't mean you can use it with your FMC or HSMC equipped FPGA board. Digilent's current crop of FPGA boards provides either low speed PMOD connectors (<10 MHz) which are ease to connect to a custom PCB or high density FMC connectors which are expensive and difficult to connect to a custom PCB. No one knows what the so called high-speed PMODs were designed to do, but they aren't suitable for advanced IO experimentation. If you want to experiment with transceivers you need to read the Xilinx transceiver user manual and know the difference between GTP, GTH and GTY transceiver implementations and maybe those from other vendors. Before choosing a general purpose board to explore advances IO I suggest: Have a thorough understanding of advanced constraints beyond location and IOSTANDARD. There are user manuals for this. Have competence in timing closure methodologies. Read the manuals. Thoroughly understand the Series7 IO, clocking, and transceiver users' manuals Pore over the board documentation, especially the schematics, for boards on your short list. A lot of FPGA board vendors will make you do the work to figure out which banks specific IO pins are assigned to. Make sure that the support includes applicable demo projects that you can build them targettin that particular board with your version of Vivado easily. Figure out what IP if any you need to do something useful with your advanced IO plans. Case 6: 1) "The minimal to accomplish the project" AND 2) "I have a very specific project to complete using specific advanced IO resources" AND 3) "I'm competent using an HDL, simulator tools, and Vivado or ISE plus I'm reasonably competent designing with digital, analog or mixed-signal devices." For this case the analysis gets complicated. If you want need to do video or Ethernet based communication there might be a board that fits your specific needs for a particular project. The general rule is that buying hardware that isn't designed to accomplish a particular purpose is rarely a good investment. 10G Ethernet is a different animal than Gigabit Ethernet. 12G SDI video is a different animal than HDMI video. You need to verify that either the board can do what you want to do or provides the IO in a form that let's you add a mezzanine card to it to do the job. Neither of these investigations is necessarily straightforward or easy. So by now you probably realize that each of the cases that I posit involve building an ever increasing level of competence and body of expertise. So everything that applies to the previous cases applies here except that you now have to select all of the boards that will allow you to complete your project. If you need to have a temporoary or time-restricted license to complete your project then what good will that be next year? Clearly I haven't addressed all of the possible scenarios for the three questions put forth in the beginning but hopefully I've presented the basic ideas for a wide range of people willing to take the time to read it. One case that I didn't address is where you want to do something using one of the many PMODs available for purchase and want to create an HDL solution to accomplish something. Again, the cheapest board available with the most standard PMODs will likely be what you want. Make sure that you understand what will be provided for you and what you needs to do for yourself. This is a small universe but one in which a lot of people will happily spend there lives. A lot of what's been presented is 'common sense', whatever that is. If you've never ridden a bike but saw the Tour de France and want to dip your toe into competitive racing the first thing to do is not spend 100's of dollars on shoes, helmets, clothes and $10K on a road bike that's just over your wildest budget ( you know because you're going to grow into it...). If, once you know what you're doing, you decide that you want to do mountain trail racing none of that gear will be useful. Also learning how to ride in the company of a local bike club will be much more productive and fun than spending weeks on the couch reading books on technical riding concepts. I hope that this provides some things to consider for the many of you not having the experience with a lot of FPGA development boards and projects. I apologize for the rough formatting....
  20. OS file permissions are a two-edged sword. It can prevent users from changing stuff that shouldn't be changed but it can prevent users from doing their work unintendedly This is a user issue. You will have to learn how to change file permissions as a computer user to the extent that your privileges allow. Depending on the OS and how security is set up this can be a pain, especially when transferring files form one OS or computer to another one. If you have an IT department they should be able to help resolve issues. If you are the IT department then you need to learn how to set up and use your OS safely and securely.
  21. I assume that you mean that you implemented a scrambler in the PL. If this is the case you need to add some IP provided by Vivado to allow the PS to pass data between the PS and the PL The PS will communicate with the PC uart using software and the PL logic will handle the communication between the PS and the PL using the interconnect There are a number of ways to do this. If you look in the IP Catalog you will see a variety of AXI and AXI-lite possibilities to allow your ARMs to pass data to and from the PL and your logic. You can't bypass the PS uart resource connected to the connector and send the signals to the PL directly. The easiest approach would be to use something like the AXI_GPIO IP, though you won't be connecting the signals to pins ( just logic ) The IP Catalog doesn't make finding all of the IP easy so keep expanding all of the categories until you find it. Once you export your hardware design to the SDK it will write a driver for you though you will still have to do some software development to create a complete application. There are a number of tutorials showing how to do this. So the steps are: add the AXI peripheral interconnect IP of your choice to the board design schematic and generate the design build a new bitstream configuration file export the design to the SDK create an application that gets data from the uart and sends it to your PL scrambler then reads the output and sends the result back to the uart. You will have to figure out a few details to make it all work but the tutorials should help with the basic concepts and using the tools. [edit] So I just realized that the previous steps are not quite right for you. I would have Vivado create an HDL to encompass the board design and then instantiate that into a toplevel design of my own that instantiates the scrambler. I think that what you are supposed to do is create your own scramble IP that you will integrate directly into the board design ( not use a standard AXI interface as I mentioned..) This is a bit more complicated than how I'd do it but there are tutorials on how to create and add IP to your own IP catalog. To anyone else reading this thread for help in a similar project. This is a good example of why the Zynq isn't the best platform for all FPGA projects. You can do this project with a CMOD-A7 without the hassle and complexity of the board design and SDK. If this were a product the Zynq device would be too costly to be viable in the marketplace. As a project that makes you learn how to do the basic Zynq development flow it's a pretty good project. [edit] Personally, I find the whole IP creation thing to usually be too much trouble for the benefit, though I could see where I might want to do this. Sometimes it's good to learn how to do things that you never have to do...
  22. @moreabhinav I'm not sure that I understand your requirements either. As Jon mentioned the UART USB connector is tied to the PS. You can route PL pins to PS resources but your software will use the PS resources. For example you can connect PL pins to the unused uart resource in the PS and it will be used just like the one attached to the UART USB connector on the board. The SDK will even create a driver for it. Also, what you have then are 2 logic pins for Tx and Rx. You can use these internally in the PL with designs of your creation or externally but with additional hardware. If you want to connect this uart to a PC then assign the signals to a PMOD and attach those pins to a TTL USB UART cable or module that you buy separately. Adafruit and SparkFun both offer inexpensive versions. This approach would allow you to connect a PC to both uarts in the PS, both controlled by the ARM cores. The Zedboard PS has 2 Ethernet controllers and the same concept can be used to provide a second Ethernet port to the PS. In this case you will need to supply your own PHY using the FMC connector. What you can't do is mux the PS pins into the PL to, say create your own MAC-less (or custom MAC of your own design) Ethernet interface using the Ethernet RJ-45 connector already on the board. It is certainly possible to use 2 PL pins connected to an HDL uart instantiated in the PL logic resources and send/receive data between it and the PS. In this case you will have to write your own drivers as the SDK doesn't have code to handle this. You will have to understand AXI bus interconnect IP. Don't think of the Zynq as an FPGA with an embedded ARM core. Think of it as a big ARM uController with more resources than MIO pins but with a mux to allow routing signals to the PS to use resources that the board designers aren't using. The issue then becomes if the board designers offer IO connectors and routing that support doing that. Let's say that you have logic in your PL to count pulses on PMOD pins and you need to reset the counts from the PS; you want to do this using the USB UART connector that comes with the board. You can certainly connect the output of your logic design to the PS through the AXI bus resources, directly as GPIO, or indirectly through BRAM or FIFOs. Perhaps this is closer to an answer to your question. If it is then you have some reading to do... There are tutorials about how to create custom IP and connect it to the PS... but I don't have links to them on hand.
  23. Never make assumptions about how much your skills are worth... I know from experience. Engineers are, in most places, at-will employees. If you don't know what this means then I'll provide a hint: You can fly from across the globe for an interview and come to work a week later to find that you are unemployed before you log in an hour and that's just too bad. I know of such a case. The days when engineers were valued as assets are long gone. Engineers aren't professionals in any meaningful way and those salary surveys might not have anything to do with you. Companies want to cut costs where it's easiest and they get the best short term (often imaginary) benefits. Tha's not to say that a company that's stuck and manager's jobs are being threatened won't pay exorbitant prices in hope of extricating themselves from self-inflicted gunshot wounds to the foot.... but don't make a career choice hoping to make money. Because they are collectively pretty stupid they aren't likely to make good decisions about throwing money at digging themselves out of a hole either. There are books about how a group fairly bright people can pool their collective intellectual resources into an entity with the brain power of a nail.... Perhaps another way to make xclx45's argument is to say that an FPGA often not the proper solution to a great many problems. FPGA devices by their very nature will never compete with one chip commercial solutions for a large variety of product needs. FPGAs aren't the future as they say, but when you need them it's nice to know how to use them.
  24. It's been awhile since anyone has posted to this project. So time for a pop quiz: Who can provide the best answer as to why no one has posted an LVDS IOSERDES2 implementation and probably never will? (Ignore the fact that despite a few suggestions for beating my rather low effort implementations I'm the only one to have posted any solutions)
  25. Well this depends on the requirements of your project, and how you propose to address them. Really high sample rates and extreme data widths appear to address a number of issues, until you look into the details and actual performance that you are likely to obtain using real components. What you need to do for a start is some analysis about how to deal with the requirements for your particular project. First address the issue of frequency band of interest. Some applications allow for sub-sampling at a lower sampling rate using filters to remove spectral content outside your band of interest. This is common in communications and medical applications. If you need to sample a really wide-band signal, say from DC to 85 MHz then you have your work cut out for you. Converting analog into digital isn't all about the ADC; the analog front end is part of the budget analyses for all of the requirements. As I've mentioned in other posts your analysis of performance includes every component between your signal source and the ADC. A converter's maximum sampling rate is but one, in some cases not even the most significant, criterion for choosing an ADC. For issues of dynamic range a 128-bit ADC would be great! But good luck finding one. Do you realize what kind of signal level the LSB of a 2V pk-pk 16-bit ADC involves? You can deal with fading signal levels using PGAs (programmable gain amp;lifiers), TGC (time-gain control) etc. There are ADC's for ultrasound applications with these built into the device. Again, every component between your signal and the ADC has to be analyzed for it contribution, positive and negative, to your requirement budget analysis. You need to understand that if your 14-bit ADC is set up to sample a signal that varies from 0 to 2V and your signal is 0.5V you don't have a 14-bit ADC any more. There isn't enough space here to deal with all of the important details of analog to digital conversion using actual hardware. Be aware that those pretty FFT plots that come with every ADC data sheet often involve some pretty bizarre and specific Fs sampling rates and single-tone input signal frequencies in order to show performance of their part in the best possible light, As I mentioned, Terasic is the only supplier of relatively inexpensive ADC/DAC boards (HSMC connector) that I know of. We're talking 14 bits and 150 MHz ADC 250 MHz DAC sampling rates. They use a fairly generic transformer front end for wide bandwidth. The Cyclone V GT board is nice with PCIe and 2 HSMC connectors. I've described a project that I did using them in the Learn section of this site. You may still have to provide upfront filtering as required. Opal Kelly sells a couple of Syzygy compliant boards and one ADC and one DAC POD. They did their homework as far as providing usable IO for a variety of interface standards; by that I mean they considered clocking, programable IO bank Vcco, and bank pin assignments, and connector with good signal characteristics for their GPIO. Digilent should make a board that is Syzygy compliant. Opal Kelly offers a PMOD Syzygy POD so I'm sure that they would welcome a collaboration. In terms of converters with advanced IO interfaces such as transceivers or IOSERDES2 you need to verify everything before selecting hardware. Start with understanding your FPGA device resources. Read and understand the reference manuals for IO and clocking. To do IOSERDES2 you need your clock inputs and differential LVDS IO in the same IO bank. High ratio serialization /de-serialization gets messy. If you want to use an ADC evaluation board and an FMC adapter for any particular FPGA board with an FMC connector your have to trace through the signal pin assignments through every connector between your ADC and the FPGA board FMC pin assignments to see if it will work. You might be able to do this with an ADC having a parallel data DDR output ( I have ) but don't expect to be lucky. I wish I had a really good answer for you but I don't. As I mentioned earlier ADC options for the Xilinx ecosystem, unless you have a lot of money to burn, are not great. BTW, Digilent allows you to send a message directly to any other registered user of their site who will get an email notification.