Leaderboard

Hello, I am using DesignLab 1.0.8 under Linux and I have a small problem when generating new bit files. The problem is that the case of the files is different from the default and therefore the IDE won't flash my new file. I either need to rename the file or create a symlink. For example the Multiple_Serial_Ports example Creates a Papilio_Pro.bit file while the IDE expects papilio_pro.bit. With kind regards

I have used SK Pang Electronics (skpang.co.uk) which is a company based in the UK. I just checked and they have the Papilio Pro and Duo in stock. They are out of stock of other items. I noticed that prices rose significantly around the time of the Brexit result, and the fall of the UK pound against the dollar and other currencies. Then again you will get a better rate with the euro against the pound, which will offset for you. Buy now while the UK is still in the EU :-) good luck... --Gary

The libraries are a fantastic aspect of the Arduino and the key thing that makes it a worthwhile if otherwise rather flawed platform. It took me a long time to warm up to Arduino but I love the way I can grab some widget and very often grab a library with example code to make it do something right away. It provides a great way to test the thing out and explore its capabilities right off the bat. I'd love to see a similar collection of HDL modules form, blocks of code that do the grunt work like initializing the device and communicating via whatever interface it uses and bring the controls out to sensible interfaces that can be tied into other modules in the top level file. Ideally these modules should be well commented, especially at the top level explaining what all the inputs and outputs do and what sort of signals they expect.

Hmmm... the old Papilios use the FT2232D USB chip, the newer ones (e.g. Papilio Pro) the FT2232H high speed variant. With a more recent board, uploads "should" be fast. I'm using high speed (30 MHz, clock divider 0) JTAG with the -H chip routinely. For xc3sprog, it may be enough to write cables.txt via command line option, then edit the clock rate. I think I've done that once and got upload times (but probably for a compressed bitstream) 200 ms or so.

Another update. I've now returned to Mike Field's original design, and done some work to port this to the Papilio Duo + Classic Computing shield. The main difference from the Papilio Plus is the memory is 512KBx8 rather than 256KBx16. This entailed a re-write of the memory controller to deal with half the memory bandwidth, but nothing else. I also added in the colour maps from Larry's Mandelbrot-Explorer. This is working very nicely indeed, panning is super smooth, and multiple colour maps is really funky. The picture below doesn't really do it justice! If anyone want to try this out, the source is it github, and I'm happy to post a .bit file on request: https://github.com/hoglet67/DSPFract Dave

Update: I decided to try a newer Arduino library for the Wii chuck and a test sketch to read the buttons and joystick position and surprisingly it worked perfectly. I then took a Digilent Analog Discovery and used the Waveforms software to have a look at what was happening on the I2C bus on the working Arduino example and then the non-working DesignLab example on the Papilio and I could see a difference in the initialization sequence being sent from each. I guess I should have compared the two libraries and found the issue without breaking out a scope, but where's the fun in that, right? The Arduino example was sending hF0, h55, hFB, h00 as the init sequence. The Papilio example was sending h40, h00, hFB, h00 as the init sequence. After doing a bit more reseearch I changed the following section in the WiiChuck.cpp in the WiiChuck library in DesignLab as below: int WIIChuck_class::init_nunchuck() { int err = 0; if (I2C.start(WIICHUCK_ADDRESS,0)!=0) err = -1; if (err==0) // if (I2C.tx(0x40)!=0) - this is for OEM Wii nunchucks if (I2C.tx(0xF0)!=0) // for clone Wii nunchucks err = -1; if (err==0) // if (I2C.tx(0x00)!=0) - this is for OEM Wii nunchucks if (I2C.tx(0x55)!=0) // for clone Wii nunchucks err = -1; I2C.stop(); I recompiled the sketch, uploaded to the Papilio and I'm now getting the following results when testing: No Joystick or button activity - Chuck: 128 127 buttons 0 0 Joystick left - Chuck: 46 127 buttons 0 0 Joystick right - Chuck: 255 127 buttons 0 0 Joystick up - Chuck: 128 255 buttons 0 0 Joystick down - Chuck: 128 46 buttons 0 0 Button C - Chuck: 128 127 buttons 0 1 Button Z - Chuck: 128 127 buttons 1 1 Button C+Z - Chuck: 128 127 buttons 1 0 I was not aware that some (all?) clone chucks do not respond properly to the standard init sequence. The following comment was in the Arduino library that I used (https://playground.arduino.cc/Main/WiiChuckClass): // instead of the common 0x40 -> 0x00 initialization, we // use 0xF0 -> 0x55 followed by 0xFB -> 0x00. // this lets us use 3rd party nunchucks (like cheap $4 ebay ones) // while still letting us use official oness. // only side effect is that we no longer need to decode bytes in _nunchuk_decode_byte // seehttp://forum.arduino.cc/index.php?topic=45924#msg333160 Thanks for the advice Alvie, using the scope certainly revealed the issue even if it wasn't due to a hardware fault or misconfiguration. Regards, Anthony

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

Hi all, over the last half year I have implemented a processor and surrounding SoC bringing the RISC-V ISA (http://riscv.org) to the Papilio Pro. It implements the 32Bit integer subset (RV32IM). The project is hosted on Gitub (https://github.com/bonfireprocessor). It still needs some additional documentation, cleanup and ready-to-run ISE projects to make it easy reproducable for others. But I post this link now, to find out if anybody is interested in my work. I will soon also post a bitstream here so anybody with access to a Papilio Pro can play with it. I have also ported eLua to it http://www.eluaproject.net @Jack: If you like I can also present the project in the GadgetFactory blog. Regards Thomas

This is a library for Designlab and Papilio Duo. The decoder module can have up to 4 encoders. For example 4 wheels on a mobile robot platform. Optionally this can be use with a PID regulator for controlling current position, velocity, and direction of an object. - The shown pins are totally optional - By default the Avr chip is disabled Download: Quadrature_decoder.zip

Assuming the need to go to multi-layer for the BGA part, that looks like it will be a very expensive board. You might look at a part such as the XC3S500E-4PQG208I which is in a 208 pin PQFP package. The FPGA is a bit more expensive but the PCB will be a fraction the cost if you can keep it to 2 layers. Also at least when it comes to Seeed, the cost of the board increases rapidly with size. 5cm * 5cm max is around $1/bd, 10cm * 10cm max is $2.50/bd, while the next size up, 15cm * 15cm max is close to $9/bd. If you can manage to keep it within 10cm square then the bare boards are ridiculously cheap.