D@n

Members
  • Content Count

    2008
  • Joined

  • Last visited

  • Days Won

    141

Everything posted by D@n

  1. D@n

    Verilog Simulator

    @Ahmed Alfadhel, Don't put spaces between the "-" and "Wall", or between the "-" and the "cc" and you'll do better, Dan
  2. D@n

    Verilog Simulator

    @Ahmed Alfadhel, I put instructions together for that some time ago. Let me know if they need to be updated any. Dan
  3. D@n

    Verilog

    @Ahmed Alfadhel, Perhaps the most complete tutorial out there is asic-world's tutorial. You might also find it the most vacuous, since although it tells you all the details of the language it doesn't really give you the practice or the tools to move forward from there. There's also a litexsoc (IIRC) by enjoy-digital that I've heard about, but never looked into An alternative might be my own tutorial. Admittedly, it's only a beginner's tutorial. It'll only get you from blinky to a serial port with an attached FIFO. That said, it does go over a lot of FPGA Verilog design practice and principles. It also integrates learning how to use a simulator, in this case Verilator, and a formal verification tool, such as SymbiYosys, into your design process so that you can start learning how to build designs that work the first time they meet hardware. I'm also in the process of working to prepare an intermediate tutorial. For now, if you are interested, you'd need to find most of the information that would be in such a tutorial on my blog. (It's not all there ... yet, although there are articles on how to create AXI peripherals ..) Feel free to check it out. Let me know what you think, Dan
  4. @tombsj, There are open source processors and network stacks you can use if you would like. I currently maintain a build for my Nexys Video board that has a GbE controller, and I have another project with a bare working implementation of the IP stack--up to UDP only. There's also a liteeth project that you might find useful for communicating with the PHY, as well as an open source lwip project for handling the protocol stack. You might find these valuable. As for Xilinx's IP, someone tweeted a response to me today pointing out that "Competition works, alternatives are growing steadily (slowly) but happening." Dan
  5. @Izzy, Welcome to the forums! You might find me wandering around here. If you are new to FPGA design, then let me welcome you to the community. There are a lot of resources on-line that you can use to learn from. Digilent's got some really good material here, I've posted some of my own, asic-world and fpga4fun have some great stuff as well. Enjoy, and have fun. When you get stuck, there are a lot of folk here who might be willing to help. I tend to limit my help on the Verilog/RTL stuff, 'cause that's what I know and 'cause it's a lot of fun helping out--but like many others, I'm not Digilent. They're here too. Dan
  6. @Roberto_UDC, Fair enough, that's your call. I notice the core you referenced doesn't have a bus interface at all, nor does it necessarily have a command interface. That'll make some of this more interesting to work through, but so be it. Let's work through the startup commands. In my examples, I start up at a 400kHz clock. Then ... The first command that needs to be sent to the card is a command zero. CS should start out inactive (high), and go active (low) at the beginning of this command. This should put the card into SPI mode in the first place. (Incidentally, did you check the pin-outs? That should be checked first ...) The next command that needs to be sent to the card is CMD1. In the CMD1 you send, are you indicating a support for high capacity cards? (Data field = 32'h4000_0000 ?) Only then is the CMD 8 sent. In this case, you need to send an appropriate interface condition. I send 32'h01a5. Can you check what you are sending? We can also check CRC's if necessary, but I'd like to believe that the core you are using sets the CRC's properly ... (Perhaps not ...) Dan
  7. @Roberto_UDC, Are you aware that the SD-card needs to start at a slower clock speed, any only after its been configured you can switch to the 50MHz clock speed? I support a SPI based SD-card controller myself. You might find the instructions for that project valuable. Basically, the card requires quite the start-up sequence (discussed in the instruction manual) before you can start reading from or writing to it. If you are willing to use Verilog and the Verilator simulator, you'll also find an SD-card based emulator in the bench/cpp directory. I've used this quite successfully to get the SPI based SD controller working in the first place. The actual demo software code is kept in a different repository, which you are welcome to look through as well. Dan
  8. D@n

    CMOD A7 Programming w/o Vivado

    @rgc, I'll be curious what the Digilent staff has to offer when they chime in, but I know of three non-Digilent techniques you can use: You can always load a design into the flash on the board, and set the board up to load from flash. If you touch the boards at all before delivering them to your customers, then this would be my recommended first step. There's a libxsvf project you can use that can be used to load a design via JTAG There's an openocd project that I've had success using to load designs via JTAG. While I haven't tried it with any Xilinx-based designs, I would expect that such would work. If you can guarantee an initial design in your FPGA, then you can use the USB/USB port to communicate a new design to the FPGA if you'd like, and to have your design burn it in. This isn't quite as scary as it sounds, since you can keep two designs burned into your flash--one that it initially loads from, and another that replaces it only if it can do so successfully. This is an approach I have used often with great success, so feel free to ask me more about it if you would like. Dan
  9. @uzmeed, You might need to explain more of what you want to do here. MicroBlaze is a complete and working CPU. It already has an ALU within it. Further, since it's a closed source ALU, I think you will struggle to modify or add anything to it. Are you trying to create a bus-based peripheral that you can interact with from the MicroBlaze which will act as an ALU? I've seen instructors ask for this before. You know, something where you write to values to the "device" and then write an operation to the device, and when you read from it later it has the right answer? That I've seen. If that's what you want to do, then you'll probably want to read this article on how to build a working AXI-lite peripheral. (Xilinx's demo code is quite broken--so is Intel's.) I have another article that discusses what it takes to build an ALU in general--perhaps that would be of interest as well. Dan
  10. @aeon20, You do realize you are on Digilent's forums and that Digilent has nothing to do with that design other than making the board it was demonstrated on? Good. It looks like the module you are looking for is part of https://github.com/lowRISC/lowrisc-nexys4 and that it has been incorporated into lowRISC/lowrisc-fpga and hence lowRISC/lowrisc-chip by using git submodules, and so those projects are referenced within the design of the lowrisc-chip but not actually contained within the project. You'll need to do a git submodules init (don't trust me on the syntax) within the lowrisc-chip cloned repo to get these directories added into what you are looking for. Dan
  11. @Abuzar, You seem to have posted twice, and this post doesn't appear necessarily related to the post that started this thread. Therefore, for anyone interested in following, I've posted my response in this thread, and let me ask that you continue the discussion from there. Dan
  12. @Abuzar, Engineering works by breaking a problem into parts in order to narrow down where the problem is in the design. If you split your design into parts, and examine the data before and after each part, what's the first part that fails? And, similarly, how do you know that component is failing? Finally, let me point out that data format and scaling are critical issues to look at given the outputs you've just shown. Dan
  13. D@n

    Large Spectrum Generation

    @zygot It wasn't just that I could get at least 18 inches ... I never managed to demonstrate the ability to go any farther. I tried listening to the signal from the next room (my goal) but never managed to make it that far. Did I stay within the band? Probably not. I was "broadcasting" on 90MHz from an 80 MHz system clock with a half inch board (i.e. an extremely disadvantaged "antenna". Yours may have been better "matched") Did I disrupt anyone else? Not likely from a rural farmhouse. A larger board, with a higher clock rate might be able to do a lot better. Still not anything I would consider "professional" or even "sales worthy" for all the reasons you cite above. Still, it's a fun story, Dan
  14. D@n

    Large Spectrum Generation

    @FR, If you want really wide, throw out the hardware digitizer and use an OSERDES to create a 1-bit sample rate. Most of the 7-series FPGAs are capable of outputting up to 800Mbps. Treat this as your signal, and Voila! Be aware, however, the devil is in the details. The digital transmission lines on many boards aren't necessarily made for 100+MHz. You may suffer from some serious distortion and/or attenuation. It's probably good enough for some hobby type work, but certainly not anything I'd try to sell to a customer. That said, I was able to use this approach to "broadcast" to a near-by FM radio using a XuLA2LX45. The FM code is still posted. It's actually pretty simple. In that case, the output signal was generated at the system clock speed (80MHz), and if I ganged all of the spare I/O's together I was able to transmit for about 18 inches or so. With a proper antenna, and some higher I/O speeds, I should have better luck. Dan
  15. @ManserDimor, You'll need something that is voltage agile if you want to do LVDS. Most of the I/O on Digilent boards is fixed at 3.3V, so check your reference manual and your schematic to make sure that you can use the voltages available to you. Dan
  16. @Takemasa Tamanuki, I'm going to have to second much of what @zygot just said. But let me go a bit further, and give you some rope to hang yourself with: here's a discussion of an SPI design used to control a flash chip. Yes, it comes with source code. My guess is that you'll decide this doesn't do the job--especially since I've built multiple SPI controllers and none of the others look like this one. As @zygot suggested, this is really a "tailed-to-device" operation. Still, perhaps it might help you consider all of what it takes to design an interface, and so I offer the link above. Dan
  17. Is this an IP core you have found somewhere? If so, it should come with instructions. Is this one you have built? Then you should have an idea of how to set it up after building and testing it. The answer also depends upon your environment. Will this UART be used from a CPU/processor of some type? Then you will need to connect it to a bus. Bus interconnects and standards vary from one processor implementation to another. Xilinx tends to use AXI or AXI-lite to connect their components. I personally prefer Wishbone (WB) for its simplicity. If your UART is not going to be accessed from a CPU, then the sky's the limit--how do you want to set it up? Dan
  18. @PaulW, You might want to dig into the I2C protocol a bit more--tri-states are required on both SCL and SDA lines. The protocol is supposed to be a shared protocol between both multiple slaves and multiple masters. You should only ever drive those lines either tri-state or low, never-high--much like you are doing for SDA above. They're also supposed to be pulled high by the circuit board itself if nothing is using them. It is valid and possible for the slave to pull the SCL line low, in what's called "clock stretching." If it helps, you can find my own I2C controller(s) here. You'll find both a master and a slave controller there, both with WB interfaces. (You can find an AXI-lite to WB converter here, if you need it.) Using them, though, requires placing two tri-state assignments in your top-level file, like these. Finally, I ran into some trouble myself working with I2C and a monitor some time back. One problem I experienced was that reloading my design did not (necessarily) reset a broken I2C connection with another device. I still needed to send a STOP condition--particularly if I hadn't stopped it with a prior (broken) design. While the bus probably should have timeouts in its definition, implementing them is (IIUC) a violation of the protocol. Dan
  19. @solonfw, My first question would be whether or not you can measure the I2C SCL line internal to the FPGA at 1 or 0 vs using a voltmeter/scope external to the FPGA. Why? Because the first I'd be tempted to check is whether or not the XDC file was set up properly. Dan
  20. @chaitusvk, Here's my puzzle --- while I see several (common) bugs in your core (Vivado's AXI-lite demo core has known bugs in it), bugs I'd like to discuss and share, I haven't yet found the bug causing the problem. Let's try this ... set reg_data_out = -1 (independent of the axi_araddr), and let's just verify that you can read from your core in the first place. I'm suspecting a couple of things, one possibility being that Vivado hasn't noticed you update the design with the adder, and so it's still building the older design. (I think "run design automatiion" might help there ...) Anotherr possibility is that you are accessing your core via the wrong address. If you can set an LED from the core on any write (if (S_AXI_AWVALID && S_AXI_WVALID) led <= !led;) that would also help determine the same thing. Dan
  21. @chaitusvk, Try reading back your adder inputs after writing them. xil_printf("Inputs to adder: %08x\n", Xil_In32(XPAR_MYIP_ADDER_0_S00_AXI_BASEADDR)); What do you get there? Dan
  22. @chaitusvk, No, I got that much. What values are you adding that are giving you the wrong answer? When you add 1+1, you should get two, right? When you add 7+7 you should get 14, right? When you add 3+1 you should get 4. Are you getting these answers? Similarly when you add 0x53 + 1 you should get 84. Is this the result you are getting? Dan
  23. @chaitusvk, You haven't said what your problem was. What is it your design does that makes you believe it doesn't work? Dan
  24. D@n

    Basys 3 implemented design

    @Chirag, I currently only have one digital design tutorial. (Digilent has more.) It does not go into "how and why to use the (Xilinx) primitives". The problem with using the Xilinx primitives (if you don't need them) is that it renders your logic specific to a Xilinx device, so if you ever switch to either a Lattice, Intel, or an ASIC design flow, or even an open source simulator, you'd need to start over with a new set of primitives. The more you can do without them--the better. That said, I do use vendor specific IO primitives--especially when I need high speed I/Os. As for enabling DSPs in your design, I'd recommend using a programming construct (from Verilog) that looks like: always @(posedge clk) if (enable) result <= ina * inb; Anything more than this may not necessarily map to a DSP. I'd also strongly discourage you from directly instantiating the DSP primitive: the interface isn't necessarily obvious, and the number of options are ... too numerous and confusing (IMHO). If you can instantiate the DSP by a simple statement, like the one above, your code will be easier to read and it will likely work with other tool chains as well. Dan
  25. D@n

    Basys 3 implemented design

    @Chirag, What you are looking at is an image of the underlying silicon die within the chip, showing the layout of the various parts physically. The six big squares are clock regions IIRC. You can save some power and some wires if you can restrict a clock to a given region. That said, I tend to run all my designs with one giant system clock, so this hasn't helped me much. In your example above, the LUTs being used are in the middle row and colored light blue. There's more there than just LUTs, but that's where the LUTs are. What more is there? I can't be certain, but examples might be memory and DSP slices. If you zoom in on this area you'll see sub-pictures showing four LUTs to a slice, the FFs in the slice, and possibly the various mux-7 and mux-8 components as well. (It's been a while since I've done so) The I/O banks are all on the edges of the design. You can use them via the various IBUF, OBUF, IOBUF, IDDR, ODDR, ISERDESE, OSERDESE, etc. primitives. A wire going to or from an I/O port will naturally use one of these, or they can be manually instantiated as well for more control of what takes place. Yes, you can change cell locations manually, but knowing what you are doing enough to be successful doing so can be a real challenge. I know some folks who have hand placed their designs to great effect. I also know of at least one open source project to do the same. Indeed, at one time I tried to build a placer to map logic to FPGA elements--my efforts didn't work out so well. That said, I know my own limits and don't try to move components around myself. Dan