Adept SDK

[zygot]

The documentation for using the SDK software libraries and sample HDL is, let's go with sparse to be kind. I've been using it for a few years but my last project has resulted in unexpected behaviour. I have a design that uses both dpmiref and stmctrl sample HDL components and want to access both in my PC application. I don't get any errors, but when I execute DeppDisable() and then DstmEnable() I sometimes have the contents of epp registers lost. Then, when I try and do a DstmIOEX() transfer UsbStmen never gets asserted and the application hangs until the library code times out. I've done this in the past with success but just am not finding what's different in the current project that is causing me grief. Does Digilent have any useful examples (HDL and C code) using both synchronous an asynchronous USB data transfers in one design? Also, can I really do overlapped synchronous IO? The API suggests yes, the documentation and my experimentation no.

[zygot]

Atilla,

 

I've gone through the code in your "unofficial" package and am still puzzled about U1-INT0#, which on the Atlys board is assigned to the FPGA pin "A5". You say that it isn't used, but looking at your StreamIOEx model EppReg.vhd this pin is in fact being used as a reset driven by the CY68013A ( I was assuming that it might be an input to the USB controller....). So what causes the CY68013A to assert this signal?

 

Are the library files in the "unofficial" package the same ones as the latest official SDK release?

 

I compiled the StreamIOEx HDL and console application using VS2010 and indeed the source appears to result in the expected behavor. I guess that you are not as bothered by ISE complaining that your EppReg code uses a gated clock ( EPPDSTB) as I am.

 

It appears that Digilent is abandening the  CY68013A ( I suppose for cost reasons ) since all of the newer boards use a different device.Is this correct?

 

thanks for your kind assistance.

[zygot]

I try not to talk to myself out loud... at least not in public... but, what's that curious U1-INT0# for? I've found no reference to it other than on the schematics and ucf files where it acquires on the more mysterious name of UsbMode.

[attila]

The dpmiref is an old demo where the ASTB/DSTM signals are not handled properly. This can cause state machine to lock. Driving the control logic directly by asynchronous signal, which might be in transition at the moment when the registers are updated causes undetermined logic result.

These asynchronous signals between different clock domains (here USB and FPGA) would need to be registered at least twice to properly detect edges.

...
signal ppASTB, pASTB : std_logic;
begin
   process(CLK)
   begin
      if rising_edge(CLK) then
         pASTB <= EPPASTB;
         ppASTB <= pASTB;
         -- properly detected ASTB falling edge
         if ppASTB = '1' and pASTB = '0' then
...
         -- properly detected ASTB rising edge
         if ppASTB = '0' and pASTB = '1' then
...

Another, elegant solution would be using the ASTB/DSTM signals as reset and clock:

   EPPWAIT <= '0' when (EPPASTB = '1' and EPPDSTB = '1') else '1';
   DB <= dataToSend when EPPWRITE = '1' and EPPDSTB = '0' else (others => 'Z');

   process(EPPASTB, EPPDSTB)
   begin
      if EPPASTB = '0' then
          -- ASTB is always write 
          myAddressResiter <= DB;
      elsif rising_edge(EPPDSTB) then
         if EPPWRITE = '0' then
            receivedData <= DB;
         end if;
      end if;
   end process;

Force the ISE to accept this as clock. This is a low frequency signals so we don't need high performance clock routing.

NET "EPPDSTB"  CLOCK_DEDICATED_ROUTE = FALSE;

 

 

The DSTM functions need FPGA logic that can read/write the USB controller FIFO.

The difference between the two function is the following: 

 - The DstmIO transfer is supervised by the USB controller software. This counts the number of read/written bytes and sets the empty/full flags according the number of bytes asked by the DstmIO function.

 - The DstmIOEx is unsupervised, allowing higher upload rate. The FPGA logic should know how many bytes does the PC expects in a transfer, otherwise the logic might write extra bytes to the FIFO that the PC will not read. If these lost bytes are not important for your project then you can ignore the respective "extra data" error.

 

See the documents and examples in the following unofficial package:

https://drive.google.com/file/d/0B-YtGABZihr-czdtcTgtM0JLRUU/view?usp=sharing

 

 

The overlapped mode means that the transfer function immediately returns and the DmgrGetTransResult needs to be call periodically, waiting for completion. While the transfer is in process the earlier passed data buffers needs to be kept alive since the background transfer thread is using it.

 

 

The U1-INT0# is not used.

The INT0 is used as EPPRST and SLCS as STMEN. Both are driven by the USB controller.

[zygot]

Hey, thanks for the clarifications. Much appreciated.

[attila]

Thank you for the observation the INT0 is actually used. I stopped working with this project many years ago...

Atlys UCF:

NET EPPRST   LOC= A5; # INT0#

NET STMEN   LOC = B2;  #SLCS

 

When the PC initiated DSTM transfer is started the USB controller software activates the EPPRST, changes port mode from EPP/GPIF to FIFO, then activates STMEN.

 

From the "unofficial" package only one example was added to the released SDK.

 

The newly used USB controller provides hardware data serialization, so the JTAG programming is much faster. I suppose this is the reason.

[zygot]

Attila Apologies for misspelling you name previously. Again, your help is very much appreciated.