Jack Gassett

Working on Papilio Nano

43 posts in this topic

Yahooo! SDRAM is working and I am able to load a sketch to the Papilio Mini board with SDRAM module, here is what I did to test:

  • I created a new circuit based on a Papilio Pro circuit and I modified the ucf file to change the locations of the SDRAM pins to correspond to the new locations on the PCIe header.
  • Moved the serial RX and TX lines to the A0 and A1 locations since we do not have the USB working yet.
  • Loaded the bit file that was synthesized with these changes to the board using Impact and the JTAG port. (This loads to the FPGA itself and not SPI Flash, impact does not support the SPI Flash chip we use...)
  • I connected a FTDI 232RL module to pins A0 and A1 which shows up as COM3
  • Verified that we could communicate with the ZPuino design running on the FPGA
    •  zpuinoprogrammer.exe -r -d COM3 -R -v
  • Used the ZPUino running on the FPGA to flash the same bit file to SPI Flash: (steps from Alvie)
    • Converted the bit file to bin file using progmem
      • promgen -w -spi -p bin -o c:\Dropbox\temp\Papilio_mini_bitfile\out.bin -s 1024 -u 0 c:\Dropbox\temp\Papilio_mini_bitfile\papilio_pro.bit
    • Wrote the converted bin file to SPI Flash
      • zpuinoprogrammer.exe -o 0 -l -b c:\Dropbox\temp\Papilio_mini_bitfile\out.bin -d COM3 -R -v
  • I was then able to reset the Papilio Mini and the ZPUino design was permanently running on the board.
  • I was then able to load sketches to the Papilio Mini board from DesignLab when selecting Papilio Pro as the board type.

The sketches did not output serial data correctly but that is a problem for another day...

Jack.

Share this post


Link to post
Share on other sites

That's neat, I like it. I'd be especially pleased with an SRAM addon, or better yet SRAM/ROM although pin counts start to be an issue unless you put them on a shared bus. In all my FPGA adventures, lack of sufficient block memory has been one of the biggest limiting factors and SDRAM is next to useless for recreating vintage hardware.

 

Jack, next time you're in Bellingham you should check out the Spark Museum if you haven't already. It's a fascinating place, I think you'd like it.

Share this post


Link to post
Share on other sites

Ohhhh! The Spark Museum looks pretty cool, I'll definitely check it out when I go back out to visit my sister again.

Jack.

Share this post


Link to post
Share on other sites

Thank you Chris,

Just a quick update, Alvie just received the prototype Nano/Mini boards and is trying to find some free time to test out the USB PHY chip that is on the board. If those chips work out well then I'll start taking the next steps towards further testing and manufacturing. Otherwise I will do another revision of the Nano/Mini using a low cost USB to serial chip instead and offer the USB PHY as a Wing.

Unfortunately things have slowed down because my wife is going to deliver our new baby in the next couple of weeks! So things are quite hectic, and I'm also trying to get the new GadgetBox platform up and running before the baby comes. So watch for the first GadgetBox to be available in the next couple of weeks and hopefully some good news about the Papilio Nano/Mini soon after.

Jack.

Share this post


Link to post
Share on other sites

Jack, I have some experience with HDL designs related to USB, so if any help is needed just ask me.

Also, even if you will decide to go with serial converter chip, I'll still be interested in seeing EDA files with USB3300 PHY chip.

Share this post


Link to post
Share on other sites
12 minutes ago, vr5 said:

Jack, I have some experience with HDL designs related to USB, so if any help is needed just ask me.

Also, even if you will decide to go with serial converter chip, I'll still be interested in seeing EDA files with USB3300 PHY chip.

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

Share this post


Link to post
Share on other sites

Hi Alvie,

EHCI is certainly nice thing to have, though probably not for Nano/Mini board and LX9 chip. For big CPUs like OpenRISC or RISC-V with Linux, U-Boot (and other similar software), EHCI is almost a "must have" thing.

For smaller boards/designs, compatibility is not so important and any easy way for implementing USB devices or specialized USB hosts would be great. I think, low cost FPGA boards with (High-Speed!) USB PHY will be in high demand.

Also nice caseworks for Mini board would help to boost popularity for this board even higher (so Jack's idea with GadgetBox is certainly the step in right direction).

Share this post


Link to post
Share on other sites

Thank you VR5,

Alvie is the man with this USB controller, I'm just more of a tester and hardware builder. :)

One of the biggest issues we are trying to figure out though is a way to trigger a reboot from the computer over the USB port. With a USB to serial chip you can always use the DTR line connected to the reset pin of the FPGA to trigger a reboot into the bootloader. But with the USB PHY you have to have a USB core running on the FPGA to trigger a reboot. We were toying around with using the SPK_R output of the USB3340 chip to try and do a reboot.

Do you have any ideas or experience that could help figure out a good solution with this issue? I don't want people to have to physically hit the reset button if they have a design that does not include the USB controller.

One thing I was thinking was to sell a stand alone FT232H dongle that could connect to the jtag port and would always be able to reset and program the device. But its not really a slam dunk solution.

Jack.

Share this post


Link to post
Share on other sites

Well, if the only connection to the computer is the USB, then we have to have some sort of USB controller in FPGA. For handling reset requests it shouldn't take a lot of FPGA cells.
 That's for ZPU/wishbone resets. For triggering an FPGA reconfiguration we may need a button anyway.

As for SPK_R, can you show me schematics on how you'd like to connect it and maybe you (or Alvie) can describe a sequence of actions for triggering a reset this way? I don't see how we can use this pin just yet...

For uploading a configuration and general development, yes - JTAG dongle is pretty normal solution. I see more pro's than contra's in this.

Share this post


Link to post
Share on other sites

I can actually think of one advantage of having USB on a breakout board: It's easier to attach the USB socket to a case from the inside.

Share this post


Link to post
Share on other sites

Hmmm, one of the ideas I've been kicking around is a GadgetBox Papilio version. I've been trying to decide whether it is better to make it as low cost as possible by not including USB and having it programmed with an external programmer. Then USB would be an optional eCog which can be the USB3300 or any other option which will give us lots of flexibility. It sounds like this would be an approach people would like? My thought is that the Papilio One/Pro and Papilio DUO are good learning boards that should have USB integrated, but the GadgetBox Papilio is meant for use in actual applications where keeping the cost down is desirable. As long as there is an easy way to add USB if you need it... Same with memory, maybe your application is just fine without it. But if you do need it then the iCog can be used to add memory.

The other thing I've been kicking around is just adding the USB3300 PHY because it is so cheap... But also have an easily accessible programming header.

As far as programming goes - I've been debating whether to go the FT232H or FT2322D and exposing the JTAG header. Or going with a serial header with DTR for reset and putting a bootloader on the FPGA. The downside of the JTAG route is that I will have to design a FT2322 module and cover all the expenses of manufacturing it and of course spend at least a month testing it. Not to mention that it will be relatively expensive for the end user to buy it. If I go the serial route I can get mass produced serial adapters for low cost with zero hassle or development and end users pay next to nothing for them...

Jack.

Share this post


Link to post
Share on other sites
On 11/2/2016 at 9:40 AM, vr5 said:

Well, if the only connection to the computer is the USB, then we have to have some sort of USB controller in FPGA. For handling reset requests it shouldn't take a lot of FPGA cells.
 That's for ZPU/wishbone resets. For triggering an FPGA reconfiguration we may need a button anyway.

As for SPK_R, can you show me schematics on how you'd like to connect it and maybe you (or Alvie) can describe a sequence of actions for triggering a reset this way? I don't see how we can use this pin just yet...

For uploading a configuration and general development, yes - JTAG dongle is pretty normal solution. I see more pro's than contra's in this.

Alvie indeed has the ZPUino handling resets from the USB controller already, but it requires that there be a ZPUino and USB core running on the FPGA for it to work.

So looking for a solution that would work with nothing loaded to the FPGA the only thing that was remotely close that I saw was the SPK_R pin, here is the schematic:

Papilio Mini Speaker reset.jpg

From the USB3340 datasheet:

USB3340 datasheet.jpg

So what I was thinking is that since the DP pin is connected to SPK_R pin in USB audio mode that would be one way to trigger an FPGA reset. But the big question mark is if there is any way from a computer to enter USB audio mode and directly control the DP pin... From what I remember the USB Audio mode is meant for Android phones so I'm not sure if we can take advantage of this on the PC side very easily... My googling around did not find any information about Windows drivers that support USB Audio mode and I've never touched any low level USB driver code so I don't know if there is any way to directly drive the DP pin...

Jack.

Share this post


Link to post
Share on other sites

Well, there are several things to consider:

- PHY on FPGA board will not go into audio mode by itself, it needs a sequence of register writes from ULPI interface (6.7.2 from USB3340 spec). PC may have access to its own USB PHY registers but not to the ones on FPGA board. And PC can't signal that it wants USB mode change if there's no a controller in an FPGA.

- PC access to it's PHY registers, direct USB signals driving - these will be highly PC motherboard/platform dependent.

So for me, PHY's audio mode for reset generation does not look like a good solution...

I think that we can use Alvie's controller when we need USB communication and reset generation, and also we may develop one more controller (rst) in Verilog/VHDL for the case when FPGA design does not need any USB functionality except resets - this controller may handle USB bus enumeration requests and implement 1 endpoint which will be easy to look up on a PC and will allow us to trigger a reset. So it could be something like this:

drawing1.png

(Maybe Alvie's controller already can work in exactly this way - I haven't studied all its details yet).

 

Share this post


Link to post
Share on other sites
Quote

PHY on FPGA board will not go into audio mode by itself, it needs a sequence of register writes from ULPI interface (6.7.2 from USB3340 spec). PC may have access to its own USB PHY registers but not to the ones on FPGA board. And PC can't signal that it wants USB mode change if there's no a controller in an FPGA.

Indeed.

However, we have two FPGA designs. The master designs always loads first, and can set those registers so that when the second (user) design loads, it is already set up.

Quote

- PC access to it's PHY registers, direct USB signals driving - these will be highly PC motherboard/platform dependent.

Not sure. I actually think we will not be able to use the method cause PC will always drive DP/DM signals... still to understand and test. I think the idea was to force an USB reset, and that will force DP/DN to go low (Single-Ended zero). May work, may not work...

 

Alvie

Share this post


Link to post
Share on other sites
16 hours ago, alvieboy said:
Quote

PHY on FPGA board will not go into audio mode by itself, it needs a sequence of register writes from ULPI interface (6.7.2 from USB3340 spec). PC may have access to its own USB PHY registers but not to the ones on FPGA board. And PC can't signal that it wants USB mode change if there's no a controller in an FPGA.

Indeed.

However, we have two FPGA designs. The master designs always loads first, and can set those registers so that when the second (user) design loads, it is already set up.

Alright. Sounds good! :)

 

16 hours ago, alvieboy said:
Quote

- PC access to it's PHY registers, direct USB signals driving - these will be highly PC motherboard/platform dependent.

Not sure. I actually think we will not be able to use the method cause PC will always drive DP/DM signals...

Well, actually I'd worry about another (almost opposite) thing.

In DISCONNECTED state both data lines are weakly pulled to 0 (via 15k resistors) by host. And device/PHY will not see any traffic until hub/host port goes thru CONNECTED to ENABLED state.

To go into CONNECTED state device has to pull one of the data lines high. Transition from CONNECTED to ENABLED state can be initiated by host SW by issuing port Reset command. However, Reset command will not do anything if port is in DISCONNECTED state.

Ok, so if we, for example, connect SPK_L to Vcc via resistor, then host will try to reset and configure port/device and we will see some level transitions on SPK_x lines after switching PHY to audio mode. PHY/FPGA board will not respond to GetDescriptor command and host will put the port into DISABLED state, so we will not see any USB traffic again. But another port Reset command can be issued , and  maybe signals on SPK_R can be used as reset signal for an FPGA/design running in FPGA. However there will be lots of transitions on SPK_x lines - so may be the low-pass RC filter will be needed.

There is still one thing to think about - how PC software will discover a port to which Nano board is connected...

And there are another things to try/study:

- I'm not sure that PC operating system will allow to issue a port Reset command for USB host/hub if that port was transitioned to DISABLED state.

- MicEn bit, will it do the same thing as SpkRightEn or "not exactly"?

Share this post


Link to post
Share on other sites

So there are some big question marks here... And another question mark is if it will work the same way on every computer system or will be be seeing weird results all over the place... This is a really great discussion though, thank you guys!

Jack.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now