• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by zygot

  1. @richa Those RS-232 charge pump logic level converters can fail to start up. Component selection is important. I assume that you've carefully read the datasheet and application notes from Maxim IC. Hopefully, you wouldn't try and do circuit design without an oscilloscope so that you can verify TxIN, RxOUT, and charge pump pin levels. It shouldn't be too hard to deduce where the problem lies.
  2. For the most part I've avoided being naughty most of the year, despite what JCOLVIN might tell you. I realize the your elves have already committed the factory resources to this year's toys so I'm getting a head start on Christmas 2020. Lately I've been finding that my favorite FPGA platforms for doing useful things aren't from you, or even have Xilinx devices on them. This is horrible as I really don't prefer Intel tools anymore. Could you assign your design elves to projects that let you keep up with the other guy's? Specifically: The Terasic OpenVino Cyclone V GT Starter board. With 4-lanes of Gen2 PCIe, a useful PCIe driver SDK, and lot's of LVDS or single-ended IO, all for under $600, what more could one ask for? Well, how about one or two 1 GbE interfaces ( Did you know that there are 10 GbE PHYs these days, hint hint ) and a Series 7 FPGA ( I'm thinking of a Kintex 160T) The MAX10 Development Kit. For under $200 it has (2) 1 GbE PHYs, DDR3, a USB UART, and an HSMC connector. Wow! Put a USB 3.0 bridge on that HSMC connector and you have a great platform for capturing Ethernet traffic between two nodes. Actually, I've got a long list of projects for this board. Unfortunately, Vivado is pretty useless here. My last wish is for you to assign whoever has decided that all of your new FPGA boards will be ZYNQ based, to the other pole running a taco concession. Don't get me wrong ARM devices with a bit of FPGA logic are great; just not appropriate for most useful FPGA projects. PS. I'm glad that you started using the SYZYGY standard as an alternative to those tired old 12-pin PMODs. Of course we all don't need a plug and play interface for our add-on boards so isn't about time for PMODv2? Don't forget that some of us boys and girls like playing with toys that can do useful things other than sell PMOD merchandise. Yours, hoping that we can all have a great 2020.
  3. zygot

    CmodA7 and Adept2

  4. No. You'll have to read and understand source code material. But I can help with specific questions if you get stuck. https://forum.digilentinc.com/topic/2866-cmod-a7-35t-demo-project/
  5. I realize that we're on opposite sides of a philosophical divide trying to assist a third party whose skill and understanding neither of us comprehend. So the best we can do is provide our best effort advise and hope that the thread progresses to a satisfactory conclusion. Your view is certainly worth consideration. Here is a short explanation for my post. Clearly, the person asking the question is doing a Verilog design, not a soft-processor design. Yes, a point and click design might sometimes be a quicker way to obtain a bit-stream. You might be shocked to know that before an Altera field application engineer created the NIOS on his own time we all used either schematic entry or text entry languages like AHDL to create designs. We did just fine with that creating quite complex designs until VHDL and Verilog became readily available. I disagree that the soft-processor as a crutch is easier for beginners. Even stand-alone IP, when it's available, isn't always easier or quicker. What if your board design, with it's vendor IP and perhaps a soft-processor doesn't work (let's assume that the designer is a beginner but with 50 Micro-blaze designs under his/her belt)? Then what? So here's why I don't think that point and click FPGA development is a real thing. The designer still has to write HDL code to connect things. The designer still has to have the skills to debug designs. All if this is easier with a minimal number of source files written by the designer rather than a script file that often gets broken when the next version of the tools is released. I realize that this is not an adequate treatment of a complicated topic. Yes the path to getting to where you are fairly self-sufficient might take a bit longer but once you are there you are free to progress without be dependent on things that you can't control.
  6. zygot

    CmodA7 and Adept2

    Check out the busbridge3 project in the Project Vault; this is one very excellent way to do what you want to do.
  7. @weilai A UART in logic and Python using PYserial is a really useful way to exchange information between your FPGA and PC. Don't even think of wasting your resources with an embedded processor or your time with the block design flow. Just add Verilog source files. If you look around in the Project Vault I've posted several projects that show how to do this. The CMODA7-35TDEMO has a Python script. You have two things to verify here: one is if your UART is working, and the other is if your Python is working. For your Verilog code this is where simulation comes in. It wouldn't hurt to make a test build with two UART instantiations and make sure that they can talk with each other. This would be fairly easy to verify using an ILA to capture incoming data. Keep working on it... once you succeed you'll have useful code for many future projects.
  8. zygot


    @tomii, Welcome to the land of Digilent. I like Opal Kelly's software development support too. I like having lot's of IO available. You'll find Digilent's price point a lot friendlier to those of us with small budgets. You'll find that those pre-Series7 based boards are no good with Vivado. Hopefully, you still have a rig with ISE installed. As to where to start, I can offer an opinion. If you want to be more on the useful end than dangerous end with your Verilog skills the non-ARM equipped boards are where to start. You'll find that the Digilent boards are a bit short on user IO if you don't want to buy PMOD modules; but I've put many a Digilent board to use doing useful stuff. One reason to start with the ARTY is that it's easy to do all HDL designs that mostly survive VIvado versions releases ( Vivado 2019.1 seems to be the exception). Once you are comfortable with the design, development, and simulation tools for Verilog only projects moving to the ARM-based framework will be easier... though there are a lot more moving parts to juggle. All of Xilinx's software development tools have been rolled up into Vitas starting with Vivado 2019.2 so that would be the version to start with. Hope you have a broadband internet connection. I don't so I'm waiting for a good 3-4 days to try and download it to see what's changed. But seriously, a very low percentage of projects that I do have any kind of programmable processor in it which makes them easy to maintain. Digilent has announced an ARM-based SYZYGY compatible board. This will be a major improvement for IO connectivity. I just wish that they started with a non ARM-based device. SYZYGY is Opal Kelly's concept and brings a level of plug and Play to the FPGA development board space. But this is for advanced projects. I would have like to see a new PMOD standard that was as well thought out ( without the P&P feature ) but that doesn't seem to be likely in the near future (Sigh!) One great thing about Digilent is their user community support efforts.
  9. I'm not sure that I understand this statement. You can't implement a UART in the PL and connect it's RxD and TxD signals to the PS MIO pins that are connected to a USB UART device on your board. I will caution you to consider how you are going to configure your FPGA device. Development boards made by Digilent or Terasic include the hardware for configuring the device as well as using debugging IP from the tools. Before making a selection understand how the configuration works and if it works with the FPGA vendor's tools. Ideally, an FPGA development board will have a standard JTAG header as an alternative means for these functions. I would suggest that beginners avoid boards that restrict configuration to a custom and or closed format. Some of the low end so called FPGA development boards are too cheap and or too difficult to use. As a beginner you want all the help and options for development that you can get so choose wisely. Some choices require more effort in figuring out what you are going to get.
  10. It is possible to mux PL pins to ZYNQ PS peripherals. You can, for instance use one PS UART connected to the MIO pins as normal and connect a second PS UART to PL IO pins. For a two pin UART interface this pretty easy to do. For an Ethernet interface not so easy. It sounds to me as if what you want to do is leverage your ZYNQ platform into something that let's you experiment with Verilog designs. You can certainly start with the board design flow to experiment with exchanging data between the PS and PL Verilog code. Simply adding GPIO ports that connect to PMODs would be a place to start. Later you can experiment with using BRAM or you own IP. Personally, I find that having Vivado create a toplevel HDL source that I control works best; but I'm pretty comfortable with HDL design. In my case I create my own HDL toplevel design source and instantiate the board design HDL code. This make connecting HDL code to open ports and pins straight-forward. If you can afford it I strongly urge you to consider buying a cheap non-ARM based FPGA development board to learn Verilog development. It's just a lot less complicated. There are a number of options for nice <$100 FPGA boards, though the best one's for the money might not be Xilinx based. Once you figure out how to implement something in HDL that you can interact with using , say a UART, then try an integrate your HDL into the ZYNQ platform. There is HDL code projects on other areas of the Digilent forums to play with to help get started. A UART is the easiest interface for debugging or connecting an HDL design to PC applications. For <$10 a good 3.3V TTL USB UART breakout module or cable is indespensibe. It is also possible to tie off the PS and just use your board as an FPGA platform; this is not something that I'd recommend. In the end you should choose the best strategy for you. Just don't be afraid to ditch a processor based design because it seems daunting. Before you are ready to implement a 6502 soft processor with peripherals in logic you should be comfortable implementing, simulating, and debugging "peripherals" in the HDL of your choice. At least that's the view from where I sit.
  11. The SDK has always been free. As of Vivado 2019.2 the SDK, SDSoC, and SDAccel tools have been replaced with Vitas. Digilent needs to remove the SDSoC voucher from its product list. It's not clear from what I've read where all of this is heading in the future and Xilinx isn't making a very good effort at making this clear.
  12. Try browsing the Project Vault area. You can find numerous VHDL or Verilog code samples among the projects submitted. I generally provide simulation testbench code as well. I believe that you'll find the authors will be helpful if you have questions.
  13. zygot

    Advanced topics

    I certainly won't argue against reading the available literature form Xilinx or Intel; tutorials, reference manuals, etc. A problem with diving into "advanced topics" is that it's hard to wrap your mind around everything by trying to absorb complicated information in a vacuum. It certainly doesn't hurt to be familiar with material on timing closure and constraints. Don't just stick with one vendor. I highly advise that you understand how Intel's or maybe even Actel's timing analysis tools work. Getting into trouble, as it were, is pretty easy. Dealing with it is probably easier with a structured approach. So, one idea for a structured approach is to browse the many Application Notes that are available from the vendors. Often they come with design files demonstrating concepts. This might be an easier way to dip your toes into deeper waters without your eyes glazing over. The reality is that simple designs often don't require much attention to timing and placement constraints but complex high clock rate designs often do. Quite a few application demo delve into advanced concepts. The nice things with this path is that you usually get some sort of analysis and explanation of the theory behind ways of dealing with complexity. One easy path to complication is, as has been pointed out above, understanding pipelining to achieve substantially higher data rates for a given design. This will introduce you to timing closure concepts, latency, valid data scope, and other issues quickly, but with specific issues to resolve. First you need to understand the AC switching specifications for your particular device so as to make the project feasible. For real FPGA design situations what takes place beyond the IO pins is critical; but this is no longer FPGA development but digital design. Ideally, one would start with understanding digital design before trying to do FPGA development; but the is no right or wrong path to enlightenment. If you aren't competent at doing high level simulation and writing useful behavioral and RTL testbenches the you aren't ready for the other advanced topics. Well, for now that's my 2 cent contribution. Bon Voyage!
  14. The only two FPGA development boards that I am aware of with two HDMI outputs are Digilent's ATLYS and Numato Labs's Opsis. One of the ATLYS HDMI outputs is unbuffered and shares pins with a PMOD so probably doesn't have the quality of the other buffered one. I don't know if the Opsis is available anymore. Both are Spartan 6 boards. If your project can have a DP output and an HDMI output The Genesys2 and Nexys Video might be good choices. The Opsis is the only FPGA board that I am aware of designed for video distribution.
  15. I'd say that the problem is that any version of Vivado 18.x doesn't work on the first try. This shouldn't and doesn't have to be so hard.
  16. @sapperlott It's too bad that your board has been sitting around gathering dust for so long; I have one that is rarely not in use. I assume that you are running the demo_BIST project? I abandoned all of those Digilent Microblaze demos long ago; too complicated and too much of a hassle. I wouldn't read too much into what "Test Short" means unless you are willing to slog though all of the source code to find out what ia being tested. [edit] Obviously, I'm not prepared to do that. It sounds as if the board is working just fine. Create you own HDL project to do something useful, involving the UART, a couple of PMOD signals, the LED and switches, and test that. If there's a spare LED available almost all of my code includes a 'heartbeat' counter to indicate that the design is being clocked. Just create a free-running counter and select the appropriate bit to toggle the LED. I'm almost positive that you are ready to get that board being useful. [edit] Those SMT USB micro connectors will not be able to withstand years of use and will shear off unless you take measures to secure them to the board. Fortunately, the Atlas has a standard JTAG header as a alternative.
  17. zygot

    ZYNQ based board

    I assume that you mean at least (???) two Superspeed USB ports. If you want two downstream endpoints on a ZYNQ FPGA board connected to the PL then the only options that I know of would be a board with two FMC connectors. Cypress and FTDI make USB 3.0 FMC mezzanine development boards capable of Superspeed data rates. Be careful of maximum Vadj voltages. The newer devices might only support 1.8V maximum. Perhaps the best option would be to consider replacing all of your criteria with a different approach. Have you proven that your host application can support two 300+ MB/s USB streams simultaneously and timing requirements?
  18. zygot

    SdSOC tools

    @asmi Again, thanks for the help. It seems that Xilinx has an issue with Firefox, even with no add-ons enabled. Even trying to get the unified installer for the 2019.2 tools I never got connected to the login page using Firefox... just lost in space somswhere. I had to use Edge to even download the installer. Horrors! I'm just curious. Are you on Linux or Windows. It's not clear if the new Vitas software development tools can do everything on Win10 and if it does how complicated that is. I'm assuming that for the SDK side there will be no significant change. This seems less likely for the other tools.
  19. zygot

    SdSOC tools

    Perhaps, but I was unable to get the 2019.1 version of the SdSOC tool; just dumped into an empty non-functional page from any link on the main website. But it's time to update anyway to the most recent tools. For those of use without broadband this is becoming almost impossible. It took me a week to get the 2019.1 Vivado+SDK tools...
  20. zygot

    SdSOC tools

    @asmi Thanks. Looks like I have a license for something that doesn't exist for my current installations. According to the release notes there is a limited number of platforms supported by Vitas so it's unclear what the future holds for most hardware platforms currently requiring the SDK. Xilinx certainly isn't making it easy to figure out.
  21. zygot

    SdSOC tools

    It's embarrassing that I have to ask this here but I have a license for the SdSOC development environment but am unable to download it. I wasted 20 minutes going round and round on the Xilinx website without making any progress. Does anyone know where the download page for this tool has gone? Xilinx has a new Veritas tool but I don't have a license for that..
  22. Programmable logic devices are absolutely terrific for some things. For your project I wouldn't have a processor, soft or hard in the design. Of course I'm a bit more confident in my HDL skills. Still, if you have experience with an HDL you should consider an all HDL design. There are fewer to things to worry about. SPI is a nice interface to design for; just don't tell Vivado that the SCLK is a clock. With even low end Series 7 devices you should be able to implement a simple 40 MHz SPI master interface without timing issues. I'd start with the SPI master and verity timing using simulation. You can feed it with data from a BRAM to send out data formatted to support whatever it is that you want to connect to and capture it with an ILA. No software to worry about. Very little resource usage. Generally, devices with an SPI interface are pretty tolerant of less than great SCLK inputs. My personal opinion is that implementing a soft-core processor in an FPGA is for an advanced developer. Yeah, I know that this goes against what most beginners hope is the case and what most FPGA vendors think will make using their devices easier and suitable for a broader audience. Really, a low percentage of FPGA designs need or should have s programmable core. If you don't have the HDL chops there are controllers that do 40 Mbps SPI like the Delfino and development kits are cheap. A TMS320F28379D launchpad would do everything you need. The only problem with that is the hardware is crazy complex to program with tons of unexpected limitations and modes to worry about. But Ti does offer pretty good tools for free. In fact that platform would be a good test platform for verifying an HDL Artix design implemented on hardware.... [edit] So after writing this I just noticed the report that you show above. I wouldn't worry too much about the TNS number as the WNS is positive. You have generate a detailed timing report to see how it came up with those numbers. Look for nets that are unconstrained. Your design might work fine as long as the IO pin locations and IOSTANDARD constraints are correct. So don't give up on what you've done too soon.
  23. When doing a new design it's always a good idea to check the pin report to at least make sure that the toplevel signal assignments are correct. If the locations don't match the schematic or constraints file then something is wrong. Always run through the synthesis and implementation messages to look for any warnings about constraints being ignored. Often location constraint issues will result in BITGEN DRC errors that prevent bitstream generation; but not always. Be aware that the tools will assign default IOSTANDARD and other IO constraints unless you provide your own. When you use vendor IP wizards in your design Vivado creates timing and sometimes location constraints that are not obvious in the heirarchal view so you have to go find them. Use problems like this to get familiar with Vivado. Open the implemented design and view all of the reports and informational views. From what you've said timing seems to be what concerns you. After generating a bitstream the main summary report shows the maximum negative slack numbers. I guess that this is what you are looking at. Usually, if a simple design doesn't meet timing it's because the tools were never given basic external clock rates to work with. Understand that if your design has a wizard generated MMCM or PLL in it the constraints file for that IP will be in your design though it will be buried within the heirarchy. If you provde your own clock constraints that relate to the same inputs as the IP constraint you will get a warning in the synthesis and implementation reports. Open the implementation and looks around. Vivado reports all signals not constrained by a known clock rates. If also reports all known clocks. Often this information will point to a silly error. Vivado is complicated and finding the right view to get pertinent information is often contextual. I still sometimes fumble around trying to get to where I want to be every once in a while.. I'm not a fan of GUIs that limit access to a particular screen contextually. You just have to spend some time getting to know the tools' quirks and behavior. FPGA development tools generate a lot of warnings. Even the IP wizard generated code generates warnings. For new projects it's worth the time to rund though these looking for obvious errors in your own code or just plain syntax mistakes or omissions that have confused the tools.
  24. Sometimes people mistakenly try to create a derived baud rate clock that closely matches the baud rate. UARTs should be able to accommodate a significant variation of baud rate error, perhaps 15% or so. So a better way to think of it, particularly on the receive side is creating lots of samples and keeping data transitions near the middle of a baud's worth of sample units. This means that clocking the UART entity at a high clock rate, providing a lot of samples per baud period, will be optimal. A 50 MHz clock for 115200 baud is fine but I've been using a 100 MHz clock for 921600 baud that's reliable. Don't think or hope... simulate, simulate.. and simulate some more. The first thing that I'd do if made custodian for someone else's code would be to simulate everything until I understood it. Reading source text often not sufficient and commentary is rarely accurate. There are a number of UART based projects in the Digilent Project Vault, some with testbench HDL tha might be helpful.
  25. No, no no... nothing about this thread is upsetting or irritating. Clearly, you are in deeper water than you should be. I do find that to be a bit frustrating, though not as much as you are likely feeling. Unfortunately, FPGA vendors, understanding how complicated their tools and the basic development flow is, see packaging everything into a GUI point and click user experience as a solution. If you are trying to create a limited design using nothing but their IP you can (sometimes) get quick results; but then if something goes wrong or you try and do something outside the coloring book you can get overwhelmed very quickly without an idea of how to proceed. That's not your fault. Unfortunately, the ARM based FPGA device are seen by those with very limited experience as a safe and easy way to do FPGA development. Actually, it's more complicated. Your project would probably be a lot simpler using a straight HDL design on a regular FPGA target. Probably, an FPGA isn't the best choice for this project. But here we are. One option is to re-evaluate your choice in platforms and start over. The other is to plug ahead and develop the skills required to achieve success. Assuming that you will choose the latter, where do you go from here? I'm sure that this will get push-back but my view is that understanding an HDL, the development tools, and basic FPGA concepts isn't what's going to get anyone to where they are competent as FPGA developers. What people need is to be self-sufficient. What makes people self-sufficient is the ability to figure out how to debug designs that don't work as intended. Yes you need to other stuff to be able to trouble shoot problems but those things aren't sufficient. You've already reached the conclusion that your Verilog skills are not sufficient to work out a plan for instrumenting and debugging your design. That will have to be addressed. It's likely that your understanding of the tools could be better as well. Do let's put aside the question of endianess, or even what might be the problem with what you have so far. You probably won't like this advice but I think that it's the best that I can think of. Get a cheap FPGA board like the ARTY A7 or similar board having an FPGA without an ARM processor. Forget about even using a processor in your implementation. With an all Verilog design the development flow is a lot easier and you have more options for debugging ( well at least they are less complicated ). Learn how to write a testbench so that you can simulate your HDL. If you don't have experience simulating HDL you aren't ready to do conventional FPGA development much less ARM PS-PL development. Learn how to instantiate ILA and VIO IP into your simulated code to verify that what you are writing to internal registers is what you think is being written. These are basic vendor debug tools and sometimes are the best option for even experiences developers with a lot of home-brewed debug tools of their own. Use a UART for user input. Learn how to add a second UART for debugging purposes. Even if you don't want to use VHDL the project that I've posted for this has a testbench so you can at least use it to explore what's happening using the Vivado simulation tool. You can instantiate VHDL into your Verilog code and visa versa. I realize that what I'm suggesting looks like going backward. It only looks that way because you have an unrealistic view of where you are based on all of the work you've done so far. If you take this advice you will have a series of manageable, incremental, and smaller goals to achieve; and over time develop the skills allowing you to do what you set out to do originally.