xc6lx45

Members
  • Content Count

    427
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by xc6lx45

  1. BTW, just mentioning this: Since you have the code already on git, it seems odd to maintain multiple files with numbers. Alternatives: create a tag if the file is of general interest (e.g. something other developers would discuss) reference the commit by the SHA hash if tagging seems like "overkill" e.g. this: https://github.com/salcanmor/SRAM-tester-for-Cmod-A7-35T/commit/de83d33960108ca66b7f2c4f37ccb498b25deafb For example, it enables a one-click "diff" between versions (which, in this example, would be extremely helpful) I can only encourage people to spend a day or two with git basics. Version management is as critical as coding, if much smaller in scope for the average user.
  2. >> However, for some reason that I don't know I do know but you get one more opportunity to find it. Hint, don't stare at the code for too long or it'll bite you (it's very simple).
  3. Is it possible that your clock is not there (e.g. not connected to the clock pin)? I would try a combinational assignment, simply route the button to the LED without clock-driven process. My VHDL spell checker is still asleep maybe someone else will spots something obvious in the code.
  4. yes, this looks like what I'd expect. Purely regarding style (opinion!), this if(~start_operation) state_reg <= idle; else begin is redundant since state_reg retains its value until overwritten. Same with this... if(rw) begin address_to_sram_output[18:0]<=address_input[18:0]; ... end else begin address_to_sram_output[18:0]<=address_input[18:0]; ... which puts the task of removing redundancy on the reader. Both could be a coding style - spell out everything explicitly - that seems more appropriate for a much larger project where you immediately see the patterns (opinion). ------------------------------------------------------------------- I'm wondering whether it is actually possible to solve the problem stateless, just using constraints If I specify Vivado a minimum delay for e.g. an enable signal relative to data, it will introduce dummy buffers. Works on a nanosecond time scale, which is exactly what this chip needs. If anybody knows the answer or has done the exercise, I'm curious.
  5. it looks like your clock is early.
  6. Hi, you will have no difficulties to run logic at 100 Mhz = 5 MHz * 20, or 200 MHz with attention to details. I would simply register the signals at the high clock rate, and put an extra register or two into the path you want to delay. The on-chip MMCM can generate a 100 MHz clock from 5 MHz.
  7. xc6lx45

    Hello

    Hi, a random thought: I've seen LCD dot matrix panels with current draw from 300 mA down to 50 or so. The blue ones tend to be better. Maybe upgrading the display is less hassle than providing external power.
  8. Hi, Please have a look at the reference manual section 7: https://reference.digilentinc.com/_media/reference/programmable-logic/nexys-video/nexysvideo_rm.pdf Figure 6: USB FPGA interfaces provided by the USB PROG port.
  9. I suspect that reset and sys_clk have LOC constraints, but not FHSS_Signal[29:0] (because the message mentions the number 30).
  10. Hi, >> "To allow bitstream creation with unspecified pin locations (not recommended)" I would not do that when working with hardware. It's useful in situations where you don't care at what pin the signal is connected (e.g. a quick feasibility check). It is possible that some pins serve a board-specific special purpose e.g. are grounded. It's unlikely this would cause damage, but you may run into problems that require serious detective work to debug. Most likely it will actually work. Just guessing: If you need the outputs because interesting signals get optimized away otherwise, the attribute "DONTTOUCH" or "KEEP" should prevent this.
  11. xc6lx45

    SPI Length

    Hi, unfortunately, it can. Try to put a 100 ohms resistor in parallel with the CLK input at the accelerometer board end to ground. CLK is most likely the most sensitive of the signals when reflected edges cause double-triggering.
  12. xc6lx45

    CMOD S6 FPGA start-up

    Hi, see table 2.6 https://www.xilinx.com/support/documentation/user_guides/ug380.pdf page 41 "HSWAPEN" As I understand, it is pulled low by R49 https://reference.digilentinc.com/_media/cmod_s6:cmods6_sch.pdf page 3. So there is weak pull-up enabled generally. Removing R49 should disable the general pullup, HSWAPEN is pulled high internally (see Table 5.2). See also this discussion: https://forums.xilinx.com/t5/Spartan-Family-FPGAs/Spartan-6-FPGA-IO-state-before-configuration/td-p/259300 As a result, your pins will be floating. If hi-Z is insufficient for safe operation (likely), you have to use external pullup-/down resistors to force them to a safe state.
  13. Don't forget coupling capacitors - single-ended RF signals are +/- around GND Frequency accuracy is only as good as the reference, which will be badly (by RF standards) temperature dependent. Good enough for FM radio but any coherent demodulation will give you a hard time. A common reference clock between transmitter and receiver makes it easier Channel grid is another possible problem. Cascading PLLs on the FPGA can improve resolution to hit a single frequency. If you have $20 left in the budget, one of those into a clock-capable input of the FPGA gives a much better timebase, both in terms of phase noise / jitter and frequency resolution (note the voltage option letter). https://eu.mouser.com/ds/2/368/si570-243514.pdf This part is just off the top of my head (from the "official" Xilinx FMC card).
  14. Hi, disclaimer (I take it you are not an FPGA engineer): Some of the terminology in your post is fuzzy (there are no "programs", strictly speaking, but I believe I understand what you meant). Please have a look at this https://www.xilinx.com/support/documentation/data_sheets/ds090.pdf page 14 "quality and reliability parameters", ] NPE Program/erase cycles (Endurance) 1,000 So the manufacturer guarantees this device can be reprogrammed 1000 times. More, and it may eventually break.
  15. You could move the body of wr0 and rd0 into idle state. As an optimization, this would reduce the write cycle time from 5 to 4 (+20 % throughput). But, more importantly: Right now, "busy_signal_output" comes up only two cycles after start_operation. If the surrounding circuitry isn't aware of this, it might check in the next cycle, see no "busy" and assume the operation is complete. edit: and mixing bitwidths 3, 4 and 5 (4:0=5) in the "localparam" statement seems dangerous.
  16. Hi, I just had a very quick look. This is maybe more about style and opinions, but is there a reason to use a blocking assignment for the state variable? To me as a human reader, this code if(~start_operation) state_reg = idle; suggests that the new value of state_reg would still be important for code further down during the same clock cycle. Functionally, it should be the same, though.
  17. ... a slightly longer answer, if anybody is interested (analog mixing with square wave LO): One way is to look at the Fourier series of the square wave as a sum of sines at frequencies f, 3f, 5f, 7f, ... and to a lesser extent 2f, 4f, 6f from implementation imperfections. Then think of the mixer as linear multiplier, and use superposition (the distributive property of multiplication) for a*(b3+b5+b7+...) = a*b3+a*b5+a*b7+... Hint, if anybody wants to formally go through the math, it gets much less messy with cos(x) = (exp(ix)+exp(-ix))/2 aka DeMoivre. So you really get multiple frequency translations instead of one. What remains to be done is to manage the input signal energy at those frequencies I don't want, with a filter or narrow-band antenna. In the digital world, you'd always use a sine wave.
  18. >> it seems like it's very desirable to have a pure sin wave, Welcome to the world of radio engineering :) Very quick answer: Many modern receivers (e.g. take your cellphone) use a digital divider for LO generation that outputs a square LO signal. It actually gives higher mixer gain (which is good for noise) since the "switches" in the mixer conduct 100 % of the time and improves balance issues. The downside is, you get strong spurious responses at n times the LO frequency, which should be suppressed by filtering at the antenna side, before the mixer. But this is one problem from a very long list that you can probably ignore for a while. Generating a square LO is straightforward - simply use the clocking wizard to instantiate an MMCM/PLL. The chip does include LC oscillators (of which Colpitts is a textbook example) and they are digitally programmable. They can also provide 90 degree phase shifted outputs from a built-in divider. BTW, if you downconvert the ADC signal in software: You need a _decimating_ lowpass filter. Either that, or the number of MAC operations skyrockets (calculating samples that are mostly discarded).
  19. Looks like you found the UART discussion in the other thread, I think I see where this is heading Using the FPGA for an downconverter frontend from a direct sampling ADC is relatively straightforward: quadrature NCO, multiply the signal with sine / cosine, lowpass filter both products and send to PC as I and Q. Note, there are fairly decent ADCs on the modern FPGAs (Artix, Spartan 7) that are capable of sampling I and Q channels in synchronized mode. Mixers are cheap - If I had to hack up something quickly, I might think about using the FPGA to generate downconverter LO signals (possibly in quadrature) for external Minicircuits ring diode mixers. Just thinking aloud... (this is creative ham radio hacking, not something I'd expect to see in a self-respecting product implementation)
  20. Hi, a little bit of warning: "Genuine" SDR on FPGA is a difficulty level far beyond "enthusiast" range. When FPGA implementation comes in, you should have a clear understanding of the algorithm side. It's the wrong technology to learn SDR. Until then, use Matlab / Octave / Scilab / Python / whatever to prototype ideas. Even if I run out of CPU horsepower and start writing optimized C code / throw in SSE intrinsics / convert to GPU-code / use grid computing / ..., it is still much more straightforward to work with than FPGA. One simple reason is that I can just write everything out in 32 bit floats, no need to touch fixed point math. Or take the slow compile cycle and lack of accessibility for internal signals. Those are actually the very same reasons why I've grown so fond of Octave over the years.
  21. Hi, could you maybe "open the implemented design" and check the timing reports? With your screenshot, this is a blind guess: One fairly popular mistake is to define a clock twice, once in the constraints file, once via the MMCM IP block. In this case, you get "inter-clock" failures ("from one clock to the other") between two clocks with different names that are in reality the same. A solution may be to disable the clock definition from the constraints file, keep the one from the clock wizard. If you want to debug it yourself: Look at the clocks in the timing report and try to explain what every one of them means. If there are some that don't make any sense, this may be the culprit.
  22. xc6lx45

    ARTY FPGA

    Hi, search for "XADC". Examples shouldn't be hard to find, it's a popular topic.
  23. Hi, generally I appreciate enthusiasm. But the amount of text you have written, including transistor-level SRAM cell schematics, seems grossly disproportionate to the actual length of Verilog code Seriously, you have not implemented a "controller". Not in any conventional meaning of the word. Now that's not very diplomatic of me. Still, I'm writing this in the spirit of constructive feedback. Harsh words, but then one of the worst things is people telling "you're doing great" when you are not. How should I start... Think of writing a "controller" as composing a symphony. It may be a long one or a short one, loud or quiet, a good one or a bad one but it's definitely not something I'd try in my first week at music school. Why, because it better be perfect. It's supposed to turn a complex device into a simple one, anticipate all the problems and make sure they don't happen. Example for "problems": your module implements combinational routing of address, outbound data and write-enable signal directly to the chip. The chip requires (datasheet, drawing page 14 and table page 12) that address and data are valid at least up to the deassertion of enable, or longer (very strictly, this is stated as t_ha/t_hd = 0 ns). For your "controller", the output timing is totally at the mercy of the driving signals. And it even gets worse: For the FPGA design tool "synchronous logic" world, only the level at an associated clock edge matters. What the signal does in-between is don't-care. Not being aware of this is a fundamental misconception of modern "synchronous logic", and suddenly straightforward and systematic engineering becomes black arts. Here is the long story. In your design, it means for example the write-enable signal may go "blip!" between clock cycles, courtesy of the outside circuitry. And this is totally OK for the design tools. But not so for the SRAM, which will randomly write garbage.
  24. Hi, this isn't specific to any particular card, but in the past there have been problems with HDMI reverse biasing. That is, a situation where it is unclear which device is allowed to supply voltage at what time.
  25. xc6lx45

    Noise on JB (Arty A7)

    Hi, have a look at the schematic, page 1: https://reference.digilentinc.com/_media/arty:arty_sch.pdf apparently, JA and JD do use 200 ohms resistors, but JB and JC don't. I suspect you're observing not "additive" noise (like, from a switching converter) but signal integrity issues, caused by the signal itself (say, reflections on a long, unterminated wire). There are several reasons why a series resistor will make it look better.