zygot

Members
  • Content Count

    685
  • Joined

  • Last visited

  • Days Won

    29

Everything posted by zygot

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. @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..
  12. 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?
  13. zygot

    Vivado Bitstream Generation

    There isn't much useful information in what you show above. To get started did you look at the post place and route resource utilization? If you don't assign inputs and outputs to pins everything will be optimized away. Even if your project doesn't have a constraints file to define FPGA pin signal locations the tool will assign pins as best it see fit. ISE and Vivado aren't too bad with regard to optimization but for the past few years Quartus has been giving me fits by removing large swaths of my design because it's decided that no output pins have any associations. You mention that you imported the project into Vivado. What exactly did you import?
  14. zygot

    busbridge3: High-speed FTDI/FPGA interface

    I agree with you but wasn't really even thinking about the performance aspect. There's a lot of gold to be found in your project.
  15. @jpeyron Thanks for the link... and chuckle. I knew from experience that this is a thing but had no idea that it's been giving a name.
  16. I've been developing Adept applications for some time now. Why is it a problem having the host have the drivers installed? You could also develop applications using an FTDI API but your host would still need those drivers installed. One issue that you might not have considered is that for Windows applications compiled by Visual Studio tools you need to have the appropriate Microsoft Visual C++ runtime installed. This can get messy. I recently **Had** to install Win10 on a laptop and wanted to execute an application that I developed for the ATLYS years ago on Win7. After hours [days] of frustration I ended up installing the most recent Visual Studio on the laptop and recompiled the source. P.S. Miraculously, I was able to import the old solution file into the new VS and compile without a lot of tears and screaming... to my recollection this is the first time that the big M didn't try and subvert my efforts..... This was even more amazing considering the changes to Win10 from the actual real OS [Win7] kernel structure that proceeded it. My view is that Microsoft abandoned the OS business years ago so I look to Linux for the future. To mangle a quote I've read: "Unix is the worst operating system; except for all the rest"
  17. And.... I have this sense that if you keep describing what you did you will answer your own question. I don't have enough information yet to help. [I confess that I haven't bothered to read through your code] Verbalizing problems, if you go into enough detail, is often a fairly reliably way to resolve them. Sometimes it helps to have someone throw in a good question or two.
  18. zygot

    board to board (ZC706 to ZC706) communication

    Welcome to debugging, where things get interesting and your work grades your design effort. Hopefully, you don't have too much confidence in any such assertions like the one above. I find myself in your position more often than I'd like to admit. Sometimes it turns out to be something completely unexpected... usually it ends with a slap on the forehead and DOH! You idiot!... Fortunately, we're working in the PL so there are options, Hopefully you have a few spare IO pins. Just as a sanity check I'd bring out the TxD and RxD internal signals to new GPIO that I'd name dbg_xxx. These can be observed wiht a scope or since I always have a few TTL USB UART cables or modules lying around try to loop back communication to a second COM port in my PC. I'd certainly try getting the PC to talk to one of your boards directly through your current pin assignments.Pay careful attention to signal directionality and be sure to avoid two sources driving any pins which could be easy to do. I might use a mux in the PL controlled by a physical switch to help with that. I never ask myself "DO I have to draw you a picture?" because usually the answer is yes... Your brain might be wired differently. Have you verified that the current signal IO standards are correct? It might not hurt to revisit the Zynq documentation for moving PS UART pins to the PL... this isn't always totally straightforward. [edit] Oh, and I forgot to mention that when things get really confusing I plod through all of the Synthesis and P&R messages. Sometimes Vivado and I aren't understanding each other the way that I assume we do. If I were smarter, I'd probably do this step after each bitstream production... but I want to keep moving...
  19. zygot

    Cmod S6 - Multilayer?

    Consider that the FPGA on your module has 196 balls. The A7 versions have 236. You can answer your own question by thinking about how one gets all of those surface mount pads to ground, voltage and signal traces.
  20. zygot

    busbridge3: High-speed FTDI/FPGA interface

    I'm having a hard time comprehending how this project has gotten only 200 or so looks and my demo project has 10X that. I suspect that views may not be a good metric for interest. No one's talking but I surmise that people (students) are getting some utility out of the terminal based UART user interface that I provide. I certainly do. Who knows? Will anyone take the time to provide feedback? Is there a Multiverse?
  21. zygot

    Cmod S6 - Multilayer?

    Hey @TireV What your are referring to is called the stack-up and refers to the layers of non-conductive prepeg material and copper plating that makes the planes and signal traces. You are correct that as a user of the CMODS6 ( or any small form module for that matter ) has an interest in this part of the board. The thickness of the module is not necessarily proportional to the number of layers. What is important is how much and how thick the copper on the prepeg layers is because large ground or voltage planes thermally connected to the IC substrate are the only route for thermal energy to be 'wicked' away from the active devices on the module. More layers is not necessarily better. PC motherboard manufactures for a while there saved cost by using 2 layer boards but there is a lot of engineering and expensive tools required to do this right. I responded to your question because it's not just a good question but a nice segue into this comment that you brought to mind. FPGA timing performance is temperature dependent. There are industries that like miniaturized high performance modules and take extreme efforts to minimize and or manage heat. These are very expensive. These modules also [should] come with very detailed testing results that indicate what the upper level of performance the modules can handle and how much heat it dissipates into the system. When someone offers you a very cheap and tiny module you can assume that thermal issues are something to keep in mind when you use it. It's not just performance that heat has on and FPGA but longevity as well. I happen to very much like and uses the CMOD-A7 modules, as well as other modules from other vendors. I also keep in mind that it's possible to run into thermal problems if I expect too much out of them. But, like a speciality tool; when you need it it's nice to have around. I have no expectation that a vendor of cheap modules tests much less would specify in their advertising performance, environmental, or thermal information. If I was buying a $100K module with an FPGA then I would insist on this information. So I offered a narrow slice of a proper reply to your question. I do encourage you to lean more... the information is out there, often as documentation on EVMs that will supply all of the PCB design information as well as the guidelines that were followed in making them.
  22. zygot

    RX / TX LED are swapped on the Zybo

    I get your frustration but also feel a bit of sympathy with the folks at Digilent. The confusion is a grandchild of the RS-232 specification back when UART usually implied RS-232. This peer to peer interface had DCE or DTE ends, connector genders and connectors with different numbers of pins.... what a mess! Using a UART was as much fun as a snowy two lane country road where there are only 3 ( the middle one being shared by traffic going both directions ) bare strips for your tires amid the ice and snow.I still have nightmares about not being able to do something because I can't find a $%#^% gender or DB-9 to DB25 changer... At least I have to congratulate Digilent on being consistent and providing a clue in the signal names as to what you need to look out for when using an external UART. So which kind of device is the Zybo? I could argue for either one...
  23. zygot

    board to board (ZC706 to ZC706) communication

    @Niranjan It seems that you spent the time to figure this out ( I failed to mention that you needed to swap pin assignments for the two boards if you use a straight cable... ). When things don't produce the expected results the first thing that I do is check the post bit generation pin report to confirm that all of the new pin assignments are indeed correct**. I'm not completely understanding your terminology.... a UART is a full duplex interface and you seem to use transmitter and receiver as references to the boards in your system... but if you're seeing the Tx data on one board's PMOD pin then you likely have the PS pin mux set up correctly. I always use the devide and conquer approach to debugging, I'd try to confirm that one board can talk to a known good UART or itself as a first step. I always convert the board diagram into HDL and use a wrapper to instantiate that into my toplevel design source code so you might have to verify that the Uart GPIO direction assignments are correct. I don't see any glaring issue with what you've already done from reading your last post. ** It's a good habit to check the pin report every time you assign IO pins new functionality.
  24. zygot

    Implementation Strategies

    @xc6lx45 Here's why I really like your last post on this subject. Between the lines I read: "Asking someone to resolve your issue is risky because every design is different and the issues created for a particular implementation is different and the best solution is different". This concept is even more true when the advice comes from someone who can't possibly understand all of the particulars of your project. Sure, there might be responses with general guidelines and testimonials of past experiences but the burden of understanding, and responsibility, is still yours. The gold in your advice is this: Have you learned about....? I understand the desire to save time but.. use that Xilinx Documentation Navigator and get to know something about your tools. Try out the timing explorer, or whatever your tool calls it, and see what the tool comes up with as Synthesis and Place & Route strategies for improving your timing closure. Be teachable.. even by Vivado. I can say with confidence that whatever you do to get today's project ills resolved will be unlikely to solve tomorrow's project ills. Till someone can put experience into a pill this is the best advice you will get ( assuming that you aren't just solving an unwanted problem and have no interest in doing future FPGA development. ) As an aside this thread opens a point of frustration that never seems to be addressed adequately. Some constraints and tool guide commands can be inserted into HDL source as pragmas and some have to use alternate means like constraints files, TCL, or GUI project settings... Vendors, is it really too much to expect that one day your tools could be more user friendly?
  25. zygot

    board to board (ZC706 to ZC706) communication

    @Niranjan Well you say how large a chunk of data is but not how often you want to transfer a chunk of data. Assuming that your idea of a UART will suffice in performance I can only say what I'd do. The simplest approach involving the least effort would be to route an unused PS UART through the PL on both boards and connect the TX, RX lines using a PMOD cable. You might be able to use the control signals as well though I doubt that this is necessary. This approach requires no HDL whatsoever. You will have to make the proper constraints assignments and provide for the new PL GPIO in the board design schematic. As to how you do that... that's part of your workload... There's also the CAN interface though you might have to provide your own PHY (check your board to see if it's already there). I know of at least one regular post submitter who would go that route. Pretend that you're hearing this in the voice of Sir Alec: "Use the can Luke! Use the can!" He'd probably be saying "Use the Loo" but we'd know what he means. If you want advice on using CAN post a question here and you'll likely get a reply form that particular contributor.