Jump to content

Search the Community

Showing results for tags 'timing'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • News
    • New Users Introduction
    • Announcements
  • Digilent Technical Forums
    • FPGA
    • Test and Measurement
    • Measurement Computing (MCC)
    • Add-on Boards
    • Digilent Microcontroller Boards
    • Non-Digilent Microcontrollers
    • LabVIEW
    • FRC
    • Other
  • General Discussion
    • Project Vault
    • Learn
    • Suggestions & Feedback
    • Buy, Sell, Trade
    • Sales Questions
    • Off Topic
    • Educators
    • Technical Based Off-Topic Discussions
    • Archived

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location


Interests

Found 5 results

  1. Good Morning Folks! And it is indeed morning, it has been a long day, I started this journey yesterday morning. By way of introduction, and to set an expectation of my level of understanding, I'm an embedded software engineer just dipping a toe in the waters of FPGAs. So very new to this! After a few weeks of playing around with the Verilog and RTL I'm now interested in Microblaze and following (faithfully or perhaps more accurately blindly) the guidance in https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi Sadly, things have not gone as smoothly as I had hoped. Despite sticking closely to the guidance I keep ending up with the following warning, which ultimately leads to a routing error: [DRC AVAL-46] v7v8_mmcm_fvco_rule1: The current computed target frequency, FVCO, is out of range for cell processor_i/mig_7series_0/u_processor_mig_7series_0_2_mig/u_ddr2_infrastructure/gen_ui_extra_clocks.mmcm_i. The computed FVCO is 562.500 MHz. The valid FVCO range for speed grade -1 is 600MHz to 1200MHz. The cell attribute values used to compute FVCO are CLKFBOUT_MULT_F = 15.000, CLKIN1_PERIOD = 26.66667, and DIVCLK_DIVIDE = 1 (FVCO = 1000 * CLKFBOUT_MULT_F/(CLKIN1_PERIOD * DIVCLK_DIVIDE)). I'm using a Nexys 7-100T so substituting DDR2 where the guide refers to DDR3, otherwise it is all pretty much identical. I have the constraints file is in place and the vivado board file is also correct. The system clock is correctly named and uncommented. This is, of course, all generated by the various automated connection and block assistants, I barely had to do anything manually. Having researched this there are a fair number of reports of this but mostly seem to be related to older versions of Vivado or people not setting up Clocking Wizards correctly. The tutorial doesn't use a Clocking Wizard, instead relying on timing from the MIG IP and I'm using the current version of Vivado. I can see where these values are defined in the generated IP constraint files but I really don't think I should be in there changing stuff to make this work. One thing I have noted is that the MIG clock period is defaulted to 3333ps (approx 300MHz), I seem to recall that the reference guide for the board says 350MHz for DDR2 but the IP configurator won't let me go higher than the 300MHz, in any case the tutorial doesn't ask me to manually change anything so I've let that be what it is. Any pointers (in English rather than FPGAish) would be greatly appreciated. As for me, I'm going to bed and will face this again in the morning :-) Cheers, Y.
  2. Hi, I'm trying to tune Atlys HDMI Demo project so that HDMI output delivers a pure 74.25 MHz 720p signal and not 75 MHz as actually designed. To achevieve this goal, I designed a self made pcore to act as a clock generator. This "720p compliant clock generator" pcore is a simple vhdl/mpd file. Attached is a diagram of what this pcore does. Mainly it is supposedly using one sole CMT, implementing cascading two DCM_CLKGEN and one PLL_BASE. The idea was to replace the original clock generator of the design with this core. Instead of delivering 600Mhz and 75MHz outputs, it delivers 594MHz and 74.25MHz. 74.25MHz clock is intended to clock buses, microblaze, hdmi_out core 594MHz clocks are intended to clock MPMC core (8 times microblaze clocks). Now for my questions ? : 1/ I am not so sure about the locked/rst chains I designed. Could anyone confirm it is correct or give me suggestions on how to make it good ? 2/ I can no longer use the clock wizard in XPS as I replaced the original clock generator with this core. If I try to launch Clock Wizard in XPS, it complains there is no clock generator core and tells me to add one from the IP Library. My question : is there a way I could "persuade" XPS that my core is a clock generator so that it can calculate and validate timings with this home made core ? 3/ Last (but not least) : the project does generate a bitstream. However I'm quite sure the whole timing part is not processed as it does not work. No signal from hdmi_out when using this core. The number of files produced during bitstream generation is awfully low (400 instead of more than 2300 when generating with original design). So I guess I must have missed something : probably the time constraints. The problem is that I have absolutely no idea where to begin with this as I have never ever coded timing constrains.. I would really appreciate any guidance on how to solve these problems. Cheers. N.B : this is an XPS project under ISE 14.7.
  3. Hi all, I am seeing an issue on multiple Digital Discovery devices, where the timing precision is off by over a percent (where I'd expect 10—100ppm, at least 2 orders of magnitude better). The problem can be seen most easily by having the device generate a simple 50% duty cycle clock on one of its output pins, e.g. 1 kHz. On two different Digital Discovery devices I tested, the scope reports a frequency of below 990 Hz. The signals otherwise look as expected (good level, stable, good edges) apart from the bad frequency behavior. I confirmed the measurement with a high-quality Keysight 53230A frequency counter. Also, repeating the same measurement using an Analog Discover 2 shows the expected performance (1 kHz accurate to about 10 ppm, which is pretty good for a non oven-controlled crystal oscillator). I have attached screenshots of what I'm seeing for one of the Digital Discovery devices below. The other one is similar (showing about 987 Hz instead of 984.5 Hz). You can already see on the scope that the signal isn't a nice 1 kHz, and the Keysight measurement confirms that quite unambiguously. It should also be noted that the Keysight measurement shows that the signal not only has an unexpected frequency, but also that it isn't as stable as one would expect. I can provide serial numbers of the devices I tested and perform measurements if this helps to pinpoint what's going on here. Any help would be appreciated. Given my very positive experiences with the AD2, I can't believe that what I'm seeing is within spec. On the other hand, I verified this with two different DD devices purchased over 6 months apart, so it looks like I'm not just looking at a single faulty device. As a side node, it seems I'm seeing the same thing on the inputs; if I sample a high-quality externally generated 1 kHz clock (coming from an SRS FS740), the timing seems noticeably off. However, Waveforms doesn't provide an easy way to display the trigger rate counts as far as I am aware, so I want to focus on the clock generation problem first, because that's much easier to verify and reproduce. If anyone else can repeat this simple measurement and share their findings that would be great! Best regards, Sidney
  4. I am working with an Arty design and I have noticed that while I have no intra-clock timing failures, I still have high severity warnings in the "check timing" portion of my timing summary related to not having constraints for input and output delay (no_input_delay and no_output_delay). Does digilent provide suggested timings for the on-board peripherals (like Ethernet and flash), or do I have to go through all the datasheets myself and estimate the trace delay? I found this thread from 2017, but the question was never resolved.
  5. Hello, my name is Caleb. I am a senior electrical engineering student at Northern Illinois University. I am using the Analog Discovery 2 in order to capture analog pixels sent from a sensor at 5MHz and then interpreting that data on the Raspberry Pi 4. I am running into questions with the timing of the logging function of the oscilloscope on the Analog Discovery. I have noticed that when I send multiple acquisitions at once I run into issues with the timing on the next acquisition. It seems that each acquisition comes in order, but there is a delay between the end of one and the beginning of the next. For example, the time from the first sample to the last would be about 1.6 ms elapsed time. However the next acquisition would have a DateTime listed that is 50 ms later than the previous aquisition. My current settings I have been using are: Scope mode - Repeated Buffer: 10 (Not sure from the source material how this impacts acquisitions..) Logging Execute: Each acquisition 8192 samples Is there a way to have the acquisitions send the data out so that the end of acq0000 would correspond to the data at the beginning of acq0001? An additional question I have is how the AD2 Date Time function is working in the csv files exported as acquisitions. Is it a real time clock on the AD2 or is it information pulled from the pc/rpi? Thank you for any help you are able to provide on this. I can provide further information if it is needed.
×
×
  • Create New...