D@n

Members
  • Content count

    1640
  • Joined

  • Last visited

  • Days Won

    120

Everything posted by D@n

  1. D@n

    Median filter verilog

    Sounds like a lot of fun! Feel free to draft something and try it! Don't touch the FPGA at first--try it in something like Verilator, iverilog, or even ghdl--it's faster than Vivado, and you only need a little bit of work with it. (My favorite approach is Verilator ...) If you want some filtering examples, feel free to browse zipcpu/dsp. In particular, you'll find a test bench article that discusses a generic filtering interface you might find useful to get you started in your quest. For bonus points, try formally verifying it. All of this can be done without Vivado and without any hardware. Once you are successful, then come to Vivado with your working component and see if you can fit it into the rest of the design and device you are working with. Good luck, and feel free to come back here with questions! Dan
  2. D@n

    Designated Numbers Moore FSM with 4 bit counter

    @jygcm, The trick is to separate the problem. You should have at least three parts: The first part is a module that does nothing but display the value given to it. Since there are 7-segments in each 7-segment display, this piece should take 7-bit inputs (8 w/ the decimal point) and display exactly the selected LEDs and no more. There's no requirement at this first part to make them valid digits--they just need to be the arbitrary configurations you require. The next step is to convert a 4-bit hexadecimal number to its associated 7-bit representation, which will then feed the part you just got working above. The third step is to implement the counters you are talking about. And, oh by the way, by the time you have #1 working above, you'll know how to do this part. Let me ask another question, though: how are you planning on simulating this and testing that your code works? Without proper preparation before going to the FPGA, you'll quickly find yourself with a design that doesn't work and no idea why not. I call this FPGA Hell. You should at least start thinking about this problem now. Dan
  3. D@n

    Designated Numbers Moore FSM with 4 bit counter

    Perhaps you might find this article worthwhile. It shows a VHDL example of how to drive the 7-segment display. Dan
  4. D@n

    Verilog coding format used by ZipCPU.

    @imc_user1, You found the C16 on open cores? Nice! Did you check out the os_book.pdf in that repository? I loved it--it's worth a read. Dan
  5. D@n

    Designated Numbers Moore FSM with 4 bit counter

    @jygcm, You can put a case statement within an if statement, yes. Which logic should use the above format? Anything that depends upon a clock, but which you want to change at a rate slower than your clock rate. Since you have chosen a two process state machine implementation, only the clocked process of the two processes needs to fit this format. The seven segment output is where you are going to have some trouble. To be successful with that, you need to rotate through which segment you send current to. Digilent recommends a rotation scheme of about 1ms. Hence, for that to work, you'd need another ce-type signal to control the logic within that portion of your design. So (sadly) that process is likely going to need to be rewritten. While it might work as is, I'm betting that the 7-segment display has more digits than just the one. Dan
  6. D@n

    Designated Numbers Moore FSM with 4 bit counter

    @jygcm, One of the common beginner mistakes is to create a clock using the logic of the board instead. Since the PLL's won't support a 1Hz clock, this is the only way to make a 1Hz clock. It's also severely flawed. Don't do it. In this case, you have to switch from your 1Hz clock counter to a much faster clock to get your seven segment display working. This will create a "clock domain crossing" (CDC) that you may find difficult to deal with properly. The problem with unmitigated CDC's is that the logic on the other side might not act properly. Worse, it will often act properly in simulation, but then fail in hardware. This will leave you scratching your head and wondering what went wrong. My recommendation for beginners is that they only ever use the system clock. To do this, you'll often want to create a clock enable signal that will be true for one clock per second--such enable signals are only ever one clock wide or this won't work. Inside your clocked logic, you should then have something like: process(clk) begin if (rising_edge(clk)) then if (i_ce) then ----- this is the enable signal --- --- Your logic would go here --- end if; end if; end process; I discuss generating such enable signals in this post from some time ago. Dan P.S. I only just learned VHDL in the last two weeks or so, after having used Verilog for years.
  7. D@n

    Verilog coding format used by ZipCPU.

    @imc_user1, Looks like i missed this post yesterday, sorry about that. Yes, as @zygot points out, I am the author and maintainer of both the ZipCPU and the ZipCPU blog. You can also find me on twitter and several freenode IRC channels. The hardware style you describe of using something before declaring it is something I would consider to be a bug and not a feature. Apparently it isn't something my tools are picking up. If you see this in my code, please create a github issue and I'd be glad to work with you to help get it fixed. As for simulators, I have only ever used Verilator for simulation. I haven't tried simulating the ZipCPU with Vivado's simulator. I like to have a simulation I can interact with--one where the serial port acts like a serial port (i.e. I telnet into my simulations), SD cards read from a valid SD card image, VGA or other video outputs display within a window on my screen, and where I can load and debug the CPU just like I would on the actual hardware. I find I can do this easily using Verilator. There's another interface that can be used for this purpose as well, (I think it's called VPI?), I've just never tried it and so have no background in it. In other words, if you want to simulate the ZipCPU using a Verilog based test bench, you will have some work to get it up and running. The most recent changes to the ZipCPU source right are in the formal branch. I haven't merged them into dev (yet), although I'm working on doing so. Basically, I've been working on formally verifying the entire CPU. In the process, I've come across an amazing number of bugs that I had previously missed in simulation. Once I verify that these bug fixes work in simulation, I'll move them into the dev branch. Once I verify that they work on my hardware, I'll move them into the master branch. Or, at least, that's my plan. We'll see what happens. Finally, if you want to build a GCC back end for your instruction set, there is a wonderful GCC internals document describing what it takes to do that. You can find that here. You will find the particular chapters on the RTL representation, machine description, and target description macros and functions the most useful. (I'm not sure if I read any more than those.) When I first started, I was given a patchset for getting GCC running on the ECO32. It was so valuable to me, teaching me how to set up my port and more, that I currently maintain the ZipCPU's GCC backend as a patch on top of the GCC 6.2 release. As for @zygot's comments on whether or not there is ever a need for a CPU within an FPGA, let me invite you to join that discussion here. A short summary would be that CPU's within FPGA's are not universally a good idea, but there are some significant and specific times and places where they make sense. Dan
  8. D@n

    Theory of pipelining/paralellism

    @Tickstart, You might find these articles valuable: Explaining clocks to software engineers Strategies for pipelining logic An explanation of the ZipCPU's pipelining strategy All go into the basics of how do you handle the signaling associated with a pipeline. Specifically, if the pipeline doesn't always operate at every clock, or if a future pipeline stage might be required to "stall" the whole pipeline. Dan
  9. D@n

    OLED on Verilog

    @Barakuda, Check out the Verilog projects at the bottom of the OLED reference page. I think you'll find what you are looking for there. Dan
  10. D@n

    OLED on Verilog

    Do you have the SPI-based Verilog in place for issuing commands to the OLED in the first place? Can you get the OLED up and running already, and so just need to know how to handle this final step? Dan
  11. D@n

    UART

    Hi @Gaurav_Mane, welcome to the forums! I usually teach building a UART in stages Stage one: Blinky. You've got to be able to turn on the LED's and turn them off at will. You also need to be able to make them blink at a rate that you can "see" it. These will help you debug your serial port. Stage two: make sure you have the pins right. No matter how often I've built UART components, I consistently find schematics that label the serial port from the point of view of the "other" chip. As the UART is set up, the lines are supposed to idle in the "high" (1'b1, or 3.3V) condition. If you set up your blinky program so that the LED stays high for half a second following any time a UART wire goes low, you should be able to identify which wire is coming from the PC to your FPGA. Don't forget to turn off hardware flow control in your terminal program. Make sure that by the time you are done you are sending the inputs into a two flip-flop synchronizer. Stage three: The wire that isn't coming from the PC should be going to the PC. At this point you should know the wires and have them set properly in your UCF file. The next step is harder, and involves getting your logic just right. For this step, I would recommend getting your logic working with a UART simulator before trying to place it on your board. For more details, feel free to check out this article. Dan
  12. D@n

    Pmod GPS: NMEA message corrupted at high baud rates

    @alexandre.willeme, The problem at this point is that you cannot tell where the problem is occurring. There are many places where this problem might reside, and it's hard to say which one is the culprit. Therefore my suggestion would be to try to get a trace from the serial port to see where the error lies. In particular, I'd want to run a logic analyzer internal to the FPGA capturing 1) the incoming UART pin, and 2) the decoded characters from the PmodGPS, and I'd want this analyzer to continuously capture until your software detects a bug. Such a trace would tell you whether the problem exists in the line from the PModGPS, the UART decoder, or your software processing. @Notarobot's suggestion above is getting at the same issue--trying to isolate what part of the design is producing the fault. Dan P.S. I got a thorough chuckle from @Notarobot's third point: "... I am sure that correcting errors due to incompatible data rate would never pass the critical design review in the industry." Well said!
  13. D@n

    Make the system clock external

    @Billel, To add to what @dpaul said, the reason why you are getting a constant "1" output is because you are setting the clock on every positive edge. If you want to output a clock, Xilinx recommends using the ODDR module. I've tried it often, and it works quite well. Using the clock, set the output to '1' on the rising edge, and '0' on the negative edge. Dan
  14. D@n

    artix-7

    @sesharao, Digilent sells many Artix-7 boards. I personally own the Basys3, the Arty (now called Arty A7), and a Nexys Video board. There's also the Nexys DDR board and the CMod A7. All of these are Artix-7 boards, but all with some drastic size differences. Are you asking about the Arty A7 board? Dan
  15. D@n

    BASYS3 programming...

    @NIcko, The Basys3 board is programmed over USB. You do not need a JTAG or any other type of cable to program your Basys3 board. Although ... I've done most of my Basys3 programming using a USB stick, so that's an option as well. Dan
  16. D@n

    Pmod GPS: NMEA message corrupted at high baud rates

    @alexandre.willeme, Is there any possibility you are overrunning your buffer by not reading from the GPS NMEA stream often enough? Dan
  17. @attila, Thank you, but that wasn't quite my question. My question was whether or not the FFT's were overlapped by 50% from one FFT to the next. Dan
  18. @Hiroki Tamakoshi, They say you should never do math in public. Let me try my hand: 0.1Hz resolution with 100Hz bandwidth means 1000 bins total, or 2k real input points. At a 200Hz Nyquist frequency (you can't go lower and still get 100Hz of bandwidth), it will take you 10 seconds to collect all of those inputs before any FFT processing. With proper Nyquist sampling in the time-frequency domain, that should give you an update every 5 seconds. (You are doing a 50% FFT overlap, right? @attila?) Can you do better? You could increase your FFT overlap rate, perhaps as high as 87% or so. This will give you more updates. You could also switch from an FFT algorithm to a series of block average algorithms. This has a lot of promise, but I think I've only ever found one application (GPS) where the approach was better than an FFT. Depending upon the signal you are looking for, there are signal selective algorithms that can sometimes work better. For example, if you assume you have a single sine wave in your input, you can often get very good resolution of that sine wave's frequency without needing to do a very fine resolution FFT--sometimes without even needing to do all of the FFT. Sometimes a PLL can be used to get frequency resolution of a single tone. If you just want frequency resolution of a single tone, my favorite method is to interpolate the FFT outputs--but that's probably a longer discussion. On the other hand, if you could accept 2 Hz resolution instead of 0.1 Hz resolution, and interpolate the points in the middle--the result would work nicely if there was only ever one tone in every 4-5 bins or so. So, there are other techniques. The reality is .... in the generic case they really don't give you any better time resolution. A good interpolator applied to the FFT outputs will give you most of what you are missing between FFT's--assuming a minimum of 50% overlap in time initially. If it's a real quality high-resolution time-frequency representation you are interested in, you should know that there is an uncertainty principle stating that your time resolution times your frequency resolution will always be greater than a fixed number. (I think it's 1/2) The Hanning window gets close to this number, although it's rather sloppy in frequency. Other filters exist, although less common and not nearly so well known, that can do better in frequency at the expense of time resolution. Perhaps you would like to share your application to see if there's an application specific approach that might meet your needs? Dan
  19. D@n

    nexys video memories

    @sosso, While the flash can be written, writing to it tends to be very slow. As a result, it works better as a ROM than a RAM. Further, the flash is still much slower than the DDR3 SDRAM. The DDR3 SDRAM is a large, full size, RAM for ... whatever purpose you would like to use a *large* RAM for. It's slower than the block RAM within the FPGA, but it's also much larger than any block RAM within the FPGA. On my Nexys Video, I'm intending to use the RAM to support a video frame buffer. Dan
  20. D@n

    nexys video memories

    @sosso, You are essentially correct. I think there are three additional flash memories on the board, but they are small and not nearly as easy to use. The cache you mention above, though, isn't an "external" memory--that's all within the FPGA. Dan
  21. D@n

    Pmod OLED rgb

    @YogaDog, At the physical level, it's a basic SPI connector. That's what the Verilog file I shared handles. At the next level up, there's a very complicated protocol associated with the OLEDrgb. To get it started, there's a careful bit of timing that has to be done properly via the reset wire and power wires, together sequence of commends you need to send to it. This was the purpose of the software. You could replace this with a state machine if you wanted, but I don't have an example of that to show you. Dan
  22. D@n

    Pmod OLED rgb

    @YogaDog, You'll have some work to do in order to do it. The Verilog file needs to be driven by a Wishbone bus master. That's why the CPU software is so important. If you wanted to, and you had a spare UART, you could use this design to create a wishbone master that would be controlled from the serial port ... but even then, you'd still have to 1) connect it to the wishbone interconnect, and 2) send the values to start it up from your host computer. You might find this simulation model more valuable. When using Verilator on a gtkmm enabled machine, you can then use it to "see" what should be on the OLEDrgb in an on-screen window. Dan
  23. D@n

    Pmod OLED rgb

    Have you seen the Verilog code I wrote for driving the OLEDrgb? You can find a C program to control that code here as well. This code uses a fixed brightness setting, but you should be able to play around with it if you would like from that point. Are you at the point yet where your OLEDrgb driver works? Dan
  24. Have you debounced the buttons yet? or were they switches? (I can't remember ...) Dan
  25. D@n

    Pmod OLED rgb

    What's the difficulty? Dan