• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by alvieboy

  1. alvieboy

    Yet Another VGA Controller

    You mean FPD (LVDS)? I have not yet explored the possibility of having S3E output HDMI or DVI either. Do you know if our current FPGA can handle that bitstream rate at IOB level ? Álvaro
  2. alvieboy

    C/RAM wing

    Let's start a new thread for the upcoming C/RAM wing. Jack: I just received it, and I successfully uploaded the CPLD program using my S3ESK (putting the device in the middle of the JTAG chain). Now, on to testing the CPLD program. If this goes OK I'll publish the CPLD controller code plus documentation on how to use it, and a 32-bit wishbone controller for papilio.
  3. alvieboy

    C/RAM wing

    Just to clarify: the design being run is not the original, but rather my own which uses an approach similar to that of an SPI ram, but with a 8/13 bit datapath. roughly this: This shows a 32-bit write followed by a 32-bit read, 8 bit at the time. Here's the bitbanging log: Starting memory test E: Select TRUE E: Set bus OUTPUT E: Set up data 0x00000100 E: Set write to HIGH E: Clock up E: Clock low E: Set up data 0x00000000 E: Clock up E: Clock low E: Set up data 0x000000dd E: Clock up E: Clock low E: Set up data 0x000000ff E: Clock up E: Clock low E: Set up data 0x000000bb E: Clock up E: Clock low E: Set up data 0x000000aa E: Clock up E: Clock low E: Set write to LOW E: Set bus TRISTATE E: Select FALSE E: Select TRUE E: Set bus OUTPUT E: Set up data 0x00000100 E: Clock up E: Clock low E: Set up data 0x00000000 E: Clock up E: Clock low E: Set bus TRISTATE E: Clock up E: Clock low E: Read bus returns 000000dd E: Clock up E: Clock low E: Read bus returns 000000ff E: Clock up E: Clock low E: Read bus returns 000000bb E: Clock up E: Clock low E: Read bus returns 000000aa E: Select FALSE This is from an actual run on HW, not simulation. Alvie
  4. alvieboy

    C/RAM wing

    Ok, I have good news and bad news. Good news is that design works as expected, by bitbanging the relevant pins. Despite all the heat Bad news is it cannot handle my 96MHz clock, and the culprit is the CPLD: Slack: -2.600ns (requirement - data path) Source: state_FSM_FFd3.Q Destination: address<9>.D Requirement: 10.400ns Data Path Delay: 13.000ns (Levels of Logic = 5) Data Path: state_FSM_FFd3.Q to address<9>.D Delay type Delay(ns) Logical Resource(s) ---------------------------- ------------------- tCOI 0.500 state_FSM_FFd3.UIM tF + tLOGI + tPTA + tSUI 12.500 address<9>.D ---------------------------- --------------------------- tF itself is 8ns. So Max. freq. for this design is about 77MHz (slightly less). Still I have to confirm timings, additional delay on read might be necessary due to latency (meaning an extra clock cycle on read). Downgrading to 50MHz/48MHz should be enough for VGA 800x600, with 4 bit per pixel, while leaving room for CPU access. Are you considering a CoolRunnerII or similar for a next version ? I wonder if we could fit an SDRAM controller in one of these, but they are probably too small. Alvie
  5. alvieboy

    ZPUino Info

    Hi. Did you program the bitfile correcly with "butterflyloader" ? Álvaro
  6. alvieboy


    Hi all, Just before upcoming Alpha 4 I'd like you to help me on the simple task of choosing some examples to be bundled with ZPUino: Álvaro PS: I'll add support (was requested) for Papilio One 500 next Alpha, with 32Kb RAM.
  7. alvieboy


    After our conversation yesterday, and since I cannot test latest VGA I wrote, I moved on to a design for C/RAM that might be suitable for everyone use. I actually wrote implementation and synthesized+fitted it, so to make sure we don't use more resources than those available on the CPLD. So, my idea is like I told you to have a mix of SPI, wide-bus and bidirectional bus. To accomplish that, the following signals are used to interface with CPU: cpu_seln: Active 0 chip select, asynchronous. cpu_we: CPU write enable, active high. cpu_clk: CPU clock. cpu_data: 13-bit data interface. cpu_seln acts as an asynchronous reset signal for CPLD, and forces the bus to high-impedance. A one-byte read cycle is performed by: 1) Selecting the device, by deasserting cpu_seln, 2) Presenting the lower 13-bit address in data interface, 3) let bus settle and rise the clock. 4) present the upper address bits in data interface, lower clock, 5) rise clock to clock in the full address, 6) CPU changes bus to high-impedance, lowers the clock 7) CPU rises the clock again, 8) CPLD presents 8-bits data on the data interface, cpu lowers clock, 9) CPU asserts cpu_seln A multibyte read is similar, just repeat 7,8 and the address and low/high byte will be "incremented", so a full continuous read is possible. Write is similar, just assert cpu_we when you're sending the upper address part. it will be latched. I just need to test properly, I must avoid spurious writes to SRAM when clock is delayed/data changes. What do you think ? Álvaro
  8. Excellent I'll take a look at your build makefile. Álvaro
  9. I will write a better "tutorial" than that one, I just had not got the time, so I chose a simple explanation of the basic requirements. I'll be expecting your results. Álvaro
  10. See if the following helps: Alvie
  11. I'll setup a web page explaining how to compile things without IDE. I'll leave a link here. Álvaro
  12. alvieboy

    I2C core

    Wanna hire me ? That was just a joke. I do this for beer. 8) Álvaro
  13. You're using the last (Alpha4) programmer, right ?
  14. alvieboy


    Actually the very basic of Wishbone is very simple. What makes things a bit complex is the bus mastering. If you only have one bus master (the CPU) then things are quite easy. ZPUino can support Wishbone easily, just needs to translate 2 or 3 signals. But only the basics, meaning no full transactions, no masters, no burst transfers. What says synthesis about max frequency ? I always thought it would be quite smaller than that. Do you have the detailed map report ? Perhaps the Wishbone master is eating all your slices. That happened to me with OpenRisc32. ZPU Core Premium is now using about 1K slices, but for example GPIO plus the peripheral pin select stuff eats more than twice that value. Muxers are a killer. Spartan6 and the Kinetix seem to have larger muxers, but they are expensive and have limited support on ISE WebPack. Álvaro
  15. alvieboy


    Hi Jack, I understand you were able to put mico32 working on papilio. Care to share some details like: * RAM size * Number of LUT/Slices * Integrated peripherals Best, Álvaro
  16. alvieboy


    Looks like those phonemes are very small, and very low quality. I assume it uses the PICTalker phonemes. Regarding VGA: do you have timings+pin information for your C/MEM wing ? That might allow a full VGA output, and I think ZPUino can handle the pace - that would allow some sort of demo, like the older 4K amazing PC demos of the nineties, with full resolution. Álvaro
  17. Something I forgot to ask you: are you using the same version of IDE and bitfile ? I'm asking this because there were some internal changes that require them to be in sync (I moved memreg[] array into lower memory so it could be shared by the bootloader and the sketch). Álvaro
  18. Ok, that is weird. What program are you uploading ? Can you try an empty one (with only loop() and setup() functions) ? Álvaro
  19. Hi, problem is you did not build the program using the IDE, so its relocations are wrong. It would never work like that. You need to use IDE to compile for now. Since your program is "wrong", it might be overwriting the bootloader. try one of these: a) upload the bitstream to FPGA only (no flash) using butterflyprog, and then before one second elapses, issue the following command (make sure zpuinoprogrammer is in your path): zpuinoprogrammer -R -v -v -d /dev/ttyUSB1 -r This should read the flash, and enter program mode (so the bootloader does not start your program). You then should upload a proper sketch using the IDE. If you already programmed ZPUino bitfile on the flash (using butterflyprog) try disconnecting the USB, reconnecting, and before 1s elapses run the above command again. I had to remove bootloader protection due to timing and performance issues. Álvaro
  20. alvieboy


    I'm creating a simple VGA text interface (I don't have that much memory to use on the 250), let's see how it goes. I don't have a display at home, so I am not able to test it. I can do this for WAV, not MP3. That would require HW implementation of at least IDCT. I might look at it later. I just helped Shazz integrating a Yamaha YM2149 device in ZPUino, it seems to work now, if he finds no issues with it I will publish as an example. SPI is quite small, so a SD card would be better. You're thinking about streaming the phonemes using serial port ? Álvaro
  21. alvieboy


    Since no one helped with a specific Papilio One demo, I only uploaded a S3ESK board demo, which uses LCD, rotary and leds. http://alvie.loc/zpuino/examples.html Ah, and Papilio One S3E500 bitfile is ready and available for download. Jack: what do you think would be interesting demos/examples for Papilio ? Which wings would be more appropriate to this ?
  22. alvieboy

    Alpha 4 is out.

    ZPUino Alpha 4 is out: A new image for Papilio One based on S3E500 is included in binary downloads. Álvaro
  23. alvieboy

    Other FPGAs?

    Perhaps a stupid question, but... why 2 FPGA ? Regarding butterflyprog: I think it assumes only one device on the JTAG chain, so you'll have to modify it. Álvaro
  24. The reason I was asking was to see if you could use some serial RAM, like 23K256 from Microchip. They are available as 8-pin DIP. You need 250ns access time. These SPI RAM can go up to 20Mhz, and random read/writes use 32 bit. That would not meet your timing unless you used 8 at same time. So it's not an option, I guess, due to price. A TC55V2001STI would do the job, but seems quite hard to source. Perhaps better you get some TSSOP and get some DIP adapter. Or maybe Jack has some memory wing on the forge.
  25. How fast needs it to be ? Álvaro