Hi guys,
Is it possible to use OLS as a FPGA dev board? What would be the best way to get to doing so? As far as I can tell it should be possible to update FLASH with some other bit stream, but maybe there is some other more elegant way? Is it maybe possible to do it form Xilinx environment directly?
Sorry if the question is a bit stupid, but I searched the whole forum and wiki and didn't find anything about it. I'm really glad with my Bus Pirate so I'm trying to find some additional usage for OLS to convince myself fully to buy it. :)
I do not have the Xilinx environment, myself, but I believe that the OLS has a compatible JTAG connector that should work with the standard Xilinx tools. Most dev environs seem to rely upon a JTAG interface for most programming and debugging.
There's also a ROM-ISP connector that might allow you to directly program the Flash with a new bit stream without even needing the PIC on the OLS, although the PIC is cheaper than a separate Flash programmer since it's already on board and at least there's support software for uploading a new Flash image.
mikuslaw,
The OLS is not really meant as a FPGA dev board, it is targeted for the single purpose of being a Logic Analyzer. The biggest issue is that the voltage regulators are tiny, 150mA. That's perfectly targeted for the LA application but I wouldn't even attempt to do much else, you may become frustrated without knowing why when there is just not enough power to supply the logic you have created.
I would highly recommend that you take a look at my Papilio One FPGA dev board (http://http://www.gadgetfactory.net/index.php?main_page=product_info&cPath=1&products_id=18) if you are looking for a cheap and Open Source FPGA dev board. It was designed from the very beginning as a full FPGA development board, and it actually shares the same base FPGA design as the OLS. I'm actually working on getting the OLS "Sump" code base to run on the Papilio One. The new Verilog core threw me a curve ball but I should have it working soon.
I think the biggest thing you are going to want with an FPGA dev board is an active community. With the Papilio One I am actively trying to build an FPGA community like the Arduino community. I am constantly releasing new projects and examples for the Papilio one with full Open source code that you can fire up and start hacking on. I'm also putting a "playground" in place to allow others to contribute their source code and projects. It's called "Gadget Forge" and it hasn't had a clear identity in the past. But I am working on cleaning it up and making its purpose as a playground for FPGA projects.
Jack.
I have a thought related to using the OLS as an FPGA development board - hopefully it isn't too much of a sidetrack from this topic.
Although the Flash Destroyer seems to have proved that I shouldn't worry about frequent reprogramming of a Flash chip, I still prefer to avoid programming Flash whenever possible. On that note, how hard would it be for the PIC on the OLS to disable the Flash after startup, and then reprogram the FPGA with a new bitstream via SPI?
I'm thinking that if you were to use the OLS for FPGA development, you might want to try several design variations quickly, without burning the Flash each time. Perhaps the OLS PCB traces are hard-wired for the Flash to provide the FPGA bitstream, but it at least seems possible for the PIC to take over the SPI bus (after the initial startup boot sequence) and directly provide a bitstream to the FPGA for experimental purposes.
While I have the topic, is this idea something that the Papilio One makes possible?
On the other hand, it seems like the JTAG port may offer the same kind of ability to change the bitstream without burning new data into the Flash. I have not actually used a JTAG interface on the FPGA, so I'm just guessing about such capabilities based on other JTAG devices that I have developed and programmed. i.e. I'm wondering if the JTAG port could be used to bypass the normal SPI Flash bitstream for experimentation.
I seem to recall that the OLS has jumpers to change the boot mode so that something other than the Flash can provide a bitstream. Is there any provision for the PIC to be the boot source for the FPGA?
If anyone cares to discuss this, I'm interested in learning more.
@rsdio
It might be possible to bypass the SPI Flash chip but I think it is a big question mark. There are many different SPI Flash chips out there that are just different enough that the Spartan 3E provides several configuration modes to support different subsets of SPI Flash chips. We are configured to use a subset of the SPI Flash chips that are available. I don't know all the details of what the differences are, I just know that there are differences. So the first question is if the PIC chip will be able to implement SPI communications in the same manner that the SPI chips that we are configured to use are. We are also configured to use the high speed mode, so the other question is if the PIC would be able to keep up.
The way the Papilio One handles this is that there is a high speed JTAG channel that is directly connected to the FPGA. When you program the Papilio One it does so over the JTAG channel, this takes less than a second and no Flash memory is ever touched. While you are developing or just checking a bitstream out you just quickly program the chip and the bitstream stays in the FPGA until power is removed. When you want to make a design permanent then you use a special mode of the Papilio Loader that actually loads a custom bitstream to the FPGA that allows the SPI Flash to be programmed over the JTAG port. This is transparent to the end user, all you need to know is that the command line is different for programming the flash. The end result is that you only program Flash when you want to make a permanent change.
This is another reason that the Papilio One is really meant to be an FPGA dev board while the OLS is meant for a targeted FPGA application. The OLS was targeted for cost reduction and the Papilio One was targeted for development.
Jack.
[quote author="jack.gassett"]The way the Papilio One handles this is that there is a high speed JTAG channel that is directly connected to the FPGA. When you program the Papilio One it does so over the JTAG channel, this takes less than a second and no Flash memory is ever touched. While you are developing or just checking a bitstream out you just quickly program the chip and the bitstream stays in the FPGA until power is removed. When you want to make a design permanent then you use a special mode of the Papilio Loader that actually loads a custom bitstream to the FPGA that allows the SPI Flash to be programmed over the JTAG port. This is transparent to the end user, all you need to know is that the command line is different for programming the flash. The end result is that you only program Flash when you want to make a permanent change.[/quote]
This makes a lot of sense. While it might be an entertaining challenge to get the PIC to do this sort of thing, it's probably smarter to simply use JTAG. The Papilio is looking more and more interesting, but does the OLS support the same JTAG modes?
I'm developing firmware for a DSP at the moment, and the process is exactly the same. JTAG tools allow downloading the in-progress firmware directly to SRAM in the DSP, where it can run and be debugged. Once firmware has settled, I have a program that can be downloaded over JTAG and which contains a copy of the final firmware as a data array that can be programmed into Flash memory. After this special firmware has been run once, the Flash has been loaded, and the DSP will boot by loading the final firmware from Flash.
On the OLS the JTAG lines are brought out to a header but they are not connected to the PIC. So the same type of thing would not be possible. The Xilinx programming cable can be used, that's what I used in the initial development. But the cable costs more than the Papilio One costs and it is not Open Source. :)
[quote author="jack.gassett"]On the OLS the JTAG lines are brought out to a header but they are not connected to the PIC. So the same type of thing would not be possible. The Xilinx programming cable can be used, that's what I used in the initial development. But the cable costs more than the Papilio One costs and it is not Open Source. :)[/quote]
Thanks for the info. I actually think it's better if the PIC is unavailable when developing for the FPGA on the OLS (it really just a distraction to have a processor on board :-) In other words, I assumed bypassing the PIC by using JTAG to talk directly to the FPGA - at least until the experimentation phase is complete (and then standard methods could be used to program the PIC and Flash).
I didn't realize that the Papilio One has an integrated JTAG programmer - that's certainly a benefit, especially since I assume it's fully compatible with the Xilinx software development environment.
I dunno... the PIC makes it easy to download new images to the FPGA serial flash ROM. I see it as a on-board programmer.
Generate a bit file in XISE, launch my downloader (http://http://dangerousprototypes.com/forum/viewtopic.php?f=23&t=1636), update ROM, test new fpga goodness. Pretty simple. Must have done it a hundred times.
Only real downside to OLS for general purpose hacking is you only have inputs, and a couple LED's, unless you use the unbuffered Wing header. Also the limited power, as Jack mentioned. There the Papilio One has OLS beat, in addition to its three Wing headers.
-- IED
[quote author="dogsbody"]I dunno... the PIC makes it easy to download new images to the FPGA serial flash ROM. I see it as a on-board programmer.[/quote]I should have qualified my statement. The PIC is only a distraction when you think about pure FPGA development. In comparison, I don't think the Papilio One is missing anything by not having a PIC.
However, in terms of the OLS feature set, I think the PIC is a great idea, and I'm very glad that it's there on the board. I see lots of potential for expanded utilization of the PIC in terms of OLS features.
Only real downside to OLS for general purpose hacking is you only have inputs, and a couple LED's, unless you use the unbuffered Wing header.
My OLS came with every header populated, so it's no more difficult to connect to outputs than inputs. If you're using your OLS this way, you might consider soldering on a row of 18 header pins, just so you're not stuck thinking in terms of the buffered inputs. My OLS has 6 headers on it! Lots of potential for repurposing.
The FPGA has a mode where it is an SPI slave and an external master (like the PIC) can load a bitstream. This is selected by the MS (mode select) pins. We hard-wired the MS and VS (variant select) pins on the OLS so it is pretty much stuck in ROM load mode.
It probably wouldn't be possible to imitate the ROM with the PIC. The load procedure is simple - the FPGA sends 0x03 (a standard read command for JEDEC flash chips) then starts sending clock ticks until it gets the magic aa55 key. It does it pretty fast though, faster than I think the PIC can go.
I have some notes on the FPGA boot modes here:
http://dangerousprototypes.com/docs/Xil ... figuration (http://dangerousprototypes.com/docs/Xilinx_Spartan_3_FPGA_quick_start#Boot_configuration)
[quote author="ian"]The load procedure is simple - the ROM sends 0x03 (a standard read command for JEDEC flash chips) then starts sending clock ticks until it gets the magic aa55 key.[/quote]I assume that you mean the FPGA sends 0x03 and then clocks bytes, all as master (with the ROM as slave).
Thanks for the response, though. Sometimes I should check myself: I see a PIC, and I want to make it do something cool. But after looking at all the options, a JTAG adaptor seems like an easier way to use the OLS in double-duty as an FPGA development board.
Hey, maybe one of the Dangerous JTAG boards can be used as an FPGA dev tool along with the OLS (although I assume that it might be difficult to get the Xilinx dev software to recognize a DP JTAG and work with it).
I did mean that, sorry, I edited it.
Actually, under Linux there is an alt Xilinx driver that makes FT2232-based debuggers appear as a parallel debug cable (or something) in ISE. robots patched it so the CPLD on the Bus Blaster JTAG programmer (connected to the B JTAG interface) can be programmed directly from ISE. There should be some links on the Bus Blaster v2 design notes page.
Wow, thanks guys. That really clarifies things. I see that there are just much better options to use in order to play with fpga - it's true that you can't have one thing do everything.
Thanks again!
Hi guys! I am thinking to use the OLS for some minor experiments too -
a) you may reflash the flash _many_ times, for an occasional experimentator almost unlimited endurance (btw I work with fram FM25H20, maybe worth of consideration for similar designs),
b) you get 16 5volt_tolerant inputs what is great! and 16 i/o,
c) basically none of the cheap dev systems includes a suitable power supply for blinking a light bulb so you have to always use an external one..
It would be great to see a similar demo as Jack is showing us with Papilio on how to use an uart rx/tx, but with OLS.. M.
If you program the OLS using JTAG, you can program the FPGA without needing to write the bitstream in the flash rom. (Mx pins don't matter)
..still thinking how to access those dir1 and dir2 pins/traces of the 74L buffer, buried beneath the package :-)...there are two via...good.. ;-)..M.
[quote author="miro"]
It would be great to see a similar demo as Jack is showing us with Papilio on how to use an uart rx/tx, but with OLS.. M.[/quote]
I had considered releasing that example for the OLS as well as the Papilio but I didn't have the time to make a special PIC firmware to pass the serial data through. The latest versions of the PIC firmware talk to the FPGA using SPI. Now that I'm thinking about it though, I guess if an older PIC firmware is loaded that used UART communications then it would be easy to adapt my example to work with the OLS. If there is interest I suppose I can make a version of that project for the OLS.
Check out the new http://papilio.cc (http://papilio.cc) website for other FPGA examples.
Jack.
It seems possible that the PIC firmware could be enhanced to provide access to both SPI and UART. With USB composite Device Descriptors, I think it would be possible to present two serial ports to the host computer. The primary port should be SPI, but a second port could access the UART. Obviously, full bandwidth to both ports at the same time would not be possible, but otherwise there should be no problem mixing the two.
The only issue I foresee is that such a complicated Descriptor could confuse Windows. I'm sure it would work on the Mac, though.
Windows would be fine. Bigger problem would be confusing the client & user. Both ports show up as Logic Sniffer's. However, the fpga only responds to one of them, and you won't necessarily know which except by trial-n-error.
Seem like it'd be better to have separate serial port builds of both PIC firmware & FPGA. It'd be a -lot- slower uploading captures though.
-- IED
[quote author="dogsbody"]Windows would be fine. Bigger problem would be confusing the client & user. Both ports show up as Logic Sniffer's. However, the fpga only responds to one of them, and you won't necessarily know which except by trial-n-error.[/quote]My understanding is that the one port we have now does not show up as a "Logic Sniffer," per se. It seems like the OLS just shows up as one of the many generic serial ports under Windows, and the user must manually select one with very little feedback if they make the wrong choice. I don't see how having another serial port would make this any worse than it already is.
Another possibility is that the USB Descriptors could be enhanced with String Descriptors for each port to identify each one separately.
Seem like it'd be better to have separate serial port builds of both PIC firmware & FPGA.
That might be necessary if nothing else works, but it would require burning the Flash every time you change between UART and SPI. USB is supposed to make things easier, and composite devices should allow this.
It'd be a -lot- slower uploading captures though.
I don't understand why it would be any slower at all. If you're not using a port by actively transferring data, then it takes no USB bandwidth. Assuming you don't try to initiate both a UART and SPI transaction at the same time (which is probably impossible to carry out, anyway, without a custom FPGA design), then captures should be exactly the same speed as before.
Note: Another option would be to have just a single Serial Device with a single Configuration, but have multiple Interfaces. The Default Interface would be the SPI OLS function, and the Alternate Interface would be the UART link between PIC and FPGA. This would prevent simultaneous use of both ports, even at low bandwidths, but that may not be useful anyway. The big drawback is that switching Interfaces requires a custom client, as opposed to just having an extra, dormant serial port.
The Logic Sniffer -is- identified as such. In my ols-winloader, the phase "Logic Sniffer" that appears isn't something I'm tossing in there. It comes from Windows, which presumably gets it from the OLS. Jawi's serial port library simply doesn't have the code to retrieve it from the setup-api.
A serial port connection between the fpga & PIC would be slower than the SPI connection. 115200baud (11520 bytes/sec) verses 10Mhz SPI (~1 MByte/sec max). Upload time would probably slow from a couple seconds to ~10 seconds. Depends on overhead in the PIC, which would have to use xon/xoff to throttle the fpga.
-- IED
[quote author="dogsbody"]The Logic Sniffer -is- identified as such. In my ols-winloader, the phase "Logic Sniffer" that appears isn't something I'm tossing in there. It comes from Windows, which presumably gets it from the OLS. Jawi's serial port library simply doesn't have the code to retrieve it from the setup-api.[/quote]That level of support for USB is different for each major version of Windows. If you're getting the "Logic Sniffer" string descriptor in your version of Windows, then it's highly likely that a dual-serial-port board would also be identified with a unique string for each port - at least if the USB Descriptors were designed with the extra information.
I have more experience with Mac OS X, but the story is basically the same: Older OS versions show less USB information while newer versions show more of the Descriptors in the UI. Usually, my clients just complain about the Windows features that aren't working, which is why I thought that Windows wasn't able to do what you're seeing.
A serial port connection between the fpga & PIC would be -much- slower than the SPI connection. 115200baud (11520 bytes/sec) verses 10Mhz SPI (~1 MByte/sec max). Upload time would probably slow from a couple seconds to 10-15 seconds.
Ah, I see what you mean. If the OLS were used in UART mode, then the normal features would be slower. But when used in SPI mode it would be just as fast, whether there are two virtual serial ports or one.
[quote author="rsdio"]That level of support for USB is different for each major version of Windows. If you're getting the "Logic Sniffer" string descriptor in your version of Windows, then it's highly likely that a dual-serial-port board would also be identified with a unique string for each port - at least if the USB Descriptors were designed with the extra information.[/quote]
Windows has quite a few different text fields for each USB device. Derived I believe from the USB standard itself. Windows & Mac should be identical in that respect. Whatever GUI presents it to the user will obviously differ...
So on my machine:
Location Info : "Logic Sniffer CDC-232"
Device Description : "Communications Port"
Friendly Name : "Communications Port (COM12)"
Manufacturer : "Microchip Technology, Inc."
I'm not -certain- what would change assuming there were two "COM" ports hanging out there. However, my guess would be two devices listed, both identified as Logic Sniffers, with different "friendly" names. ie: treated like there was a USB hub with two Logic Sniffers plugged in.
So ols-winloader, which just grabs the first non-empty string (in the order shown above) would display:
"COM12 - Logic Sniffer CDC-232"
"COM13 - Logic Sniffer CDC-232"
Kinda confusing as I said...
-- IED
[quote author="dogsbody"]Windows has quite a few different text fields for each USB device. Derived I believe from the USB standard itself. Windows & Mac should be identical in that respect. Whatever GUI presents it to the user will obviously differ...
So ols-winloader, which just grabs the first non-empty string (in the order shown above) would display:
"COM12 - Logic Sniffer CDC-232"
"COM13 - Logic Sniffer CDC-232"
Kinda confusing as I said...[/quote]
Mac OS X has some intelligence in this area, and will smartly distinguish and identify USB devices depending upon where the descriptors appear. I was actually caught by surprise one time when I upgraded OSX and then suddenly a USB Device that I had designed (hardware and firmware) had more interesting strings. USB offers a lot of places to add String Descriptors, but many Devices don't bother, and thus Windows also doesn't even look - kind of a Catch-22.
USB implementations are far from "identical" between Windows & Mac. Apple tends to follow the USB Specifications a lot better and supports more compliant devices.
What version of Windows are you running?
XP. I'm pretty sure Windows looks. There are tons of structures to sift & enumerate. The details get stored away in the depths of the registry. Perhaps it's GUI doesn't bother parsing it all though. So they have the capability, the information is all there, they just aren't bothered.
-- IED
There are definitely some improvements in Windows 7 compared to XP. XP is downright brain-dead when it comes to the USB specifications. Unfortunately, Microsoft has only added a few bells and whistles to Windows 7, without really digging deep to fix the incompatibilities that Windows has with the USB standards.
Case in point: USB-MIDI devices which implement Entity Elements will not even show up in Windows, despite being perfectly to-spec, and despite being recognized in Mac OS X for the last three major generations. I was briefly encouraged when I got in contact with a Microsoft tester for Win7 who wanted access to an USB-MIDI device with one or more Entity Elements, but the whole thing fizzled out. The weird thing is that we have a bona fide Catch-22 here: No commercial entity can sell a true USB-MIDI device that implements everything in the official USB-MIDI specification, because Windows will ignore it. Thus, every manufacturer dumbs down their USB-MIDI Device in order to work with Windows. But then, Microsoft cannot add support for the missing features because they have no devices to test against, since any commercial company that tries would go out of business. I've made an outstanding offer to my contact at Microsoft to provide example hardware with a custom firmware that is proven to be correct on OSX, but it seems that the proper motivational carrot has not been found.
Looking at this from another angle, the only difference between Apple's last few OSX releases is that later releases find more places in the User Interface to display various String Descriptors from a Device. Earlier releases still work with all USB-compliant Devices, even the elusive full-spec USB-MIDI, it's only the minor eye candy that has changed. Meanwhile, Microsoft has added some eye candy, but all versions of Windows lack full support for certain devices that are spec-compliant.
the phase "Logic Sniffer" that appears isn't something I'm tossing in there. It comes from Windows, which presumably gets it from the OLS.
I noticed this, great feature that I love.