xc6lx45

Members
  • Content Count

    427
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by xc6lx45

  1. 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.
  2. xc6lx45

    Vivado free for Artix-7?

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

    Vivado free for Artix-7?

    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.
  4. 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.
  5. 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.
  6. It may be the non-blocking assignment <= in combinational logic e.g. 2'b00: switched_clkdiv <= clkdiv[0]; try 2'b00: switched_clkdiv = clkdiv[0]; See https://stackoverflow.com/questions/26727727/assignment-operator-in-verilog "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 .clk(clkdiv[i-1]), .rst(rst), .D(din), .Q(clkdiv) 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.
  7. 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]; endcase end
  8. 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).
  9. 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.
  10. 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.
  11. Hi, the first solution most people would think of is to use a UART. Ethernet is much more work.
  12. 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.
  13. 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.
  14. >> 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.
  15. 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).
  16. 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.
  17. 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 :)
  18. 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.
  19. Hi, >> Any thoughts would really help. and >> 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.
  20. 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.
  21. ... was just in the middle of rephrasing the above post somewhat more diplomatically. There are many good reasons to use FPGA, e.g. an FPGA engineer will probably earn a higher hourly rate than a Raspberry PI programmer so don't let me distract you 🙂
  22. Hi, >> applying various algorithms if you don't know the algorithms yet, it might be easier to get the ADC data into a softcore CPU, then prototype in C using floating point. The point is, experimental prototyping of algorithms in fixed point RTL is a slow and painful process.whereas reloading a .elf binary takes a second. I'm guessing your intent but I suspect you'll find eventually that an FPGA is not the optimal platform choice for your application. Meaning, you can most likely get the same result cheaper and with less effort e.g. using a Raspberry PI + SPI converter. I'm guessing this simply because higher-rate ADCs where FPGA makes sense (hundreds of MHz) are hard to come by as OTS modules. Otherwise, if you design for, say, 1 MSPS, the FPGA fabric will do less than 1 % of the work it could do but you pay for 100 % so people usually don't use FPGA, if a CPU or DSP will do the job.
  23. The module uses an on-board-antenna, which is always a compromise. So yes, you have the option to connect a more suitable antenna. But this is an "amateur radio" topic, there is nothing "software defined" about it. Boosting the transmitter on one side of the link for a modern two-way protocol won't help much - beyond its own transmit range, the remote end may hear you but it cannot acknowledge reception. Hint: If interested, you can do quite serious software defined "radio" with audio and loudspeakers, e.g. OFDM. The basic challenges - synchronization, frequency error estimation and correction, channel frequency response, multipath reflections etc are pretty much the same if not more visible. And, a white noise spectrum will break most loudspeakers. Don't ask how I know 🙂
  24. Hi, there's a lot of new information in your last post. You aren't just "trying" FPGA but have a professional interest in Zynq. Don't let anybody scare you it's "difficult" and go for it, possibly with the cheapest board, no tutorials and low expectations like, blinking LEDs for quite a while. Given the price tag of any industrial training coarse, an FPGA board for self-study is a no-brainer. Maybe save some money to buy your FPGA engineer a coffee once a week, with some questions in mind
  25. Hi, >> I would be really glad if someone helps  no one is going to do your course homework for you. But, I think you should talk with your supervisor. You've been thrown in at the deep end of the pool, which is OK only for someone who knows how to swim. Reading between the lines, you don't. Now if this is a follow-up to a VHDL course: Review the course material and lab exercises, it will probably give you some shortcuts. If one could teach simply by throwing people into the pool, there would be no need for schools... Otherwise, it looks (based on your post, of course), like a nasty amount of work without any focus e.g. connecting to "a" toy RC car feels like an exercise in tinkering, not engineering e.g. buy a $10 RC toy and hack the transmitter with an MTC61-ish optocoupler. To the FPGA, it looks like a LED. Do not assume it's easy (in a sense of "don't assume swimming is easy").