• Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by xc6lx45

  1. xc6lx45

    Timing constraints are not met.

    is it possible that this block isn't meant to be used at 100 MHz? There are 27 levels of logic, the signal needs 18 ns through the transistors alone plus another 15 ns for routing delay. The design demands the signal to be ready after 10 ns... I may be wrong, observing from the distance, but this looks like a typical beginner mistake in the "IP block" (if this is 3rd party, non-Xilinx): Leave sufficient registers = delay in any non-critical path. Done consistently, it will also speed up P&R tremendously - the job gets so much easier. If it were an output from the IP block, you could fix the situation by running the output through a chain of ~ 5 registers, and turning register rebalancing on in the options. But, I suspect, this was tested with a lower-frequency clock (e.g. 12 MHz from USB is popular)
  2. xc6lx45

    understand and configuration of xadc

    If that helps, I don't think the XADC has write-sensitive registers (at least not seen as a "black box"). It's unlikely to "trigger" anything. I've used the XADC with initial values only and it worked as expected. But it's a fairly complex subsystem, several things can go wrong.
  3. xc6lx45

    Hi, Interested in LabVIEW

    Just a thought: .NET has grown into a mature and capable platform. Used correctly (meaning: designing for GC avoidance), you'll spend more or less 100 % of CPU time in the instrument drivers (plain data acquisition - outside of algorithms, of course). Multi-threading with the "Task" model is very straightforward, knowing a few "gotchas" (e.g. it's user responsibility to wrap GPIB IO in a mutex, possible exhaustion of the shared task pool) Now if cost is an issue, "free" is hard to beat. "Free", assuming you have Visual Studio available. I have actually tried Mono as "truly free" alternative with industrial production code and it worked straight out of the box but the above-mentioned "algorithm" part became notably slower.
  4. Hi, I think your C code does not do what it suggests it does. Here... int ddr3_addr1, ddr3_addr2, ddr3_addr3, ddr3_addr4, ddr3_addr5, ddr3_addr6, ddr3_addr7, ddr3_addr8, ddr3_addr9, ddr3_addr10, ddr3_addr11, ddr3_addr12, ddr3_addr13, ddr3_addr14, ddr3_addr15, ddr3_addr16; ... you create variables ddr3_addr on the stack. Here ... Status = DDR3datawriting(&ddr3_addr1, &ddr3_addr2, &ddr3_addr3, &ddr3_addr4, &ddr3_addr5, &ddr3_addr6, &ddr3_addr7, &ddr3_addr8, &ddr3_addr9, &ddr3_addr10, &ddr3_addr11, &ddr3_addr12, &ddr3_addr13, &ddr3_addr14, &ddr3_addr15, &ddr3_addr16); ... you give the address of the variables (still on the stack!) to the function and here ... *ddr3_addr1 = *(int*)0x80000000 = 0xBABABEE0; you write the value 0xBABABEE0 into abovementioned stack variable ddr3_addr1 in main(). This is not what you want, probably. Further, the same value goes into memory address 0x80000000 (this looks meaningful - base address of your DRAM). Here... xil_printf("\n\r Data written at 0x80000000 is %6x\n\r",*ddr3_addr1); you read it from the stack variable. My suggestion: Clean up the code to the essentials, five lines plus headers. And use volatile for pointers to force hardware IO (otherwise the processor cache may delay the write and / or intercept the read). Link: Discussion on chained assignments in C. In a nutshell: Do not use unless you feel you are entitled to a different opinion 🙂
  5. xc6lx45

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

    for slow outputs: https://www.sparkfun.com/products/10680 Actually, "slow" is relative. This can get pretty darn fast by CPU- or PC standards. I use them extensively (the 74HC595, not the board), driven from an FT2232H chip using MPSSE mode at 30 MHz. The edge-sensitive input will respond to glitches (cable reflections) in the x00 MHz range so I need to pay some attention to wiring: Either short lines, or arbitrarily long but terminated in Z0, which is e.g. 100 ohms for a ground-signal-ground-... ribbon cable or a scavenged ethernet cable.
  6. xc6lx45

    understand and configuration of xadc

    Well, with "software" I meant the libraries and everything on the controlling side of the bus. So if that "software" doesn't configure the XADC mode etc, of course it'll rely on the initial value. But I guess most engineers would be reluctant to rely on initial values without good reason (such as "why not? Don't you see it works!") My point was, the functionality to set initial values and to configure from software is redundant, in a general sense. Neither one will achieve anything the other cannot do, except maybe operation from clock cycle #1 for initial values.
  7. xc6lx45

    Making a GPS locked 1,000,000 pulse per second

    Just to get you guys down to earth: Sync'ing a free-running clock to a reference has been a textbook problem for a long, long. Long time. The words "QPSK" or "Software Radio" can get you in trouble with export control, basically anything but whipped cream. Maybe even that in countries where cows are holy. It's just ridiculous 🙂 ------- A few of the questions raised above clear themselves easily if I remember that the power spectrum of a (jitter) signal is the Fourier transform of its autocorrelation. Or something like that. Don't quote me. In plain words, the low-frequency-heavy jitter "signal" tends to change slowly, "correlates with itself" up to fairly long time intervals. That's why I see little absolute jitter (in seconds) looking at nearby edges, but it gets worse with increasing distance. It may be entertaining but it is ultimately pointless to discuss high frequency PLL performance (such as the randomness of adjacent clock edges) when the discussion is about a 1 Hz low-frequency reference. If I cut through the smokescreen, it all comes down to the simple fact (e.g. Leeson's equation) that I need something better than the on-chip VCO ("higher Q"). Something that does a better job in turning a low frequency into a higher one. Otherwise there is nothing we can do about PLL jitter at higher "frequencies" (in terms of jitter spectrum or autocorrelation of the jitter time signal).
  8. xc6lx45

    understand and configuration of xadc

    Maybe one additional comment: The XADC appears as a register space on the bus. In Vivado you set the initial values that are valid until overwritten through the bus. If your software configures the XADC anyway, the initial values don't matter.
  9. xc6lx45

    Making a GPS locked 1,000,000 pulse per second

    >> which when graphed look very much like a normal distribution. I suspect you can directly read off the room temperature after a bit of averaging...
  10. well, the important thing for me wasn't even speed, but having datapath and actual drivers in the same simulation. Maybe it's just my corners of the woods, but often the software is more complex than the hardware.
  11. Oh, and just for laughs: Try to disable Windoze Defender.
  12. Hi, I can feel your pain. For PC hardware, I believe the best option is a gaming style PC, not "industrial" Xeon or the like. You need single-core Formula-1 performance, not multi-core combine harvester efficiency. A while ago I did a write-up on some design issues that have a real impact on small design closure time (note, not today's Vivado version). The obvious message is, make sure your IOs are (un)constrained correctly and throw in pipeline registers at the right places. Give the tool an "easy" design, not "barely feasible". https://forum.digilentinc.com/topic/9181-vivado-slowness-reality-check/?do=findComment&comment=27913 EDIT: And double-check that you don't have duplicate clocks. This is easy to miss and can be a real killer for build time.
  13. Worked for me... it's a while ago now but I had my drivers working when silicon arrived and knew there was a saturation bug in the datapath that needed a gain staging workaround. Success story for the marketing department, if there were any.
  14. xc6lx45

    VHDL BASYS3 internal clock problems.

    works for me. Stare long enough and them bugs get scared.
  15. xc6lx45

    Making a GPS locked 1,000,000 pulse per second

    >> together over the course of several minutes, suggesting that the PPS was .. less than perfect. this may just be a consequence of the loop bandwidth I mentioned earlier. The loop filter must achieve huge suppression for the 1 Hz update interval plus loop stability. It's long ago and I'd have to read up on "exotic" loop filters but what I've seen so far was low order. Even though PLL settling time was a real headache up to the point of using multiple PLLs when we couldn't tune them fast enough. I remember one reference (most likely it was the NI sync framework for PXI instrumentation) that mentioned PPS settling times in the 1/2 hour range. The obvious question is, why don't they use a more intelligent algorithm but I suspect a linear PLL is as good as I can get for normal distributed noise, which seems safe to assume for steady-state operation. "Clever" algorithms (think "median", sign clipping or the like) may have an advantage only if I can't rely on the error being Gaussian.
  16. xc6lx45

    Making a GPS locked 1,000,000 pulse per second

    BTW, you can do square-to-sine conversion by a simple cascade of numeric integrators. The output is frequency dependent but since the frequency variation you expect is in the ppm range, this is manageable. I posted an OK-ish rail-to-rail (!) DAC here . Verilog unfortunately, but it's only a few lines of code. Measurement results and discussion are here.
  17. xc6lx45

    Making a GPS locked 1,000,000 pulse per second

    Makes perfect sense, putting a simple PLL around a PLL. At frequencies approaching DC, jitter is unbounded - the clock edges just wander away, proportionally to the frequency offset. Done correctly, you'll eliminate the constant term and effectively put a null into the jitter spectrum at 0 Hz. Order of infinity reduced by one 🙂 Mission accomplished. Improving the "inner" PLL at higher frequencies is intuitively impossible, the on-board oscillator is already the best we've got to turn a low frequency into a higher one. A random reference: Figure 3.6 here and the text below ("Noise at offset frequency outside the loop bandwidth is passed to the PLL output.") Your "loop bandwidth" can't be higher than the comparison frequency, which is limited to 1 Hz from the GPS reference. What you could do is use a better "loop filter": What will happen in your implementation is that the periodic 1 Hz update has periodic spectral replicas at n*1 Hz (probably on a 1/n slope) that will appear in the output spectrum: Obviously, the output frequency is updated at a 1 Hz rate. Those changes are not smooth, so they create harmonics at n*1 Hz. This is what the "loop filter" is needed for.
  18. No problems with this one for uncritical two-layer FR4. https://de.beta-layout.com/leiterplatten/ As long as you don't make mistakes, standard PCB processing is extremely robust (compared to more exotic features like when I throw in Rodgers 4350 layers and plugged vias)
  19. xc6lx45

    reading XADC from user space

    Possibly this isn't helpful (I haven't used this combination myself) but can't you simply keep the file open, like /dev/snd for example on conventional Linux with legacy OSS sound?
  20. xc6lx45

    reading XADC from user space

    >> because opening/closing is taking in my case to much time. This just as an unspecific comment: A common solution for being able to start data acquisition "immediately" is to keep it running continuously, e.g. into a circular buffer. The start time then just becomes an index into the buffer. With typical industrial test equipment, it goes as follows: - I arm the instrument. It starts sampling into a buffer -Once sufficient pre-trigger samples are available, the instrument returns it's ready to accept a trigger -I trigger the measurement -internally, it looks back in time , according to its own processing delay etc and calculates the index into the buffer that corresponds to the trigger time We're not exactly beating causality but it's the next best thing... Also, I would think twice before using Linux for a problem that may turn out to be hard real-time. Those issues can become nasty when it looks like a sporadic glitch that I can solve later, and finally realize it's conceptual. At least study the capabilities of the IP / libraries you intend to use. The XADC itself is a fairly precise piece of hardware.
  21. xc6lx45

    fft spectrum analyzer on SOC

    and I was curious what brings you to that question. It's so difficult to come up with a meaningful homework problem (this one would be good), I don't want to carelessly ruin it 🙂
  22. xc6lx45

    fft spectrum analyzer on SOC

    homework problem?
  23. xc6lx45

    [NEED HELP] Fast Connection FPGA-PC

    You can probably make this work with UARTs if you use FTDI's own API (not Windows serial). If I remember correctly, they support officially 3 MBit/s and inofficially a lot more. You need 2.88 MBit/s plus protocol overhead. The same standard FTDI chip (e.g. .FT2232H) will give you up to 30 MBit/s through its MPSSE (high speed serial) mode. It's easier to connect one externally (e.g. "FTDI mini module" for $20) to the FPGA than to use the on-board FTDI chip of most boards. The latter is feasible (you have to go through the JTAG port) but the external-chip option is much easier to bring up. If you're after continuous (not burst) capture, setting up a PC for reliable real-time audio is a topic of its own...
  24. xc6lx45

    Best FPGA card to learn Network Message Processing

    Would a DP83848 as PHY give you the interface you need? If so, it's around USD 10 per port on a single breakout board (check ebay).
  25. Hi, 4 V does not seem right. I think you should supply the board externally (not through USB but use the external power input). Test with a different PC. Yes it's inconvenient but it may save you many hours. Or if not possible, put in at least a different USB card. USB is a mess, and creating a reliable high performance USB bus-powered design may be much harder than most people would expect ("high performance" because an FPGA is by far the most sophisticated electronics component ordinary mortals get to play with). For curiosity, read up on polyfuse memory, one root cause why those things can be near-impossible to debug. And the minimum number of cycles on USB connectors. And the recent crisis regarding low quality USB cables (and no one would have cared if they hadn't caused things to actually break).