zygot

Members
  • Content Count

    688
  • Joined

  • Last visited

  • Days Won

    30

zygot last won the day on February 20

zygot had the most liked content!

2 Followers

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

4356 profile views
  1. zygot

    Zybo Z7 Development Board ESD&Safety

    @Sduru All electronic equipment is susceptible to ESD damage. Especially, on a board like yours with components exposed. Especially, if you are not using it in an environment where humidity is controlled. If you were working in such a controlled environment at a company, using company equipment, they would ( should ) require you to work on an ESD pad with a wrist band that has a qualified ESD to ground path to leak off ESD currents. And that's in a lab environment where the possibility of static discharge is minimal. If you are working at home and on a desk with a carpeted floor in the winter when heating is likely to make static a relatively likely possibility then I would suggest that buying a small ESD mat and ground strap is a worthwhile investment. You can damage your equipment without causing it to fail catastrophically. Yes you can be lucky enough to ignore well established and proper electronic handling guidelines without having an issue ( or more likely not being aware that you've had an issue ) but ignoring well established and proper guidelines is just a bad idea. You can get away with a lot of risky behavior for a while but sooner or later the piper will send his bill and you will pay. As a general rule you should never touch components on a PCB; at least without proper grounding. But even if you are very careful to move a board by the edge or shielded connectors like Ethernet RJ45 jacks that are grounded you can still zap components if you've built up enough static charge. You've asked a very good question. I understand that there are people who will choose to ignore this advice but I've given you an answer that is consistent with professional practice. Expensive electronic development kits don't come in a anti-static bag with a seal that is supposed to break when you open it for no reason even though it cost more for the vendor to do this. BTW ESD mats are high resistance affairs that are design to leak off static charge to a good ground ( this might not be available where you are working at home ) without endangering you to high voltage low impedance sources. Thought I'd mention this for anyone thinking that they might make their own cheap workstation....
  2. zygot

    busbridge3: High-speed FTDI/FPGA interface

    What this project offers is about the best throughput for the FTDI USB 2 devices short of synchronous 245 mode. Digilent boards can't do this mode unless you modify the EEPROM settings and use the FTDI API; something that Digilent strongly discourages as you can brick your device, and hence your board if you make mistakes. I successfully did this for my Nexys Video but rarely take advantage of the effort that was involved; perhaps one or two projects. (I count learning experience as a positive project objective). Still were talking about 20-30 MB/s instead of 8 MB/s sustained average throughput which is rarely worth the effort. I still get a lot of mileage out of my ATLAS and Genesys Virtex V boards because they use the significantly more usable Cypress device and I can get 35+MB/s for large data transfers. More importantly, they have a number of modes that you can write HDL to support optimizing a particular requirement. For USB you should understand that throughput is not the only, or for some applications, the most important metric to creating a successful application involving an FPGA/PC application. Ahhh, sometimes change isn't all that wonderful....
  3. zygot

    ethernet communication with pc

    I forgot to mention that unlike some interfaces you can download copies of the Ethernet standards which provide (almost, they won't provide code to implement a robust PHY interface in HDL for you FPGA board for instance) all of the information that you need to implement a workable application. Well you can get the standards for others if you pay to become a member of the organization that maintains them. I have nothing against using wikipedia, I do so frequently, but it's not always the best, or most reliable, source for information. Really, parsing the packet structures for Ethernet is not a big deal or close to the being a significant part of the work involved in creating a usable application.
  4. zygot

    ethernet communication with pc

    @PhDev Perhaps you'd be willing to provide a simple application to the Project Vault demonstrating your positive experience with these cores that come in the form of pre-compiled netlists. It's been my experience that becoming invested in such IP with very limited documentation is, in the long run, not very productive. There are, obviously, quite a few people out there who just need a quick and dirty solution to solve a problem and don't have long term interest in developing standard Ethernet based projects.
  5. zygot

    ethernet communication with pc

    The following argument is just a philosophical perspective. I understand that there are people who want to do stuff but not necessarily spend the time to learn stuff. That's fine but I'd suggest to those people that they should find another platform to do their stuff. Raspberry Pi is a very useful platform. There are no doubt alternatives for it than a full blown OS to make projects easier. There are a lot of Rpi or simple micro-controller based alternatives out there. There are also people who need to do stuff and have a very fixed time frame to do it in that precludes the normal preparatory learning. That's also fine. But they also should find a less complex way to do their stuff to ensure making that deadline. I know that FPGA vendors would like to maintain the illusion that FPGA development is just like programming a computer, just more capable and flexible. It isn't. It won't be for a very long time. Yes you can replicate a particular demo easily ( sometimes if the project source isn't a tcl script ) but try and make it do new tricks and you will find youself stuck, or at least stuck having to go and learn everything that you didn't want to learn when you started. If you just have to use and FPGA and can't learn Ethernet basics then perhaps you can bootstrap someone else's project to fit your needs if you're lucky. If you only need to do 1 thing and then move one to other endeavors find the simplest way to do it and move on. There are products that almost trivialize the basic Ethernet communication. Making a workable application might not be so easy. If you choose to do your stuff using an FPGA then I suggest that you are choosing to learn all of the little details and minutiae that software libraries or full blown programs like MATLAB do for you in the background. Taking the time to learn about every subject that you're working with is a given with FPGAs. It's really not a good tool for the casual developer. FPGAs just aren't the best solution for every problem; even for people who are really proficient at using them. I've had involvement with companies who's products used Ethernet for control and data transfer and once timing, responsiveness or throughput requirements start driving the design it's not easy for them to meet customer needs even with an Ethernet expert in house.
  6. zygot

    Cmod S6 - Multilayer?

    It's easy, even for well trained people to develop mistaken ideas about PCB design. I've been involved with PCB design for digital and analog signals up to about 3 GHz. The analysis and rules for UHF or microwave is very different than that for 100 MHz. I'm very reluctant to make any broad generalizations that might be interpreted as guidance. I'm not countering the advice of @xc6lx45; just making a comment. Yes, I agree that you can find very good guidance from IC manufacturers who want their customers to be happy with the performance of their devices. Often very good general rules are available as application notes or EVM board design files. Some take great care in explaining why they chose to place parts, panes, traces, etc. the way they did. I never ignore such help. Designing a PCB to mitigate radiating energy in controlled spectrum is a bit different than thinking about designing a PCB to be less susceptible to external radiation. Often susceptible circuitry is shielded by a cage. You can find these on many a Xilinx development board. From the perspective of a PCB as a victim of electro-magnetic radiation I couldn't put a boundary on the frequency range of interest. Warning, long old man tale follows: I may have mentioned this in another post but many years ago I interviewed for a job with a high-end modem company. One of the engineers who took me for a tour explained how he had changed the whole philosophy of board layout by eliminating all planes and just having return traces to provide a path for return to ground currents from every component. After a long discourse he asked what I thought of his idea. I had to tell him that it really didn't make much sense or conform to what I had already learned. We had a brief discussion about this but who wants to get into a brawl with some nut interviewing you for a job? Later interviews with higher level managers confirmed that everyone in the company was grateful for the new direction for a number of reasons. Needless to say that, since I didn't choose to drink the cool aid , I wasn't considered a suitable candidate for a position with that company. Many years later I had an interview with another company and during a discussion with one of the engineers I found myself relating this prior experience. The guy interviewing got all red in the face and after a bit of silence told me that he was the engineer responsible for that change in design theory and that it ended up being a fiasco. He mentioned that he missed a few things in his analysis. I didn't make a suitable candidate for that company either.... If you are going to design a PCB or use a high performance component then you better avail yourself of all the reliable information you can find. Better yet work for a company that has years of success doing verifiable products that meet specifications under rigorous testing. For most of us general rules of thumb will do for the kinds of boards that we can afford to make. There are a few good texts but IC and microwave and RF component manufacturers still supply good advice if you can find it.
  7. zygot

    Cmod S6 - Multilayer?

    Uh Oh... you're prying open a can that a lot of people would rather not see opened. When I think of EMC I'm usually concerned with electromagnetic transmission by the product. If you buy just about any evaluation, demo or development board from major vendors, like Xilinx, you'll find some verbiage somewhere that the product in question does not conform to FCC rules and regulations and is only to be used in a lab setting ( let me say that this is a very poor paraphrase here ). You won't see that kind of verbiage anywhere in the packaging or user's manual of FPGA development boards like the ones discussed on this forum. My guess is that there's no such testing and it's gone unnoticed by the relevant organizations. Of course EMC has victims as well as aggressors ( forgive me if I get the lingo wrong.. it's been a while since I spent time in an EMC test chamber ). You are interested in what kind of effect an EMC aggressor might have on, say a CMOD6. I'd say you and a lot of other people; some with 'friendly' agendas and some not. Certainly if you wanted to send your CMOD6 on a mission to the moon you'd have to consider this. You'd also have to consider those very high energy Alpha particles flying about. For a while now IC vendors have been accommodating, to a limited extent, the Apha particle situation, mostly for high altitude aviation applications. FPGA devices and a lot of MCU devices have an SEU to detect such events. I'm quite sure that there are a lot of other radiation types an astronaut using your CMOD6 would need to be concerned about. Generally, for extreme environment applications these types of concerns are dealt with on a system as well as component level. If you scrounge around there are application notes on this topic. Start with Actel (Microsemi) as they are big in the 'non-terrestrial' market. Hmmm.. you're on to asking questions about a class of very interesting related topics for investigation.... [edit] One thought that just occurred to me... is that you might want to use an FPGA platform where the gerbers are available as this would provide a wealth of information.
  8. zygot

    ethernet communication with pc

    "Don't let Zygot discourage you". I certainly agree with that! I won't walkback on my advice though. You need to do some preparation and though the information you need is there to be found it's not going to be neatly packaged into a form that can be trivially added to your project and make it work. By the time that your application is useful you will have the basic understanding. Just writing a Windows or Linux application to talk to your FPGA requires some knowledge. Once you've written your first HDL to detect and extract packet headers and data it gets a whole lot less mysterious but that first one can be difficult for those learning the subject. Also you need to have a basic understanding of the physical layer; 10/100 isn't the same animal as gigabit. You need to understand the hardware platform that you are working with. Supporting triplespeed MACs in your HDL involves some digital design techniques that are beyond the beginner's stage. I'd never want to discourage anyone from completing a project goal but I certainly think that it's fair to point out the scope of the work involved. I'm not the type of person who pushes an adult who can't swim into the pool as I call out "Don't worry, you'll figure if out". (Evidently in some parts of the world they do this to newborn babies and it all work out...) As I've mentioned in other posts the FPGA vendors don't want to make it easy for users ( especially casual ones ) to use Ethernet without being tied to their own IP. At least Digilent configures their Ethernet PHYs is a usable state out of reset making things less painful. The lowly UART is fairly simple in comparison to Ethernet. Even still, trying to implement a multipoint network network using HDL Uarts is a significant undertaking.
  9. zygot

    ethernet communication with pc

    There are a few projects in the Digilent Project Vault that might interest you... specifically ones by hamster and vonmuller. I hope that you don't think that you can do anything useful with the Ethernet interface without having a basic understanding of the layers and protocols involved, especially if you want to communicate with a Linux or Windows computer. This is not a trivial undertaking. Opencores has a few projects that might be educational.
  10. zygot

    board to board (ZC706 to ZC706) communication

    You can get the SDK to add a few example projects for any device in the system. Open the system.mss and click on the OS (the default is the standalone but you may have chosen another one when you created your BSP). Scroll down to the uart_x that you run through the PL and click on the demonstration examples. There is a nice variety of demonstrations and you probably want to add them all. The SDK will build these for the uart you selected. This is one nice feature of the SDK. If you chose another OS, such as the RTOS I'm not sure if examples are available. You likely want to use the interrupt driven example as a basis for your design ( depending on how you designed your overall software control). Of course, there are a lot of ways to arrange your communication protocol so I hope that you've spent some time thinking about how it will work. The simpler the better. Understand that the purpose of the example code is to show you the basic requirements to implement a particular interface and not to solve your problems... that is they are there for you to pore over and understand how they work. I can't send you code because your application is unique to you. If your SDK OS has a hardware abstraction layer then you will likely need to find other sources for example code. I rarely need (or want) a full-up OS like Linux for embedded applications. [edit] I should have mentioned that since you have at least two FPGA boards ( and ony you know what else ) you have a system. The basic system definition and design approach should be the first thing to flesh out. This includes inter-board communication; for instance are the boards peer-peer or is there a hierarchy? You can always tweak the system design if the lower level considerations demand it once you start fleshing out the actual implementation. If you haven't given any thought to the system interactions and structure then you are in for a lot of unnecessary work as the project nears integration.
  11. zygot

    board to board (ZC706 to ZC706) communication

    @Niranjan, I had some time yesterday and created a Zynq design that brings out the unused PS UART0 to pins on a PMOD via the PL. I don't have your board but I did use a Zedboard which is close enough. I just wanted to verify that my advice was usable. I used Putty and a TTL USB UART for testing. The effort wasn't without hitches. Since my first hardware included both uarts the SDK decided to associate UART0 instead of the default UART1 as the port for stdin/stdout. It took a while to realize and fix this. My first build also had a copy/paste error that assigned UART0_TX to the wrong pin. As it's been a while since I've used the SDK it took awhile to realize that I couldn't attach UART1 to the Console like I've always done in the past. The combination of errors and tool version changes made for a lot of necessary work. Basically though, most of the pain was dealing with the SDK software. It reminded my why I'd rather do everything in HDL** rather than mess around with all of the burden and nasty surprises that come with FPGA processor development. But making use of PS interfaces that aren't used on a particular board is not all that hard, once you remember where all of the Eclipse controls are located. ** Except for once, when I installed the tool version to match a demo, I've never been able to create a workable project for board design, TCL scripted Digilent demos. Very often the IP in the demos can't be updated so they are locked and getting a bitstream is impossible... haven't figured this out yet. When I try to revive or change one of my own old project that was working when I left it a few years past I've gotten familiar with the bugs and peculiarities of more recent Vivado versions ( thankfully ISE is old but I know what I'm getting ) and I end up trying to update them into new tools. This almost always means scratching around to resolve incompatibility issues, particularly in the SDK.. and many many hours of effort that displaces time for actual design. Still, I do use those ARM-based FPGA devices when I have not other reasonable choice.
  12. zygot

    Vivado Bitstream Generation

    I should mention that the Zynq is a whole different (more complicated) deal than regular FPGA devices. The Zynq has an ARM that has to be tied off if not being used. You can find information about this on the internet. The tool flow is more complicated. I suggest that you target a different board/device once you've had success creating a configuration bitstream from the original sources. Don't worry the objective isn't to run your code in hardware yet. As much as I like the FPGA devices with a hard ARM processor core subsystem I would never recommend using that platform for beginners to FPGA development. Even if I assume that someone has some knowledge and skill with an HDL a lot of the battle involves getting to understand the tools ( a particular version of the tools ). Find a cheap plain old FPGA board to figure all of this out using only HDL sources. I use HDL only until I absolutely have to have a programmable processor and then turn to my ARM based devices. Back in the days design tools involved pencils, quadril paper, and lot's of cranial heating. The software based tools weren't perfect but they were generally reliable once you figured out their peccadilloes. In this century doing anything useful involves a little mental preparation, some skill and ingenuity and wrestling with belligerent tools that change with every version release and bugs that come and go. Fighting the tools can be 60% or your effort. Don't add complications that aren't necessary. To paraphrase a quote from Einstein: "Everything should be as simple as possible; but no simpler". This advice works on every level of human endeavor.
  13. zygot

    Vivado Bitstream Generation

    @Hunaina You don't need a board with the correct target device to generate a bitstream. Once you have that success you can use the reports from the tools to compare to your new version or project. It's easier to build on something that worked, even if you can't test it in actual hardware. If you are coming from a software development background prepare to be shocked... FPGA development is a whole lot more complicated.
  14. @Archana Narayanan I appreciate having the feedback with your resolution. It's often the simple things are escape our analysis when things don't work the way we expect. No matter how long you engage in software or FPGA development the little, seemingly innocuous, details are likely to bite you..
  15. zygot

    Vivado Bitstream Generation

    There should be no problem porting HDL-only sources to different tools; like ISE, Vivado, Quartus, etc. The first thing to do is create a bitstream for the original device using the original source. If you can't get the original project to work then there isn't much hope for modified versions. There's more than source code to a viable project. When you change the device target, as you are doing, then it's likely that resources being used in the original project are different in your new project. Even if the resources are similar things like BRAM, clock managers or PLLs and the like will usually require recreation by the tools. I've tried out many an opencore project or code snippet. I always (try to) recreate the original claims for the IP as a first step. I then spend the time going through the code to understand how it works. While I often see novel approaches to problems rarely do I find anything that I want to use 'as-is'. I'm guessing that you are new to this, Yes?