• Content count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jaxartes

  1. Hamster's SDRAM_Controller

    Unfortunately, any such component is going to have to interface to the memory controller, to read from RAM, and perhaps share it with whatever component is doing the writing. I agree, that's a pain, but it's unavoidable. The one aspect you don't have to deal with is USB. The Papilio boards have a USB-to-serial converter already built-in on a separate chip (the FTDI chip). So what you need to find VHDL code for is serial communication, period. You connect that to the correct two pins, to go to the FTDI chip; and you interface the code to your architecture; and that's that. If there is, or could be, a soft-CPU somewhere involved in your design, that makes serial interfacing a bit easier, though it has its own complexities. If not, have a look at http://opencores.org/project,uart2bus. I haven't tried it, because I haven't needed it, but it provides a memory-oriented interface accessed over a serial line. The fact that it's designed for 16 bits address and 8 bits data might be annoying, but not insurmountable. A small CPU, using a few kilobytes of on-chip RAM, and with a serial interface and a memory interface, is the route I would take. Start with a simple working system that's already been created, and which has a serial interface (I expect most of them do); then adding the "glue" logic to connect it with your design, and writing a program to talk over the serial port and perform whatever test actions you have in mind. Best would be one that doesn't need to use the SDRAM itself, and can operate entirely from the on-chip BRAM. http://forum.gadgetfactory.net/index.php?/topic/2511-papilio-pro-without-sdram/, a recent thread on this forum, might be of interest in that light.
  2. While experimenting with the example "ZPUino_VGA_Adapter/Demo" in DesignLab 1.0.7 I've run into a couple of problems. I've attached a copy of the sketch, with my modifications to variously make the problems better or worse. I was running on Papilio Pro, with Arcade MegaWing, with 800x600 graphics selected. Code: video_sketch_2.ino.txt 1. The microsecond time values that are transmitted on the serial port, are sometimes very wrong. The wrong values are ones like 4254601156 -- a little under 2^32. The cause: TIMERTSC wraps around every 40 seconds or so, so so does the result of micros() based on it. Now, subtracting one "unsigned long" from another, when the wraparound occurs, wouldn't be a problem. But dividing by 96 or whatever clocksPerMicrosecond is, and then subtracting, results in this problem. I see that some fix was put in for millis() but none for micros(). Workaround: A microsecond-granularity "stopwatch", functions stw*(). But they wouldn't be portable to non-ZPUino platforms, and they assume everyone wants microseconds. 2. With the workaround for #1, a new bug popped out: There's a crash happening in testFilledRects() and testFilledRoundRects(). It either hangs the sketch or restarts it. This problem turns out to have nothing to do with #1, it's just one of those "heisenbugs" which disappear and reappear when you change the code or try to debug them. The cause: The loops in those two tests will sometimes pass out-of-range (namely negative) values to gfx.fillRect() and gfx.fillRoundRect(); and when those functions try to draw to off-screen addresses they probably overwrite some important memory location. It's a matter of opinion whether the bug is in the sketch, for passing illegal values to those functions; or in those functions, for accepting illegal values. Workaround/fix: Changing the loops to avoid out-of-range values. Problem #2 only appeared with those two functions, that I could see; it might apply to others but be harder to reproduce.
  3. upper and lower case in Linux

    Thanks for pointing this out. It happens to me too (with Papilio_Pro.bit / papilio_pro.bit).
  4. Ok, done. I've submitted issues #24 and #25 in ZPUino's GitHub site. I have a couple of related questions: A. Out of curiosity: You mention "We can use conditionals easily on ZPUino, unlike Arduino". What makes the difference/is the difficulty? I thought the big performance problem with conditionals was in pipelined architectures, and I wouldn't have expected the AVR8 architecture to have a deep pipeline. B. Speaking of performance, do you think a "blitter" (2D graphics accelerator) would be of any use in ZPUino? I'm thinking of creating one as my next project. The design I've got in mind would do memory-to-memory copies via DMA, with enough sophistication to draw straight lines and rectangles (but not other polygons or curved lines, without a lot of help from the CPU; also it wouldn't do antialiasing).
  5. Ok. Here are some additional resources, specific to that MegaWing: http://papilio.cc/index.php?n=Papilio.LogicStartMegaWing. On that page's "Quicklinks" section: "LogicStart MegaWing Generic UCF" - used with the Xilinx ISE software to map pin names and functions to the pin numbers the software uses. Also tells it how fast the clock is (32MHz). "ADC128S102 SPI ADC Datasheet" - I'd say download this. You don't have to read it, but if you want your Verilog/VHDL code to use that chip it's worth having. "Download a PDF version of Mike Fields book" - It's a beginner introduction to VHDL, but it also explains how to deal with the FPGA side of things.
  6. Xilinx ISE software: The software for physically implementing Verilog/VHDL designs on Xilinx FPGA's. This is not the newer software (Vivado) but it's the version which works with the Papilio Pro. The free version is called "WebPack." It's a large download, several gigabytes. Found on Xilinx's website. Data sheets for the chips on the Papilio Pro (SPI flash, SDRAM, FTDI USB interface): linked from the Papilio Pro hardware guide, http://www.papilio.cc/index.php?n=Papilio.PapilioPro. You're not going to use all of them, but they're handy to have around for when you want something. Similar information for devices/ports on whatever MegaWing you got. Which MegaWing did you get? There are several. I've been using the Arcade MegaWing. DesignLab software: http://forum.gadgetfactory.net/index.php?/files/file/236-papilio-designlab-ide/.
  7. Alvie - I see what you mean regarding issue #2 and performance. As far as I'm concerned, fixing the "ZPUino_VGA_Adapter/Demo" example program (to avoid passing the invalid coordinates in the first place) is good. Alternatives to compile time conditionals that occur to me, I'll just throw them out there: an additional set of functions, wrappers around the current ones, that add the checksa new class, wrapper around the current one, that adds the checks (or a subclass? I'm not sure how that would work out in this case)
  8. Announcing the VTJ-1 terminal: https://github.com/Jaxartes/vtj1 This is a text terminal, similar to the old VT102, which can go on the Papilio. It could potentially be useful, in some projects, as a way to provide a minimal screen/keyboard interface for a project that doesn't need real graphics. Or in combination with retro computing projects where the target machine is meant to be used with a terminal. The code on GitHub is for a standalone device to be built for the Papilio Pro with the Papilio Arcade MegaWing. It should be fairly simple to adapt it to the Papilio Duo and to other shields/wings. It's meant to be suitable for combining with other designs, they communicate only over a serial port. VTJ-1 uses some block RAM (19kB) and <20% of this FPGA's LUTs; one PS/2 port; video and audio out; and leaves the other on- and off- chip resources to the other core. So far I've gotten it to work with Will Sowerbutts's "socz80" system, where both reside on the same FPGA on the Papilio Pro. It would also be interesting if somebody got it to work with the J1b Forth computer, or as a DesignLab "chip." Mostly it's in 6502 assembly code (!) along with Verilog.
  9. I've noticed that when I try to use "papilio-prog" to reconfigure the FPGA, it gets stuck. The command completes and returns to the prompt, but the Papilio just sits there instead of coming back up in the design which is loaded onto the SPI flash. The four LEDs on the Arcade MegaWing are faintly lit as they are during programming. What I did in particular was: "papilio-prog -vr". I've got a workaround. I follow the command by: "papilio-prog -vc" (display current status). That seems to wake it up. Other system info: I've seen this with two different builds of papilio-prog, both built from the GitHub branch "master". One from September 2014, and one from now (version 2.8). I'm running xubuntu Linux in VMware on top of Mac OS X, with a Papilio Pro and Arcade MegaWing.
  10. Designlab and Pipistrello

    One trick that might or might not be of use: Maybe you can put the zpuino .bit file on the flash, and load all your other .bit files directly to the FPGA (non-persistently)?
  11. CBM MOS 1351 controller chip

    I believe there's an open source recreation of one of the SID chips, used in the RetroCade Synth project. There may be ones for the other chips, but they wouldn't be found here. I'll list places I'd recommend looking, at the bottom of this post. But note, these are not the original chips, but new designs that try to replicate the behavior of the old chips. I expect the original chips' actual designs are long gone. And these re-creations may be imperfect; and many are likely to differ in details of external interfacing. Thus, they would not be drop-in replacements if that's what you're looking for. Regarding Papilio and the Xilinx software: The Xilinx software is used for building many of the Papilio projects as it is. But I'm not clear what you're really asking. Regarding PLD: If you mean CPLD, I haven't worked with them, but I think their capabilities are a lot less than FPGAs and that might be a problem when trying to get complicated designs to work. Places to look for open source re-creations of these chips, or related information: http://opencores.comhosts a lot of open source designs. http://www.visual6502.orgreverse engineers a lot of old chips. ftp://www.zimmers.net/pub/cbm/documents/projects/interfaces/mouse/Mouse.htmlhas a lot of info about the Commodore 1351 mouse. https://twitter.com/MEGA65Retrois a project for creating a sort of "super commodore" machine on an FPGA, they may have worked on including related functionality.
  12. CVSD decoder

    Re hex files in ISE: In Verilog you can use $readmemh(...) to read a file of hexadecimal text. ISE reads that in at build time. It may not be as convenient as programs which insert the data into the bitstream after build, but I haven't tried those. Its input file is not the same as Intel HEX files. It's a really limited format, hardly more than just a sequence of hexadecimal numbers one per line. mkarlsson gives an example in this recent thread: http://forum.gadgetfactory.net/index.php?/topic/2494-coe-file-embedded-in-bit-file/
  13. COE File embedded in BIT file?

    I would guess that the memory (BRAM) contents included in the bitstream are either compressed or scrambled. At any rate, looking at the .bit file from my current design, I don't find the strings from my program. But I believe it's there, otherwise it wouldn't work. I agree with offroad's statement regarding inferring memories rather than using the Xilinx core blocks. It's easy, it's portable, and it harmonizes nicely with your Verilog or VHDL code.
  14. Papilio One as High Speed DAQ

    You might find a pulse counter design already on the internet. Of course, you'd still have to see if its capabilities meet your needs, and perhaps modify it to work on the Papilio too. As for developing one, the difficult part may be the counter, not the UART. It depends on how fast you need the counter to be, and how fancy you need the protocol to be. If the counter logic is sampling input at 200MHz, then the shortest pulse must be more than 5 ns, and the shortest gap between pulses must be more than 5 ns, and the actual rate of pulses must be less than 100MHz. It's easiest if all logic on the FPGA is running at the same speed. (It's by no means required, but it's easiest.) Your counter might be fast, and your UART might be fast, but if you have a CPU, it'll be rather slower (the fastest I'm aware of is 128MHz and that's on Papilio Pro). I'd consider two, quite different approaches, with different advantages and disadvantages. Approach 1: A CPU, with counter and UART attached to it. The only custom parts are the pulse counter, and the software running on the CPU. The CPU would allow you to make the protocol as complicated as you'd like. But it also limits the speed of your counter. This approach has less "custom" stuff, and may be easier for that reason. Approach 2: A counter and a UART. This lends itself to a fast counter, but a very limited protocol. Perhaps just sending the numeric counter value, over and over again, as fast as possible. This approach has more "custom" stuff, but less stuff overall, and may be easier for that reason. (There's also an approach 3, with all the counting done in software. Easy, quite slow, could be done on a micro controller instead of an FPGA.) Approach 1 allows a fancier protocol, while approach 2 allows greater speed. Each may be easier depending on your skill set. Regarding sending different types of data through a UART: What's transmitted through a UART is bytes, usually 8 bits each. There are a lot of different ways to represent a type in bytes. I'd recommend using what's easiest to encode, even if it isn't very "pretty," effectively moving the complicated parts from the FPGA to your host computer. The prettiest representation for a number would be in decimal ASCII. The number 1234 might be represented then as five byte values: 48, 49, 50, 51, and 32 (the 32 is just a space). But while it's easiest to read, it can be a pain to encode. The easiest to encode would be a single byte numeric value. But you're limited to the range 0-255, and some software on your computer may try to interpret parts of that range as control codes. There are a lot of other encoding options in between those two extremes. Hexadecimal (base 16) is easier to encode; it's especially easy when you have a CPU; and it's still fairly easy to read. "Base-64" is similarly easy to encode, and more compact; harder to decode, but not really hard. Do you really need to accept commands from the computer? That's a tricky part in itself. I'd try to do without it if possible. If you need to know how many pulses between two points in time, just subtract the two counts on the computer side.
  15. Platform for use with GHDL

    With this and many other FPGA platforms, you'll probably end up using the vendor's toolchain. For Papilio, that's Xilinx ISE. It contains its own VHDL & Verilog implementations, which are capable of generating output for Xilinx FPGAs. There would be other ones for Altera FPGAs, etc. See also: http://electronics.stackexchange.com/questions/12432/can-i-use-ghdl-or-some-other-vhdl-compiler-simulator-than-webpack-with-a-spartan
  16. How about designing a video game console?

    Perhaps the thing to do is to start with something like the primitive, micro controller based systems you mentioned, and start extending from there. Using an FPGA lets you add custom peripheral "chips" to your design. You can create and include peripherals or accelerators that are suited to your needs or ideas. Unfortunately, the highest performing stuff doesn't fit on the hobbyist-priced FPGAs, and the fanciest designs can take quite a long time to build and debug. Debugging is what takes a lot of time, at least for me. If I hadn't honed my debugging skills (and patience) over years as a programmer, I'd have gotten nowhere in Verilog. Polygonhell mentions the space required by 8 bit processors. It's not necessarily that much. There's a re-creation of the 6502 (used in many personal computers and consoles of the 8 bit era) which ends up taking about 10% of the slice LUTs on the LX9. CPU is only part of the matter -- some other devices are also complex, and even simple ones can add up. For example, my current project has a 6502 with text-mode video [1], serial, and PS/2 interfaces, and comes in around 30% of the slice LUTs. (I'm hoping I can get it to coexist with the "socz80" system, another 8 bit one, which comes to about 70%.) There's a lot of variation in how much space things take up. There are a variety of 32 bit processors that will fit on the LX9. ZPU/ZPUino is one, and there are quite a few others, including some historic ones. (I was just now reading about the "J2" core, based on the "SH2" architecture, that was one of the processors in the Saturn.) While some 8 bit architectures are a bit cramped. [1] Arguably the text-mode video is only half in "hardware:" Vertical timing and addressing are done in software.
  17. J1 Forth CPU on Papilio Duo

    Speaking of small CPUs in Verilog, I've long been wanting to put in a plug for this one: Arlet Ottens's 6502 model (http://ladybug.xs4all.nl/arlet/fpga/6502/). A historic architecture; more versatile and portable than PicoBlaze; and fairly compact. On the Papilio Pro, it uses about 9% of the LUTs and gets a clock rate of up to ~90MHz.
  18. Communication zpuino/fpga

    It's too bad there isn't enough BRAM for your design. I was going to suggest it: Each BRAM has two independent ports for access, and there are 32 of them, while there's just one SRAM. You mentioned soft processors, so I think I should point out: You have two hard CPUs in your solution already: The AVR micro controller on the DUO, and the CPU of the SNES itself. Each has its own memory, and advantages and disadvantages: AVR: Popular toolchain (Arduino); limited capability (32kB program memory, 2.5kB internal SRAM); accessing external SRAM could take some effort; can run independently while SNES is playing games. 5A22 (SNES): Probably harder to program, but you might find it more familiar or interesting since it's SNES. And although accessing the DUO's SRAM could take some effort here too, it's effort I think you already planned to make. In the latter case, using the SNES CPU, here's what I imagine: the FPGA would provide "glue logic" to access the SRAM, and a variety of custom expansion chips. These would be mapped into the SNES's memory and might be the following: SD card readerBRAM containing "bootloader" software: this reads the SD card and writes to SRAMmemory management unit (MMU), if desired; it might enable/disable writing to SRAM, or hide the boot loader BRAM or SD card readerI have no idea if this is more or less easy, or useful, than multiplexing access to the SRAM between ZPUino and the SNES.
  19. Communication zpuino/fpga

    Since I haven't worked with these exact tools, I can't give you details or certainties, but I think I can give some general ideas on #1 and #2. Re 1: I believe ZPUino has a GPIO device, providing a bunch of digital input/output lines. I would expect that in schematic editor, you should be able to connect one or more of these to your other design elements, instead of the external pads of the FPGA. Then you'd use digitalWrite() on the ZPUino side. For more sophisticated communication, there are a lot of options (serial, I2C, SPI) but I suspect Wishbone would be best at that point. Re 2: What do you want to use that fixed-location memory for? That might help come up with an alternative. A cursory look at http://github.com/alvieboy/ZPUino/blob/master/hardware/tools/zpu/zpu-elf/include/malloc.h (assuming that's the right place) and some similar files suggests there isn't such a function. Since I expect all this software is open-source, you might be able to create one, but that's probably a significant task. Some possibilities that might work: You could, at init time, try malloc()ing blocks of memory until you run out. Then free all the ones you got which don't contain your desired range. That requires your desired memory range fall into a single malloc()ed block..Some malloc() implementations have a limit stored somewhere, indicating the location above which they don't allocate. Maybe you could put your block at the top of that, and move that pointer.malloc() doesn't use space that belongs to the stack, or the program code. alloca() allocates from the former (it gets freed automatically when you return from the function); the latter is where the global variables you declare in your code are placed. Neither lets you pick the exact address ahead of time, but they make it a little bit predictable and they protect it from malloc().
  20. Xilinx VHDL UART Example

    There's something called "UART to bus" at open cores. I think it provides basically the functionality you're looking for, except it's not wishbone compatible and it's not DesignLab integrated. http://opencores.org/project,uart2bus There are probably others out there.
  21. I expect it's possible, I suspect it's even easy. I don't know exactly how, because I haven't used DesignLab. The main differences are going to be that the DAC is connected to a different pin on the FPGA, and that the audio wing is stereo (2 outputs) while that megawing is mono (1 output). For the former, DesignLab probably has a way to select what board combination you're using (which is what determines the FPGA pin). For the latter, it's probably just a matter of not using the "splitter" I see mentioned in the documentation; or else, I'd just take one of the outputs (left or right) and leave the other unconnected.
  22. SPI TFTs?

    I can see how such a converter would be useful. I can think of some challenges it would have, namely: Speed: If I understand the ILI9341 data sheet right, in serial mode it takes at least 16 bits per pixel, at most 10 million bits per second. That's 625,000 pixels per second, much less than is sent over a VGA interface. 625,000 pixels/second = 8.14 frames/second for 320x240 frames. It can handle more in parallel mode, but you'd need more wires (and the post was about SPI). Memory: Admittedly, it doesn't really need to handle every pixel, every frame; most of the time they mostly don't change. So the converter would detect what has changed, and transmit that. It would keep a record, on the Papilio, of the pixels which have been sent to the display, and would send the differences. That store would be, for 16bpp color, 128kB. That's more than the FPGA on the Papilio has, so the converter would need access to the off-chip SRAM or DRAM, making it harder to use. (4bpp color avoids this problem, and could be used for a lot of retro-gaming and computing.) Logic: When the screen changes faster than the serial interface can handle, the converter would necessarily lag behind. Depending on how it chooses which pixels to update, there might be unpleasant artifacts.
  23. CD Quality Audio 44.1kHz Delta Sigma DAC Spartan 6

    I get the feeling this problem isn't about the clock rate being too low, or the interpolation filter. asic_designer: You say it sounds horrible. How bad? (i) Not hi-fi, not very good for music, but good enough for talk. (ii) Not even good enough for normal talk on the phone/radio. (iii) Not even recognizable. Problems with the clock rate would be (i). If it's (ii) or (iii) then that's not it. The sound quality of a sigma-delta DAC should degrade gracefully, as the clock rate goes lower. I did synthesizer projects running at 32MHz and 128MHz and the sound was good enough to my ear. As for the latest question: It's A. The DAC is continuously summing. And it should sum, not zero, but the latest sample value. The way a sigma-delta DAC works is that it generates a waveform that has only highs and lows, nothing in between. The interpolation filter averages it into a much slower waveform, but also one that's more gradual. So, say your desired wave is a sine wave at 1kHz and you've got a sigma-delta DAC running at 32MHz. Then in the middle of the wave, if it's 50% between high and low, you'd expect to see a fast 16MHz square wave coming out of the FPGA (high low high low ...). And if it's down to 25%, you'd expect to see an 8MHz, 25% duty cycle wave (high low low low high low low low ...). So, here are my suggestions: Sum at the full clock rate, adding the current sample value. If that fixes the problem, great. Otherwise, the rest of these tips are for debugging.Save a few thousand samples in memory and send them back to your computer. Examine them to make sure the sample values are right. If the samples you're trying to play aren't right, then no DAC can make them sound right.Make sure the sample width (in bits) and signedness are what you think they are. Playing a signed sample as unsigned is going to sound horrible. And the adder you build the sigma-delta DAC around, needs to handle whichever it is you're giving it.
  24. External programmer needed?

    I don't think they're saying some boards work and others don't. Instead, I think the "may or may not work" could be any of the following: It depends on which Xilinx tool you're using.It depends on which features you're using on that tool.It depends on which version of that tool you've got.It's tricky to set up. Some people have figured it out or been lucky enough to have it work, others might have difficulty.Somebody has used it, but we're not sure if it really works well enough to have other people rely on it.Most likely the latter two. I think what Gadget Factory have done is shared what information they have, from trying this out. They might not have had the time to do the kind of detailed testing that would be required to change those "may be"s to certainties. And Jack's priority has probably been on the Papilio tools, rather than the Xilinx ones. I imagine that most of us are using the Papilio tools. I know I am.
  25. You could also consider doing it the other way around -- using the Arcade MegaWing in place of LogicStart. That's what I've been doing. I've got the Arcade MegaWing and haven't loaded a single arcade game onto it. The Arcade hardware gives you the joystick ports, and stereo audio, and its VGA has greater color depth. You keep the PS/2 ports and lose the micro-joystick, some of the LEDs, and replace the slide switches by a smaller number of push buttons. Slide switches may be a little more helpful for very basic logic learning projects, but push buttons seem more natural to me for anything more advanced. More LEDs would be nice, but four is enough for a lot of stuff. As for adding additional ports: Each MegaWing board takes up all the Papilio's pins, making adding new ports tricky. The Papilio Duo has the Classic Computing shield, which can be split to free up a few pins. It's probably also possible to get a few pins out of the PS/2 ports or joystick on Arcade but I haven't tried this, due to the effort of finding or building an appropriate break-out cable. (I've deleted comments about PS/2 - serial adapters, as they're not really relevant. Other edits above, to fix a mistake.)