D@n

Members
  • Content Count

    1832
  • Joined

  • Last visited

  • Days Won

    130

D@n last won the day on April 29

D@n had the most liked content!

About D@n

  • Rank
    Prolific Poster

Contact Methods

  • Website URL
    http://zipcpu.com

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. @herve, There's an option for Vivado to create a ".bin" file. Copy this directly to your flash device, starting with the first byte (unless you use warmboot, etc.), and you should be there. Don't forget that you might also need to adjust the configuration load options as well. Dan
  2. @aadgl, I don't really have any tutorials on how to do this, but I do have an example including some documentation on how to set up the example. Using the example, I can access the memory from a Wishbone bus. The basic operation is: (some wishbone master, either CPU, DMA, or whatever) -> (WB to AXI bridge) -> (MIG controller with an AXI front end) -> external memory pins. You can find this project here, and its documentation here. Dan
  3. @longboard, Yeah, that's really confusing isn't it? At issue is the fact that many of these chips are specified in Mega BITS not BYTES. So the 1Gib is mean to refer to a one gigabit memory, which is also a 128 megabyte memory. That's what the parentheses are trying to tell you. Where this becomes a real problem is that I've always learned that a MiB is a reference to a million bytes, 10^6 bytes, rather than a mega byte, or 2^20 bytes. The proper acronyms, IMHO, should be Gb, GB, Mb, and MB rather than GiB or MiB which are entirely misleading. As for the memory, listed as 16 Meg x 8 x 8, that's a reference to 8-banks of 16-mega words or memory, where each word is 8-bits wide. In other words, the memory has 16MB*8 or 128MB of storage. You could alternatively say it had 1Gb of memory, which would be the same thing, but this is often confused with 1GB of memory--hence the desire for the parentheses again. Dan
  4. Combinatorial logic shouldn't depend on the clock, and certainly not on the edge of a clock. My advice would be to put all references to rising edges specifically into your processes. Dan
  5. I'm really not the VHDL designer that others are, but this particular statement caught my attention: controller_was_in_use <= controller_in_use when rising_edge(clk); That ... just doesn't look right. The rising edge of the clock is an instant in time. This is a continuous assignment. Were I the synthesis tool, I'd be tempted to simplify this to 0. Dan
  6. As I recall, you are stuck with the 4:1 mode. That puts your system clock rate somewhere between 80 and 83MHz. The best choice you have for a system clock frequency that will support (naturally and natively) a 1MBaud UART would be 80MHz. On the other hand, UARTs--even at 1MBaud--are slow. You could easily use a second clock with your UART, and use a proper clock domain crossing to get just about any frequency. Dan
  7. @jrosengarden, Looks to me like your 4b carry nibble is inverted from what it needs to be. That's all. Dan
  8. You missed a change. Check out the line: addsub_4bit nibble1(carry[2], s[7:4], a[7:4], b[7:4], carry[1]^op, op); Dan
  9. @jrosengarden, Ok, I think I found your bug. Your carry bits are messed up. In the case of the 4-bit, you want to XOR the operation (not cin) with the carry to get the four bit add/subtract to pass. That will then properly subtract two 4-bit numbers, but it will also leave the carry wrong for the 8-bit adder. To make the 8-bit add/sub work, you'll need to invert carry[1] at the 8b level as well.. See the attached, Dan jrosengarden.tgz
  10. @jrosengarden, Can you tell me how the 4-bit subtract is supposed to work? Specifically, what is the carry supposed to do? Are you trying to calculate (A-B-carry), or (A-B+carry), or ... I'm not sure. I'm currently looking at A=8, B=0, and seeing some results I don't get either. Dan
  11. @jrosengarden, Ok, I found the bug in my proof -- I did "read_verilog file.v" instead of "read_verilog -formal file.v" ... now I'm getting failures on the 4-bit adder. Tell me, what should the response of the 4-bit adder be if A=0, B=4'hE, and cin=1? I'm getting an answer of 4'hF with a carry. Dan
  12. @jrosengarden, Which simulator are you using, and what does your test bench look like? Dan
  13. @jrosengarden, Tell me more. How is it "not" working? It could be associated with how you've set the design up ... Dan
  14. @jrosengarden, I just ran your design through a quick formal analysis. It works. Feel free to try out SymbiYosys yourself. You can read my Verilog tutorial, which includes the basics of how to formally verify a design, on the ZipCPU blog if you'd like. I'm also attaching the files I used for the proof, so you can take a look at what I verified. Dan jrosengarden.tgz
  15. @aabbas02, What's the data rate of the filter compared to the number of taps? As in, are you going to need to accept one sample per clock into this filter, or will you have reliable idle clock periods to work with? I'm wondering, if you have to build this, how easy/hard it might be. Dan