• Content Count

  • Joined

  • Last visited

Everything posted by hamster

  1. A reasonable sized FPGA should be able to absorb your CPU designs and the Nexys Video is a pretty capable board. Is there any chance of including a "show_utilization -hierarchical" where we can review things? My feeling is that with a bit of though a lot of FFs and LUTRAMs could be revised to use more efficient, denser resources. Have you done much reading of the 7-series user guides, and the style guides that help you to write code that infer the most effective resources?
  2. Because I am quite happy to use a whole block of RAM rather than debugging indexing and sign-flipping code... It's actually one full cycle (half positive, half negative). It is jsut a column from a Google docs spreadsheet https://docs.google.com/spreadsheets/d/13srKHRNCD2dfbMglMvvCUESHR23kHWlzAJ24MJ_erzc/edit?usp=sharing I could have also got away with just one quadrant, but then it would be more 'active' code on what I'm not interested in playing with
  3. I can't see the latching issues, but agree that if the +/-2048 was a separate signal, then the code could be simplified quite a bit... however, the optimizer should be doing that at the moment. "Premature optimization is the root of all evil" and so on. One other finer point. As currently written +full scale value will generate a stream of all ones output but a -full scale won't generate all zero outputs, but a zero value gives a perfect 50:50 mix of ones and zeros. Others might need it that -full scale gives all zeros, and +full scale gives all ones, but a zero value will give sligh
  4. @Dan, I managed to find the 'average' option rather than 'decimate' which has stopped high frequency noise showing up in the spectrums, giving a more reasonable noise floor.
  5. BASYS3 + PMOD Breadboard + Analog Discovery 2. It was just a hack, so the table was a quick formula in a spreadsheet, yes, I assume the + and - sides are both rounding towards zero causing some asymmetry, but with 11 significant bits that should be somewherere about -60dB at a guess. Most of the noise is just the shoddy physical implementation. Flying wires on a breadboard, on PMODs, just the shielded wires on the AD2 and so on. If I leave a wire hanging around it will pick up most the noise too, maybe 6dB lower than on the channel that is under measurement. This was just a qu
  6. I played around with a 1st and 2nd order 12-bit Sigma Delta DAC implemented on the FPGA. I found the results quite interesting, as the change is pretty simple to implement and the change to the noise on the output spectrum is quite significant, with lowered 2nd harmonic and a much smother noise floor. VHDL code is on GitHub at https://github.com/hamsternz/second_order_sigma_delta
  7. I think of std_logic_vector the same way I would think of digits in a number... the rightmost digit is digit zero. It most likely isn't the best way set things up for this example, but it avoids the need to swap the bit ordering in the ASCII characters. Oh, for the button synchronization... signals take time to get across the chip (speed of light, capacitance and so on), so different parts of the design can see different values for the same signal as it change unless. As you can't control when the user might press the button you have to sample the value of the input signal on the clock
  8. Had a hack at it... tested working on BASYS3 library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; entity msg_repeater is Port ( clk : in STD_LOGIC; btn : in STD_LOGIC; tx : out STD_LOGIC; led : out STD_LOGIC_VECTOR (3 DOWNTO 0)); end msg_repeater; architecture Behavioral of msg_repeater is constant char_t : std_logic_vector (7 downto 0) := "01010100"; constant char_e : std_logic_vector (7 downto 0) := "01000101"; constant char_s : std_logic_vector (7 downto 0) := "01010011"; constant char_space : std_
  9. Away from my laptop at the moment, but they way I would do this: A register sized to hold your clock rate (28 bits for 100MHz). If it is less than the baud_rate, set 'bit_tick' to '1' and add (clock_rate- baud_rate) to the register. Otherwise set baud_tick to '0' and subtract the baud rate from the register. That will give you 'bit_tick' that is 1 for the right number of cycles per second, and allow you to keep everything in the design running in the same clock domain. You also want to have a synchronizer on your button, to make it work reliably. You also have a pr
  10. hamster

    Basys 3 clock question

    IC9 is the 100MHz oscillator. It is on the bottom, just to the right of center. See the bottom left of page 5 of the schematics (on the resources page). Part code is DSC1033CC1-100.0000T
  11. You need a top level module, that describes all the signals that are connected to your FPGA. It will then contain all you synthesiable VHDL components that make up your design, and describes how they are connected to the each other and the outside world.
  12. Ok - here's how to drive the seven segments, from 1000 feet up. You need to have the constraints for the segments and the anodes for the display. See the board's reference manual and master UCF file for them. ##7 segment display #set_property -dict { PACKAGE_PIN T10 IOSTANDARD LVCMOS33 } [get_ports { CA }]; #IO_L24N_T3_A00_D16_14 Sch=ca #set_property -dict { PACKAGE_PIN R10 IOSTANDARD LVCMOS33 } [get_ports { CB }]; #IO_25_14 Sch=cb #set_property -dict { PACKAGE_PIN K16 IOSTANDARD LVCMOS33 } [get_ports { CC }]; #IO_25_15 Sch=cc #set_property -dict { PACKAGE_PIN K13 IOSTANDARD L
  13. Oh, here is a paper that might provide some insight... have a search for "Efficient FPGA Implementation of the RC4 Stream Cipher using Block RAM and Pipelining filetype:pdf" (The URL was too long to post here).
  14. Hi! RC4 was designed so that it doesn't map well to dedicated hardware, but uses only a small amount of compute power so it can be implemented on all but the tiniest microcontrollers, so implementing it in an FPGA is a great learning experience of what software problems are hard in hardware, and why. I looked into implementing RC4 a long while ago, and decided that a high performance implementation is pretty much impossible (where high performance is greater than one byte encoded/decoded per cycle). I've had a look at your code, and it looks like you are writing only for simulat
  15. On this topic I've been making an audio DSP board using the CMOD A7, where additional noise is a real pain. My initial prototype board had some audio noise problems - I couldn't hear it but I could measure it. I initally thought was due to the CMOD-A7 and could not be fixed, but eventually put down to quite a few different causes: - I had nearly shorted the output of one of the DAC to GND, which as causing spikes on the power rail. Once fixed things were a lot better, but not perfect/ - I had not made any real attempt to stitch the top fill to the ground plain on the bottom - a
  16. The last of the parts came in and the new board is up and running. Here's the old and new boards side by side, and spectrum of a 10kHz test tone going from the ADC, through the FPGA and then DAC (top = new board, middle = old board, bottom = no board in the loop. The additional work I did on grounding on the PCB has paid off, with a very good noise floor - better than I can measure with the tools I have to hand.
  17. I just had a look at the J1b source, and saw something of interest (well, at least to weird old me): 4'b1001: _st0 = st1 >> st0[3:0]; .... 4'b1101: _st0 = st1 << st0[3:0]; A 32-bit shifter takes two and a half levels of 4-input, -2 select MUXs per input bit PER DIRECTION (left or right) and the final selection between the two takes another half a LUT, so about 160 LUTs in total (which agrees with the numbers above) However, if you optionally reverse the order of bits going in, and then also reverse them going out of the shifter, then the same shi
  18. The toolchain is pretty simple to build but takes a while - for me it was just clone https://github.com/riscv/riscv-gnu-toolchain, make /opt/riscv (and change ownership), then run './configure' with the correct options, then 'make'. There are a whole lot of different Instruction set options and ABIs, so I definitely recommend building from source rather than downloading prebuild images. At the moment I haven't included any of the stdlib or soft floating point. I'll add that to the "todo someday" list.
  19. I've just posted my holiday project to Github - Rudi-RV32I - https://github.com/hamsternz/Rudi-RV32I It is a 32-bit CPU, memory and peripherals for a simple RISC-V microcontroller-sized system for use in an FPGA. A very compact implementation and can use under 750 LUTs and as little as two block RAMs - < 10% of an Artix-7 15T. All instructions can run in a single cycle, at around 50MHz to 75MHz. Actual performance currently depends on the complexity of system bus. It has full support for the RISC-V RV32I instructions, and has supporting files that allow you to use the R
  20. Clip the oscilloscope ground lead to the probe tip, and wave it near the board.. Tell us what you see...
  21. WAV files are the simplest to work with. 1. The WAV file have s small header on it, then they are all raw sample data, usually stereo pairs of 16-bit signed numbers. Just write a small program in your favorite scripting language to print out data after about 64 bytes. 2. For phone-quality audio, you need bandwidth of 300Hz to 3kHz. - this needs around 8000 samples per second, and about 8-bit sample depth . You could use some u-law or a-law compression to increase dynamic range (https://en.wikipedia.org/wiki/Μ-law_algorithm) 3. - 8 kilobyes per second, if you play raw 8-bit samp
  22. The "DC and Switching characteristics" tells you the delays in the primatives, but can't tell you the routing delays. The only way to truly know it to build the design in Vivado, and then look at the timing report. Inference of DSP blocks and features is pretty good as long as your design is structured to map onto the DSP slices. There are little gotchas like not attempting to reset registers in the DSP slice that don't support it. Skim reading the DSP48 User Guide will pay off many times over in time saved from not having to redesign stuff over and over to help it map to the hardwa
  23. My views - if you want to learn low-level stuff (eg. VHDL/Verilog coding), buy a board with lots of buttons, LEDs, switches and different I/O over a more application specific development board. I think think that the Basys3 is pretty good for this and better than the Arty. Once you have sharpened your skills, then look for a board that will support your projects. If you want to initially work at a systems level, using IP blocks and so on, then look for a board that has interfaces that supports your area of interest. Debugging H/W when you are also debugging FPGA designs is no fun. A Zynq
  24. hamster

    Dividing in Verilog.

    It may well do, but not knowing *all* the details of what you are doing means I can't offer you useful advice.