zygot

Members
  • Content Count

    967
  • Joined

  • Last visited

  • Days Won

    45

Everything posted by zygot

  1. zygot

    Offline Installer

    I've been thinking that we've not been talking about the same things for a while now. In order to use your CMOD you need Vivado to create the configuration bitstreams. The last time I downloaded Vivado it was a file north of 40 GB. Yes, Gigabytes. Xilinx also supplies much smaller installers that require an internet connection in order to install Vivado on you PC. Digilent supplies tools for standalone configuration of the FPGA using bitstream that you create. Also, their tools can supplement Vivado to allow Vivado Hardware Manager to use the Digilent configuration facilities. Digilent also has software development tools and APIs for compiling your own software applications using various interfaces found on their FPGA boards. These files are all reasonably small. Trying to do FPGA development in a room or building without any internet access is going to be difficult without full support from the IT people maintaining your network and computing resources.
  2. zygot

    Offline Installer

    About 20 MB to less than 1 MB depending on OS and format. Digilent has a nice GUI configuration tool for Windows but not for Linux.
  3. zygot

    Arty S7 with Simulink

    Xilinx has a number of documents relating to using System Generator as well as Vivado. This is where to start. Part of the Vivado installation is the Document Navigator a tool to find and download current versions of all documents. By "configuring" pins I assume that you mean setting location constraints for a particular board. Do read the Series 7 Constraints User Manual. When your source code is MATLAB and the System Generator is generating HDL your design flow will be different than the normal HDL design flow.
  4. zygot

    I bricked my CMOD-A7

    Before you start cutting you might consider trying to force JTAG configuration mode. It looks like the mode pins have 1K pulldowns for access.
  5. zygot

    Offline Installer

    @mattk My development PCs are sequestered from the internet as well; and have all of the available Digilent tools installed using the executables provided by Digilent's Resource Center. I just downloaded them to an internet connected PC. We're not talking about large files here. The Vivado tools are way too large for physical media and have to be downloaded. Perhaps you need to submit a request to your IT person to vet the tools and have them installed. It doesn't make a lot of sense that users in a closed environment would be allowed to install software on their own in such a setting.
  6. zygot

    Arty S7 with Simulink

    It's been a very long time since I used the MATLAB FPGA design approach. I suspect that MATLAB doesn't support all devices or platforms. I also suspect that your answer lies in MATLAB support rather then here. Hopefully, someone else can surprise me. I think that this site is mostly visited by people with OCTAVE or other MATLAB clone budgets.
  7. zygot

    I bricked my CMOD-A7

    The CMOD mode pins default to SPI programming so if the contents in the FLASH are bad you have a problem. Unfortunately, there's no room for a JTAG header on these modules so I'm guessing that you need a way to clear the FLASH. I can't think of a way for the FLASH to brick your FTDI device. It does look as if your USB driver is disconnecting the JTAG endpoint which is a problem. I'd certainly try the code that @xc6lx45has provided as it uses a different driver. This would be a lot less mysterious if the schematics were complete. As an alternative Digilent probably should provide a utility to erase the FLASH on products with limited configuration options and a preference for FLASH configuration.
  8. Not infrequently my advice is anything but appreciated; but I don't see that as a reason not to offer it if it seems appropriate. You've chosen a rather challenging project to learn all of the aspects that your request mentions. No problem, everyone has their own slightly different environment in which they thrive. Vivado Document Navigator offers a lot of vendor documentation. It can't hurt to to see what Xilinx has to say does it? Read about FPGA architecture and how the tools work. Familiarize yourself with the datasheet for your device. Read about constraints. Read about HDL support for synthesis and preferred syntax for inferring common digital structures. Read a few interesting application notes. Most aren't perfect but do contain key concepts. There's too much information for most people to digest in a sitting but just skimming though the pertinent documents will establish a map for where to look when trying to solve particular problems later on. Regardless of the mastery of digital design and HDL concepts that one has understanding how the tools work ( are supposed to work ) for a particular programmable logic vendor is basic. Other vendors have useful documents as well. Altera has had some good concept related documents though Intel seems to have maded finding them very hard.
  9. I was going to ignore this post. But then I thought that perhaps I could make a point that reading though Vivado synthesis and implementation errors and warnings is a more fruitful exercise, in terms of learning how to write HDL, than having someone offer "fixes" to get through bitgen. Getting a bitsteam and what you interpret as a successful simulation is not a guarantee that the HDL, or even the concept is good. So, I decided to download the code and try and build the project to see what Vivado synthesis might be complaining about. When the Vivado 2016.2 placer exited with errors I had to re-read the thread again as I thought that you didn't get past synthesis; I got through synthesis using your update code. I then started looking at the code. In general modern FPGA devices have two classes of signals; clocks and logic. This is important because the timing analysis for synthesis, implementation and bitgen rely on this. If you want design an SPI interface where the SCLK period is a few orders of magnitude greater than the combined delays of the logic resources, and Vivado doesn't classify SCLK as a clock it's OK to use logic derived signals as clocks for connected devices external to the FPGA. When you try to use logic derived signals as clocks in your HDL then this becomes a problem for a lot of reasons. When you use clocks as logic inputs this can be a problem. As to the CLOCK_DEDICATED_ROUTE FALSE constraint, occasionally, poor pin planning make having to use this constraint in order to use a particular FPGA external device interface work. It should not be a way to overcome design errors. I'm all for clever ideas and inventive designs but if you are going to break the rules, written or not, then you had better be able to understand the ramifications of what you are doing, and figure out what the tools have inferred from your code, and be able to verify your hardware implementation. It's very easy to mistakenly think that your design is doing what you think that it's doing in hardware when it isn't.
  10. There are two general approaches to dealing with the Soft processor or ARM processor flows when these are embedded into a design. One is to do the whole design within the framework of the tools, in VIvado the board design flow. I've done that using Xilinx IP and creating and packaging my own IP. I much prefer the other approach which is to constrain the whole IP stuff into a "black box". I use interfaces that have external pins exposed that are easy to connect to HDL. BRAMs are useful or sometimes it makes sense to package my own interface IP. Once the board design is complete and generated I have Vivado create an HDL file encapsulating the entire mess and then instantiate that as a component in my own toplevel HDL. Make sure to let Vivado know that you want to control the heirarchy not Vivado. There's no right way to do it; it depends on you own preferences and convenience. A good general rule, in my experience, is that letting the tools control things is never as good as having the tools let me control things. In the end the price of convenience usually results in unwanted constraint. Also, vendor IP is happy to use up resources with functionality that I don't need. I still use ARM based FPGAs but can't remember that last time I felt the need to use a MicroBlaze or Nios. [edit] Oh... and most important is that vendor IP is prone to being broken with new tools versions. Upgrading old IP, especially for soft processors, is rarely as simple or trivial as the vendors want you to believe that it is. Just yesterday I was testing a demo release for the Project Vault by rebuilding it on another host. The design was created in Vivado 2016.2 and the test build was created in Vivado 2019.1. There were only two IP, an MMCM and a FIFO and Vivado 2019.1 choked on both because it has restructured it's internal IP handling. This was the first time in quite a while that basic FPGA resource IP got trashed by a tool version; but it happens. For most of the other IP this happens a lot more frequently. If the SDK is involved then schedule a few days or more to figure out how to resurrect old designs created by past tool versions.
  11. Before attaching any FMC mezzanine card to any carrier, particularly yours, the first step is to know what Vadj IO Bank voltages are supported by your carrier board. Then, you have to go through the schematics of board boards to make sure that pin assignments will support whatever IOSTANDARD you need. Never assume that the FMC standard or connectors indicate compatibility of carrier and mezzanine cards. Even if someone tells you that they've used a carrier and mezzanine board combination the onus is on you to verify everything. Again, the fact that the connectors on two boards can mate doesn't imply functional compatibility.
  12. @rivermoon You'll figure it out. Pouring through texts, on-line content and example code will help clarify what's involved. Once you figure this out you can step back and make a fresh analysis of what it is that you want to do and how to do it simply. I doubt that you need a full client server implementation on both boards; but since you mention website it sounds like you'll need to figure out a lot of stuff before you system meets your goals. As I mentioned before, if you can set rules for the conversation and limit the scope of the network only a few packet types and limited functionality need to be used. It's hard to make that assessment if the basic concepts are fuzzy. If you intend to expose your application to the web I hope that you'll educate yourself about security issues. The vast majority of companies that sell internet connected products do an extremely bad job at this, to everyone's detriment. Implementing most things for educational purposes is great. Deploying systems with some capabilities imposes a responsibility that not everyone is willing or able to accept. If your hardware operates in a limited universe you can have complete control over what it does. If you don't have complete control over what it's doing, well... I'll let you complete the thought.
  13. My only advice so far then is to write lots of single task components and lots of testbenches and get simulating. Since you are experienced in HDL that isn't anything new to you. I'd certainly spend the time to consider the overall structure of your design and how you plan on moving data into and out of it. It should be both challenging and fun. An ounce of preparation is worth pound of debugging; if you can get past my habit of mixing metaphors.
  14. I can't recall an assumption that I've made using generic tools that hasn't bitten me in the posterior; perhaps I just tend to remember the bad experiences. So you have two boards that can function as an echo server. That's a start. If the only thing between your two boards is a CAT 5e cable then that are a lot of complexities that you might be able to ignore. One of the nice things about the SDK is that it provides a lot of example and source code. It doesn't make up for a lack of knowledge about a particular protocol. I assume that you will want to send UDP packets as your setup should be ideal for this. Start with conceptualizing how exactly a conversation between the two boards might play out. Is one controlling the other? Is there a format for request and reply that can be imposed? How do you plan on making this as simple as possible?
  15. That's quite a project. I think that I know how I'd do it but then I'm not taking your course, don't have a deadline, and have no idea what exactly it is that your instructor expects you to demonstrate as knowledge gained from taking his course; and this is important. One thing for sure is that I'd implement the task in OCTAVE using the simplest statements, no short cuts, simple structures with a mind to HDL implementation. Then I'd work on the HDL implementation. And here's the important point: I assume that you are expected to use an HDL and not pre-packaged IP or MATLAB code producing scripts. You don't want to jump into the English Channel if all you are expected to do is demonstrate that you can stay afloat on you back for 20 minutes. For an HDL project this is both interesting and somewhat challenging. You need to understand fixed point signed binary, bit growth, and more. This makes me think that I should be very cautious in suggesting an approach because I'm not the one needing a working solution by some deadline....
  16. Here's a thought that @D@nand I can completely agree on. I have some experience with electronics in hostile environments and I wouldn't want to assume the responsibility of providing guidance in the form of simple answers to simple questions either. It's harder than you think.
  17. @josejose You don't mention what kind of functionality your Arty A7 performs. Just thinking about a remote outdoor installation for the Arty good old RS-232, or better yet RS-422 is the simplest, safest and more secure way to establish communications between a remote device and a secure device. You have fewer wires, and can run much longer, and cheaper cables. If 57600 baud is adequate you might consider such an option. Of course you need a compatible connection on the other end. I'd rather not contemplate the phone connection end.
  18. Could you please can provide any guidance on how to use remotelly the Arty A7 board from my cell phone? Yikes!!!
  19. No. Unfortunately the MIG tools is a pain in the "" to use. You can't modify a design. You have almost always have to slog though every step for each iteration of a design. As I recall it does let you import pin assignments from another project. I don't know of any easy way to use the tool.
  20. zygot

    Verilog Simulator

    I've worked as a consultant or employee for a lot of companies that have years of accrued experience developing programmable logic based products that have been deployed by customers. All of them use the standard logic simulator tools. Some only use the free tools that come with the FPGA vendors' toolset. Some buy the full versions of ModelSim or other logic simulators. This isn't by accident or lack of sophistication. It's true that only a subset of Verilog and VHDL are supported by programmable logic synthesis tools. Verilog and VHDL were developed to do simulation long before the IEEE added standard libraries to them so that programmable logic vendors would adapt them for use as a synthesis source. All FPGA vendors provide documentation on what exactly their synthesis tools support for these languages. Logic simulators, even Xilinx's home grown one, support most of Verilog and VHDL. After all they are simulators! All of my testbenches use non-synthesizable Verilog or VHDL. Beginners and self-taught people often get into FPGA development with a lot of bad assumptions and conceptualizations. They also don't read the documentation provided by the vendors of the products that they want to use. I'd agree that finding good guidance on how to write a testbench is hard to come by. Beginners should start off using the minimal features of Verilog or VHDL until they've mastered those and then add to their repertoire as the gain experience. Verilator is a cycle based simulator. That makes if fast; but it's fast because it simulates a greatly simplified model of digital logic. If you're simulating a PDP11 it's a good tool. If you're simulating the latest Intel Xenon processor I'm pretty sure that you don't have a tool that has complete code or behavioral coverage. I strongly disagree that sub-clock timing isn't important to beginners. I would argue that simplifying logic design into a cycle based conceptualization is more confusing and counter-productive. There certainly are valid reason to use a cycle based simulator; even for logic design. These types of simulators are not preferred nor should they be the first option though. They are simply not capable of performing all of the simulator duties required for a complete programmable logic design flow. Use the simulator provided by your FPGA vendor. Learn basic simulator language concepts. Learn about limits of FPGA device resources and support for whatever source format you choose to submit to their syntheses tools. Most importantly, take some time to develop a basic understanding of digital design using real devices and real wires. I realize that LUT based programmable logic devices aren't a bunch of gates but the same concepts important to designing circuits with LSI and MSI devices on a PCB apply to FPGA design. If you find that ModelSim or Vivado simulator is taking too long you can adjust the sample unit of time to speed things up. A one pico-second timescale isn't necessary for most designs. You can finds ways to work around a lot of simulation time that isn't important to your analysis. All of the applications that you mention above are relatively simple designs in terms of timing analysis. At some point you may want to do something more challenging and will have to provide proper timing and even placement constraints in order to get the vendor's tools to properly synthesize and place logic so that your design will work. at some point sub-clock timing considerations will dominate the timing analysis of a high clock rate design. Verilator and SymbiYosys can't help you do that. Time based simulators can. You can only go so far with simple models of real things. My advice is to become reasonably expert with the tools recommended by the vendors who make the devices and make the tools to develop designs for. Once you have a level competence with those logic simulation tools then branch out and try other options. I would agree with anyone suggesting that Intel and Xilinx have done a poor job with code coverage, as you say, formal analysis of HDL source code. This is one area that needs to be addressed. There are companies that address this shortcoming. [edit] I forgot to mention that a lot of people resist post-route timing simulation because it often involves a bit more work. In the commercial environment where teams are working in parallel to make integration and delivery schedules having this analysis is vital to success. You need traditional logic time based simulators like the one that comes with your vendor's tools to do this. One more reason to become adept at using them.
  21. zygot

    Data acquisition

    I much prefer the Xilinx ecosystem but when I have a job to do I have found that it's best to select the appropriate platform that best suits my needs at the best cost point. You should spend the time to make sure that Quartus will allow you to build a configuration sof file using NIOS with an Ethernet interface without an IP license. I believe that Intel provides the default flashed demo source as a test. I have used the board's 1GbE port in an all HDL non-standard protocol application. Don't get the latest Quartus version as it doesn't support the low end parts. I am not fond of what Intel has done to the Cyclone family.
  22. This got lost through the cracks of another thread but I think that it is worth pursuing. I believe that I already know the answer but since the topic comes up on a regular basis and the FMC connector is frequently offered as a solution, an answer from some else would be helpful I have the Nexys Video, Genesys2 and Zedboard FPGA development boards sold by Digilent, but let's say that I'm contemplating a purchase of one of them in order to do a high speed ADC or DAC conversion project. Has Digilent tested any such mezzanine cards with any of the aforementioned Digilent boards and can certify that they are compatible?
  23. This got lost through the cracks of another thread but I think that it is worth pursuing an answer for. I have the Nexys Video, Genesys2 and Zedboard FPGA development boards sold by Digilent. Digilent doesn't sell but one FMC mezzanine cards and doesn't test or validate the compatibility of any either. So, the purpose, one assumes, is for the customer to design their own mezzanine cards. I want to design my own FMC mezzanine card to be used with one of the aforementioned boards. Where do I find a PCB trace report of the LVDS lengths so that I can do that:?
  24. zygot

    Verilog

    This line keeps popping up in my thinking because it's been bothering me; not because it's necessarily wrong but because it suggests ideas that are. Engineers and scientists work with models in order to interact with or manipulate reality. Idealistic, simplistic, and incomplete models get you so far. The better your model the more likely that you will be able to maintain the illusion that you have conquered some aspect of reality. There are a lot of reasons why programmable logic that connects an FPGA to an external device fails to work. Without attempting to be all inclusive I can think of a number of reasons off hand: The logic, that is the behavorial boolean mathematical design is flawed The model of the external device behavior is conceptually wrong or simplistic The final implementation has timing errors; which basically amounts to a failure to implement a design so that it operates correctly The physical interface between the FPGA and the external device is poorly conditioned. Any sales pitch for a product that claims to solve all of those problems mentioned above should be treated with considerable scepticism. A formal logic analysis tool can certainly help find incomplete or in some cases faulty logic. The usual suspects are if-then-else and case statements that don't include all possible logic input conditions. Formal logic analysis tools can't over come deficient models of how the external device works, or how the interface works, or all of the conditions your design needs to account for. They certainly don't provide perfect models for anything. At some point for a given programmable logic device and a clock rate the timing and perhaps placement constraints start becoming as important to success as the actual HDL code. And, depending on your synthesis and implementation settings it's a bad assumption that the optimized synthesized and implemented logic agrees with what the HDL designer intended for the tools to infer. You also need a good oscilloscope and the skill to use it in order to "close the loop" as it were for a lot of interface designs. There are a lot of tools available for the FPGA designer. The competent developer will be familiar and expert enough with all of them to understand the tool limits and strengths. The best tool lies somewhere between the designer's ears. Don't rely on software based tools to make up for your lack of expertise or inability to develop models that are adequate for the job at hand. Use all of the tools, as is appropriate, to make the one you walk around with a better tool.