• Content Count

  • Joined

  • Last visited

Posts posted by xc6lx45

  1. >> 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 nature of the forum (e.g. "product can do X but AD can do Y"? This is just the opinion of one user, please feel free to do whatever you like.

  2. 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 possible entertainment value it is totally, utterly useless assuming your post is about a practical problem to solve. So you might want to provide some additional information, or review the earlier answers.

  3. 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.

  4. 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). 

  5. 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.

  6. 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).

  7. 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.



  8. 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.

  9. 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 frequency response. Rule of thumb is, any frequency that fits a full number of cycles into the delay line is notchedout.

    That's the short answer. The long answer might stretch across shelf meters in an EE library :-)

  10. 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 build up without limit and eventually destroy the circuit. What's typically done (I have not studied this specific PSU) is to put in a high-impedance voltage divider (many megaohms) that puts the secondary side effectively at 50 % of the mains voltage. So much for "ground" ... This is e.g. the "buzz" you can feel from many laptops running on AC power. This is usually safe since the current is limited but then components break and no one understands why.

    It can help to ground the circuit on my desk properly (e.g. any self-respecting lab power supply has a "GROUND" pin) and make sure that this ground connects first and disconnects last with respect to any two-pin wall-wart power supplies. But this doesn't remove the problem, just makes it appear in a controlled, repeatable manner. 



  11. no, it looks just like in the datasheet. 


    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.

  12. 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:


    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 schematic for implications as I just did a cursory search for the dependent "analog" 3.3 V supply.


  13. >> 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 any of those other than putting a quick hello-world design on an EVB.

    You'd think it doesn't matter for corporate users but I ended up more than once in the wrong corner of the corporate legal jungle (maybe skunkworks but this was business-as-usual) without access to production licenses and no way to sort it out quickly without stepping into CAPEX territory. Lesson here, the shiny hardware on my desk alone is useless e.g. seen a development board high in the four-digit price range reduced to paperweight duties or once a box full of Ettus RF toys, several of everything originally bought for MIMO, and of course completely useless for what could have become a "hardware implementation" on the slideset for management.

    For me personally it's a very strong reason to stick with no-cost licensed tools, because when I take the time now to learn some technology, I want to be reasonably certain that I can pull it out of the hat in a few years with minimum hassle. It's the same story with large tool suites e.g. Mentor or Cadence or ADS or Matlab or whatever - there is always a risk that corporate winds change. That's why I'm so fond e.g. of Octave or (here's a real dinosaur) Maxima. No one can take that away so it's a safe investment of my time.

    But I digress - both Lattice and Xilinx tick that box for me even though it's not perfect.

  14. 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 the years, it's nothing to be overly concerned about.

  15. 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 (on ASIC this might be different if you know the clock is guaranteed to be off on rst but that's a different world and I'm still not convinced I'd do this)

    Conventionally, you'd write the functionality as follows

    reg [26:0] ct;
    wire LED = ct[26];
    always @(posedge clk) begin
        ct <= ct + 27'd1;
        if (rst) // note rst is sampled on posedge(clk)
            ct <= 27'd0;

    Feel free to replace the addition with explicit D FF equations but the overall "look" should be the same (think in terms of Moore/Mealy machines, data moving register-to-register through combinational clouds)

  16. 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 Lattice e.g. ICE40 is less capable, no combinational mode. AFAIK..)


  17. >> 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).



  18. 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 with a hot glue gun...

  19. On 11/11/2020 at 5:59 PM, attila said:

    Hi @xc6lx45 @Fabio FZ

    Is this "electrical length correction" expressed in time?
    I think I can add such option to the NA.


    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"