• Content count

  • Joined

  • Last visited

  • Days Won


D@n last won the day on May 28

D@n had the most liked content!

About D@n

  • Rank
    Prolific Poster

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  • Interests
    Building a resource efficient CPU, the ZipCPU!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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


    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


    @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