Jaxartes

Members
  • Posts

    90
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Jaxartes

  1. You set the baud rate on the host (PC) side, in whatever program you're using to communicate with the FPGA. You're right, there are only two pins which communicate the data between the FPGA and the FTDI chip. The transfer rate isn't communicated -- it's set independently on each side. They have to be set to the same value (within a few percent) in order to communicate. On the FPGA side, this is something you do in your Verilog code, usually with some kind of counter. On the other side, it's controlled by the host (PC). I imagine the host sets up the baud rate on the FTDI chip over USB. Anyway, that's taken care of in the operating system and device drivers. Those in turn are set up by whatever communication software you run on the PC side. The exact details of that depend on the communication software and the operating system.
  2. Assuming you're in DesignLab, maybe try clicking the "Load Circuit" button before the "Upload" button. The "Load Circuit" button will upload both ZPUino and whatever I/O devices are used in your sketch.
  3. When it comes to VGA output, different boards will have different numbers of digital pins used to generate the analog color lines. On Papilio the VGA Wing uses three (one per color component), the LogicStart MegaWing uses eight (2-3 per color component), and the Arcade MegaWing uses twelve (4 per color component). So when adapting a design, meant for one of them, to another, you have to change the relevant parts. As for the errors you're getting, I can't be much help, as I don't work usually with VHDL but with Verilog instead. But what I suspect is that there's a difference between a single logic signal (STD_LOGIC) and an array of some number of logic signals (STD_LOGIC_VECTOR) even if the "some number" is 1. I believe that's the same thing treadstone says above. You might have to make small changes to the syntax of the VHDL code to change one to the other. To up convert from one bit per component to three or four, you can do what treadstone suggests above (make that one bit the msb, and fill the rest in with zero) though what I'd usually do instead is copy that one bit to all three or four.
  4. Yeah, I can see that. I don't know exactly what's causing the error but my guess is: That 'video_ram' was meant for the Spartan-3 FPGA found in the Papilio One board, and not the Spartan-6 FPGA you're building it for. A lot of Verilog or VHDL code is portable, but some things which use vendor primitives might not be. And it looks like video_ram is one of those; see "https://github.com/thelonious/vga_generator/blob/master/vga_text/ipcore_dir/video_ram.v". I see two options for fixing it: (a) Use Xilinx's core generator to make one that will be suitable for Spartan-6; or ( write one which can be inferred and therefore will be more portable. I would usually choose ( but I'm afraid neither (a) nor ( is really easy. (a) is explained in chapter 15 of the eBook linked here: http://forum.gadgetfactory.net/index.php?/page/articles.html/_/papilio/logicstart-megawing/intro-to-spartan-fpga-ebook-r34
  5. Regarding the error message: I can't read it in your post, it just shows up as "?" for some reason. Regarding how to "call" it: The "Code x32" means "character code 0x32". That is, when the value 50 (0x32) is found in the video_ram, the corresponding font data (what you quoted above) is displayed on the screen. So the question for you is how to get the codes for "hello world" into the video_ram. It looks like emitCharCodes.pl is part of that process. I think it's used to generate a new video_ram.coe file, and then you build the whole thing using ISE.
  6. By tools do you mean DesignLab? I think it could go either way. It gives you a lot of help, but also imposes its own way of doing things. I was able to do plenty without it (until starting my current project, which depends on DesignLab for unavoidable and non-technical reasons). Soft-CPU and SoC (system on a chip) designs, in Verilog and VHDL, are plentiful.
  7. 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.
  8. Thanks for pointing this out. It happens to me too (with Papilio_Pro.bit / papilio_pro.bit).
  9. 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).
  10. 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.
  11. 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/.
  12. 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)
  13. 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.
  14. 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.
  15. 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.
  16. 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)?
  17. 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.
  18. 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/
  19. 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.
  20. 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.
  21. 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
  22. 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.
  23. 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.
  24. 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.
  25. 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().