• Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by xc6lx45

  1. 2 hours ago, grf said:

    It seems to me that the A7 is booting, my machine briefly recognises it as a JTAG device, then (*sadly) the A7 starts it's demo app, which appears to tear down the JTAG port -


    I think that when I am  lucky (the 2% of the time!) I am hitting the hw_server just as the device is being seen for the first time, or in one of these 'cycles'.

    I really think that it it was not for the demo app trying to use the UART my connection would be stable. 

    if you can bring it up once in Vivado HW manager (maybe with the help of an external +5 V supply), you might be able to erase the flash.

    If not, you may be able to prevent loading the bitstream from flash e.g. by pulling INIT_B low (R32 is on the bottom of the board, its label slightly below the CE mark). See https://www.xilinx.com/support/documentation/user_guides/ug470_7Series_Config.pdf "INIT_B can externally be held Low during power-up to stall the power-on configuration sequence at the end of the initialization process. When a High is detected at the INIT_B input after the initialization process, the FPGA proceeds with the remainder of the configuration sequence dictated by the M[2:0] pin settings.""

  2. @Boris_S


    I didn't even mean you should rig up a test cable. It would, most likely, show when the FTDI chip goes into shutdown, but that's it (it would be more useful if you could compare with a known-good board, but I think that's not the case)

    Of course, there is always the possibility of broken hardware.

    If I had to make the board work, I'd try to supply 5 V externally, with e.g. 47µ tantalum cap in parallel. There is one corner pin for external supply.
    I suspect it will not reach the FTDI chip directly (D1 in the schematic), but may help to suppress current spikes from the FPGA.

  3. Hi,

    the difference may be that this board is bus powered.

    Most likely the USB cable and / or the PC side USB hardware are at fault, even if they work with other boards.There can be supply issues that border on Voodoo, e.g. caused by permanent changes in polyfuses on the host after tripping them once. You cannot "prove" that a cable etc works by testing it with another device (not stating this as a philosophical concept but as a lesson learned the hard way with a unit that went to customers...)

    If you would rig up a debug cable with an amperemeter in +5V, you would probably observe that the FT2232H USB chip draws ~80 mA once it's initialized by the driver, and this drops to zero when the chip decides USB is bad and it shuts down. There is AFAIK nothing that can be done about this in software or configuration.


  4. Hi,

    I think a UART is the least effort. Parsing ASCII hex data in a state machine is easy and intuitive to debug, at the price of 50 % throughput.

    If you like, you can have a look at my busbridge3 project here, goes up to 30 MBit/second. The example RTL includes very simple bus logic with a few registers, so it's fairly easy to connect an own design. Note, it's not meant for AXI, microblaze or the like as it occupies the USB end of the JTAG port.

    In theory, it should work on any Artix & FTDI board as it doesn't any LOC-constrained pins.

  5. Just as a reality check: To e.g. make a LED blink, the required CMOD A7-specific content is about five lines of constraints from CMODA7_Master.xdc. This may look more complicated than it actually is. And BTW, good choice, it's a great little board 🙂

  6. Hi,

    don't worry. Vivado Web edition is free and includes everything I need. Look out for "Vivado web edition download". You will need to register with Xilinx, it's free but an export-controlled product.

    If you download existing projects e.g. tutorials, you may need the correct (older) version. Otherwise, the latest version is probably the best choice.

  7. One typical "small project mistake" that makes Vivado painfully slow is lack of constraints or spare registers for asynchronous inputs / outputs, that is, switches and LEDs. See here https://forum.digilentinc.com/topic/9181-vivado-slowness-reality-check/ for a discussion.

    For a conventional, non-interactive simulator, iverilog would be my choice, with gtkwave.


  8. FYI: The MAXX schematic shows the "standard" FTDI-JTAG connection but it is possible that your board has some additional buffers in-between. I noticed this on the CMOD A7 (not S7), needs some GPO bits set to work with custom FTDI-JTAG code. As an opinion, I don't think there's a real risk of breaking anything.


  9. It may be the non-blocking assignment <= in combinational logic e.g.
    2'b00:   switched_clkdiv <= clkdiv[0]; 

    2'b00:   switched_clkdiv = clkdiv[0];  

    "It is Recommended to use non-blocking assignment for sequential logic and blocking assignment for combinational logic, only then it infers correct hardware logic during synthesis."

    and http://www.sunburst-design.com/papers/CummingsSNUG2002Boston_NBAwithDelays.pdf
    It is illegal to use a nonblocking assignment in a continuous assignment statement or in a net declaration.

    Actually I'm not 100 % convinced this really is the issue (check warnings).

    Are the outputs from your divider chain really what you expect them to? This looks a bit odd


    BTW I think you are violating one guideline I didn't even mention: Don't mix information signals (as from .Q) and clock signals (as going into .clk). Many books teach this, with either simulation or ASICs in mind. It also works on a breadboard circuit. But on an FPGA, those are physically different structures, and connecting them makes a mess of things for the tools.

    If you try my example, note I forgot to increase the counter :-) that is, counter <= counter + 24'd1.

    And, reading other peoples' code is probably a good idea.
    Check Vivado "Tools / language templates", Verilog/Synthesis constructs" for Xilinx official examples, e.g. "Example modules / DSP / Complex multiplier". Note, some of this is quite advanced or specialized.

  10. Hi,

    just a thought looking at the code: What I read between the lines is that you're starting out with the wrong textbook. Most of the "legacy" material you find on the web etc is not optimal for FPGA. Your code examples will work but they set you out on a path that is steeper than necessary.

    Some general guidelines

    • avoid combinational expressions "always @(*)" but assign results to registers using delayed assignment <=.
      The obvious objection "but isn't this slow?" is usually countered with "not if it lets me increase clock frequency by 10x or more".
      Using the register hardware on the chip costs nothing, they will just sit idle if you don't but it'll save you a lot of trouble.
    • Let the language do the job for you, e.g. use a 32-bit register and increase by 1 instead of cascading instantiated flipflops.
    • Usually there are much better alternatives to "generate". Save it e.g. for parameterized, reusable code

    The code below will probably pass timing up to 300 MHz on an Artix (haven't tried this specific example):

    reg [23:0] counter = 24'd0;
    reg [1:0] swReg = 2'd0;
    reg LED = 1'd0; // register the output (don't drive chip outputs from a combinational expression)

    always @(posedge clk) begin
    swReg <= sw; // registered copy of asynchronous inputs, one cycle late
    case (swReg)
    2'b00: LED <= counter[23];
    2'b01: LED <= counter[22];
    2'b10: LED <= counter[21];
    2'b11: LED <= counter[20];

  11. Hi,

    >> My question is whats the relation between sampling frequency and clock frequency for single rate FIR filter? 

    you can demonstrate this if you open the "implementation details" tab on the left and the "channel specification tab" on the right.

    For example, I have entered 168 coefficients as an arbitrary, not too small example. Let's assume the FPGA can implement this at 300 MHz, so put 300 into clock frequency (default value).

    If the filter needs to process one sample per clock cycle (300 MSPS input rate), I get 84 DSP slices and 0 BRAMs on the "implementation" tab (the design keeps its coefficients in the logic fabric, internally).

    On the other hand, if I allow 300 clock cycles / input (1 MHz input sampling frequency), hardware utilization goes down to a single DSP slice and one BRAM. (because internally, it becomes a state machine that reads its coefficient vector from RAM).




  12. Hi,

    two ideas (can't tell you the root cause right away, maybe someone else has a better idea):

    - The wizard-generated PLL comes with its own input buffer. This can be a problem when I try to drive more than one PLL from the same input pin.

    - Are you using any constraint locking the MIG PLL to PLLE2_ADV_X1Y1? A full text search through the project (my own tool would be "grep" in an MSYS command window) should locate it.

  13. On 4/3/2019 at 3:29 PM, bhclowers said:

    but worry that the sound card will ultimately be limited in the types of waveforms it can output with respect to custom binary waveforms

    Well, let me put it this way: Recording an audio frequency impulse response e.g. 5 - 20 kHz based on a CW-ish sweep is a problem that has been solved with sound cards for ages.

    Now the word binary raises some alarm flags, whether your problem is well defined and / or fully understood (and if not, I wonder how much better hardware you will need to fix it).

    Hint (blind guessing at the problem):

    - mathematically, "binary" signals are Dirac pulse streams with an unlimited spectrum

    - technically, communications folks use "pulse shaping filters" to tame the bandwidth, e.g. to 125 % of the symbol rate

    - in reality, ill-informed people and Simulink default-options-users rely on "sample-and-hold" aka stairstep or (putting lipstick on a pig) "zero-order interpolation"). Which combines the disadvantages from both worlds: the result is neither mathematically tractable nor anywhere near bandlimited.

  14. 17 minutes ago, David lebental said:

    Thank you for your input. Do you think I should add another 5v 60a power supply to the end of the strip?or should I run another wire from the 5v60a power supply to the end?

    I wouldn't put two supplies in parallel. If one short circuits the output for whatever reason (circuit fault or even self protection shutdown in some models), the cable would burst into flames.

    Driving both ends from the same supply (possibly with an additional "fat" cable) sounds like a good plan. Or, run the additional cable in parallel with the strip and connect it at intervals.

    Higher voltage seems also a good idea, but I haven't checked the datasheet.

  15. Just a thought: can't you simply use a sound card?

    You do not need FFT. if you generate a cos(omega t) source signal. For the received signal r (t), calculate

    A = average of r(t) cos(omega t)
    B = average of r(t) sin (omega t)

    where the average is calculated over an integer number of periods at frequency omega (this drops out an unwanted double frequency term).

    Sqrt(A^2+B^2) gives the magnitude and atan2 the phase.

    In an implementation, you can do independent bursts for each frequency, with differing source power (according to the power handling capabilities of your transducer) and length (to set the required accuracy for each frequency). Make each source burst slightly longer than the averager window, so that the measured system can settle into steady state.

    I've done this with radio frequency testing equipment, but there's no reason why it shouldn't work with a sound card. A loopback reference measurement usually improves accuracy significantly.

  16. >> I can get the lights to work for a little bit then they start acting really crazy

    It might even be possible that the current is heating the wires (which might take a couple of seconds), which increases resistance to the point where it fails.

    If so, it might work on a cold day and fail in the sun... maybe a parallel power supply wire could stabilize it.

  17. Hi,

    I think there are multiple layers of bugs. I suggest you discard the "example" except maybe for the interface,, start from scratch and don't use "for" loops anywhere (the result has only four entries).

    Some of the bugs (again, I wouldn't bother with the code. By the time you've understood the clever bits that won't work, you could have written it twice from scratch, IMHO)

    scanf("%d", &A[j]);
    scanf("%d", &B[j]);
    Res1[j] = Res1[j] + (A1[k] * B1[k][j]);

    where is the 2nd dimension?

    Where do you read "8 bit" values?

    what happens if I use "int" in C (which is signed) and "int" in Verilog (which is not)

    What happens if your result goes out of bounds (e.g. beyond -128..127 if signed or 0..255 if unsigned)? This isn't necessarily a bug but usually you safeguard e.g. using saturation or a separate overflow output.

    When you compile it, you may run into timing issues since it doesn't allow for processing delay (add registers to the output, the software will never be that fast anyway).

    If I had to do this homework, I'd start with multiplying a single number (not a matrix).

  18. one detail that would help is if you find out what kind of "bitstream" this is supposed to be. This is, unfortunately, not "obvious".
    E.g. UART => use the known baud rate for timescale. Or SPI-ish => first look at the associated clock signal and check that it looks right.

  19. OK, that's plenty of new information. So forget all about "radio":  You have a bitstream coming out of an Arduino sketch and want to show it on a scope. The question is whether

    >> 2 oscilloscope channels with 12 bits at 2MHz bandwidth and 6.25 MS/s max sampling rate

    are up to the job. My guess is "probably yes" - I wouldn't expect MBit rates from a remote.

    Maybe if you show the result you're getting, someone can tell what's happening.

    Considering yourself a "noob" is no excuse to be lazy with your posts :)


  20. You could have a quick look here: https://www.rtl-sdr.com/forum/viewtopic.php?t=2233

    They suggest looking up the device by its FCC registration number to get basic info (channel frequencies, modulation format). The point is, it's quite a reverse-engineering project.

    Unless you have additional information e.g. some tutorial for the for the specific device you're looking at, this is not not a simple hacking project. And probably not a fun project since the main problem is that adequate tools are out of reach (e.g. just grab the whole band as IQ capture on a power trigger, all channels at once, for later analysis in Matlab. It's a fairly basic job but the required "adequate" instrument comes with a $50k price tag, give or take some).

    Ham radio enthusiasts might take a different view but they'll probably have at least a RF spectrum analyzer at hand to e.g. visualize the spectrum.


  21. Hi,

    >> Any thoughts would really help.


    >> This is my first experience with an O-Scope

    >> a 433mhz receiver connected to an arduino

    maybe your post doesn't really reflect the work you have already done and you're skipping over the "obvious" details (except that they can't be "obvious" since it doesn't work).
    That said, my first impression is what you're trying is completely over your head.

    For example: "433 MHz" is a frequency band (so-called ISM band). There is no such thing as "a" 433 MHz receiver for remote controls. Both ends of the radio link need to agree in a myriad of details, e.g. modulation, coding, protocol before you can look at bits with a logic analyzer.

  22. Hi,

    >> We are forced to work in assembly with picoblaze.

    you might have a look at the ZPU softcore CPU with GCC. The CPU is just a few hundred lines of code but most of its functionality is in software in the crt.o library in RAM. I understand it's quite well tested and has been used in commercial products.

    Not surprisingly, using an FPGA to implement a processor that then kinda emulates itself in software (aka RISC :) ) is maybe not the most efficient use of silicon - I'm sure it has many strong points but speed is not among them...

    Unfortunately, the broken-ness of Xilinx' DATA2MEM utility (to update the bitstream with a new .elf file) spoils the fun, at least when I tried in ISE14.7 (segfaults). When it works, the compile/build cycle takes only a second or two.

    Long-term, porting the processor to a new platform would be straightforward, or even fully transparent if using inferred, device-independent memory. This would also work for a bootloader that is hardcoded into default content in inferred RAM. I might consider this myself as a barebone "hackable" CPU platform strictly for educational purposes.