alvieboy

Members
  • Content count

    865
  • Joined

  • Last visited

  • Days Won

    18

Everything posted by alvieboy

  1. alvieboy

    RISC-V on Papilio Pro

    Thanks for sharing. I still have to ship your stuff, will do so during this week. Also quite busy over here, but definitely have no connectivity issues I will try your design later, but more interested in the HDL design than in the demo. There's been quite some hype around RISC-V, but to be honest I believe it won't live longer - there are some issues with ISA, and some extensions may not play well with others. Also, MIPS is for sale AFAIK, if they drop the patents it may well be a more serious contender to ARM (I think at least Cavium may have some interest in buying MIPS from Imagination - and Imagination is eager to sell everything due to recent contract changes with Apple) Alvie
  2. alvieboy

    Recording from Delta-Sigma DAC to PC

    it's probably better just to stream it using a serial port at 3Mbit/s. The audio DAC relies on the speaker themselves (their inductance) to perform a low-pass filter, in both Sigma-Delta and PWM outputs. What you hear is probably switching noise and some aliasing. Alternative is for you to design such an analogue filter. It can be technically possible to send that data over USB using a simple transceiver and isochronous transfers, but we have not done it before. Alvie
  3. alvieboy

    Reset behaviour question

    Synchronous resets are not an issue. Reseting the clock generator is General rule is: - If you have a single clock on your system, make sure the reset signal is deasserted at least one clock cycle after your clocking is stable. Do not deassert it if you use a DCM/PLL until it locks. Do not reset DCM/PLL unless you absolutely need to. - For multiple clocks its a bit more tricky. You will need a reset for each of your clock domains. Here async reset for the reset itself may prove useful - assert resets asynchronously, but deassert them synchronously for each of your clock domains. May not be enough, though. Alvie
  4. alvieboy

    Programming to FPGA SPI Flash not working

    You can try using ZPUino itself to perform the SPI programming. Let me know if you need some pointers on how to do it. Contact me at alvieboy@alvie.com Alvaro
  5. alvieboy

    dcachev2_zpuino_preliminar.tar.gz

    Version 2.0.0

    99 downloads

    Preliminary ZPUino dcache (v2)
  6. alvieboy

    RISC-V on Papilio Pro

    Implementing a IWF cache (Important Word First) is quite complex. I did it for xThundercore (which is another CPU I am developing), but ended up quite big, and to be honest I did not see any spectacular performance improvement. One technique (which is simple, but may require compiler awareness) is to assume all forward branches to be a miss, and all backward branches to be a hit. I'll send you my dcache by private message (and the write buffer). Alvie
  7. alvieboy

    RISC-V on Papilio Pro

    Another question - note that I have had not much time to look at your implementation - why are you snooping the data bus cyc in the instruction cache (I assume it's your change, has a TH comment on it) ? Alvie
  8. alvieboy

    RISC-V on Papilio Pro

    Not if you use the embedded multipliers. Those are slow (never managed to get a 32x32 to work above ~105MHz or so). I have a data cache I wrote for ZPUino (not published, it's a two-way associative). Let me know if you want to take a look. Regarding bitfiles: how you program the design afterwards - or do you have to embed the code inside the bitfile ? We can try porting the ZPUino bootloader for your new platform, should be pretty much trivial. Alvie
  9. alvieboy

    RISC-V on Papilio Pro

    Do you have clang+llvm working for the platform ? Last time I looked it seemed like work in progress. Or do they use gcc ? What's the current clock rate for the system ? Can it go past 50Mhz ? Alvie
  10. alvieboy

    Papilio Pro 3.3V rail max current

    I have powered ESP8266 using PPro rails just fine, even when overclocked. Just make sure you have a nice caps on ESP supply to support the high current bursts. On another note: I have ESP8266 wings ready, in case you want them. I can sell you the PCBs for USD1.5 each, plus shipping. Or I can share design with you if you want to build them yourself. Alvie
  11. alvieboy

    microSD write issue

    Excellent. Now, we should document that somewhere... just unsure where. The code size different is substantial I believe, even if you don't actually use writes. Alvie
  12. alvieboy

    microSD write issue

    I assume you're using the SD library. If so, try creating a file named "config.h" in your sketch folder, and add the following line: #define SD_WRITE_SUPPORT 1 That should enable write support. Sorry this is not documented anywhere. It should be, but unclear where I'd put such information... Alvie
  13. alvieboy

    Sometris game

    Good work Alvie
  14. You're the man, Markus
  15. alvieboy

    Arcade MegaWing: Diodes and capacitors on VGA

    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
  16. alvieboy

    OV7670 vhdl code.

    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
  17. alvieboy

    load sketch into SPI flash

    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
  18. alvieboy

    microSD write issue

    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
  19. alvieboy

    Yet another VHDL CPU core

    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
  20. I believe we also have the generic VGA working on DUO for those resolutions. Alvaro
  21. alvieboy

    Building ZPUino on Windows

    It should be fixed by now, I think.
  22. 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
  23. alvieboy

    Working on Papilio Nano

    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
  24. alvieboy

    Working on Papilio Nano

    Btw, here's the USB wishbone controller: https://github.com/alvieboy/ZPUino-HDL/blob/master/zpu/hdl/zpuino/contrib/usb/usbctrl.vhd
  25. alvieboy

    Working on Papilio Nano

    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