alvieboy

Members
  • Content count

    830
  • Joined

  • Last visited

  • Days Won

    17

Everything posted by alvieboy

  1. Good work Alvie
  2. You're the man, Markus
  3. AFAIK the diodes are just for protection [to make sure we don't kill the VGA monitor], and the caps (which should only be a few pF) are part of a low-pass [although HF] filter. Jack should have more details. You can perfectly live without them, though. Alvie
  4. I have an implementation for it. let me know if I should publish it (I think it's on an non-published ZPUino branch) Alvie
  5. To be more precise, the FPGA boots the initial ZPUino from SPI flash [FPGA design], it starts, waits for 1 second for serial/usb commands and then loads the user code from SPI flash and executes it. Alvie
  6. Not that I know of. It should work flawlessly out of the box. Note that often "writing" is disabled, to save code space. What issues are you encountering ? Only write not working? Alvie
  7. No, I never used Microblaze at all. I find the architecture (most notably the function preambles/postambles for C ABI) a bit awkward. And it's commercial Alvie
  8. I believe we also have the generic VGA working on DUO for those resolutions. Alvaro
  9. It should be fixed by now, I think.
  10. We have such an implementation using the SDRAM. If I recall well, it works OK at 640x480x8bit. Ideally you should get a memory which is almost 3 times as fast as the fastest datastream you need (read or write). You will also need to arbiter between the read and write requests, and probably will need a read FIFO to account for the jitter of the arbiter (we do exactly that). You may want to take a look here: https://github.com/alvieboy/ZPUino-HDL/blob/master/zpu/hdl/zpuino/devices/video/vga_generic.vhd Alvaro
  11. Indeed. However, we have two FPGA designs. The master designs always loads first, and can set those registers so that when the second (user) design loads, it is already set up. Not sure. I actually think we will not be able to use the method cause PC will always drive DP/DM signals... still to understand and test. I think the idea was to force an USB reset, and that will force DP/DN to go low (Single-Ended zero). May work, may not work... Alvie
  12. Btw, here's the USB wishbone controller: https://github.com/alvieboy/ZPUino-HDL/blob/master/zpu/hdl/zpuino/contrib/usb/usbctrl.vhd
  13. Any expertise is welcomed What we have put to work so far (with a PPro and my USB wing) packs a simple USB transceiver, so all PHY-related stuff is actually inside the FPGA. This works well for full-speed (12Mbps) and we have a quite generic USB interface for it, with support for most useful endpoint types, but not all (isochronous is not supported). The internal design we have uses also ULPI, so should be fairly simple (never that simple, is it?) to use USB3300 or other ULPI/UTMI chip. But USB 2.0 puts some emphasis on larger endpoint sizes, and memory is not that big internally. My idea (original idea) was to actually have a EHCI interface to the CPU, but not sure it is worth the effort. Not sure when I will be able to test USB3300, I will let you all know when I do. Alvie
  14. Might well be.. or at least play a role on it. Can you try setting all those actively driven to FAST ?
  15. On the mapping report (.mrp) you should see if your IO pins have dedicated IO registers. +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | IOB Name | Type | Direction | IO Standard | Diff | Drive | Slew | Reg (s) | Resistor | IOB | | | | | | Term | Strength | Rate | | | Delay | +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | CLK | IOB | INPUT | LVTTL | | | | | | | | DRAM_ADDR<0> | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | .... | DRAM_CLK | IOB | OUTPUT | LVTTL | | 12 | FAST | ODDR | | | | DRAM_CS_N | IOB | OUTPUT | LVTTL | | 12 | FAST | | | | | DRAM_DQ<0> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | DRAM_DQ<1> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | ... | DRAM_DQM<0> | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | | DRAM_DQM<1> | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | | DRAM_RAS_N | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | | DRAM_WE_N | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | As you can see here, the address lines have OFF in Reg(s) tab, meaning "Output Flip Flop". The Clock line is driven by a ODDR flip flop. The data lines have both OFF and IFF (Input Flip Flop). All other control lines have OFF. This ensures minimal delay from clock to pad, and to chip, and its very important to timing. You seem to have increased one of the timings, though. I wonder it is the same issue we are facing with newer SDRAM parts. Alvie
  16. It may relate to different setup/hold values, and how FPGA routes stuff. Can you check that all your DATA/ADDRESS lines for the SDRAM have IO registers ? Alvie
  17. That's there to support larger devices in the future. Right now we tie that line to '0': DRAM_ADDR(12) <= '0'; Alvie
  18. It's fairly easy to use the SDRAM, once you understand the basics of how our controller works. You can use the controller separately, no need for ZPUino at all. Let me know if I can be of some assistance. We may eventually even come up with a decent how-to Alvie
  19. That's easy. "Design" tab, expand "Synthesize - XST" and choose "View RTL Schematic". Alternatively you can open the .ngr (RTL) or .ngc (Technology) file inside ISE, after synthesis. The RTL view shows you the design prior synthesizing the low-level elements (LUTs, Flip-Flops, so on). The technology shows you how they are mapped into LUTs and FF and so on. This is still prior to mapping, so things can change a bit in the process. Note that due to optimizations sometimes what you see may be a bit "mangled". In that case, enable "Keep Hierarchy" in Synthesis options (right-click on "Synthesize - XST", choose "Process properties"). Glad your problem is fixed now. Alvie
  20. Yes, VHDL is synchronous to the clock, and completely independent of what CPU does. No, all registers (if address is correct) shall at least ACK the transaction (although it may happen that read/writes do not read anything useful or have any side effects). Can you also share the code (.elf) generated ? It may happen that the IO is being directed to a wrong or invalid address.
  21. Tony, can you send me these files that are generated by the ISE build process: .ncd .ngd .syr .mrp (make sure you enable detailed map report, if possible -see options for Map generation) Zip all of them and send to "alvieboy@alvie.com". I'll try to see what is happening. The only "normal" lockout from the CPU point of view is when it tries to read/write to a IO location and ACK never comes in... Alvie
  22. Now they show. Nice work Alvie
  23. Same problem here with the images (and not using Tor). I'm very eager to get my hands on one of these. Actually, I do need something similar at work - I had to give up using FPGA due to lack of USB. Alvie
  24. I think Jack thought about that SRAM usecase. Regarding USB: Our plan for USB is to have a "master bitfile" that, when invoked, presents a MTD device to the host for programming (drag-drop a bitfile). Works in all OS without any drivers. Plus a CDC serial port for debugging or serial programming. After the user bitfile starts, the USB PHY is completely available to the user to do whatever he wants (like a videocamera, for example). Or you can just power it down. Alvie
  25. FTDI is expensive. USB does not work for you because there are some implementation issues (note that there's a PIC controlling the USB). Also, lack of serial support on USB is a killer (I spoke with Dave a few years ago about that, but I also had no time to implement the new endpoint). I have a few XuLa myself. I like them for some projects, due to the small size.