Adept DPTI support

[zygot]

The user's manual for both the Nexus Video and Genesys 2 boards claim to have a USB 2.0 parallel DPTI supported by the Adept API. They have the hardware but the latest Adept software does not support the FT2232H device in the mode it's designed to be used in. The Windows Adept Utility does not support the FPGA on either board. What's your time frame for making good on your advertised functionality?

[sbobrowicz]

You are correct, the public release of the Adept SDK has not been updated yet to include DPTI support. This is an oversight on our part, so thank you for bringing it to our attention. We are putting together a new release of the SDK that contains the DPTI library, Documentation, and a software example (both Host PC and HDL code). I'm doing my best to make sure that this gets released the week of the 27th, but I can't guarantee that schedule.

We apologize for this inconvenience, and for the other troubles you've encountered while trying to use your new Nexys Video and Genesys2. We will do our best to get you a solution to this problem as soon as possible. Let us know if we can help anyway else in the meantime.

[Sergiu]

hello,

have you looked at the projects from this location?

https://github.com/Digilent/NexysVideo/tree/master/Projects/dpti

Sergiu

[zygot]

2 hours ago, cchamp said:

I wanted to use DPTI demo because it seemed to be a fast way for using USB interface and then save time for my others developments

There's nothing wrong with that. It's just not going to be as trivial as you want it to be. Then again the USB standard isn't as simple or straightforward in practical use as you want it to be. I felt compelled to write my own HDL to handle the CY7C68013A 8-bit interface after using it on a few projects. Ditto the FTDI devices. I've never since felt that any of that effort was a waste of time. But wadda I know? (you're making me feel like Fiddler on the Roof)

As to getting a 'fast' way to do nifty things. I advise abandoning foolish quests when it comes to complex things like FPGA development and USB interfaces. Bite the bullet, do the work, get the reward...

2 hours ago, cchamp said:

In fact I'm struggling with genesys2 reference manual that is full of errors

It took a couple of years of badgering on my part but the latest version of the Geneys2 documentation has appeared to be free of the obvious errors that afflicted earlier versions for a while now, if you can find it. One document that Digilent has always gotten right, as far as I've seen, is the schematic. The schematic is your gold standard. It's true that since moving to the FTDI programming and USB interface their schematics have been incomplete... that's another topic. You need to know something about the device connections to do DPTI and Digilent's constraints files have been a reliable, if inadequate, substitution for providing that information. I really have no idea what kind of proprietary magic they believe that they are hiding by supplying a blank page in their FPGA board schematics. My gut feeling, from decades in the electronics industry,  is that it must involve some NDA information that FTDI is willing to share with them but not the rest of us (end user slobs who finance all of this). And yes I know, companies have a legitimate right to protect themselves from miscreants who'd rather steal their engineering than pay for it.

[cchamp]

I wanted to use DPTI demo because it seemed to be a fast way for using USB interface and then save time for my others developments. In fact I'm struggling with genesys2 reference manual that is full of errors and some code that isn't working for the device it supposed to work with.

 

[zygot]

@cchamp

I haven't looked to see if the demo code has been updated for a while now. I assume that you read carefully through this thread and noticed that ( unless it's been updated recently ) the demo has one source for both the Nexys Video and Genesys2 boards and that the source doesn't work with the Genesys2 without modification. It's quite possible, if you're not careful, to do the simulation and overlook this. All I can say is that I've used the DPTI interface on both boards for some time now without issue using both HDL ( modified for the Genesys2 ) and my own along with the Adept software and FTDI driver code.

I don't know the why or (I suspect more likely) the who but for some reason Digilent has shown a great reluctance to admit to or address issues with the Genesys2 documentation and sample code that I've advised them of. For the Nexys Video board, I reprogrammed the FTDI eeprom to allow using it in it's fastest mode and only use FTDI driver software. Please note that mistakes in reprogramming the FTDI eeprom can make the board unusable and is highly discouraged by Digilent.

It's a shame that Digilent decided to abandon the Cypress USB interface as it's more flexible and powerful (and more complex and difficult to develop with).

Since the Genesys2 has an FMC connector you can also do what I've done and add a USB3 interface. Both FTDI and Cypress offer inexpensive development boards and free tools to have a much more capable interface (assuming that you need to transfer a LOT of data at high transfer rates)

Evidently the idea of developing self-sufficiency as my previous post suggest doesn't appeal to you. It seems to me that since moving to FTDI Digilent has lost interest in making the USB interface on some of its boards as useful as they deserve to be. This is why I recommend anyone wanting to use it to become self-sufficient. I realize that there are users of FPGA boards who believe that they don't want to develop a level of expertise in specific interfaces like USB. Personally, I don't believe that FPGA boards will ever become a simple appliance suitable for casual development. Perhaps this helps explain why many of my answers to technical questions on this forum seem to encourage a path that the questioner would rather avoid. 

[cchamp]

I tried dpti demo both in jtag programming mode and in flash programming mode. So far the dpti reference manual PDF and dpti PDF weren't very helpful.

thanks for your help

 

[jpeyron]

Hi @cchamp,

Is the Genesys 2 set to JTAG on the  “mode” jumper (JP5) and a media selection jumper (JP4) as shown in the reference manual here? It appears that the Demo is first failing in the DptiIO() function on line 300  and then failing the DmgrGetLastError() function on line 325 of the DptiDemo.CPP. I would look at the PDF provided for the DptiDemo.CPP in the doc folder for more insight into your error.

thank you,

Jon 

 

[zygot]

On 9/4/2018 at 3:37 AM, cchamp said:

tested the logic with the provided test bench and it seems to work fine.

Yeah, I don't have a high regard for the supplied testbench.

Have you tried restricting data transfers to blocks that are multiples of 512 bytes? There are a number of ways in both hardware and software to mishandle termination of partial USB data frames. Review the Adept API. I bet you can change that timeout value in software... and this might help find your problem. Clearly, a process in either the hardware or software is waiting for an event that never comes.

Here's an opportunity to develop a bit of debugging skill. When I can't figure out what's going wrong I code up a bit of instrumentation. These kinds of diversionary projects are rarely a waste of time because I always have a new tool in my toolbox to use on future projects. Two avenues come to mind.

• Vivado ILA
• USB UART debugging. Look through the Project Vault for some ideas here.

Failure is sometimes the best thing that can happen to an engineer as it occasionally pushes one into a new path with a better endpoint and at the least expands a designer's horizons in terms of insight and overall perspective. (Just don't try to explain this to a manager...)

Zygot thought for the day: You can learn a lot more from debugging a hardware or software design than from creating and implementing a design; so embrace adversity as a tough but honest and reliable friend.

Sometimes handing someone the answer to a problem is the worst possible thing that you can do to them.

[cchamp]

yes I did and had the same result but the logic part of dpti demo is in synchronous mode

I tested the logic with the provided test bench and it seems to work fine.

I used wireshark to monitor USB traffic, I can see data being sent to the Genesys2 but still the same time out error.

Does someone  have an idea of what could be wrong ?

[zygot]

@cchamp,

Have you tried using the asynchronous mode?

[cchamp]

Hi,

 

I'm trying to use dpti demo for Genesys2 board. I can launch software  but I get a time out

Synchronous DPTI Port Enabled

beginning data transfer...

ERROR: data transfer timed out after 30.004000 second

 

Is anyone went through this kind of problem ?

Regards,

Cedric

[jpeyron]

Hi @sethu,

You can find the VHDL file in the Digilent Adept 2 sdk folder here: digilent.adept.sdk_v2.4.2\samples\dpti\DptiDemo\logic with the dpti demo here: digilent.adept.sdk_v2.4.2\samples\dpti\DptiDemo.

thank you,

Jon

 

[zygot]

29 minutes ago, sethu said:

Theoretically USB should be able to reach 60MByte/s, and since the USB controller on my Nexys Video has a 60MHz clk port for the DPTI bus, it should be able to achieve speeds near that

No. Please re-read this thread starting at the initial post.

As to the DPTI driver I haven't looked to see what the latest version is. The one that I've used, when I don't use my own interface, has some issues. You'd get the impression from the code and documentation that what Digilent provides supports both the Nexys Video and Genesys2. Obviously, the third party who did the design never actually tried using it with the Genesys2. The first problem is that reset input. Again comments already in this thread point out the issue. You will have to make modifications for the Genesys2.

Another issue with the DPTI interface is that is seems to claim that it can operate in either synchronous or asynchronous modes. Perhaps this is a semantic problem but unless you are willing to reprogram the FTDI eeprom to do "synchronous 245" mode you cannot achieve the maximum data transfer rates. I did that for my Nexys Video board. Please note: Digilent highly discourages users from reprogramming the FPDI eeprom as it is possible to brick your interface.

Having said all of that, I have used the (modified in the case of Genesys2 ) DPTI HDL for both the Nexys Video and Genesys2 successfully. I encourage simulating the provided code. I also highly encourage experimentation with the interface to develop a feel for what it's capabilities are in real world applications.

Lastly, if you want to transfer large amounts of data a very high rates both boards sport an FMC connector allowing you to add a USB 3.0 interface. Cheap development kits are available from both FTDI and Cypress Semiconductor to try out this option. Regardless of what USB interface you use it is necessary to be somewhat knowledgeable about how USB works and pay attention to details like always sending data in native packet sizes to achieve desired data rates.

[sethu]

On 6/7/2016 at 8:38 PM, nversluis said:

I have a question for the developers: Currently the transfer speed seems to be limited to 20MB/s when using the demo, but I do not know what the limiting factor is. Theoretically USB should be able to reach 60MByte/s, and since the USB controller on my Nexys Video has a 60MHz clk port for the DPTI bus, it should be able to achieve speeds near that. Is there a way to speed up the transfers or is this just because the demo uses a loopback and will actual one-way transfers be faster?

Also a little feedback on the new SDK: The reset button of dpti_ctrl.vhd in the demo seems to be implemented vaguely; it's active-high, while the reset buttons on most boards are active low, and the readme.txt doesn't instruct to uncomment the reset button in the master .XDC.

Furthermore, all signal port names are so that they match the default names of the header ports in the .XDC-file except for the reset, which is called "rstbtn" instead of ""cpu_resetn".

This means that i had to invert the reset signal in the dpti_ctrl.vhd code and adjust the constraints file in a way not stated in the readme.txt that comes with it. Not really a big deal, but something you may want to update for the convenience of other users, so I thought I'd inform you.

Thanks for the great support so far by the way, I really appreciate your work.

where can i find dpti_ctrl.vhd , Please point me to the demo file location, Thanks

On 6/7/2016 at 4:44 PM, nversluis said:

I see the files have been uploaded successfully. Awesome! Thanks for your cooperation. I'll start working with DPTI right away.

Where can i find the DPTI demo files , I'm working on Genesys 2 Board , is this demo made for Genesys2 or Nexsys Board, Thanks 

[zygot]

Dan,

Perhaps this is a discussion more suitable for another venue. As I've tried to explain the limitations of USB are in the interface itself, the implementation of the controller device, OS kernal state etc. Once you've extracted data from an endpoint it doesn't matter what form it's in; SPI, 8-bit parallel, 32-bit parallel for USB 3.0 etc. At that point it's just what happens to be convenient for the logic connected to the endpoint. I've connected a LOT of different hardware to USB 2.0 and 3.0 and the needs of that hardware is what drives all of the decisions that affect "performance", and each one is different. Unless I'm just not understanding what it is that you're asking it appears that "performance" from your perspective is simply how many bytes of data can one push through a particular USB hose. My concept of performance is a bit more complex. For FTDI solutions there is only one mode that offers the maximum potential data throughput; synchronous 245 fifo mode... if you are transferring large chunks of data. However you use those 8 parallel bits extracted from the FTDI pins will not affect "performance" whether you serialize them, aggregate them into a 64-bit bus or do anything else to them.

 

[D@n]

No, what I am interested in is specifically USB.  While FMC can easily be made faster, I'm specifically interested in the convenience of USB.  Given that, the next question is how fast/far you can push performance over a USB bus.  In addition, how should the FPGA be connected to the USB bus processor. The FTDI chip offers a very useful solution, providing both JTAG and UART over USB.  Other useful solutions might be SPI, DEPP (8x serial port), and ... well, what makes the most sense?  If you were building a new USB interface, what would you build?  (That's the question I'm asking of myself these days ...)

Dan

[zygot]

Dan,

I'm not sure how to answer your post but here are some thoughts based on my experience.

There is no single solution to all USB based requirements. It really depends on what you want to do. For USB 2.0 the Adept interface with the CY68013A based ATLYS board is far superior to the FTDI based Adept interfaces in terms of designing an optimal interfaces for many different requirements. Your requirements of course depend on what it is that you want to do. If all you want to do is transfer large blocks of data without latency concerns then the Nexys Video and Genesys2 boards have that nice FMC connector. Both FTDI and Cypress offer low cost development boards for adding a USB 3.0 interface to anything with an FMC or HSMC connector. The drivers for the FTDI FX60x is still a work in progress and as their USB "stack" is fixed you are limited in how you can use it. The Cypress FX3 is much more flexible with an on-board ARM processor and GPIO but requires a considerable learning curve and another level of development tools. It what you want to do involves data transfers of arbitrary length, including small data transfers, and you need to control latencies ( for instance a control loop involving both a PC application and FPGA interfaces ) then things get quite complicated. At least the Cypress option give you a chance to address these issues. The problem for Nexys Video and Genesys2 users is that there is only one FMC connector limiting how useful these boards are for real-world designs. ( It would certainly be nice if Digilent, or anyone for that matter,  made a board more suitable for something other than experimentation; and provided adequate support for it)

For anyone not familiar with USB please understand that it is not like a SPI interface where the sustained data rate is closely coupled to the clock rate ( OS and software concerns being ignored... we are talking about a PC application working with external hardware after all). Unfortunately, if you want to use your computer to control external hardware PCI, PCIe, USB and SATA are what we have.

While adequate for a large variety of applications USB is not an ideal interface for connecting a PC an external hardware, but is the 'easiest' of the bunch.

[D@n]

Zygot, NVersluis,

Here was my USB thought and plan: Use a chipkit with a PIC32 and USB connector to see if I can't get a faster interface running over USB.  The "new" interface would be open, and my current plans allow for connecting to the FPGA via UART, SPI, and 8x parallel I/O wires.  As always, the goal would be to build an interface that runs at "full speed", but it does remain to be seen what speeds can be accomplished by mere mortals. 

Dan

[zygot]

Nversluis,

For USB 2.0 you can expect that 1 packet (512 bytes) of data will be transferred at a 60 MB/s rate. You cannot expect that there will be two packets being transferred without a period of time between them in which no data is transferred. All USB protocols have overhead and latency issues that you have to deal with. In general, for USB the smaller the total data transfer size the lower the transfer rate for a complete transfer. If all you want to do is transfer 1 KB of data every millisecond or so even USB 3.0 can make the old parallel port ( are you old enough to know what that is?) look competitive. (I still use the LTP in ECP mode for low latency transfers of small amounts of data) For USB 2.0 if you can average about 40 MB/s you're doing pretty good, and that will be for a 1 MB+ data transfer. In addition to the USB protocol there is OS and driver level issues conspiring to rob you of that magic 60 MB/s data transfer rate.

I encourage anyone wanting to use USB for real-world designs to do some experimenting. The time spent will be well worth it. Unfortunately, the FTDI devices, unlike the Digilent's old CY68013 based USB interfaces don't allow much in the way of optimization for a particular purpose.

The DPTI support in the new SDK is quite a mess. I had to figure out what you did to get it working on the Nexys Video ( obviously, the developer didn't have hardware to try out his <effort>. Contrary to documentation the demo code requires quite a bit of modifications to function on the Genesys2. Sadly, (sigh!) this has become the norm for the new Digilent.

regards,

zygot

[JColvin]

Hi nversluis,

I asked some of our applications engineers about your question previously, but I have not heard back from them yet so I will let them know that you are still waiting for a response.

Thank you for your patience,
JColvin

[nversluis]

I have a question for the developers: Currently the transfer speed seems to be limited to 20MB/s when using the demo, but I do not know what the limiting factor is. Theoretically USB should be able to reach 60MByte/s, and since the USB controller on my Nexys Video has a 60MHz clk port for the DPTI bus, it should be able to achieve speeds near that. Is there a way to speed up the transfers or is this just because the demo uses a loopback and will actual one-way transfers be faster?

Also a little feedback on the new SDK: The reset button of dpti_ctrl.vhd in the demo seems to be implemented vaguely; it's active-high, while the reset buttons on most boards are active low, and the readme.txt doesn't instruct to uncomment the reset button in the master .XDC.

Furthermore, all signal port names are so that they match the default names of the header ports in the .XDC-file except for the reset, which is called "rstbtn" instead of ""cpu_resetn".

This means that i had to invert the reset signal in the dpti_ctrl.vhd code and adjust the constraints file in a way not stated in the readme.txt that comes with it. Not really a big deal, but something you may want to update for the convenience of other users, so I thought I'd inform you.

Thanks for the great support so far by the way, I really appreciate your work.

[nversluis]

I see the files have been uploaded successfully. Awesome! Thanks for your cooperation. I'll start working with DPTI right away.

[JColvin]

Updating that files are packaged up now but just need to be pushed live, hopefully will be completed today.

[JColvin]

Hi nversluis,

I am also still waiting on the SDK from the appropriate engineers...

I believe the design has been validated, but needs to be appropriately packaged up into whatever file structure it needs. I'll definitely post back here when I learn that it has been made live.

Thanks,
JColvin

[nversluis]

I see the SDK has still not been updated yet. Any news on it's availability?