xc6lx45

Members
  • Content Count

    596
  • Joined

  • Last visited

  • Days Won

    35

Everything posted by xc6lx45

  1. >> if(count = "00000000" and pulseon = '1')then >> if(pulseon = '0' and Trigger = '0' and pulsetrig = '0')then shouldn't there be Clk'event in this? Without good reason, I would strictly avoid any non-clocked code e.g. reset That is, if(Clk'event and Clk = '1') then ... all your code here
  2. I think you are operating far, far out of spec... Just as a reality check: "process variations" in space need to be under control across the wafer for economic production. You're trying to show differences across the die. The old proverb applies, "correlation is not causality". You might have a look at the delay budget in timing analysis for the paths. Probably you'll find your answers there. And, I suspect with a few selected constraints for max. datapath delay (important: use -datapath_only flag) you can turn this result on its head...
  3. Hi, check the warnings. Most likely there is a bug in your design. If the tools remove logic, it's redundant - either you did tie it intentionally to a constant or there is some other issue (e.g. no clock) that makes the pulse_length input non-observable in the output. You might add a final output register right before the IO interface with the DONT_TOUCH attribute: The tools will deliver an implementation that is "correct" as seen by static timing-analysis (setup, hold margins etc). The signal is free to do whatever between clock edges (see "hazards" on Wikipedia). But I suspect this is not the main issue here if parts get optimized away.
  4. Hi, just a thought, reading and guessing what you're after (and I may be wrong). I see a risk that you're underestimating the difficulty / workload / learning curve substantially, by orders of magnitude. There is nothing that cannot be done, but so many things that need to be done and stack up. Many people have learned the hard way there's a long distance between features on vendors' slideware and functional features in a design. Zynq would seem the logical choice. Soft core doesn't even get close to 2x 666 MHz, 256 kB processor memory, 512 kB cache plus the FPGA. You might do the experiment, get some cheap recent board, set yourself the goal of a basic "pipe-cleaning" exercise to bring up the basic features using only the tools (not just build a ready-made example project, stealing line-by-line is OK). If you eventually start to feel this takes too much work for stuff that "should work", this is just the point I'm trying to make 🙂 If you're getting into the technology, I would strongly suggest to first get a "simple" Artix board e.g. CMOD A7 for the FPGA end of the "pipe-cleaning". A Zynq contains almost exactly the same FPGA but is less accessible because it is "owned" by the PS = ARM side. The small ones need only no-cost licenses (=Vivado "Webpack").
  5. The first one in main() is correct. The 2nd and 3rd one are after PL configuration. Alternatively, locate this line fsbl_printf(DEBUG_INFO,"In FsblHookBeforeBitstreamDload function \r\n"); in fsbl_hooks.c and put it there but it should make no difference.
  6. is this 10 ns per division on your scope? This is unlikely to show an 80 kHz sinewave... A picofarad capacitor isn't likely to help. The values I gave are not the only choice but they were calculated for an 80 kHz sine (resulting in a 100 kHz or 88 kHz cutoff frequency).
  7. Hi, shouldn't that delay go into the FSBL (not the user application)? in fsbl_hooks.c there should be a function before bitstream upload, that seems a good place (or early in main.c)
  8. xc6lx45

    IIR compiler

    IIR filters are more challenging for several reasons (bitwidth / coefficient quantization, internal gain boosting / biquad Q, limit cycles, nonlinear group delay, non-feedforward data flow, ...) You will probably find that once you've gone all the way through a fixed point implementation, IIR filters are not as attractive as suggested by the MAC count. Of course, they do exist and it may work just fine (depends also on the values of the coefficients you're trying to implement). Your filtering problem from the other post had a fairly narrow passband and a huge stopband. This is very expensive use of a FIR filter... If you use a more sophisticated (multirate) architecture, you'll be able to get the same or better filtering with maybe 1..5 % of the MAC count. One approach is: - design an inexpensive band stop that suppresses the alias band of the following decimation step - discard every 2nd sample (said alias band folds over your wanted signal but we've made sure there is no significant energy) - repeat the procedure as many times as possible - design a final filter that provides steep edges and equalizes the sum of all earlier stages The point is that the cost of later stages gets much lower because the sampling rate drops (you may actually find most of the MACs get used in the first stage, and the last one is basically for free thanks to the much lower sampling rate). Now this isn't trivial, people like me get paid for this... fortunately there aren't (yet) wizards for everything.
  9. You could try a 10 ohms series resistor, then a 150 or 180 nF parallel capacitor to ground.
  10. I think you should go back to the basics. Set up a simple FIR filter e.g. [1 2 3 4 5 6 7] impulse response, and get your simulation working that an input of [..0, 1, 0.....0] gives something that resembles [1 2 3 4 5 6 7]. In your simulation this is not the case (the filter has 123 different coefficients, your simulation shows only a single output value).
  11. yes, it's the highest positive 16 bit signed number 32767 (0x8FFF is the smallest negative number, -32768). You could also consider 0x4000, which is a single bit, makes your coefficients easier to recognize in the output (because multiplying with this number is a single bit shift operation).
  12. true but it's a five-line job e.g. in Verilog reg[15:0] counter = 0; reg [15:0] impulse = 0; always @(posedge clk) begin counter <= counter + 1; impulse <= (counter == 0) ? 16'h7FFF : 0; end plus the protocol interface (e.g. trigger a new valid sample if counter[7:0] == 0)
  13. ... and how about a simple impulse response test (feed a stream of zeroes with an occasional 1 and check that the filter coefficients appear at the output). Just wondering, isn't there a "ready / valid" interface also at the output if you expand the port with "+"?
  14. xc6lx45

    DAC spartan3e

    You're trying to drive an external SPI DAC, right? SPI_MISO is to get information back from the external component to the FPGA. So in theory, no you don't strictly need it. It's also possible without an external DAC, using a resistor and capacitor instead as lowpass. Here is one example including sine wave generation that allows rail-to-rail output (that is, 0..3.3 V). It's probably the fastest way but this is not exactly "newbie" territory. In other words, if this happens to be a course project, double-check that this approach is legit. Otherwise, better be prepared to explain how it works link/code
  15. >> Otherwise you can always using the clocking wizard to create a PLL to create your 32 MHz signal if you don't strictly need an external source was just about to suggest that... check the clocking wizard (use MMCM "primitive", not "PLL" for a 12 MHz input clock). Reading between the lines of your question, there is a good chance this will save you a lot of work with a few mouse clicks.
  16. Hi, check your options for bitstream generation. There is a clock frequency setting that determines the time it takes to move the data from flash to FPGA.
  17. A reverse Heisenbug... the problem appears only when you try to study it You could try to insert a series resistor at the point where you attach the instrument e.g. 100 ohms (can be much higher, if needed reduce the SPI clock speed. It'll form a lowpass with the cable capacitance behind it). A T-wire arrangement is generally problematic for edge-sensitive signals (CLK, not DATA), this can fail at any clock frequency => isolate the T-branch with resistor as above. Have you checked the current consumption? It's not something we see frequently nowadays but in theory it could be latch-up. One experiment is to add e.g. 10 kOhm resistors between MOSI, MISO, CLK, CS and either GND or VCC, and check that the design always works robustly. Otherwise it points to a floating-digital issue e.g. your driver tri-states CS instead of pulling it high, or something the like.
  18. Hi, most likely, your test instrument has such high input impedance (1 MOhm / 24 pF according to the product webpage) that it does not affect a typical measurement. Now in case it does, the first thought is use a 10:1 scope probe (as found in a typical lab), to avoid loading the source.
  19. xc6lx45

    register clear on raed

    The idea is also known as "read-sensitive". One thought: Most likely, you want to know both numbers at one common point in time. Unless you stop the test, the two reads are not atomic, and register contents may change between them. One possible solution is to agree between RTL and driver SW that register A (e.g. "number of words") is read first, then register B (e.g. "number of bits"). The RTL code would then, on a read event on register A, return contents of A on the bus and at the same clock cycle copy contents of B into a "shadow register", say C. The driver software first reads from A, then slightly later from C. No matter the time interval between the reads, the two numbers are guaranteed to be consistent. Background info: This pattern is frequently found with combination with time stamps: Say, we need to know the "hardware time" T and a number of readings Q, R, S, ... exactly at that time. So I define one read-sensitive register for T that returns the time stamp and at the same time copies Q, R, S to shadow registers that can be read through the bus. Register sensitivity is a wonderful feature to dramatically reduce SW driver complexity in RTL design (and, like most things clever, can backfire horribly if you outsmart yourself or your colleagues).
  20. Also have a look at C# ...Read # as two stacked ++ rows... In the right hands, it's twice as fast :)
  21. Hi, this leads to the right direction (but not exactly the same board and note the OBSOLETE OBSOLETE OBSOLETE header https://wiki.gnuradio.org/index.php/Zynq >> My doubt lies in knowing if it is possible to communicate the FPGA card to the GNU RADIO application directly or if necessary from an external program apparently they run the application on the chip, with FPGA "accelerators" as kernel modules. Once you're there, streaming the data e.g. via Ethernet "should" be straightforward (but never assume anything...) >> I'm quite new on the subject of FPGA Just a word of warning on Zynq, don't underestimate the complexity: Besides FPGA it's serious embedded ARM, and you can't really choose, in what order you run into which wall... As long as I stick to the well-trodden paths, this remains invisible but be prepared to invest working weeks (possibly months) into the platform. That said, if you have the time and energy, it's definitely worth it.
  22. Hi, one thing comes to mind: for a power line grid frequency of 50 Hz, you can use a 20 ms moving-average window over the data, notches out the power line hum (which is probably visible somewhere at such high resolution)
  23. I must admit I didn't read the manual of that tool... but "Coefficient fractional Bits" should do the required scaling (my guess: "20" for the correct value, given your 120 dB peak gain) I'd try to re-run the wizard with new, default settings to get rid of the error. Have you checked your input file, are there very large numbers (such as 32-bit-ish, like 2e9)? It may be that the tool uses 32 bits internally and needs some headroom (guessing,..), try to export to a lower range. For example, sign bit + 1 integer bit + 16 fractional bits (18 total) would seem reasonable.
  24. Well, I'm not familiar with this particular tool. But at a quick glance, I think you need to set "Quantization" to e.g. "quantize only". Then the field "Coefficient fractional bits" becomes enabled. If it doesn't fall into place easily, start with a simple example, e.g. import a 0 0 256 0 0 FIR with 8 fractional bits and you should see 0 dB across the frequency response. Hint: for an order-of-magnitude cross-check you can get the DC gain of a FIR filter by summing its coefficients. In your example, this should be around 0.0001 for ~ -80 dB @ 0 Hz And PS: one possible explanation (this is a long shot) is that you designed for 12 bit coefficients and exported in 32 bits => +20
  25. My first guess is that the tool needs to know the position of the decimal point of your number format. It's off by 20 bits (=> 1048576 => 120 dB). Fixed point knows only integers, so it's a matter of interpretation.