Cactus

Members
  • Content count

    35
  • Joined

  • Last visited

Everything posted by Cactus

  1. I'd like to use CLaSH (http://www.clash-lang.org/) with a Papilio Pro. By and large, it works; however, CLaSH requires an asynchronous, active-high reset spike to initialize registers. This is because CLaSH generates assignments on RESET only, instead of initializers; here's an example VHDL generated from CLaSH: -- Automatically generated VHDL-93 library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.NUMERIC_STD.ALL; use IEEE.MATH_REAL.ALL; use std.textio.all; use work.all; use work.blinkertop_types.all; entity blinkerTop is port(-- clock CLK_32MHZ : in std_logic; -- asynchronous reset: active high RESET : in std_logic; LED : out std_logic); end; architecture structural of blinkerTop is signal \#tup_app_arg\ : unsigned(31 downto 0); signal \s'\ : boolean; signal \#s'_case_alt\ : boolean; signal s : boolean; signal \#finished_case_alt\ : boolean; signal \#k'_case_alt\ : unsigned(31 downto 0); signal ds : blinkertop_types.tup2; signal \#finished_app_arg\ : signed(63 downto 0); signal x : unsigned(63 downto 0); signal x_0 : blinkertop_types.tup2; signal \x#\ : unsigned(63 downto 0); signal k : unsigned(31 downto 0); signal \#w\ : unsigned(63 downto 0); begin LED <= '1' when \s'\ else '0'; \#tup_app_arg\ <= resize(to_unsigned(0,64),32) when \#finished_case_alt\ else \#k'_case_alt\; \s'\ <= \#s'_case_alt\ when \#finished_case_alt\ else s; \#s'_case_alt\ <= false when s else true; s <= ds.tup2_sel0; \#finished_case_alt\ <= tagToEnum(\#finished_app_arg\); \#w\ <= (\x#\ + to_unsigned(1,64)); \#k'_case_alt\ <= resize((resize(\#w\(31 downto 0),64)),32); -- register begin blinkertop_register : process(CLK_32MHZ,RESET) begin if RESET = '1' then ds <= ( tup2_sel0 => false, tup2_sel1 => resize(to_unsigned(0,64),32) ) -- pragma translate_off after 1 ps -- pragma translate_on ; elsif rising_edge(CLK_32MHZ) then ds <= x_0 -- pragma translate_off after 1 ps -- pragma translate_on ; end if; end process; -- register end \#finished_app_arg\ <= to_signed(1,64) when x = to_unsigned(32000000,64) else to_signed(0,64); x <= resize(\#k'_case_alt\,64); x_0 <= ( tup2_sel0 => \s'\ , tup2_sel1 => \#tup_app_arg\ ); \x#\ <= resize(k,64); k <= ds.tup2_sel1; end; (Note how `ds` is not initialized but set in the `blinkertop_register` process when RESET is high) Of course, for a simple circuilt like above, where the initialization is for 0 anyway, just setting RESET to always low works; however, any slightly more complicated circuit will need register initialization to non-0 values as well. In these cases, I really need the spike. Is there a pin on the Papilio Pro that I could use in my UCF file to get this reset spike? I was able to get it working, in more complicated circuits requiring non-0 initialization, by using a (negated) LogicStart joystick direction, but this approach has two problems: I am getting a warning from the Xilinx tools that the joystick input shouldn't be used for reset or anything clock-like: WARNING:Place:1109 - A clock IOB / BUFGMUX clock component pair have been found that are not placed at an optimal clock IOB / BUFGMUX site pair. The clock IOB component <RESET> is placed at site <P57>. The corresponding BUFG component <RESET_IBUF_BUFG> is placed at site <BUFGMUX_X3Y13>. There is only a select set of IOBs that can use the fast path to the Clocker buffer, and they are not being used. You may want to analyze why this problem exists and correct it. This is normally an ERROR but the CLOCK_DEDICATED_ROUTE constraint was applied on COMP.PIN <RESET.PAD> allowing your design to continue. This constraint disables all clock placer rules related to the specified COMP.PIN. The use of this override is highly discouraged as it may lead to very poor timing results. It is recommended that this error condition be corrected in the design. I would like my circuit to start in an initialized state instead of requiring me to press a button
  2. For my next project, I need to use a PS/2 keyboard as an input device, and a 1602 LCD module for output. This means I will need a PS/2 port and some free pins (six to be exact) at the same time. What options do I have if I don't have a standalone PS/2 wing? My current plan is to take an Arcade MegaWing, and put it on a Papilio One flipped, i.e. by leaving the connector marked U$1WING2 free, and then use some male-to-male jumper cables on that connector to connect to the LCD on a breadboard. By re-mapping the pins in the UCF file, I should be able to get one of the PS/2 connectors working that way, right? Is there a better way to achieve this?
  3. I just got the PS/2 wings in the mail, thank you! I've meanwhile manned up and made a PS/2-to-breadboard adapter by soldering a PS/2 connector to a stripboard; that went well apart from mixing up GND and Vcc on the first try, frying the keyboard... Check the result:
  4. Cactus

    Output voltage on pins

    What is the output voltage level for 'high' signals on the Papilio Pro? I'd like to communicate with 3.3V components from it, is that possible by just connecting directly to the pins? I see there are separate 3.3V and 5V power pins. If I have a component that requires 3.3V signals and another that requires 5V, is there a way to communicate with both with a single Papilio Pro?
  5. Thanks, by moving the Arcade MegaWing (instead of flipping), and using P85/P83 of the Papilio One as the PS/2 DATA/CLK lines, I got it working. However, my schedule has also changed, and so I might have enough time to wait for the PS/2 wing, so I'll be taking you up on your offer. I'll send my shipping details in a private email. Thanks a lot!
  6. Cactus

    Output voltage on pins

    Thanks; I've tried and managed to drive the 5V device (a 1602 LCD) with the 3.3V signals (and 5V power of course).
  7. Thanks a lot Jack, I might take you up on that offer -- but I'm in Singapore and I'd like to build this in time to show it off at a meetup in two weeks' time, so waiting for extra parts is not an option. So will a flipped Arcade MegaWing work?
  8. Cactus

    Output voltage on pins

    Thanks, that's very helpful. And what if I need to do output to a 5V device? I guess I could use one transistor per line, but is there an easier way?
  9. So, on a Papilio One 500k, I would use bscan_spi_xc3s500e.bit as the -b file? And the Java GUI just auto-detects it and picks the right one?
  10. Hi, I can use papilio-prog -f foo.bit to upload my bitstream to RAM, or I can use the Java GUI to flash it. Is there a way to use papilio-prog to flash to SPI from the command line? The obvious flag would seem to be -b, but that just results in: Please specify main bit file (-f <bitfile>)
  11. Hi, I'm trying to use the PS/2 port of the Arcade MegaWing using a Papilio One. Before diving into it headfirst, I thought I'd try some off-the-shelf code from someone who actually knows what he's doing, so I found a very simple PS/2 driver at http://soclab.cn.nctu.edu.tw/course/FPGA102/ps2_ctrl.pdf. The attached zipfile is a Xilinx ISE archive of my version of that code. All it tries to do is set LED3 to high after the first key is pressed. LED1 and LED2 are connected directly to the PS/2 Clock and Data ports. Before I even connect my keyboard (a Microsoft Natural 4000 via a USB-to-PS2 dongle) to the FPGA, LED1 and LED2 are already continuously on. After I connect it, both LEDs stay on, and if I press a key, LED3 doesn't turn on. I should also add that there's a LED on the keyboard itself that shows that the keyboard is definitely at least connected to the power pins. What am I doing wrong? ps2.zip
  12. Cactus

    PS/2 ports on Arcade MegaWing

    Thank you everyone for your help -- the solution was indeed to get a proper PS/2 keyboard. Now all the test configurations work as expected.
  13. Cactus

    PS/2 ports on Arcade MegaWing

    I'll try getting a true PS/2 keyboard and will report back.
  14. Cactus

    PS/2 ports on Arcade MegaWing

    Alex: Thanks! Can you maybe send me a bitfile for testing? I am now at the point where I'd like to make sure the hardware (incl. the usb -> ps2 dongle!) is working before looking at anything else.
  15. Cactus

    PS/2 ports on Arcade MegaWing

    I have now also tried the code from http://ec2-122-248-210-243.ap-southeast-1.compute.amazonaws.com/mediawiki/index.php/Papilio_S6/Keyboard_Joystick, by connecting joy_up directly to one of the LEDs. If I understand correctly, that should result in the LED lighting up as long as I am pushing the left cursor key on the keyboard, right? Still doesn't work.
  16. Cactus

    PS/2 ports on Arcade MegaWing

    I've added this question to Electronics.SE: http://electronics.stackexchange.com/questions/99277/using-the-ps-2-port-of-the-papilio-one-fpga-from-vhdl Does someone have a ready-made .bit file I could upload to a Papilio One + Arcade megawing and smoke-test the PS/2 connectors? Something that flashes the LEDs when keys are pressed on an attached keyboard, etc.?
  17. Cactus

    PS/2 ports on Arcade MegaWing

    I have now also tried https://github.com/thelonious/ps2_io/tree/master/keyboard_scan_code again with a slight change that should light up LED<0> on the first successful keyscan (see attached), and that doesn't work either. Does anyone have a full .bit file I can use to just smoke-test the Arcade PS/2 ports? I'm starting to think the hw or the USB dongle might be at fault here. keyboard_scan_code.zip
  18. Cactus

    PS/2 ports on Arcade MegaWing

    My goal is 100% learning VHDL and building stuff from first principles. I've meanwhile found a Papilio-oriented tutorial at http://hamsterworks.co.nz/mediawiki/index.php/Papilio_Plus/PS2_Keyboard, which I tried to port over to the Papilio One by replacing the UCF file with the attached one. However, it also seems to have the same behaviour: pressing keys doesn't seem to result in any change to the LEDs. keyboard-ucf.zip
  19. Cactus

    PS/2 ports on Arcade MegaWing

    I should probably also add that of course I don't know if LED1 and LED2 really are continuously on, I haven't filmed it with a 32M fps camera
  20. Hi, I've finished the first version of my first ever FPGA project: a CPU that uses Brainfuck as its machine language. See http://gergo.erdi.hu/blog/2013-01-19-a_brainfuck_cpu_in_fpga/http://gergo.erdi.hu/blog/2013-01-19-a_brainfuck_cpu_in_fpga/ for details. Now, I'd like to split it into two parts so that I can upload the CPU definition proper into the FPGA's flash memory in one go of papilio-prog, then upload the programs (preferably as a raw blob, i.e. without any processing on the original Brainfuck program file) by running papilio-prog again. So basically, I'd like to be able to upload ROM data without having to re-load the hw configuration bitfile. Is this something that's somehow possible with papilio-prog? How? Thanks, Gergo
  21. Hi, After taking the baby steps with my brand new Papilio One + LogicStart and playing around with it, I've noticed now that there's a weird ghosting effect going on with the rightmost digit of the seven-segment display: if I set any of the other anodes to low and the rightmost one to high, the segments of the rightmost one still light up faintly. This doesn't happen with any of the other digits. Now, of course I first thought it was my time-multiplexing code that was wrong, but it even happens with the simplest possible static code: SS_DP <= '1'; SS_ANODES <= "0111"; SS_SEGS <= "1010101"; This will light up the first digit with a wierd Y-like shape, but will also light up the fourth one slightly. This started happening after a couple of weeks, and I haven't disassembled and reassembled the LogicStart megawing from the main FPGA board in the meantime, so it kinda just started happening overnight. Any ideas what this could be? How I could fix it? Please note that it might not be easy for me to get access to a multimeter. Thanks!
  22. Hi guys, I haven't had time to even plug my Papilio in for a month now (combination of illness and day-job deadlines), and today when I turned it on, the issue seems to be... gone. As if the fix was to just let the board lay around for about a month... Is this a significant new clue?
  23. Hi Jack, Wow, that sounds like awesome service! However, I'm in no hurry (I can work on my lame projects with just 3 digits for now), and so I'd prefer to wait for you guys to figure out if the current is limited enough with the current design; if not, I'd rather wait for the next iteration of the design to be manifactured. To answer other questions: The video was recorded in a room at night, but with the lights on Is the transistor dirty -- how do I check? I've tried basically just running my finger over the exposed leads around the display. Does PULLUP/PULLDOWN on SS_ANODES<3> help -- not at all. When driving the digits with a constant work cycle, the brightness of the digits definitely depends on the number of digits turned on. Thanks, Gergo
  24. Hi Jack, Thanks, I got it working with this (although I didn't check the VGA output). Unfortunately, the flickering ghosting issue remains. I am now sure it is a hardware issue. Is there something I can do to fix this, or do I just need to write it off and order a new one? Thanks, Cactus
  25. OK so I figured out the rotated UCF file on my own, based on http://www.gadgetfactory.net/blog/wp-content/uploads/2011/02/Papilio_Pins.png: # 7-segment display NET "SS_ANODES<0>" LOC="P11" | IOSTANDARD=LVTTL; NET "SS_ANODES<1>" LOC="P5" | IOSTANDARD=LVTTL; NET "SS_ANODES<2>" LOC="P94" | IOSTANDARD=LVTTL; NET "SS_ANODES<3>" LOC="P91" | IOSTANDARD=LVTTL; NET "SS_SEGS<6>" LOC="P9" | IOSTANDARD=LVTTL; NET "SS_SEGS<5>" LOC="P98" | IOSTANDARD=LVTTL; NET "SS_SEGS<4>" LOC="P95" | IOSTANDARD=LVTTL; NET "SS_SEGS<3>" LOC="P3" | IOSTANDARD=LVTTL; NET "SS_SEGS<2>" LOC="P2" | IOSTANDARD=LVTTL; NET "SS_SEGS<1>" LOC="P10" | IOSTANDARD=LVTTL; NET "SS_SEGS<0>" LOC="P4" | IOSTANDARD=LVTTL; NET "SS_DP" LOC="P92" | IOSTANDARD=LVTTL; # Input SW NET "SWITCH<7>" LOC = "P18" | IOSTANDARD=LVTTL; NET "SWITCH<6>" LOC = "P23" | IOSTANDARD=LVTTL; NET "SWITCH<5>" LOC = "P26" | IOSTANDARD=LVTTL; NET "SWITCH<4>" LOC = "P33" | IOSTANDARD=LVTTL; NET "SWITCH<3>" LOC = "P35" | IOSTANDARD=LVTTL; NET "SWITCH<2>" LOC = "P40" | IOSTANDARD=LVTTL; NET "SWITCH<1>" LOC = "P53" | IOSTANDARD=LVTTL; NET "SWITCH<0>" LOC = "P57" | IOSTANDARD=LVTTL; With this setup, I get the exact same ghosting issue, which I guess means the problem is on the LogicStart, not on the main board (which I guess is good news if it turns out I need to replace it)