• Content Count

  • Joined

  • Last visited

Everything posted by xc6lx45

  1. Hi, most likely your scope and probe are the bottleneck. I remember doing the experiment once, and getting rise times around 3 ns from one of the direct outputs of a CMOD A7, after switching to an active probe on a "non-hobbyist" scope.
  2. >> I could not give a direct answer. I heard Analog Discovery has more capabilities. I guess someone will have to do their homework ... after seeing the 2nd copy of the question my first thought was "lazy student meets lazy teacher". Not sure if that qualifies as an appropriate answer :-) But then, the 2nd thought is you're asking for discussion of a "competitor" product (if that is even the case) which seems pretty irregular. Why don't you have a look at the relevant capabilities and features and narrow down your question in a sense that is more constructive, given the na
  3. I'll take the bait ... the problem with "buffering output" in an IIR filter is that the output is the result out of the filter. But despaireth not - mathematically I can do it for a cyclic signal: write as discrete Fourier series, scale with the frequency response of the filter (Z domain transfer function), transform back to time domain. This works for non-causal and/or instable IIR filters, as long as there is no division by zero anywhere. It's the kind of thing that makes engineers run into walls in an otherwise straight corridor. But I'll be the first one to admit that besides possib
  4. I dimly recall the process ... it's been a while ago... yes I think you can do the two steps separately from the command line (first upload the bridge .bit file, then do flash operations). But when you get the readout of the flash ID bytes, that part seems to be working already (it can be also done in a single command). And, spartan 6 / 7 are very similar if not identical as far as xc3sprog is concerned.
  5. I haven't studied the code but I suspect you have to add the 0x16 size ID (e.g. from datasheet, see the format of other entries). Actually I'd check first that all the other bytes (after JEDEC) match the identity of the flash chip (see datasheet, search again for JEDEC). If yes, your programming bitstream is working correctly (and probably it does already now, but the specific device isn't supported yet).
  6. Well non-causal filters are a specialized topic... Most students fail the exam first time because you have to hand in the answers actually before knowing the questions :-) Anticipating what you're asking for: Usually the control theory guys use IIR filters because speed matters. Communications guys use FIR cause they can't stand the damage IIR does to their signal. Take this with a grain of salt. You might want to think some more on what exactly it is you want to find out, otherwise it's unlikely you'll get replies that are actually useful for your specific problem.
  7. Yes, two steps. First it uploads the attached bitstream to the FPGA, then that is used to access the flash. I think it detects the flash by reading some vendor ID from standardized registers (there is no "scan chain", the flash is not on JTAG but SPI). And yes, the pins in question go to the flash memory. Note, the last two lines of the constraint file are important but I think they match the regular CMOD A7 constraints file (but please check).
  8. Hi, with xc3sprog I believe you'll have to compile the programming bitstream for your target device as it's not included. You may also need to make minimal changes to the executable e.g. add the vendor ID (if I remember correctly). The hard part is setting up the build process with CMAKE etc. Expect to spend a working day or two on this. The attached programming file did work with Artix on a Trenz module (not tried specifically with CMOD A7). You'll have to put in correct constraints for the chip in question and build with Vivado, then have xc3sprog load it as programmer bitstream.
  9. BTW, any real-world("causal") filter causes lag on the signal. The difference you're probably looking for is that a FIR filter settles to an input within a finite time span, where an IIR filter settles only asymptotically. E.g. don't be fooled by the structure of the alpha tracker. It can be (and usually is) very slow to react to the input signal (aka "group delay") even if it's based on a single delay element.
  10. Hi, you can try a so-called "alpha tracker" y = alpha * prevY + (1-alpha) * x where y is the output, x the input and prevY the output from the previous compute cycle. It's "the" standard quick&dirty "IIR" filter. alpha is a constant slightly below 1 (e.g. 0.9, .99, 0.999 are typical values. "Moving average" is computationally even cheaper y = prevY + x - xDelayedByK where xDelayedByK is a past input value from a delay line. It's "the" standard "FIR" filter (the recursive equation is just an implementation shortcut). It has a comb-shaped freq
  11. Well, I doubt you'll find a satisfying answer to the root cause. If you aren't aware of any abuse, I'd put it down on bad luck. Ethernet is transformer coupled and isolated (other than 1 nF, see "circuit A" here https://www.mouser.de/datasheet/2/706/fastjack-gigabit-520265.pdf) so you can probably rule that out. >> since power supply that ships with board doesn't connect to ground from wall outlet Actually this is where things get complicated. You can't have perfect isolation between primary and secondary sides of the power supply because this would allow static charge to
  12. no, it looks just like in the datasheet. https://www.ti.com/lit/ds/symlink/lp5907.pdf?ts=1609885581480&ref_url=https%3A%2F%2Fwww.google.ru%2F page 34 "SOT 23" and just to make it clear (referring to the subject line) it's not a capacitor but a linear regulator. If I had to make a bet what killed it, I'd suspect potential issues between the power supply and any other "ground" that was connected to the board.
  13. Hi, just a common sense answer. This is a case for Digilent or vendor support as the board is obviously broken. IC25 is a power supply component, regulator from 5 V to 3.3 V for analog. Schematic, see here "sheet #13 out of 13" C2 quadrant: https://reference.digilentinc.com/_media/reference/programmable-logic/pynq-z1/pynq-z1_sch.pdf Most likely it's shorting 5V and causing trouble indirectly. Assuming I'm not paying for the stuff I'd simply unsolder it (and lose the analog filtering capabilities) but that will void your warranty. Just a thought, please check the
  14. >> Free to me means that you can install it and uses it without fear of having the tools stop working after some period of time. Perhaps someone can confirm that impression. Good point, the licensing is definitely a topic to be aware of when thinking long-term. The no-cost Lattice license needs to be renewed every year. (I just double-clicked iCEcube and was informed "your license expires in 14 days ... a new license can be generated"). I consider it still "free to use" but that's my personal view. They also have smaller devices e.g. MACH (different toolchain) but I haven't used an
  15. well, for DDR-less operation there isn't much choice... it's not as bad as it may look at first glance.
  16. There may be a surprisingly simple solution: Set up a bootloader project and insert your own code where the hardware is as awake as you need it (it starts single-core). There are also some low-level tricks like locking your code in the cache for maximum speed. A word of warning, if you write it to FLASH and accidentally make JTAG unusable, you may need to short FLASH pins with e.g. some paper clip to sabotage the boot process and make the device responsive again. That is, unless your board has bootmode jumpers broken out (didn't check). I think this has happened to me once or twice over
  17. and one more thought: It may be that the dff.v design was actually trying to infer the register I added in the first post ("edge-sensitive latch") on Q and newer tool versions don't allow for such creative use of the language. I might be wrong but apparently this example has worked once.
  18. just for completeness, "reset strategy" is a fairly complex topic by itself. E.g. what are the implications of being edge sensitive on two different signals, does the FPGA hardware even support this (it sets off a red warning light, I'd have to look into the synthesized design if I had to deal with this construct but it seems suspicious in FPGA land). On toy projects, many problems just won't show. Later in a physically large design with fast clocks it opens a barrel-of-worms with 10-inch teeth, can you guarantee each and every timing relationship between rst and clk everywhere on the die
  19. BTW if you want an FPGA to replace an embedded controller chip, you might have a look at Lattice (they require less complex supporting circuitry. For example, look through Xilinx requirements on power supply sequencing). If you plan to copy a mass-produced design, check the prices of components first. It's not unheard of that EVBs are actually cheaper than the FPGA component alone without substantial bulk discount. And there can be nasty surprises with voltage regulators). If interested in Lattice, please double-check that the CPU architecture builds as intended (I believe the BRAM on Lat
  20. >> so I'm looking at building a FORTH core (note I was a FORTH consultant back in the day ...) You might have a look at James Bowman's "J1" CPU with the supporting compiler in gforth. It's very accessible. I used in in a fractals fun project with my own minimal compiler and float implementation (not claiming this is production-ready in the hands of someone else). This project includes a PC side simulator using Verilator. This might score high with regard to simplicity of the workflow (the most complex part is maybe the UART-based bootloader, which is optional). https://p
  21. >> Obviously I would need actually I'd disagree with that use of "obvious". It looks to me like you want to cover the PHY layer with random components that happen to be included on some FPGA board. And that could become a problem (e.g. look at Ethernet and the transformers built into the sockets, and the implications on the signaling).
  22. You might have a look at the low end of the frequency range, especially if your application is sensitive to group delay variations. DC-coupled, even more difficult.
  23. HI, if you search the forum you may find a few similar requests. Apparently you are unaware that the FTDI/JTAG solution is licensed, please search the forum (I haven't heard of anyone using the FT4232H though). For plain bitstream upload you could adapt this project (the bitstream uploader is a small part of it, just delete the rest). Alternatively, there are other FTDI/JTAG solutions e.g. xc3sprog. But none of them will provide you deep integration wíth the Xilinx tools. The quickest way might be to break out the electrical JTAG interface, get a licensed module and integrate it
  24. 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"