zygot

Members
  • Content count

    579
  • Joined

  • Last visited

  • Days Won

    23

zygot last won the day on July 31

zygot had the most liked content!

1 Follower

About zygot

  • Rank
    Prolific Poster

Recent Profile Visitors

3766 profile views
  1. zygot

    Nexys Video

    Xilinx tools definitely take [expected] internal operating temperatures into account when calculating timing analyses. Their tools don't make this obvious. For anyone wanting to do a lot of FPGA design I suggest downloading a free version of Quartus from Intel. Intel (ALTERA) provides a much better reporting of expected timing due to [expected] temperature. Reading Quartus reports for an FPGA board demo will be at least instuctive to those who's experience is limited to Xilinx tools. The tools, of course, don't have a way to know how a particular board will contribute to the difference between [exected] and actual junction temperatures. I can tell you that it isn't necessarily the same throughout the entire device depending on what IO bank is driving a particular external device. I you are using your Nexys Video in the lab without driving a lot of outputs on all of the PMODs and FMC connector you (probably) don't have to worry about temperature. If you are using the FMC connector and all of the boards interfaces that might not be so. The rational for monitoring internal device temperatures becomes more important if you are trying to test new hardware interfaces that might be abusing outputs. {edited} If you are driving a few outputs into ground with maximum current constraints the XADC won't be of much use as by the time you see a reading you probably have damaged the device. It's not my intention to spread FUD, just useful information. Your question is one that I've not seen before and is a good one.
  2. zygot

    Nexys Video

    This refers to the environmental operating temperature limits. Internal temperature will be higher. What counts is the maximum internal temperature if you're worried about damaging your device. Things like delay and switching are temperature dependent and applications that work when the substrate temperature is 40 degrees C might not work at the extremes but I doubt that you'll ever have to worry about it. I am not aware of Digilent providing an ISE compatible .ucf file. It might be time consuming ( mostly to check for errors ) but not too hard to create a pin location .ucf constraints file based on the xdc one. The syntax is not completely different. I've done it for a few Digilent boards on a subset of pins. Be aware that ISE doesn't support all of the current variants of Artix and Kintex devices.
  3. zygot

    Nexys Video

    @Bilal29 When you power up your board it is running an application from flash. What you are looking at is the FPGA internal temperature. 47 degrees is fine and if the DDR is running it will go higher. The DDR, when running, adds quite a bit of thermal energy to the board's copper planes which helps increase the internal temperature of most components on the board. You can move JP4 to the middle 2 pins to prevent power-on configuration from FLASH. The board should not be warm to the touch. Unfortunately, there's no application to run the LCD display and tell you what the FPGA temperature is. An essential tool for the FPGA development lab (especially testing new FPGA based hardware) is an IR temperature reader. You should never touch components on an FPGA board unless you are properly connected to ground through a ground strap to prevent static discharge. This is deadly to your board. You are right to be concerned about excessive internal FPGA temperatures, which is why the Series 7 devices have the ability to monitor it. Xilinx provides information on normal operating conditions in its data sheet. I highly recommend that all applications for Series 7 devices include monitoring of internal temperatures. It would be neat, and instructive, if Digilent provided a way to look at XADC internal measurements with and without external components operating.
  4. It's true that many ISE and Vivado IP provide some timing constraints but that doesn't mean that every design using the IP will have no failing paths. A lot of people are unaware that their designs have constraints that they didn't provide. I have worked on many designs where all constraints were met on one day and not the next with minimal or no source changes. I've worked on many projects where all constraints were met and the hardware might appear to be functioning *perfectly* but on the next bitstream exhibiting odd behaviors, still with a perfect timing score. As far as I know this is how things work for complex designs or some designs that utilize most of a parts resources. If you want to have a secure job then be the one who can take all of the teams masterpieces and understand how to create final working bitstreams for the company's products day after day. Some companies don't even have a person with this level of competence.
  5. zygot

    Has anyone ported GNU Radio to a zynq development board

    I might be very wrong about this but I doubt that a Pynq-Z1 platform is going to be a satisfying host for GNU radio. Graphics performance alone is likely to be a serious issue. Rebuilding this suite of tools for regular PC flavors of Linux on x86 or 64-bit machines from sources isn't a trivial undertaking. You'll have to do that for ARM based platform with limited resources. I would be pleased if someone who's done this proves me wrong.
  6. zygot

    Artix-A7 CMOD I/O Pins - Need more I/O Pins

    @xc6lx45 , Well I can think of quite a few ways to increase IO for specific applications too. It just seems to me that suggesting selecting an appropriate FPGA board for a particular application is the most sensible reply to the question. Sure, if you understand digital design and know exactly what your interface requirements will be by the time a project is done you can find ways to increase the number of inputs or latched outputs. Likely, the venture will cost more than just buying the board that meets your initial requirements. There are a lot of ways to get custom logic wrong, either in design or implementation. I have no problem encouraging someone to spend a lot of time learning but hesitate to push someone into a lengthy and time consuming adventure that is doomed to failure. I'll use this sincere but inadequate advice as an example. When transmitting signals there are a lot of requirements to meet. For a uni-directional signal you have a driver ( of various topologies ) , media, and a receiver ( of compatible topologies ). The bandwidth requirement of the media has to be high enough to support the characteristics of a particular driver and is proportional to the rise/fall times of the switching output. Reflections are an artifact that will occur where there are discontinuities of impedance from the driver, through the media, to the receiver. Driver output impedance, receiver input impedance, PCB traces, vias, stubs, connector pins, device pins or balls, wires, etc are all factors to take ito account and getting any of them wrong can contribute to all kinds of issues. There's a good deal more to be considered for competent digital design but you get the idea. Can a novice get lucky if what he wants to do is set mostly static outputs or know how to handle crappy inputs in his FPGA design? Sure. Can he generate all kinds of problems that he might not be able to diagnose much less resolve? Likely. That's the basis for my reply.
  7. zygot

    Artix-A7 CMOD I/O Pins - Need more I/O Pins

    @tnet, My assumption is that if you had any digital design experience you wouldn't be asking the question; and the truth is that no one can answer your original question without having more information such as do you want... 84 inputs, 84 outputs or 84 IOs, how much are you willing to pay, etc. With that in mind I'll answer the question that I believe you really want to ask. Is there a cheap Artix board with 84 IO pins accessible through connectors? Look at Opal Kelly. There are probably more options but I don't have specific experience with them. Boards with HSMC connectors will meet your requirements but they generally don't use Xilinx devices. If cost isn't too important either of the Digilent boards with an FMC connector will work and you can buy a debug adaptor from Xilinx to provide your IO.
  8. While I'm sure that there are restricted applications for such a system I am also sure that quite a few technology sectors in physics, agriculture, automotive and other fields are interested in and are patenting such things. As far as I know basic thought experiments, other than perhaps in cryptology, are still legal to perform. That's not to say that if I create a piece of hardware and publish it that someone in a governmental agency who thinks that such a technology has national security implications won't pay me a visit and co-opt and become it's new owner. ( I can think of a few stupid, though innocent enough, open source projects from around the world have been quashed in recent memory). My purpose in setting admittedly very stringent capabilities was two-fold: Make the reader think about what it takes to produce much less measure and verify those claims ( typical self-driving vehicles use 60+ GHz radar, very expensive lasers systems are certainly applicable) Point out the complexities of drawing conclusions about what use this line of thought might be for any particular application. Still, I can think of, and have created, less ambitious synchronized multi-board systems that are useful and don't represent a technological security threat.
  9. I can believe that you counted x number of clock periods. I can believe that you did this over a specific number of time intervals. So far so good. What I'm a bit suspicious of is that every one of those time intervals were 1.0000000000 second +/- 0 seconds, or that the average of all of those intervals was exactly that number. Averaging lots of stuff over very long periods can provide some useful information... and lots of incorrect assumptions. Most of what I want to do in an FPGA is concerned with intervals of a tiny fraction of a second. What's important is the repeatability and stability of a clock over this small interval or even from one rising_edge to the next rising_edge. As to locking a garden variety clock module to a precise very stable external source, I 'd say this. If we could have, say 4, prototypes 100 feet apart, and each locked to that source, and each putting out a different source pulse, say 1.652 ms 10 times a second, whose rising and falling edges were within, say 100ps, then we could have something pretty interesting and useful.
  10. No, but I have seen ads telling me that I can eat anything that I want, do no exercise, and take a totally harmless pill that will return my body and appeal to my 20's self ( OK, disclaimer, I was very thin but not all that appealing back then either... ). I can eat my steak dinner 5x faster by shoving the contents of the plate into a blender and chugging it right from the jar... might even be healthier. I do get the concept that having tools that provide answers very quickly can improve productivity. I've submitted card decks to a mainframe and waited a day or two to get back the results. I see simulation as a bit more than a tool though. The verification process is about more than moving on to another design challenge. The whole design process is an intellectual exercise. A simulator is ( can be ) to the intellect like a piece of gym equipment is to the body. There's more to design than 'I came, I saw, I conquered'. Understanding the nuanced details is, I think, better than blasting through projects. Still, not feeling it. I guess that the argument that "never tried it, don't know what is, don't know what it does, don't care, don't need it" just isn't that compelling to me. Again, I'm not trying to challenge anyone's religious views. When you get to a spot where the you start thinking that the must be something else to try then perhaps timing simulation will come to mind. If you never get to that spot then don't worry about it. If the pinnacle of your FPGA career is making the hex led displays look like a clock you don't have to worry about timing constraints or much else... certainly not timing simulations.
  11. Yeah, that's what's stuck in my craw. I was able to put off mentioning my feelings about this post until today. It's been too long since I made a credible attempt at any sort of jitter analysis but I still have the after-taste of it being quite hard. I'm sure that there are labs that can properly characterize this kind of thing but they have very expensive equipment and timing sources plus a lot more accrued experience than I'll ever have. My only real point is that I feel very uncomfortable about coarse treatment of a complicated subject in the absence of a very knowledgeable moderator. Still, it's one of those ideas that are hard to get out of one's head... like certain jingles or pop tunes of yore. So... wouldn't be interesting to have, say 4, PPS sources and compare outputs... you know, if one can figure out how to do that meaningfully. I still wouldn't want to be making any claims. Perhaps it's just so late that most of my brain has gone to sleep...
  12. @hamster, This is the kind of project that gives me heartburn. I really want it to be all true. On one hand it's an interesting idea that a lot of people have thought of and it comes from a usually reliable source. On the other hand the commentary uses a lot of technical jargon that is, well, bothersome. Terms like "GPS disciplined", jitter, etc. shouldn't be thrown around lightly. There's a reason why no one sells $10 "GPS disciplined" clock sources with certified jitter and accuracy specifications. The text says that "my FPGA board's onboard 100MHz oscillator is 100,000,800 Hz". I'm not sure how you are measuring that but I am sure that it isn't that all the time, at any instant or over any particular interval. You board's 100 MHz oscillator frequency has age, temperature, and voltage dependent characteristics on top of the initial error. You also say that "with the PPS input the 1MHz input goes from 1,000,008Hz down to 1,000,000Hz +/- ~0.5Hz". How was that measured? Do you have a NIST (I don't know what the NZ standards bodies are ) calibrated frequency counter? Using the term jitter doesn't really mean anything. There are a lot of specific ways to view jitter, and a lot of types of jitter. Maybe it's me but I get an uncomfortable feeling when I read the word being used generically, especially when it's prefaced with the word 'absolute'. I think that the idea is interesting but the presentation might be misinforming. I'm not even sure that you have the right to claim "world's worst GPS disciplined 1MHz source". Still, it's an interesting idea that I haven't seen presented before. I just have the feeling that it's all a lot more complicated than how you present it.
  13. I hope that the thread doesn't get stuck on one small aspect of the simulation experience.
  14. There's no avoiding meta-stability issues, just minimizing the effects when they occur and occasionally finding a different way to implement you logic. It's a complex topic. You will find a number of 'solutions'. Pick your poison. Neither do I. It would be nice if one could find a fool-proof way to create or implement perfect designs. FPGA devices aren't perfect. FPGA tools aren't perfect. OUr understanding of the problem is not perfect. I think that it's possible to become competent enough in say, C programming, to be able to adapt to almost any environment and be useful. It's not possible to be so good at it that you can develop fault-proof designs for real world hardware in real world environments. If you do all PC work you will have some challenges moving on to embedded work. FPGA development is a lot more complex than developing software for a particular CPU. [edited] No problem, just keep doing FPGA development until someone has a very difficult project with specific validation requirements. Th's that short reply.... I've seen this on many occasions in many workplaces. The project that I'm working on now fits the bill. I'm not a believer in testimonials. You just never get all of the information that you need to make a good assessment. I've worked with brilliant people who just plain got an analysis wrong so I don't tend to follow testimonials blindly. By the way, to turn your argument around a bit; you're saying that you've done 100's of timing simulations and know beyond a reasonable doubt that they are worthless? I know of quite a few companies who'd be shocked to hear this. Every once in a while I run into someone who claims that everyone else, all the textbooks, all the professors have gotten something wrong and that they have the answer to a problem that no one else has found. This has happened to me at least 5 times as I can recall at the moment. One was a Phd with a small company selling power meters to utility companies. I can't think of a one of them who were able to prove themselves to be correct ( you might tend to think that if a utility is buying product that's proof enough but I think that if a utility sees a way to make more money they might not be too curious about how it's made ). Rarely, someone does come along and re-write the textbooks and alter a curriculum; but not that often. I am only conveying information that is a best practice in industry in my experience. There's usually, but not always, a good reason why most experienced places do something a certain way. Most companies are not into wasting time and money in development. I really have no need nor interest in convincing anyone that the have to incorporate timing analysis into their skill set. ( and it is a skill set as using a tool is the only way to become adept at using it ) When people are ready to understand that they need to use a particular tool then all I need to do is inform them of its existence. [edited] In general, having to develop a new skill while under a lot of pressure to meet a deadline is not an ideal way to work. Better to have the honed skill in the toolbox ready for when it's needed. My reaction to a lot of what you've been saying is that you haven't been exposed to very complicated designs, you haven't been exposed to rigorous validation requirements, or you aren't quite getting what's involved in the whole process. iCE40 FPGA's are one small niche in the FPGA world and represent small devices with limited capabilities ( that doesn't make them easier to develop for ). Again, you seem to think that IOs are a design. IOBs in Xilinx devices have features enhancing the part's usability for particular applications. I'm sure that you've created designs that don't fit into IOBs. My experience with significantly large and or complex and or high speed designs is that it's very hard to nail down logic placement and routing over many design cycles and preserve performance and operational reliability. Once you arrive at such a situation timing simulation becomes more than an intellectual concept.
  15. I appreciate your point. This raises the little issue of the 'elephant' in the room. Is our development process focused on fixing problems or gaining insight and a deeper understanding of how real world devices and interfaces work? There are, sometimes, certain easy to apply 'fixes' that seem to resolve a host of deficient design flaws. No doubt that this is the quickest path to a 'working' design. Then there is having the insight and knowledge to design for overcoming specific issues when and where it is required. Developing this knowledge and 'gut instincts' about designing FPGA systems takes quite a but longer, asking more questions when things appear to be 'working', spending the time to characterize particular scenarios, and of course simulating, simulating and simulating ( hopefully with better testbenches for each iteration. The things that you mention are IO timing related. A design can meet IO timing and still fail in internal portions of a complicated design. No design is a good design if it doesn't address all of the issues that the real world hardware will face or all of the potential conditions that the logic will be exposed to. Gaining the insight to account for all of this in a design is an evolutionary, and usually time-consuming process. As to my personal experience. I take the short route when I have to meet a deadline. I take the longer route when I want to learn something. Give me a 'working' design and I can find a situation where it doesn't work as the designer intended.