All Activity

This stream auto-updates   

  1. Today
  2. Good work Alvie
  3. Last week
  4. Sometris game

    Original version of game was running on PIC18F6622 and Dingoo A320. Now it's running on Papilio One 500K + Arcade Megawing. I've used the ZPUino soft processor which is realized by Xilinx Spartan-3E FPGA. VGA signal is also generated by the FPGA. The game can be played with integrated buttons of Arcade Megawing or with Atari/Commodore joysticks. I've used a QuickShot II Plus (SVI-102 Plus) joystick in the video below: Demo Please, use the .bit file included in the ZIP. Otherwise buttons and joystick are not working properly. sometris_v121.zip
  5. Hi Jack, Sorry for the delay. Attached is the file. Thanks, fpga_guy top.bit
  6. Hello Thomas, Yes, it will continue with SDRAM, we have identified an ISSI SDRAM chip to use instead but there is still some work to be done to verify before we do the next run of boards. I'm also seeing if I can find a supply of the current SDRAM chips to do one more run of the Papilio Pro with the current chip. Jack.
  7. 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.
  8. Are there still SDR-SDRAMs on the market? DDR will be difficult with a soft memory controller, and SRAM is small and expensive... I'm currently working on a project which implements th RISC-V ISA (see riscv.org) and runs a port of eLua to this architecture on a Papilio Pro. It is making great progress, I will post more information here in the forum in the next days. I'm already thinking about moving to another board (e.g. Pipistrello, Arty). But in some way I like the PaPro a lot: It is "publishing friendly" because I don't need a Xilinx CoreGen generated core to access the DRAM. With ISE a synthesis run for the LX9 usually takes only a few minutes including map, place and route, so it is possible to quick check design changes in Hardware As long a design fits in the LX9 it is really a convenient platform. And Xilinx has recently announced that they continue supporting the Spartan 6 series because of their success. Thomas
  9. It's not retired but the SDRAM chip that is used is obsolete. We are looking for replacements which will take a little time... Jack.
  10. I don't think its a good idea to connect directly to ground... I think that drive strength is how much current it will provide through that pin under load. So put a load in by connecting a 1k resistor in series with your ammeter and then see what the current is... Jack.
  11. 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?
  12. Hi, I have seen the pro is out of stock, and also can't be preordered. Will it be in produced again or is the product retired? Regards Thomas
  13. Thanks for the suggestions/precautions. I understand your message completely. I have been an electronic technician for many years. However I don't feel that troubleshooting the board has a high likelihood of actually fixing it (I have no experience with SMD..); so I won't be going to the trouble. Paul
  14. Jack, Thank you. I've sent the email. Because of typos on my part you may receive more than one email. Paul
  15. psehorne, We can replace the board for you if you feel confident there is an issue with it. Just send us an email to support@gadgetfactory.net with your shipping address and a link to this email. Jack.
  16. Congratulations on finally breaking this one loose. The scenario like you describe has happened to me several time too. It's so easy to get the blinders on with this type of work. You think you know what the problem is so you just go further and further down the rabbit hole trying to fix it and it turns out to be something simple somewhere else. Good job and I'm sure you will not regret the Oscope. Jack.
  17. 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.
  18. Hi, the very bright decimal points were indeed one "feature" of the resistor-less board. But best take a magnifying glass and look for the resistors, then you have peace of mind. I'd simply use a multimeter in diode mode on the headers to check the segments, or jumper wires to +3.3 V / GND (but don't do this without resistors or there will be 7-segment magic smoke).
  19. You can post your bit file here and one of us can try to load it to our Papilio Pro board and see if it is the same result. That would let us know if it is just your board or the bit file... Jack.
  20. Just received my Pro and MegaWing a couple of days ago. I have not been able to get segments in digit 0 to light up. Below is the VHDL that works for the other three digits. Seg7_AN(x) (all four 0 through 3) are all un-commented in the ucf file, and I get no compile errors. The Seg7_test process flashes all the other three digits once per second. EDIT-1:You can disregard the code referring to LEDs and Switches; that all works too, and it not relevant to the problem. EDIT-2: One other thing of note. The decimal points (of the three working digits) are very bright, but the other elements are very dim - hardly visible in normal room lighting. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity Seven_Segment_LED is Port ( Seg7_AN : out STD_LOGIC_VECTOR(0 to 3); Seg7_A : out STD_LOGIC; Seg7_B : out STD_LOGIC; Seg7_C : out STD_LOGIC; Seg7_D : out STD_LOGIC; Seg7_E : out STD_LOGIC; Seg7_F : out STD_LOGIC; Seg7_G : out STD_LOGIC; Seg7_DP : out STD_LOGIC; CLK : in STD_LOGIC; -- 32MHz for Papilio Pro, period 31.25 ns JOY_SELECT : in STD_LOGIC; SWITCH : in STD_LOGIC_VECTOR(0 to 1); --reversed LED : out STD_LOGIC_VECTOR(0 to 3); LED1 : out STD_LOGIC); --reversed end Seven_Segment_LED; architecture Behavioral of Seven_Segment_LED is signal Counter : STD_LOGIC_VECTOR(24 downto 0) := (others => '0' ); signal CLK_1Hz : STD_LOGIC; constant Seg7_AN_ON : STD_LOGIC := '0'; constant Seg7_Element_ON : STD_LOGIC := '0'; begin LED(0) <= SWITCH(0) AND SWITCH(1); LED(1) <= SWITCH(0) OR SWITCH(1); LED(2) <= SWITCH(0) XOR SWITCH(1); LED(3) <= (NOT JOY_SELECT) or CLK_1Hz; -- Joy Stick normally high, acitve low. -- So line below holds LED1 on until JS_Select ir pressed. -- Then LED1 will flash at the rate of the preselector counter CLK_1Hz. LED1 <= JOY_SELECT or CLK_1Hz; Seg7_test: process (CLK_1Hz) -- flash LogicStartMegawing 7-segment LEDs at 1Hz begin Seg7_AN(0) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; --CLK_1Hz; Seg7_AN(1) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; Seg7_AN(2) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; --CLK_1Hz; Seg7_AN(3) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; --CLK_1Hz; Seg7_A <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_B <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_C <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_D <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_E <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_F <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_G <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_DP <= Seg7_Element_ON; --NOT CLK_1Hz; end process Seg7_test; Prescaler: process (CLK) -- flash onboard LED1 at 1Hz begin if rising_edge(CLK) then if Counter < "111101000010010000000000" then -- counter to clock freq /2 Counter <= Counter + 1; else CLK_1Hz <= NOT CLK_1Hz; Counter <= (others => '0'); end if; end if; end process Prescaler; end Behavioral; Only after I had this problem did I search this forum. I found hits about no current limiting resistors. But those discussion are a few years old, and at the time Mr Gassett stated that new boards were coming out with current limiting resistors. I just received my boards this past week; could my boards be old stock without the current limiting resistors; or is there a problem with my code?
  21. Earlier
  22. I don't think UART pins are the problem because everything works fine when I download to the FPGA. It only behaves badly when I try to write it to the serial flash. The Microblaze MCS program is written to sends the "Hello World" message at a fixed interval continuously. It only sends one char when I write it to the flash. fpga_guy
  23. Ah, that is a good idea... the crosstalk can make it kind of work sometimes... That sort of thing has happened to me before. Jack.
  24. Hi, random guess: Is it possible that the UART pins are swapped? It seems unlikely, but undriven digital inputs can do this kind of crosscoupling voodoo.
  25. If it helps: there is no need for resistors. You can plug male-female jumper wires into the FPGA board on one side and a 15 pin VGA cable on the other (the diameter of the pin matches). I'm using this as a standard debug tool in 640x480 just HSYNC, VSYNC, GREEN (on/off) and GND. The voltage is slightly out-of-spec but the monitors I've tried with didn't object. I think you won't regret buying a scope. Another immensely useful and free tool is an "activity detector" where you trigger a counter using an unused input and put e.g. every 5th bit on a different LED. Then plug a wire into the input and probe as needed. You could try to fit a SUMP logic analyzer core into the design (disclaimer, never tried this myself. For me it works as advertised on a 2nd board). Edit and pay attention to your programming LED. It is possible that the FPGA resets for whatever reason (e.g. random short circuit on 3.3 V when you move the boards a certain way).
  26. No, the scope is absolutely what you need to troubleshoot this. That and a logic analyzer when you need to see what is happening on more then two pins at the same time. I bet you get it figured out in a couple hours with the scope. Jack.
  27. 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....
  28. that is an odd one... I would recommend opening up your xise file in a text editor and compare it to a known working xise file... Jack.
  29. Load more activity