alvieboy

Any expertise is welcomed What we have put to work so far (with a PPro and my USB wing) packs a simple USB transceiver, so all PHY-related stuff is actually inside the FPGA. This works well for full-speed (12Mbps) and we have a quite generic USB interface for it, with support for most useful endpoint types, but not all (isochronous is not supported). The internal design we have uses also ULPI, so should be fairly simple (never that simple, is it?) to use USB3300 or other ULPI/UTMI chip. But USB 2.0 puts some emphasis on larger endpoint sizes, and memory is not that big internally. My idea (original idea) was to actually have a EHCI interface to the CPU, but not sure it is worth the effort. Not sure when I will be able to test USB3300, I will let you all know when I do. Alvie

Might well be.. or at least play a role on it. Can you try setting all those actively driven to FAST ?

On the mapping report (.mrp) you should see if your IO pins have dedicated IO registers. +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | IOB Name | Type | Direction | IO Standard | Diff | Drive | Slew | Reg (s) | Resistor | IOB | | | | | | Term | Strength | Rate | | | Delay | +---------------------------------------------------------------------------------------------------------------------------------------------------------+ | CLK | IOB | INPUT | LVTTL | | | | | | | | DRAM_ADDR<0> | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | .... | DRAM_CLK | IOB | OUTPUT | LVTTL | | 12 | FAST | ODDR | | | | DRAM_CS_N | IOB | OUTPUT | LVTTL | | 12 | FAST | | | | | DRAM_DQ<0> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | | DRAM_DQ<1> | IOB | BIDIR | LVTTL | | 12 | FAST | IFF | | | | | | | | | | | OFF | | | ... | DRAM_DQM<0> | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | | DRAM_DQM<1> | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | | DRAM_RAS_N | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | | DRAM_WE_N | IOB | OUTPUT | LVTTL | | 12 | FAST | OFF | | | As you can see here, the address lines have OFF in Reg(s) tab, meaning "Output Flip Flop". The Clock line is driven by a ODDR flip flop. The data lines have both OFF and IFF (Input Flip Flop). All other control lines have OFF. This ensures minimal delay from clock to pad, and to chip, and its very important to timing. You seem to have increased one of the timings, though. I wonder it is the same issue we are facing with newer SDRAM parts. Alvie

It may relate to different setup/hold values, and how FPGA routes stuff. Can you check that all your DATA/ADDRESS lines for the SDRAM have IO registers ? Alvie

That's there to support larger devices in the future. Right now we tie that line to '0': DRAM_ADDR(12) <= '0'; Alvie

It's fairly easy to use the SDRAM, once you understand the basics of how our controller works. You can use the controller separately, no need for ZPUino at all. Let me know if I can be of some assistance. We may eventually even come up with a decent how-to Alvie

That's easy. "Design" tab, expand "Synthesize - XST" and choose "View RTL Schematic". Alternatively you can open the .ngr (RTL) or .ngc (Technology) file inside ISE, after synthesis. The RTL view shows you the design prior synthesizing the low-level elements (LUTs, Flip-Flops, so on). The technology shows you how they are mapped into LUTs and FF and so on. This is still prior to mapping, so things can change a bit in the process. Note that due to optimizations sometimes what you see may be a bit "mangled". In that case, enable "Keep Hierarchy" in Synthesis options (right-click on "Synthesize - XST", choose "Process properties"). Glad your problem is fixed now. Alvie

Yes, VHDL is synchronous to the clock, and completely independent of what CPU does. No, all registers (if address is correct) shall at least ACK the transaction (although it may happen that read/writes do not read anything useful or have any side effects). Can you also share the code (.elf) generated ? It may happen that the IO is being directed to a wrong or invalid address.

Tony, can you send me these files that are generated by the ISE build process: .ncd .ngd .syr .mrp (make sure you enable detailed map report, if possible -see options for Map generation) Zip all of them and send to "alvieboy@alvie.com". I'll try to see what is happening. The only "normal" lockout from the CPU point of view is when it tries to read/write to a IO location and ACK never comes in... Alvie

Now they show. Nice work Alvie

Same problem here with the images (and not using Tor). I'm very eager to get my hands on one of these. Actually, I do need something similar at work - I had to give up using FPGA due to lack of USB. Alvie

I think Jack thought about that SRAM usecase. Regarding USB: Our plan for USB is to have a "master bitfile" that, when invoked, presents a MTD device to the host for programming (drag-drop a bitfile). Works in all OS without any drivers. Plus a CDC serial port for debugging or serial programming. After the user bitfile starts, the USB PHY is completely available to the user to do whatever he wants (like a videocamera, for example). Or you can just power it down. Alvie

FTDI is expensive. USB does not work for you because there are some implementation issues (note that there's a PIC controlling the USB). Also, lack of serial support on USB is a killer (I spoke with Dave a few years ago about that, but I also had no time to implement the new endpoint). I have a few XuLa myself. I like them for some projects, due to the small size.

Currently we do not suport per-pin interrupts. The main reason for this is because one would normally not use the GPIO pins for this purpose, but rather design a custom VHDL controller. What exactly are you trying to implement ? Best, Alvie

Congratulations to @EtchedPixels. ! Well deserved, my friend. http://www.swansea.ac.uk/graduation/honoraryawards/alancox/ (I know, a bit off-topic, but who cares ? ) Alvie

I was updating my LLVM tree today (long time since I did it) to prepare for XThunderCore SmallISA, and I found a new CPU in there, called "Lanai". A quick search returned some info - this CPU seems to be in development by Google [1][2][3], and it's similar to a microcontroller but aimed at massive parallel computations. Did not have time to explore much - looks like a classical RISC to me ythough. You can get a glimpse of the instruction formats by looking at the LLVM implementation: https://github.com/llvm-mirror/llvm/blob/master/lib/Target/Lanai/LanaiInstrFormats.td Any of you ever heard of this, and if any soft-core implementation is available in the wild ? Magnus ? (I will update you guys regarding the XThunderCore SmallISA in a couple of weeks). Alvie [1] https://www.phoronix.com/scan.php?page=news_item&px=Google-Lanai-Architecture [2] http://www.theregister.co.uk/2016/02/09/google_processor/ [3] http://lists.llvm.org/pipermail/llvm-dev/2016-February/095118.html

You will need a few other tools if you want to re-generate the bootloader. mingw+make, perl, ISE and zpu toolchain should be enough. Sorry for the inconvenience of being hard to build this in Windows - the platform is not designed for development from its ground up.

Ok, I think I fixed the last major bug in MTP transfer. I can now upload huge files (like 6MB) to Papilio [without storing the data, of course] with no transmission errors. Let me try building a standalone .bit file so people can experiment with it (and report bugs - surely many will pop up). The configuration is also more dynamic now. Example of a full USB + MPT setup: void setup() { Serial.begin(115200); SPIFlash.begin(); MTPUSBDevice.begin(0x1D50, // Vendor 0x4000, // Product "Gadget Factory", // USB Manufacturer "Papilio Pro USB", // USB Product, "2.0", // USB Serial number, "Gadget Factory", // MTP Manufacturer "Papilio Pro MTP device", // MTP Model "1.0", // MTP version "0123456789ABCDEF" // MTP Serial number ); mainStorage.setName("FPGA Firmware"); mainStorage.setUUID("af5449fe-cbda-452e-9bdc-588b1d5eb8da"); mainStorage.setCapacity( 8*1024*1024 ); // 8MB mainStorage.setFree( 8*1024*1024 ); // 8MB MTPUSBDevice.addStorage(&mainStorage); } You can have multiple storages. The main base class is abstract, so a storage can be anything you like - flash, virtual, memory, SD-card FAT, so on, so on. Alvie

Never heard of copacabana (except for being a brasilian city), care to share some links ? Regarding the MTP (and SerialUSB)... much has been going on. Expect a much more mature library on next version, just fine-tuning some details. Alvie

So, Back a while ago I ordered some USB wings to play with, with just an USB 1.1 transceiver (TUSB1106PWR). Easy to solder. Only supports 12Mbit though, but the advantage is you can fit everything on a 8-bit wing. Jack actually did a demo of the PCB as an example for the 3D brd Viewer a while ago (you can watch it here: ). Since the transceiver is not actually a PHY, I've used a PHY from Opencores [1], with only some small modifications so I could use 96MHz as clock instead of the usual 48/60MHz. This PHY presents a UTMI interface which allows me to switch to a hard PHY in the future with minimal modifications. I then needed a packet decoder of some sort. I used [2] also from Opencores, and translated it (the packet decoder only) to VHDL (original is Verilog). This helps decode the PID from USB packets and perform CRC checks. Still a lot to go though. I then wrote a packet engine, that understands all important USB transactions, implements endpoint buffers and endpoint configuration. This took me a while, and required me to understand almost all of USB1.1 (with exception of hub transfers). Learned a lot. This packet engine is tied to a wishbone interface that goes directly into a ZPUino slot, so it can be controlled. All upper layer (descriptors, data transfer, so on) are handed in software, as typical microcontrollers do. Right now it works! The device can be enumerated, in Windows and Linux, and things look promising for the next days: [1547151.706742] usb 2-1.5: new full-speed USB device number 74 using ehci-pci[1547151.801847] usb 2-1.5: New USB device found, idVendor=efbe, idProduct=adde[1547151.801853] usb 2-1.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3[1547151.801856] usb 2-1.5: Product: USB Wing[1547151.801859] usb 2-1.5: Manufacturer: Alvie[1547151.801861] usb 2-1.5: SerialNumber: Rev 1.0[1547151.802582] cdc_acm 2-1.5:1.0: ttyACM0: USB ACM deviceStill needs a proper PID/VID though Another test was to present it as a CDC device, so we could use it as a serial port. Things are looking great too in that area, should be fully working tomorrow after some software changes. Lots of interrupts going on. I'll keep you posted Alvie [1] http://opencores.org/project,usb11_phy_translation [2] http://opencores.org/project,usb1_funct

Niiice!

Indeed, writing a SPI master/slave from scratch is a good exercise It's actually one of the easiest interfaces you can design (waay more simple than an UART, for example) You can eventually use ZPUino SPI for this, you just need to drive it using wishbone signals. Alvie

Larry, let me reply to you as a blog post, so others can understand what a SoC is and how it differs from "regular" microcontrollers. Will do shortly. Second, but most important, thanks for your words. You do seem enthusiastic about this new FPGA world - we try to encourage people to learn, understand and explore - this gives us strenght to keep on working and providing as much as we can so that you, ultimately, can have a even better understanding and knowledge that we do Not impossible, and definitely not improbable. With FPGAs, the clock speed is the limit Which is close to sky, actually. It's like either buying a car or designing the engine - guess which presents more fun. Even if the car cannot speed to 100mpg, it's still your engine, optimized for a lot of stuff (fuel and oil consumption, less emissions, temperature-variable compression or combustion, so on). Alvie