Jaxartes

Members
  • Content count

    89
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by Jaxartes

  1. 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.
  2. Jaxartes

    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.
  3. Jaxartes

    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.
  4. Jaxartes

    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.
  5. 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.)
  6. Jaxartes

    DCMs and static timing

    I think the most important part of the timing report is pass/fail -- either it meets timing (with the clock settings you're using) or it doesn't. The second most important is, if it meets timing, by how much? If it fails, where? If it meets timing, but the MHz it lists is below the clock speed you've set up -- I think it's talking about a different clock. When you've got more than one clock speed on your FPGA, the notion of which one is the "real one" seems ill-defined. If it doesn't meet timing, it still might work. I've seen it happen. But I wouldn't count on it. Even where the listed MHz makes sense, it's not an absolute speed limit for your design. Sometimes I've raised the clock rate a little above that, and rebuilt, and it's made timing even at the higher clock rate. I think the tools manage to trade off logic size for speed. As I kept raising the clock rate, eventually it failed. And the timing report told me it failed. I don't think the 62.5MHz means that the 100MHz clock rate you chose is not getting checked. In the timing report on one of my projects, I see "Requirement: 12.5ns", which corresponds to the 80MHz I set up to get out of the DCM. On the same report, it lists maximum frequency 62.5MHz. I think that 62.5MHz is what input clock the DCM itself can handle with the current settings. When using the oscillator on the Papilio, that's always 32MHz. In a board under development or a more complicated design, it might vary.
  7. An open source ARM compatible core, "Amber," exists, but it's an old version of ARM and I don't know how well it fits small FPGAs. Numerous other processors exist. Jack has mentioned ZPUino. C to VHDL conversion doesn't seem like it would be very practical for most purposes. The two languages are doing very different things. Converting C code meant to run on one architecture, to run on another, is closer to practical. It does have various annoyances, but they're surmountable with skill and patience. The most common issue would probably be that types such as 'int' and pointers may be different sizes than 32 bits. But 32 bit integer types would still exist.
  8. Hi there, I'll try to answer. The overall architecture of the system would be like this, four parts in roughly a chain: Part 1: On computer, in Python: Connects to the serial-over-USB port on the Papilio and transmits commands. These commands can be in whatever protocol you want, one you find, one you design, etc. Part 2: On Papilio: Receives those commands over the serial port. Part 3: On Papilio: Interprets them, translating them into commands taken by the L6470 IC. Part 4: On Papilio: Communicates with the L6470 IC. Part 1 you sound like you'd know how to do. Part 2 is commonly called a UART, and very widely available. Part 3 would be custom, it might be simple or complex. Most likely, part 3 would be a SoC: The combination of a CPU with some software to run on it. Part 4 would depend on the IC; for the L6470 IC it sounds like this would be a SPI master, also widely available. As for languages used: The "hardware" implemented by the FPGA is commonly done in one of two languages, Verilog or VHDL. But an alternative exists for Papilio, called DesignLab. A lot of people have used it, and it seems quite well suited for what you're trying to do. As for the software part of part 3, that would depend on what you use for everything else. With DesignLab, I believe you get an Arduino-like environment. Other approaches do exist. You might do part 3 entirely in logic, without a CPU or code running on it. Probably harder that way. The design of the protocol is wide open, and important. It could complicate your code in parts 1 and 3. There are a lot of possibilities. I don't have any particular recommendations, except to make it text-based, for easier debugging. In the recent past I've used the following: 1. Numeric parameters (in decimal), separated by dots (.), followed by alphabetic two-letter commands. 2. Each command on a single line, the first character is the command, the rest is its parameters. 3. ECMA-48. Well-suited to what I'm doing, but not for motor control. I'm curious, how did Arduino prove insufficient for this? It has SPI, it has a serial port over USB, it has a development environment. Is it lack of CPU power, memory, some additional I/O interfacing?
  9. I've just now tried this out on my Papilio and it seems to work fine. I get one cycle of "high", 207 cycles of "low", repeat. I don't think minor the modifications I made did anything. So I suspect your VHDL is ok and the real problem is "downstream" from there. Things to consider: treadstone's suggestion of aliasing in your logic analyzer: See what happens if you change your sample rate.Is your output signal going to the pin you think it's going to? In your project directory, look for a file whose name ends with _pad.txt. It was created by ISE, and it'll tell which signal goes where. Open it in a text file viewer and search for a line with your signal name (e.g., CLK_OUT). It'll appear on the second column of the line. And on the first column of the line, you'll have the FPGA pin number. I mention this because one of my early FPGA designs (perhaps my first) somehow got the wrong pin numbers for things, which meant nothing worked. Deleting the "project" in ISE and putting my HDL code in a new project, somehow magically made it work.Do the same thing with your clock signal; on the Papilio Pro it should appear on "P94".Is the code you're running what you think you're running? If you changed your design and didn't rebuild, or for some reason loaded an old bitstream instead of the new one, you could see some surprising results.That's all I've been able to think of. None of them seem super likely to me, I'm afraid, to match what you've been seeing. (In case you're wondering what modifications I made: I added a "clock enable" signal to your VHDL, and wrapped it in a little module of my own. The end result ran your code at 75Hz instead of 32MHz, and transmitted the output to my computer at 1200 baud as '0' and '1' characters. It would've been a lot easier if I hadn't messed up my own counter, and got 75baud and 600baud before finally getting the 1200 I was trying for.)
  10. I notice in the wiki, "http://papilio.cc/index.php?n=Papilio.PapilioPro" and "http://papilio.cc/index.php?n=Papilio.PapilioDUOHardwareGuide" both have a dead link for the Macronix SPI flash datasheet. The link "http://www.macronix.com/QuickPlace/hq/PageLibrary4825740B00298A3B.nsf/h_Index/3F21BAC2E121E17848257639003A3146/$File/MX25L6445E,%203V,%2064Mb,%20v1.8.pdf" fails with something about not being able to find the server us1spsp1.macronix.com. I've found another link on the Macronix site that seems to be the right one. But I can't tell, on my own, if it's the same document or not, since it's not my product. The link is: "http://www.macronix.com/Lists/DataSheet/Attachments/2249/MX25L6445E,%203V,%2064Mb,%20v1.8.pdf". Problem first noticed two days ago.
  11. Jaxartes

    A whole bunch of questions

    Here's my attempt at answering a few of the questions: 1. Both Papilio Pro and Papilio Duo have the same FPGA (Spartan 6). The Papilio Duo has an addition to that an AT micro controller chip. The Papilio Pro and Papilio Duo have different onboard, off chip memory. Papilio Duo is more recent but I don't believe it's compatible with "wings" like the RetroCade one, instead it takes Arduino-style "shields." 2. I'll note that I in turn am using Papilio Loader on Linux within VMware Fusion under Mac OS X 10.9.5. When I first got my Papilio Pro I tried setting up the loader on the Mac side, and had problems. (I don't remember what they were.) 3. I have no answer. Somebody would have to figure out why it's not working. (Tried building & running it just now, on my system, which is older than Yosemite. It compiles, and runs, and fails with "Could not access USB device 0403:6010. If this is linux then use sudo" and that's when run under sudo.) 4. I don't think the RetroCade synth board has any persistent state onboard. The actual work of the synth is done on the Papilio board. My Papilio Pro came preloaded with a demo program that wasn't for any particular wing. I don't know what it does on the RetroCade; on the Arcade MegaWing it causes some of the LEDs to blink and produces a clicking sound on the audio output. As for changing it, I believe the Papilio Loader can do that, though I haven't ever actually tried it.
  12. Rewiring and JTAG are outside my expertise, sorry. But I will note that according to the Papilio One Hardware Guide (http://papilio.cc/index.php?n=Papilio.PapilioOne), JTAG on this board already operates between 2.5V and 3.3V levels. It says the FTDI chip is 3.3V while the Spartan 3E's JTAG port is 2.5V. So maybe the problem is something else?
  13. Jaxartes

    FPGArduino - where FPGA meets Arduino - FER

    That occurred to me too. Though one potential advantage of FPGArduino is that you could conceivably start modifying the HDL, adding your own peripherals, etc; and still have an Arduino program do a lot of the heavy lifting for communication and control. I have no idea how it compares with DesignLab in that regard (having not tried either). They seem to be accomplishing the same thing. As for CPU architectures, the more the merrier. Especially ones that have good development environments available for them and are available for multiple FPGA platforms.
  14. Quick start doc: http://papilio.cc/index.php?n=Papilio.GettingStarted. It describes the Papilio Loader app which can take a ".bit" file produced by ISE and load it onto the FPGA. It's all I've ever used. I don't know if anyone has managed to get ISE to program the Papilio directly -- I vaguely recall hearing about it, but when I looked for the info now I couldn't find it. Maybe someone else will post the details. But all I've ever used is the "papilio-prog" command line, from the Papilio Loader app. Regarding UCF files, the GadgetFactory site has a few downloadable UCF files for the different boards. For example, http://forum.gadgetfactory.net/index.php?/files/file/2-papilio-one-generic-ucf/. You take the file, copy it, and edit to remove any pins you're not using in your design.
  15. I noticed tonight at http://papilio.cc/index.php?n=Papilio.Buy, the entry for the Classic Computing Shield is labelled "LogicStart Shield". Took me a moment to figure out why there would be two entries for "LogicStart Shield" with different prices.
  16. My question has to do with having devices plugged into one another, and into power, and the order in which they're plugged in (or powered on). I've got a Papilio Pro + Papilio Arcade MegaWing. It's connected to my laptop via USB, and that's how it gets its power. I've also got an LCD monitor attached to the VGA port on the MegaWing. And that gets its power (and ground) from mains, separately. Is there a "best" or "safe" (least likely to produce hardware damage) order in which to plug these in to one another? What I'm thinking of doing is: Plug display into power, then plug display into Papilio, then plug Papilio into computer. (Computer was on all the time.) That seems safest to me, but I'm not an expert on these things. A more convenient order, which I believe I've done but which seems riskier, is: Plug Papilio into computer, then plug display into Papilio, then plug display into power. I know that at least some computer manuals, historically, laid out rules for the order of plugging and powering. And of course, hot-plugging on a connection not designed for it is bad. But USB is supposed to be tolerant, and I've usually treated VGA like it is, too. So, is there a right order for doing this?
  17. Jaxartes

    plugging order guidelines?

    Ok. Thanks!
  18. Jaxartes

    Material for understanding IOBUF and clock routing

    I realize now I misphrased my #3; when I said "if I separate the synchronous and asynchronous parts" I should have said "if I separate the sequential and combinational" parts. That is, the part where a value is put in a register, and the part where it's computed. Which, anyway, isn't something I always do -- only when it seems to help.
  19. Jaxartes

    Material for understanding IOBUF and clock routing

    I've been assuming the opposite, that it doesn't make a functional difference which way you do it. I find my own reasons for choosing one over the other have to do with ease of writing/understanding: 1. If it's something simple, then it's easier to put it all in one place with "counter <= counter + 1". 2. But if I might use 'counterNext' in more than one place, I'll want to put the computation of it in one place, and the use of it in however many others are applicable. I don't know if the synthesis tools can infer that three different references to 'counter + 1' are the same thing, but if nothing else it's easier for me to tell that only a single "add" is happening. 3. And sometimes, when working on something tricky, I've found it easier to understand if I separate the synchronous and asynchronous parts.
  20. Jaxartes

    Serial port issues

    My question #3 about different baud rates -- was about different from 3Mbps, not from each other. A lower baud rate on both sides, might not be as demanding about timing. It's also possible that one side is not accepting the baud rate setting it was given. It's happened: I set my computer, and my FPGA design, to do 28,800 baud, but the computer did 38,400 baud instead. In that case the failure was blatant, though; not like this. I agree with Alvie's comment about reading fast enough. While our computers are able to process 3Mbps easily on average, doing it reliably, continuously, is another story. I'm not sure what-all buffers are involved in reading this serial port, but the FTDI chip's buffers are 384 bytes in one direction and 128 bytes in the other direction. At 3Mbps, a buffer-full would pass in about a millisecond. If the operating system schedules another task it may let it run for longer than that. (Depending on settings; I know our Linux platform at work is set to one millisecond, and many are set up for longer.) And random access to a spinning disk can take a few milliseconds. Although, that would only explain the loss of data (lines 3482108 through 3482112 in the output you posted); I don't see how it would insert the zero byte. And I've seen similar lossage at only 115.2kbps.
  21. Jaxartes

    Serial port issues

    Hmm. Miscellaneous thoughts, mostly things you could try in debugging: 1. You say your C program doesn't have the problem. Would it let you know if it got a 0x00 byte? Depending on how the C program is written, the 0x00 byte might be invisible. 2. What CPU utilization is shown by your Python program? Is there any chance it's failing to keep up with the 3Mbps data rate? (I have no idea what effect it would have, if it failed.) 3. What happens with a different baud rate setting? This could make a difference a number of ways. If something is failing to keep up with the speed, of course it would show here. And I had problems with one of my designs, where the host (computer) side was using a different baud rate than I told it to. (I didn't realize 28.8kbaud was nonstandard.) Then the problem was far more severe than this (all bytes were corrupted); I wonder if a small mismatch could cause subtler problems, though I don't think it should. 4. Just a random note, another program that can read/write the serial port on Linux is "screen /dev/ttyUSB1 [baudrate]"; exit with control-A backslash, or it'll leave a background process talking to the serial port.
  22. Ah, I see. So I would assume that the input to your function, increases smoothly (even linearly) with time? Then you might also consider the following: A simple low pass filter will smooth out a function. Two low pass filters will smooth out the function and its derivative -- and so on. And it should be fairly easy to make (though I haven't tried it on FPGA): Each filter has a state variable. The state variable might need extra precision.Every clock cycle, the state variable is updated: subtract some fraction of its difference from the inputMake that fraction of a power of two, so that "division" becomes easy.You would have to adjust the number of filters, and the exact fraction to subtract, to suit your application. Too many, or too-low frequency, and it becomes sluggish. Too few, or too-high frequency, and you still have sharp changes. But with such filters you could take a roughly approximate function and "smooth it out" to be good enough. Or have the filters do all the work, and use as your function the step function (it's here, then suddenly it's there in zero time). The calculation, at each iteration, is linear, even though the function it ends up producing, over time, is exponential. See also: low-pass filter, Butterworth filter.
  23. I'm fairly new to FPGAs myself (it's been 7 months since I got my Papilio Pro), so there may well be some tricks I'm missing. This issue seems like something lots of people will have dealt with. A generic solution might be presented as something quite different, and perhaps not as a matter of FPGA logic: It might be presented as digital logic design (since the same issue would apply on ASICs as well as on FPGAs). You might also try looking at SDRAM controller cores (such as Hamster's): their interface, and the structure of simple cores that use them (if any are simple). The SDRAM, like your lookup function, is a fixed, single resource with (sometimes) multiple uses. So they could provide an example of dealing with complex multiplexing. I'm curious, what is this function for?
  24. I think you're basically right. The BRAM has two read ports, so you could have two components accessing the lookup table at the same time. Any more, and they'd have to take turns. The logic for taking turns needn't be terribly complicated, but you'd have to make each component capable of waiting (for its turn). Another option, if you're planning on ten identical components using this lookup table, running in parallel at 100kHz, is: Redesign with a single component, running on ten different sets of inputs/outputs/state variables, at 1MHz. Of course, that's not an option if the logic of the components is quite different, or if you need higher speed or more components. (Also, when I tried something like this, the small fast memories needed for all those inputs/outputs/variables took up a lot more space on the FPGA than I'd expected.) And you'd have to make sure you're always working on the right set of inputs/outputs/state variables at any given time. I'll also point out, just using a BRAM, even without sharing it, leads to a couple of inconveniences: Each BRAM read takes a clock cycle: You get your result one cycle after your input went in. So that adds one pipeline stage to your logic.If your lookup table's input is 32 bits, and its output is 32 bits, then the total BRAM needed for the lookup table is 32*2^32 bits, that is 16 gigabytes! (Not 36 as I initially stated, oops.) This FPGA doesn't have nearly enough space.I have only vague thoughts about what you could do about the latter: If you can get away with reduced precision, at least on the input side, then it can fit: A lookup table with 14 bits input and 32 bits output would fit into the BRAM on the Papilio Pro or Duo, just barely. One with 11 bits input and 16 bits output would take up a single 2kB BRAM.On a small scale, smooth functions resemble straight lines. So you might have a small lookup table, and then interpolate between values in the lookup table. Linear interpolation would just require an addition or two and a bit shift. Quadratic interpolation would add multiplication into the mix, meaning you'd have to use one of the DSP blocks for it, but would get a higher-precision result out of a small lookup table.You might also exploit any patterns in your input. You'd know those, I wouldn't. But if each input is related to the previous input, that might also mathematically relate each output to the previous. Example: to synthesize an approximate sine wave without a lookup table, use the relation that sin'(x) = cos(x) and cos'(x) = -sin(x) (and do something about the continual loss of precision).
  25. Jaxartes

    About FPGAs and how to choice

    Re FPGA capability, short answer: It's complicated. And I'm almost a newbie, but here are some thoughts and pointers. For figuring out what a given FPGA can do, the best way is to look at what results people have gotten from trying similar designs on similar FPGAs. Somewhere on the forum there're discussions about resource usage and clock rate with AVR8 (an Atmel-compatible core) running on a Papilio board; the results may extend to other boards using the same FPGA chips. You can download vendor tools, and run them on an actual design (for whatever chips you have in mind) and see what results they give you. The general story is more complicated than number of gates or any straightforward set of numbers. It's going to depend on the particular FPGA architecture and the particular design and how the features of one make the other work. For instance, logic on the Xilinx Spartan3 (used in Papilio One) consists primarily of 4-input lookup tables (LUTs), while that on the Xilinx Spartan6 (used in Papilio Pro and Duo) is in 6-input LUTs. A 6-input LUT is "more logic" than a 4-input LUT, but it'd be hard to quantify how much more. Either one is more than a 2-input "gate" but again, by how much? And FPGAs have other, more specialized logic in addition to the LUTs: Block RAM, carry chains, multipliers. It can make a big difference, how well your design takes advantage of those. 10k gates sounds really small. Even 100k gates sounds small; the smallest that the Papilio series uses is 250k gates. Clock rate also can vary a lot, depending again on the particular logic design and how it fits into the FPGA's particular resources. It can vary pretty widely. 8MHz doesn't seem like a problem, though, for recent chips. Choosing an FPGA board often comes down to other things, for me it was what I/O devices are attached to it, and how it connects to a host computer. I found "100 Power Tips for FPGA Designers", by Evgeni Stavinov, very helpful. The e-book edition is much cheaper than the print one, by the way. (Code examples are in Verilog, but code examples aren't IMO the most important part.)