Luís Marques

Members
  • Posts

    12
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Luís Marques

  1. The reset behavior is automatically generated by the tools; you can choose from a predefined list of behaviors (sync (default), async, at boot (FPGA)) for each clock domain, but currently only synchronous is implemented. Any issues of guaranteeing proper timing of the async reset signals would be outside of the scope of the auto-generated RTL, so you would have to take care of that manually.
  2. - The circuits have an implicit clock, but you can specify your own input clock ports and assign those clocks to sub-circuits. Synchronization between those clocks domains is done manually; - You can integrate external Verilog / VHDL modules, so if your hard-IP blocks can be instantiated from Verilog / VHDL then you just instantiate one of those; - At its most basic, you manually instantiate the stages and registers that connect the various stages, just like in Verilog / VHDL. It should be possible to create higher-level abstractions based on that, but I haven't explored that yet. If you mean how do you use the times ("*") operator and automatically get a multi-cycle multiplier, you can't do that, not at the moment, you'll have to manually create a multiplier. Of course, you can design a generic/parameterised multiplier once and be done with that. You get more flexibility for creating generic components than with Verilog / VHDL, whose introspection abilities are a bit limited. You're from Coimbra? Yeah, we can meet there some time, or whenever you come to Lisbon :-)
  3. Hello, I've just returned from DConf 2017, in Berlin. There I gave a talk on how to use an extension of the D programming language (DHDL) to design hardware. I showed a demo of Classic Empire, a game written by Walter Bright (the original creator of D), running on a Papilio Pro, inside a soft-core RISC-V CPU, plus my own handmade "wing" IO accessories and respective controller IP blocks (VGA, 7-segment, sound, etc.). You can see a quick demo below: You can also see the full talk, if it sparks your interest: Thanks to the generosity of GadgetFactory, we raffled a Papilio Pro and some accessories to the participants of the talk: Gauging from his reaction, Vang Le was very surprised and happy to be the winner, and he's looking forward to exploring the world of FPGAs. In my demo I loaded the binary code for the game through the USB/UART, using a custom utility. In the next few months I plan to further tweak this demo, so that the game code is loaded from flash and it works with standard GadgetFactory wings. When that is done, I'll provide the bit stream files for the combined hardware design + the game. Walter Bright has indicated that he would provide permission for the FPGA version of the game to be distributed freely, so GadgetFactory could use it for its showcase. Later, I will provide the source code for my whole setup; I used the LDC 2 D compiler with the (old) LLVM RISC-V backend, and I had to workaround a lot of bugs of invalid RISC-V code. When the new LLVM RISC-V backend is released I expect all of that to be alleviated or completely fixed, which will help with the release of the complete demo setup. I'll keep providing updates and feedback here on the GadgetFactory forums. You can also follow me on Twitter (@Luis3m), or email me if you have any questions (http://www.luismarques.eu/about). Also, a shout-out goes to Mike Field, whose book / tutorial helped me get started with FPGAs and hardware design. I shared the love for his book with some conference participants :-) So long, Luís
  4. On Windows 8 ArcadeBlaster didn't seem to work properly. I installed it on a Windows XP VM, but I didn't manage to get PacMan (or any other thing, IIRC) working on a Papilio Pro + LogicStart. I managed to get the DesignLab working on Windows XP (I didn't try it on newer Windows versions), and I tested that the audio DAC on my LogicStart is still working. I thought I had managed to blew it up somehow (although I don't know how I would blow up an RC filter), but it's working all right. (The audio jack doesn't seem to like stereo plugs though, if you insert the jack fully it only plays the mono audio on one side...) Now I have to figure out why the audio doesn't work correctly on my own RTL... I figured out the original problem (I had used the sox program to convert all my audio files to a known 8-bit 11K bitrate raw format, but I hadn't specified unsigned PCM, and my delta-sigma logic was using unsigned integers) but while diagnosing this issue the sound started playing at an extremely low volume and with an high pitch noise, and I'm not figuring out what's wrong... and I didn't keep a commit with the original design >< ...) Thanks for the help!
  5. Hello, Do you have a .bit file for the Papilio Pro + LogicStart that plays some audio? Something weird is going on here, and starting with a known good .bit file would help Thanks, Luís
  6. Thanks for the feedback Jack. Here's what I would expect to see. With 3.3 V (IOSTANDARD=LVTTL) and a 1K resistor, I would expect a current of 3.3 mA. Given the DRIVE options of 2, 4, 6, 8, 12, 16, 24, I would expect all of the DRIVE values other than 2 to let the full 3.3 mA to flow. Here's what I get: DRIVE=2: 2.85 mA DRIVE=4: 3.05 mA DRIVE=12: 3.18 mA DRIVE=24: 3.22 mA The values for DRIVE > 2 make some sense to me, since they are within a somewhat reasonable margin of 3.3 mA (< ~9%). With DRIVE=2 I don't get the expected current limit of 2 mA, by a large error margin (~42%). With the 'scope I didn't detect any weird power switching pattern.
  7. I was looking into how to limit current from FPGA pins, in the context of safely driving 7-segment LEDs. I thought that the .UCF output drive strength values were somewhat arbitrary values, but according to "Spartan-6 FPGA SelectIO Resources User Guide" the values are actually in mA. Nice. Yet, when I went to test this I got unexpected values. For instance, when I chose LVTTL & DRIVE=12 I think I got something like 46 mA, and when I reduced it to DRIVE=2 I think I got 6 dot something mA. Whatever it was it was very different from the specified DRIVE value. This was tested by shorting that pin to GND, with just the amp meter in series. Since the current did reduce when I reduced the drive strength, I though that maybe my cheap multimeter was not correctly calibrated. Yet, when I connected a 6.1 V power source with a 1K resistor in series I got the expected 6.1 mA. Any ideias?
  8. OK, I told you I felt like was going insane, right? I now know why... So today my oscilloscope arrived. I unpacked it, connected the power, calibrated the probes and explored the menus. Then I started examining the VGA sync signals of the Papilio + LogicStart, so that I knew what kind of signals I should expect to see when I used my homemade perfboard megawing. I explored all kinds of triggers, statistics, etc. Ahh, it's good to not be blind anymore and have a 'scope. Once I was confident I knew how to use this scope and understood the VGA signals I though "OK, time to connect my homemade megawing". In my homemade perfboard megawing I decided not to match the LogicStart pinout because the layout would not be very convenient for the perfboard I was using. So the first step was to change the .UCF file contents to the one I had written to match my homemade megawing. And as I was doing this I looked again at the contents and suddenly I had a chill: "wait, I have a few pins I'm not using... including the the 7 segment displays I haven't soldered yet... and also... oh my god... I have a reset pin assigned to the LogicStart joystick click... and now this pin is not connected to anything... so it's floating... oh god, don't tell me that...". So I changed my top level verilog file to ignore the reset port, and re-synthesized. I double-clicked the shortcut I had created to upload the bit file to the FPGA and... I got a 100% perfect image. Not only did I get a good sync, but the colors matched perfectly. So my perfboard circuit had been perfect all along, including the color components. No wonder I thought I was going insane. No matter how much I tried to diagnose the electrical part (without looking at the signals, i.e. just the DC components) I was never going to find any fault. Duh. I feel silly, but also relieved. I mean, my confidence was plummeting. I'm not an EE by training by I though a simple circuit like this wasn't going to be a challenge. So when it did prove a challenge it was time for a bit of soul searching. But now I've come back from hell, having slayed the beast, holding its head by its hair. Muhahaha. Bow before me, silly VGA monitor. Anyway, that's what happens when you make a silly mistake and 1) assume too much about where the fault generally should lie, and 2) don't have the adequate equipment to quickly diagnose it. Not that I ended up needing the scope to diagnose this... Thanks for all the feedback, guys.
  9. Jack, thanks for the feedback. I tried a lot of things, here are some highlights (not in chronological order, for clarity): 1) When I use Papilio + LogicStart, and manually connect vsync and hsync between the LogicStart VGA plug and a VGA cord by using jumper wires it works (even without connecting any GND!). 2) On the other hand, when I manually connected (using jumper wires) the same pins between the Papilio and the LogicStart it never worked (with or without GNDs). This persisted even when I used a lower resolution / clock rate and/or increased the drive strength of the vsync / hsync FPGA pins or used different slew rate, etc. 3) One of the first things I had tried, thinking I might just have loose connections on my jumper wires (despite doing continuity checks with my multimeter), was to use header pins. So I soldered resistors to a 16-pin header on row B (the one used by the LogicStart for VGA), at first just vsync/hsync and GND. Fail. Maybe my monitor needs to detect something on the color pins? So I solder some resistors for the color pins. Fail. OK, maybe try a different monitor? Fail. Wait, let me check that the header pins are 100.0000% in. I got an image on my TV. That was the only time something other than 1) worked. 4) Given the eventual success on point 3), at that time I had assumed that my previous failures were probably due to improper electrical contacts, although that was a bit strange given that the LogicStart seems to work very well even when it is far from well plugged in. So in a perfboard I soldered 3 rows of 16 pin headers + 6 rows of 4 pin headers, to fully match the 2 Papilio wings / 3 rows and power pins. This provided a very good mechanical connection, similar to connecting the LogicStart, and with continuity testing I verified every pin. Then I soldered the appropriate resistors to replicate the VGA voltage dividers of the LogicStart and checked the connections and total resistance (because I had to use multiple resistors to match some of the values). Then I soldered a VGA connector. Fail. Despite testing for the appropriate continuity and resistance multiple times and in different ways, so far my perfboard has been a failure. 5) Which brings me to my last point. I did all of this without an oscilloscope, which would have helped a lot. For instance, I went back to soldering just two resistors for the 2 sync pins but cutting the resistor pins and connecting wires as short as I could, in an attempt to try to reduce any interference. But that failed too (on my standard monitor, did not try it on the TV where I had the success). Without really seeing the waveform I'm flying blind, my cheap multimeter only helps so much. So today I gave up on this for now and ordered an oscilloscope. I had been delaying this purchase for several reasons, but one of them was that I wanted something that allowed me to reasonably see the waveform for the SDRAM pins, which precludes choosing some of the cheaper scopes. I went for a Siglent SDS1202X (200MHz 2ch 1 GSa/s), which might just cut it for the SDRAM (one tradeoff for the higher bandwidth is that I had to go with a 2ch scope, otherwise the prices skyrocketed...). So now I'm waiting for the scope before wasting any more time on this. More news next week....
  10. Yup, I did connect those. I tried multiple (equivalent) pin positions even -- just in case; also at multiple places too, just in case (e.g. multiple GNDs pins connected at the same time). Although looking at the schematic I think +3.3V and +5V are not used for the VGA. The only voltage source (with respect to GND) comes directly from the FGPA pins to the color components and [v|h]sync pins, I think.
  11. I think I'm going insane. I have a Papilio Pro + LogicStart MegaWing. I'm displaying a VGA image by using both (108 MHz, 1280 * 1024 * 60 Hz). So far so good. OK, now I disconnect the LogicStart MegaWing and I manually connect the pins relevant for VGA between the Papilio and the wing by using jumper wires . My VGA display says no signal. I've checked the wiring more times than I can remember. WTF? As a sanity check I tried connecting the relevant wires for a 7-segment display segment (1 segment + 1 anode + GND) and it worked. No luck so far with VGA though... Can anyone reproduce this issue? Which pins did you connect?
  12. Hello, In the Arcade MegaWing schematic each VGA color component has two diodes and one capacitor. Could anyone clarify the following? 1) what are the values of these diodes and capacitors? the schematic doesn't say, it has only a "BAV199" marking 2) In the image <http://papilio.cc/images/Arcade_MegaWing1.jpg> I see empty soldering pads near the VGA connector, so I guess the diodes and capacitors were not actually installed on production boards, were they? I guess they are not essential, since the LogicStart MegaWing doesn't have them. 3) Essential or not, what is the purpose of that part of the circuit? Thanks a lot!