• Content Count

  • Joined

  • Last visited

  • Days Won


zygot last won the day on May 14

zygot had the most liked content!


About zygot

Recent Profile Visitors

8231 profile views
  1. zygot

    PMOD I2S2 IP

    You are probably correct about that. But if you walk over to the desk of one of your compatriots who's been around for a while ( not raising the subject of age ) they will remember the old days when FPGA boards, even those from Digilent, came with one or more RS-232 ports. This was way before ARM was born but Digilent did provide code for a UART that worked well enough to include in its support. You may have to sit through a few boring discourses but the code is there, somewhere.
  2. zygot

    PMOD I2S2 IP

    I mentioned ZYNQ because it's not clear what FPGA board the person asking for support is using. You don't need to touch AXI for your ZYNQ designs. I've posted a few alternatives. The Fun with Phasors demo is but one approach. I use a UART in my designs a lot and have found that I do need a wide range of serial settings. While I don't do much in the way of RS-232 is is still a viable alternative to RS-422 for some applications and it's nice to have a UART that can function in such an environment.
  3. zygot

    PMOD I2S2 IP

    @[email protected] I looked at your IP core link. I looks pretty nifty but I have a question. Why in the world would anyone want to put an AXI bus between their logic and an HDL UART? In particular, why would they do that for a soft processor? It seems like hitching a trailer with a couple of mules to the back of your ATV in case you get stuck crossing a creek. Just excess baggage. Anyway, I'm not sure that an AXI-UART is going to simplify life for anyone needing an HDL UART core. For ZYNQ designs the PS has 2 UARTs. Almost all ZYNQ FPGA platforms connect one of them and the other can be connected to PL pins without an HDL UART instantiation. It is a nice demo of your AXI work however. I do think that the link might steer people to a useful discussion on the subject of the AXI bus. I'm a bit less sure of posts to this forum that could be viewed as trolling. Perhaps Digilent needs a special AD warning symbol. RS-232 needs to be designed to work with equipment that might have a significant baud rate error. What's the baud error that your UART tolerates? +/- 15%?
  4. Xilinx script generated code and resources provide a lot of interesting solutions to problems. Some of what Vivado deposits into your project directory is encrypted sources, but most are not particularly easy to read text, and often well worth the gander. One problem with script generated code are irritating things like std_logic_vector(0 downto 0). Still, I say you're on the right track. Just make sure that you understand what your found solutions are doing and what they are intended for. But that's just SOP.
  5. It's been a few month ago, so I can't point to sources, but there were security issues found in the popular ZIP utilities that most of us use. The .rar format didn't suffer from that particular issue. I'm just pointing out that: Choices of selecting a particular utility or format may have a reason that isn't obvious Everyone should stay up to date with security related news. It'll take you mind off of the constant SARS-COV2 news, though you should stay informed about that as well for you own personal safety, but not necessarily help in the search for a good night's sleep. Glenn's post is a very good one. Do ask why. Being curious is not just for toddlers.
  6. zygot

    Eclypse-Z7 FPGA Fan

    I can confirm that the example can indeed change the Eclypse-Z7 fan settings. Just curious, is there a way to turn control aspects of the SYZYGY and support hardware that doesn't get stored, that is that doesn't survive a power off/on cycle?
  7. The Eclypse-Z7 isn't the only FPGA platform for using those nice Digilent ZMOD pods. It isn't the easiest for sure. Check out an alternative way to do SYZYGY phasors. NOTE: The ZmodDAC1411 goes on SYZYGY Port B for this demo. XEM7320_phasorToy_R04.zip README.txt
  8. I just posted an update to fix an assortment of typos.
  9. I woke up in the middle of the night realizing that I never mentioned which port on the Eclypse-Z7 the demo supported the ZmodDAC1411; it's the ZMODB port. The A port is reserved for a later version using the ZmodADC1410. I choose to take this as a positive sign that at least a few neurons deep within my brain are busy doing some useful work. Once I get that fan spinning I'll post an update fixing a number of typos and omissions. Currently I'm finishing a XEM7320 version of the demo.
  10. @[email protected], All good. Perhaps my first post turned a non-issue into a paper dragon. I really just wanted to mention that vendor IP, especially for basic structures, doesn't need to be ignored. I'm all for designing my own IP as long as it ends up doing what I think that it should. It's a balancing act. A lot of my paid projects wouldn't fit if I only used vendor IP. On the other hand doing you own requires extensive verification, and more importantly lots of use running on hardware. I didn't look through the code so I'm guessing that he used a single clock FIFO without considering clock domain crossing analysis. Perhaps if I'd read his code I wouldn't have adding my 2 cents in the first place. I have no doubt that there are a lot of people finding your blog interesting an informative as not everyone has someone knowledgeable to offer mentoring.
  11. By my definition a Dual Clock FIFO is one that allows for moving data from one clock domain to another. A Single Clock FIFO can't do that. Asynchronous to me implies combinatorial logic that isn't clocked. But perhaps we've just been reading different material. I've got no problem with your home grown FIFO. But I would point out that all IP, vendor supplied or home grown, has limitations which have to be documented, In all of my years of VHDL development I've never felt the need to write my own basic IP like FIFOs, RAM, etc. If you need to minimize resource usage, then it might be worth the effort. For FIFOs I often have asymmetric widths on the write and read sides. Yes you could design your own but at some point you realize that trying to make one grand Ip that does everything for all purposes for all applications suffers the the law of diminishing returns. As long as I can use vendor IP for FIFOs I've found it to be quicker than the alternative. I'm betting that I've completed more designs instantiating clock domain data fifos than you have so I'm not ignorant on the subject. Of course, as a learning exercise, which is what your asynchronous fifo link points to, writing your own can be a worthy use of time.
  12. zygot

    Eclypse-Z7 FPGA Fan

    @malexander, I don't know when these issues were fixed but I'm working with repository source that I got 2 days ago. I think that the bigger issue is that whoever is writing the code isn't testing it on actual hardware. So, is it your belief that the dpmutil code example and dpmutil code have successfully changed the FPGA fan on real hardware? Creating lots of branches on git is a bad idea since it's hard to tell what state the underlying dependencies are. That and the utter lack of commentary for both code changes, git submissions, and the Digilent git website. It can;t be easy for your developers and it sure as heck is a pain in (**a lot of places**) for customers to deal with. Digilent needs an adult to supervise its software development, especially if you want to keep working engineers, who have their own problems to solve, interested.
  13. I regularly use the dual clock FIFO IP from vendors for moving data between clock domains. I'm not sure that @[email protected] and I have the same definition for asynchronous fifo but if you read the vendors IP documentation it does mention issues with flag timing. When necessary I just find alternate methods of keeping track of data counts. If you instantiate the Series7 hardware IO_FIFO then what you get is a dual clock FIFO, though it isn't BRAM or LUT based. Really, I believe that the point to make is that you need to understand what it is that you instantiate and how it behaves.
  14. @amb5l, You might want to consider posting this to the Digilent Project Vault, where it belongs. By posting it to where lots of FPGA related questions are posted every day your visibility will disappear making it invisible to most visitors. Just a thought.
  15. Well, until someone from Digilent has a better explanation, I'll just point out that this wouldn't be the first time I've seen their constraints files niss pin assignments. I've never known their schematics to be wrong yet. I make a habit of checking the schematics anyway before using pins and interfaces that I've not previously used. Just check the configuration user's manual to confirm my recollection about CCLK post configuration; but I'm betting that you are good to go.