xc6lx45

Members
  • Content Count

    739
  • Joined

  • Last visited

Reputation Activity

  1. Like
    xc6lx45 reacted to zygot in CMOD S7 Timing Violations with Clock Wizard   
    Yes, and @artvvbgave a reply that should resolve the problem.
    In this project you have two clocks. One is the MMCM input clock and the other is the derived 25 MHz output clock. Since you aren't using the input clock clk anywhere in your design there can't be inter-clock failing paths, or even inter-clock analysis. I've had experience with the board design tool for ZYNQ design get wrapped around the axle, so to speak, because I specified a non-integer PL clock in the Zynq System and made it an output to the PL only to have Vivado change the frequency assignment for the output pin symbol  by rounding or dropping a digit, creating just this kind of silly mis-match. I've had more than a few go-rounds with Vivado with this. And the board design messages don't make it easy to figure out what's going on. Fortunately, I don't often use the board design approach. Could the difference between 83.33 ns and 83.333 ns be enough to completely confuse the tool's timing analysis? There's not much else to go on. This idea would be supported by the fact that Vivado thinks that there are 2 derived clock domains when clearly you are instantiating only one.
    I'm suspect about the Wizard created timing constraints after create_clock and wonder if that's an issue or just a side effect of buggy software ( 83.33 and 83.333 shouldn't be different frequencies ). I've usually never seen anything beyond that one when I use the IP to create MMCM or PLL clocks. Your screen shot doesn't show the whole clk_wiz_0.xdc file so it's hard to say. It is conceivable that demanding too tight a jitter specification for a particular output frequency would cause problems; but not the gross timing issues that Vivado is reporting.
    I started off writing about timing constraints, until I re-read the post, and deleted those comments. There should be absolutely no timing errors for the code posted on the CMOD-A7 target. I believe that you are just a victim of a bug in your version of Vivado.
    [edit] I'm surprised that you didn't get any error messages when you validated the board design prior to generating output products. In my experience I've always gotten enough warnings and errors before leaving the board design schematic...
  2. Like
    xc6lx45 got a reaction from attila in DUT delay   
    Yes, it's just a roundabout way to express it via the speed of light (usually with the effective epsilon_r of the dielectric as extra parameter, then it's really a physical line length).
    For AD frequency range, using time seems a good choice, IMHO.
    For example, taking a random Rohde manual: https://cdn.rohde-schwarz.com/pws/dl_downloads/dl_common_library/dl_manuals/gb_1/z/zvl_1/ZVL_Operating_en_09.pdf
    Page 137 "Phase Delay/El. Length"
  3. Like
    xc6lx45 got a reaction from attila in DUT delay   
    OK I think I got your point. You want to zero out some baseline delay with a phase that's linear with frequency.
    On a RF VNA the feature would be labeled "electrical length correction" or the like, if that's of any use to locate the parameter.
     
  4. Like
    xc6lx45 reacted to zygot in How to generate a higher frequency than input frequency using DDS compiler from xilinx   
    @xc6lx45,
    Spoiler Alert! This is one of those ZYNQ beasts with onboard ADC and DAC converters. The issue is essentially a lack of documentation and transparency on the part of Xilinx on how their devices work.  My earlier posts to this thread shows that I didn't get it at first either.
  5. Like
    xc6lx45 got a reaction from [email protected] in How to generate a higher frequency than input frequency using DDS compiler from xilinx   
    A sneaky way out of it is to use n (e.g. n=8 ) generators in parallel, with a phase offset of 1/n sample.  This is literally a "polyphase" approach.
    For high-end fast DA / AD converters you won't be able to operate at the converter's clock rate on an FPGA so it needs to be split on multiple, parallel lanes anyway.
     
  6. Like
    xc6lx45 got a reaction from fel88 in Wrong pins assignment led to electrical damage   
    Hi,
    it sounds very unlikely. Now it does happen that boards fail (which is very rarely related to the FPGA itself, but more often unreliable USB cables, connectors, failing voltage regulators, PCB microcracks and, did I mention, unreliable USB cables) but usually, the problem is somewhere else.
    The FPGA GPIO circuitry is very robust. Unless there is an external power source involved outside the bank voltage range, I doubt you'd manage to damage it even if you tried.
    I guess we all know those panic moments, like "oh no I've bricked / toasted the board" and then you have a coffee, reboot the PC and everything is well again.
  7. Like
    xc6lx45 got a reaction from attila in RF Spectrum Analysis with Analog Discovery 2   
    Hi,
    P=V^2/R
    that is V = sqrt(P*R). For 5 Watts and (assuming!) 50 ohms the voltage at your dummy load will be 16 V RMS or, multiply with sqrt(2), +/- 22.3 V peak.
    Consider using a 1 : 10 probe, check against the 22.3 V with some margin. This calculation assumes a largely sine-shaped waveform  which seems a safe bet if you're FCC compliant with regard to harmonics.
    If you want to use a 50 ohms input you may consider a series resistor. For example, 1 kOhm into 50 ohms is (approximately) 1:20 voltage division. A 1/4 W rating would be at the limit (16^2 / 1000 is around 1/4). Probing your load with this will cause a minimal variation in load impedance (mismatch) - this is where a power splitter would come in for "serious" RF engineering - but  most likely this can be swept under the rug. Or use 10k.
    it's funny how time flies - nowadays, buy a premium mobile phone and chances are good there's a modulated DC-DC converter inside with a bandwidth of many times said "RF" frequency...
     
  8. Like
    xc6lx45 got a reaction from amenah89 in What is the ideal way to insert the video to this card artix-7 100T CSG324?   
    Hi,
    maybe I'm missing something here but even a plain 640x480x60 VGA signal has a pixel clock of 25.175 MHz, against the XADC maximum sample rate (2 channels!) of 1 MHz?
  9. Like
    xc6lx45 got a reaction from [email protected] in What are the preferred method of varying sampling frequency?   
    OT: I think Barbara Dennerlein once discovered such a place playing Hammond organ on a generator-powered festival... almost in tune...
  10. Like
    xc6lx45 got a reaction from Altis in Digilent A7 PMOD Input Voltage   
    You may be able to make it work with e.g. a 10 kOhms serial resistor that limits the current into the FPGA input through the FPGA's clamping diode to the FPGA's supply rail at 3.3 V.
    But please validate this for yourself e.g. with a google search.
  11. Like
    xc6lx45 got a reaction from itse me mario in Genesys 2 Audio Codec with FIR filter   
    True but you'll need some means to break down the problem into smaller pieces that can be debugged individually. Otherwise you have this big black box and the information "it doesn't work".
    I'm not trying to sell you any methodology, simple answers or miracle tools - I would cut most corners myself if I had to do a similar job but you may need a little more "scaffolding" if doing it for the first time. A lot more if learning FPGA design along the way.
    BTW, the current consumption of your codec might serve as quick-and-dirty indicator that your register writes are going through (works for a module, not sure if this will help you)..
  12. Like
    xc6lx45 got a reaction from macellan in Microblaze issues for a beginner   
    Hi,
    >> but I feel like lost in documents
    Welcome to FPGAs. This is pretty much the name of the game (but it also makes the struggle worthwhile - if it were easy, everybody would do it 🙂 ).
    As a general direction, a solid (basic) tutorial is good but don't expect to be led by the hand all the way. The constant version changes make this quite difficult (good news: it means there is technological progress ... well at least in theory but the guys from the marketing department said so and they'll surely know ...).
    More specific directions: Have a look at Microblaze MCS. It's fairly simple - set up the most basic system with some BRAM (=memory "internal" to the FPGA fabric) and one UART. Once you've got that printing "Hello World" - which is mostly a question of baud rates and not mixing Tx/Rx pins, you can add features one by one and the sky is the limit.
    Well, at least until the little girl next door pulls out her Raspberry Pi, running four cores at 10x the clock frequency - don't complain no one told you: by absolute standards, the performance of any softcore CPU is pathetic, compared to a regular ASIC CPU on the same technology node. So eventually you'll have to move into FPGA territory, or it makes little sense except as a learning exercise.
  13. Like
    xc6lx45 got a reaction from CPerez10 in Simple question regarding Anvyl Spartan 6 clock frequency   
    Hi,
    as a simple (oversimplified?) answer, designing for higher clock speed requires higher effort (possibly "much" higher effort), and the resulting optimizations make the code harder to work with.
    Using the clocking wizard to generate a 500 MHz PLL is easy (try it). But writing logic at those frequencies is a different story (e.g. try to implement a conventional counter that divides down to 1 Hz. Why do all those XYX_CARRY signals show up in the timing report already at synthesis?). You also need to distinguish between what is feasible in plain logic fabric, and what can be done with dedicated "hard-macro" IP blocks such as SERDES.
  14. Like
    xc6lx45 got a reaction from [email protected] in Simple question regarding Anvyl Spartan 6 clock frequency   
    Hi,
    as a simple (oversimplified?) answer, designing for higher clock speed requires higher effort (possibly "much" higher effort), and the resulting optimizations make the code harder to work with.
    Using the clocking wizard to generate a 500 MHz PLL is easy (try it). But writing logic at those frequencies is a different story (e.g. try to implement a conventional counter that divides down to 1 Hz. Why do all those XYX_CARRY signals show up in the timing report already at synthesis?). You also need to distinguish between what is feasible in plain logic fabric, and what can be done with dedicated "hard-macro" IP blocks such as SERDES.
  15. Like
    xc6lx45 got a reaction from JColvin in spam for a good cause: COVID-19 research on your FPGA workstation   
    Hi,
    most people working with FPGAs will have a reasonably capable PC under their desk. You can make that CPU power available for COVID-19 research when it sits idle through [email protected]
    The project has apparently been around for many years doing protein research. A summary is here.
    I found that on Windows, installation is pretty straightforward:
    Install BOINC create an account Start BOINC and select [email protected] It can be configured in many ways e.g. set it to use CPU power only if the machine has been idle for a minute. I leave it running at 100 % in the background and don't notice any obvious slowdown. From the few hours I've spent on the topic I got the impression that my old (but water-cooled and diligently overclocked) desktop still outclasses the other hardware I've tried: The newer laptop has good burst performance but goes into thermal throttling after a few seconds. ARM-based Android devices were far off, they probably have better power efficiency but lack  the memory bandwidth (e.g. I see ~10 GB for 12 threads plus 2GB storage).
    So take this as a motivational speech that your FPGA design rig could be a valuable contributor. About one day of uptime got me on position 392.924 of the [email protected] worldwide ranking and I hope this post will motivate many of you to beat this 🙂
    Cheers

    Markus
  16. Like
    xc6lx45 got a reaction from Bobby29999 in Inverse Transform Sampling method on FPGA   
    Playing the devil's advocate, you could put a softcore processor on an FPGA, then recompile the standard C code. Work done in a day (plus a week if you're bringing all the tools up for the first time) but does not make any sense.
    This leads to a very interesting question is, "why does it not make any sense"? Because it does not use the FPGA efficiently. This is unfortunately a common problem to educational projects, "just do anything" even if it makes no sense. Which is unfair because providing answers would require more expertise than can be expected from a student. Instructors are lazy.
    A possible answer to my own question, "yes but we need 1000x higher data rate than the softcore CPU delivers" or "it may use no more than 500 LUTs and only a single BRAM". An FPGA can do many things but the design effort for what starts to look like a "real" design task will skyrocket, e.g. a pipelined implementation with multiple independent operations in flight at the same time.
    A hint, fight laziness with laziness and try to negotiate away any auxiliary tasks like starting value generation (e.g. agree on a hardcoded seed, or have it sent via UART as hex number).
    For example, one strategy (that might even make sense in some scenarios e.g. when the CPU is there anyway) would be softcore CPU based with a few FPGA-optimized hardware accelerators for critical functions.
  17. Like
    xc6lx45 got a reaction from Bobby29999 in Inverse Transform Sampling method on FPGA   
    Well OK, what I wrote was maybe not accurate to the final digit ...
    What I meant is this
    "The IEEE standard goes further than just requiring the use of a guard digit. It gives an algorithm for addition, subtraction, multiplication, division and square root, and requires that implementations produce the same result as that algorithm. Thus, when a program is moved from one machine to another, the results of the basic operations will be the same in every bit if both machines support the IEEE standard. This greatly simplifies the porting of programs. Other uses of this precise specification are given in Exactly Rounded Operations."
    Intel got quite some publicity on their division bug so I'd assume those should work properly (note, not a word about logarithms) but yea, this is not my specialty area
     
  18. Like
    xc6lx45 reacted to zygot in Inverse Transform Sampling method on FPGA   
    It's been too long ago but I do remember taking the scenic side journey into investigating performance of floating point on Intel processors. Mostly what I remember is that it was interesting, informing, had unexpected surprises and was a valuable exercise. Just recommending the excursion to anyone interested in 'bit exactness'.
  19. Like
    xc6lx45 got a reaction from Bobby29999 in Inverse Transform Sampling method on FPGA   
    I think you need to think carefully about the quality of your math functions. For example, IEEE 754 guarantees bit-exactness in many cases but on an FPGA you usually cut corners where you can since you're stuck on reprogrammable logic technology instead of ASIC / hard macros. The low bits rarely matter with one-size-fits-all floats (or "doubles" if one-size-fits-all-floats is too small size 🙂 ) but from a cryptographic point of view (where also the statistics of an error matter), this could be a killer.
  20. Like
    xc6lx45 got a reaction from john_joe in Powering Zybo-Z7-20 directly from USB charger???   
    one unintended consequence is that it will put your board at a potential of 115 V RMS relative to ground (the typical charger has only two mains terminals without ground, and uses internally a high-impedance voltage divider to prevent a charge buildup between primary and secondary side). You can show it with a digital multimeter, on many units you can even feel the buzz when touching the low-voltage wire. Obviously, not all chargers are the same, on some you can't feel it and on others it's fairly unpleasant). That said, it's done frequently e.g. with Raspberry Pi. I can't comment on Zybo but I've used chargers to run FPGA boards standalone without incident.
  21. Like
    xc6lx45 got a reaction from [email protected] in ADC to FFT using Lattice FPGA   
    are you sure that your whole architecture makes sense? FFT size / memory is limited, at such a high rate you can transform only a very short burst. For example, to isolate power line hum (which is very likely something you'll find in the data) you need at least 20 ms...
  22. Like
    xc6lx45 got a reaction from [email protected] in ADC to FFT using Lattice FPGA   
    I don't know which device family you are using, but for example for MachXO3 locate this document
    http://www.latticesemi.com/-/media/LatticeSemi/Documents/ApplicationNotes/IK/ImplementingHighSpeedInterfaceswithMachXO3-Devices.ashx?document_id=50122
    The high-speed generic DDR (GDDR) interfaces are supported through the built-in gearing logic in the Programmable I/O (PIO) cells. This gearing is necessary to support high-speed I/O while reducing the performance requirement on the FPGA fabric.
    The idea is to instantiate a PIO cell that captures data on both clock edges for you. Do not think in terms of rising and falling clock edge on an FPGA for general logic: Verilog or VHDL offers simply more flexibility than FPGA technology. There is also a lot of ASIC- or simulation-driven (or just clueless) material on the web to cause confusion.
    Unless you're into specialist applications e.g. low power, stick with one clock edge for the whole design (reality check: it might seem a clever idea to use both edges, especially given that Lattice devices often have invertible clock inputs. But, the hardware is never perfectly symmetrical so it will always sacrifice some timing margin over the equivalent single-edge design with double-frequency clock via duty cycle uncertainty. It gains nothing also because standard logic cells (exception: PIO above) with edge sensitive input will only trigger on one edge at a time - this goes down to the transistor level circuitry)
    Then, use a 24 bit FIFO. You will not be able to deinterleave the data in real time - that would mean running at 400 MHz. Do not underestimate the difficulty of reaching even 200 MHz - I suggest you do some early synthesis trials to avoid hitting the wall with a design that works in simulation but can never close timing on hardware. I don't know all the Lattice families by heart but "Lattice", 200 MHz and what I read between the lines in your first post rings an alarm bell for me e.g. it comes as a surprise how many logic levels you really get when you've worked with 6-/7 input LUTs before and suddenly are down to four.
  23. Like
    xc6lx45 reacted to zygot in How do you use verilator with Xilinix unimacro elements?   
    You already have a proper simulator in Vivado. Learn how to write a testbench. Where's the Verilator evangelist when a potential convert needs him?
  24. Like
    xc6lx45 reacted to [email protected] in need advice for budget friendly road to FPGA based soft(firm)ware defined radio   
    @apchar,
    I recently had an opportunity to do some gateway defined radio work with an iCE40 Ultra 5LP, a digilent MIC3 MEMS microphone PMod, and a SX1257-Pmod for a radio.  Hardware wise, the set up was really easy to do--and so I'd recommend it to you at all if you are interested.
    You can find my project, source code and references to hardware, here.
    Dan
  25. Like
    xc6lx45 got a reaction from SigProcbro in Zynq 7000 Baremetal with webpack.   
    I don't think there's anything to stop you.
    As a starting point, you could create a "FSBL" (first-stage boot loader) project and cut it to size by deleting out anything you don't need. There are some essential parts you do need, such as powering up the level shifters between PS/PL, enable PL clocks etc.
    IMHO, the easiest way to get there is to start from working code, even if you intend to not use a line of Xilinx code in the long run.
    Note that when you do this, storing a faulty FSBL in flash memory can soft-brick your board when it prevents JTAG access on power-up. This is easy to fix if you're aware of the issue, takes some paper clip acrobatics to short a flash pin at power-up so it doesn't load from flash. Happens rarely, I think I had to do this once or twice in total. Some boards have boot mode jumpers, in this case no paper clip is required...