Jump to content

zygot

Members
  • Posts

    2,859
  • Joined

  • Last visited

Everything posted by zygot

  1. You're in Luck! Here at Quick-draw Bill's University of Cosmetology, Neuro-Surgical, and Electrical Engineering Arts we equip people for the multi-dimensional skills required by tomorrow's workplace. Sorry... just kidding... haven't finished my morning cup of coffee. So while I can wrap my head around what most of the things you mention might entail I'm still having difficulty figuring out how all them are connected. Fortunately, I'm awake enough to figure out where to start the interrogation. You didn't think that you could come here and get help without an interrogation did you? To me the obvious place to start is by side-stepping the complicated questions and getting straight to business. Why did you decide that a Nexys Video is the ideal board for completing your project portfolio? Is there a lot of video involved? If so I'd recommend spending the extra money on a Genesis2 as the FPGA is much more capable. But really that question is intended only to get you focused on a basic issue. Let's put aside what the FPGA device requirements might be since there's no detail on which to make such an assessment. You obviously want the most performance that you can afford in terms of selecting an FPGA device and will have to settle for designing an application that fits its capabilities. Evidently, you've already determined that and Artix 200T is sufficient for your needs. Perhaps telling us how you made that determination might help you get a helpful answer. As for selecting an FPGA board platform for learning FPGA development or some generic Verilog or VHDL experimentation this is a bit more solvable. First, you need to decide what features your platform requires. Does it need external memory? Does it need Ethernet connectivity? Does it need to be extensible (work with specific add-on boards)? Clearly, you want Ethernet connectivity. I know a little about what's involved in high-speed, low latency trading applications and I can tell you that they don't involve a MicroBlaze and proprietary MAC IP. There are no FPGA boards available for you to buy that are suitable for this actual application. That doesn't mean that you can't do 'deep packet inspection' and try and emulate 'low latency' whatever that means for your demonstration project. It does mean that you should be doing everything in an HDL, that you code by yourself. This implies that you have a very good understanding about all of the layers that make up Ethernet. You should know that what you can do in a particular FPGA device using only logic narrowly crafted for a particular purpose in VHDL or Verilog is very different than what you can do using vendor provided IP with a MicroBlaze. This design flow will use up significant resources of your FPGA device that you might need for actual working logic. In fact, MicroBlaze and low latency are headed in opposite directions. You ask: "what would be the best data/peripheral connection options to achieve high throughput and low latency on this board? Is it possible to extend the board with PCIe?". This implies that moving data between your FPGA platform and a PC is a critical specification. Notice that I left of the part about 'for this board' because I don't think that you're ready to make that call yet. A board with a 1Ge port, DDR memory, PCIe and HSMC connectors for extensibility could be the Cyclone V GT Devlopment board. There is even a possibility for developing applications using that PCIe and I'm betting that you are fairly clueless as to what that entails. That wasn't an insult. That means that there are a lot of things that you need to understand before you decide that an interface is what you want to use. Of course nobody doing high-speed trading is thinking about 1Ge Ethernet except possibly as a debug port, so perhaps 10/100 is adequate for your project demonstration. You'll need to explain yourself a bit clearer here because your choice of words is telling me that you aren't quite grasping what it is that an FPGA does. This is a big problem. You don;t want to start designing your projects to work on a platform that doesn't support its requirements. Rule 1 of selecting an FPGA development platform: Don't choose a board that you hope will meet your needs. Figure out what your project requires and choose a board that supports it. This implies that the first step is defining a project. Specifying the project requirements in terms of hardware. Lastly, looking around for the best fit within your budget.
  2. zygot

    Eclypse-Z7 FPGA Fan

    Thanks, the information is appreciated.
  3. zygot

    Eclypse-Z7 FPGA Fan

    @malexanderIs anyone closer to making the Eclypse-Z7 fan control available to non-Linux application code? Is there any plan to provide a Standalone source for accessing the PMCU registers from the ZYNQ? The protocol isn't supported by Xilinx PS example code as far as I can tell. It would be nice if developers would update the Digilent GIT repository with status commentary so that users would be able to know when changes worthy of going to the trouble of updating the source is appropriate.
  4. zygot

    Eclypse-Z7 FPGA Fan

    Thanks, The FAN isn't a fire yet ( as far as I know ) so I don't need a solution today, but I'll certainly need to turn it on and off at some point. The people who argued that an Eclypse-Z7 Linux OS is a normal use case didn't seem to get the hardware people on board and have a lot of work to do to make that a reality. As of now its only purpose seems to be to connect the Ethernet port to the SDK for running Linux applications from the SDK. For what it's worth, I'd argue for not having a live FS, so that no one can destroy the FS accidently. There should be space available in the FLASH to store inter-session configurations, setting and what have you.
  5. zygot

    Eclypse-Z7 FPGA Fan

    @malexander, Ok, that's something. Currently, I'm doing development for bare-metal applications so I'm not booting into the FS, just booting into JTAG mode. So, how do I control the FPGA fan when there's no OS to run decutil or any other application/utility? On the subject of permissions; it a real hassle having to do 'sudo systemctl poweroff' and then have to type in a password just to shut down the OS before hitting the power off switch. I can only imagine the debates that went on while developing this product; and am happy not to have been involved. Still, the result is an OS that doesn't seem to know what it exists for, at least on running development code, and a board that can, in theory, support bare-metal, Xilinx RTOS, or other configurations. As of today, I find the Eclypse OS as more of a distraction than a platform for developing applications. Lot's of disconnected appendages in the Eclypse-Z7 ecosystem. You don't have to work to hard to confuse me but I have a distinct feeling that I'm not alone here. Regardless, of application I need to be able to run the FAN. P.S. Juggling various Linux, Xilinx and other platforms while working on multiple projects might be fun for software guys but it really is a headache for poor old me. Debian might be mother, but her offspring certainly don;t play well together. Let's see, is it ifconfig, no wait what am I running at the moment? ARRRRG!!!
  6. zygot

    Eclypse-Z7 FPGA Fan

    I have yet to hear the FPGA fan run on this board. The documentation and even schematics are confusing as to just how this is supposed to work. Can anyone shed some light on this and indicate if the FPGA fan is currently supported? Clearly control is tied to another header and involves a controller external to the FPGA.
  7. It took me less than 10 minutes to download the archive from this thread to my Win10 box and create a bitstream. At least try it out and let me know what you think. After 2019 all of my Python 2.x code will become depreciated so it may be awhile before I do a rewrite.
  8. I knew that there was some confusion when I saw OOB... just didn't get the specifics correct. This project is referenced as a Community Project with link in the CMOD A7 Resource Center. The OOBs from Digilent typically use the MicroBlaze board design flow. I don't unless the target is a ZYNQ based board. My project isn't in the Digilent GIT. Download CmodA735tDemoR1.zip from the top of this thread and try it out. I have a nice Python script to interact with it and reasonable documentation. Read the README.txt in my project to see what it does. Compare the flow for both projects and compare the resource usage for both projects. My project wasn't Vivado version dependent until Vivado 2019.2 came along but as mentioned on the first page of this thread still works albeit with a little extra effort. I'm not sure how you conflated Digilent's project with mine; but that doesn't really matter... I still think that mine's more useful. You can use the dcp as a source in your own project using this one as a guide. If I'm a bit shocked by anything, it's that the latest verison of Vivado still works with a dcp created in Vivado 2015.
  9. require Well, I'm happy for you but what you built wasn't this project. I don't use Microblaze. You might want to go to the top of this thread and download the zip file and try out my project as an alternative. I just downloaded the archive file from the Digilent Project Vault to my WIN10 box and built it using Vivado 2019.2. I just had to create the MMCM component in Vivado 2019.2.
  10. I appreciate that argument. I try and avoid providing executable programs, text source using embedded scripts, and anything depending on tools having the letters JAVA in it for the same reasons. From my perspective, providing a constraints file that can be read and checked plus source HDL is the safest thing for everyone. You should be in the practice of checking the post place and route pin assignments for all new project bitstreams regardless. Even if you think that you are using a constraints file with valid location and IOSTANDARD assignments things happen....
  11. There are other posts dealing with using the NMV. Be careful as once you have something in your FLASH device that starts the configuration process you can find your module appearing as a bricked board.
  12. You are correct that Vivado 19.2 has broken IP from previous versions. I'll try and create a release for Vivado's latest. Meanwhile, though I haven't tried it yet , I expect that if you create your own MMCM using the Vivado 2019.2 IP Wizard you should be able to build the project using the other sources.. I prefer that users create their own bitstream. NMV ???
  13. Everything needed to create a bitstream is provided. A couple of the HDL source is provided in the form of a dcp file. Are you having trouble creating a bitstream? ISE doesn't support the Artix 35T device.
  14. I suppose that the first part of this sentence is a pass for the second part but I still had to wince at reading it. You can have storage using combinational (un-clocked) logic. If a synthesis tool decides that your code requires storage it will infer a latch; and provide a warning that it did so. The warning indicates that inferred latches are generally bad. One problem with learning your first HDL on your own from a book is that you might be tempted to use keywords without understanding the ramifications of your choices. There is a place for variables and := in VHDL, but not for assigning values to logic elements like std_logic or std_logic_vector. A problem with offering a critique of code in a venue like the forum is that it's easy to provide advice that, while addressing an aspect of poor coding might cause more confusion than solution. There's only so much space and time for posting coding critiques and too often an attempt at making it concise and easy it ends up being misleading. My point isn't to criticize hamster or anyone posting code; it's to suggest that there are better ways to learn how to use and HDL effectively than this format provides.
  15. Well you get points for doing some research. I suggest that you start with reading the Xilinx literature for the ZYNQ device on your board to see how the PS and PL connect. Then look at the schematic for your board to see what the various interfaces connect to. If you look on page 8 of the Arty 7 schematic you'll see that the DDR and UART signals are connected to PSxx pins or PS_MIOxx pins; that is to the PS. A few ZYNQ boards have DDR and or Ethernet connected to PL pins but most like the Arty7 have all of the user interfaces connected to the PS. SO... tying off the PS and just using the PL, something that is possible by the way, is going to be difficult for what you want to do. Neither the UART or DDR for the Arty 7 are connected to the PL. It is possible to create a program running as a bare-metal application to service an AXI connection between some design in your PL and the PS to allow you to connect a TTL USB cable to PL pins to a UART in your design. There are a number of options for building proper AXI interfaces to your PL HDL code and I like to use BRAM. Since your interface is a UART a DMA interface seems a bit extreme to me on face value... but I haven't tried to do this. My personal preference for ZYNQ designs is to have the bare minimal board design functions needed to connect the PS to the PL. I then use the HDL entity or module created by Vivado representing the board design as a component in my toplevel HDL design file where all of my real design goes. I'm not quite understanding what exactly it is that you envision as the layers of hardware involved but you can't read/write directly to DDR from either the PS or the PL. Both have external memory controllers that are quite complicated, though on the PS side most of it might be something that you can ignore. Perhaps starting off with a simpler design concept; like creating a bare-metal PS application to read PL registers for address, write data etc and write other PL registers like read data. Given typical UART speeds a polled service should be usable. That project will be more than enough to keep you busy for a while. I'm curious as to why you would want to do a ZYNQ project without the ZYNQ.
  16. 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...
  17. @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.
  18. @Notarobot Hi backatcha!, I do appreciate the testimonial about your success with the Red Pitaya. Such comment help me assess my judgement about the suitability of unknown products. I've had enough unhappy experiences with investing time and effort into tools that restrict vital information that all I see are red flags when considering new ones. So now I'll have to revisit the product pages again in the future.
  19. Oh that! I had such high hopes. This board started out as an open source hardware/software platform and now is something else. The hardware design is not available and calling the software open-source is probably a stretch. But the board is so close to being useful that I still check it out every few years as a possibility.... perhaps one day the company that controls this will go back to the project roots.
  20. @herve As far as a board with ADC and DAC devices meeting your sampling and bandwidth requirements look at Terasic ( they are Intel FPGA based ). As to actual ADC and DAC devices meeting your delay requirements this is tricky ( you'll have to run through the data sheets for the devices on the Terasic boards if they look promising ). I don't know of any converter boards that I feel comfortable recommending that you can easily ( or with some difficulty ) connect to your FPGA platform. The ADC spec. game is challenging even for seasoned engineers. You probably want to look at flash or pipeline architecture ADCs. The current output DACs tend to have the least delay. Once you've figured out what components you want to use there's the analog end to consider. Usually ADCs need a good driver amplifier to get performance and if you use a current output DAC you will probably have to use an OP AMP to get a voltage of the desired span. These all will have a deleterious effect on delay on both ends. There is no easy answer for your question. [edit] If you need to do any processing such as frequency filtering on the ADC or DAC sides this will also of course affect both data and group delay but you will have some control over this.
  21. After mulling over my previous post here I thought that it might be good to post a few remarks about the IP in this project. There's nothing specific to the CMOD-A735T in the code that makes up the IP, just that the dcp file was synthesized, placed and routed for that part. As my first offering of a project using Vivado I wanted to experiment with creating Vivado IP for distribution of functionality as opposed to source. I've since submitted a number of other projects to the Vault using the same IP but "compiled" for a different part. The basic functionality is part of a lot of my projects for internal use. Having an HDL component ( really multiple components ) that converts std_logic_vectors to ascii hex and the other around is a very useful thing to have in your toolbox. Hopefully, you've looked though UART implementations in HDL ( even better taken the time to understand UART fundamentals and written your own UART ). If you have done that, you understand what a nifty thing it is to have is a UART based widget that allows for interacting with and debugging your FPGA design internals. Allowing a user to interact with this interface using a simple keyboard is, as I hope this demo shows, a very nice format for a number of reasons. There are a lot of ways to solve design problems. Usually the most obvious is also the most complicated and the least elegant. The most elegant solution usually requires some insight that often requires quite a bit of experience. That's my segue into commenting on the std_logic_vector <--> ascii problem. There's a number of ways to address this. A simple lookup table ROM is the most obvious; and happens to be the way the the IP in this demo does it. I also use a generate statement to create an array of processes to do this. I did it this way because I really had never tried using a generate process approach before, not because it was necessary or even efficient. ( For me being able to experiment with new approaches makes FPGA development interesting and fun ). Having said that, you should know that the user interface is totally customizable with respect to the size of the std_logic_vector and the approach that I took supported this easily. If I was going to rewrite this portion of the IP again I likely would have taken a different approach. I also would have taken a different approach than use lookup tables. Can you think of alternatives? The std_logic_vector <--> ascii portion of the IP is by no means the bulk of the design but perhaps the trickiest, especially for custom IP that uses generics to support any size std_logic_vector ( or, perhaps, unsigned ). There's nothing magical or innovative there. In fact, that's why I encourage whomever is reading this to work out their own solution. You don't need hardware... just ModelSim or Vivado simulator. That, to me, makes it an ideal problem for newbie HDL artists to solve. I do want to end by mentioning that your can use the same IP provided in this demo in your own Artix 35T designs by studying how I use it here.
  22. Hi @abd, Part of the CMODA35T demo was indeed integrated into an IP form. The source for that code is not currently in a release form. The objective of the demo is to provide an alternate, quick and painless way for individuals new to the Xilinx toolset to create a bitstream and see their new CMOD-A35T working. Please understand that there aren't many people getting paid to provide code or assistance around here; so there's that pesky trade-off of providing something for free and providing something intended to better the "community". The more important purpose of the demo is to encourage users to try developing their VHDL skills; so providing a bit of motivation to have them design their own functionality isn't a bad thing from my perspective. There is plenty of HDL source available in the Digilent Project Vault to assist in this process. Of course, there are also a number of people willing to help with specific questions on this forum as well. I realise that developing you own code base ( IP if you will ) is a daunting task for those getting started and using the development methods that Xilinx and Digilent prefer appear to be an easier short cut to working designs. I'm encouraging the longer, more difficult, path because I believe that the destination is a much better place to operate in. There are other forums within the Digilent ecosystem that offer a discussion of ideas and might be interesting or even perhaps useful. I do thank you for mentioning that you tried out the demo. I have been encouraged to submit new projects to the Vault and always try to allow users to expand on the project's limited objectives by re-using source.
  23. @stempelo, It took a while to find out if anyone has tried out any of my posted projects... but thanks for the feedback. The project is as unambitious as one can get but does demonstrate an alternate to the standard Digilent demo and a lot easier to modify... plus it's relatively immune to Vivado versions. This was one of the first projects that I did and it had specific goals. You might find the S3 Starter Board Programmer project interesting as well as it features the CMOD-A7-35T in a different role and has more HDL example code.
  24. JColvin, Sure, please do that. Tomorrow I'll be posting an esoteric but much more interesting project.
  25. CmodA735tDemo is a Vivado project that requires very little resources and is an easy way to try out the board's resources. Requires Vivado 2015.2 or later and a Cmod A7-35T board. There is a Python program to run the demo that also requires Python 2.7 and pyserial 2.7 but any terminal emulation program such as Putty will also work, though with a bit more effort. CmodA735tDemoR1.zip NOTE: Vivado 2019.2 and later breaks the Vivado IP created in earlier versions. To build this project in Vivado 2019.2 just follow the README file except instead of adding the clk_wiz_0.xci file as IP you need to create an MMCM using the Vivado 2019.2 clock Wizard (use the default name) . The only thing that needs to be changed from the default settings is the input clock rate which is 12 MHz. I use the archive above from here to build the project just today using Vivado 2019.2 on WIN10.
×
×
  • Create New...