Hi Peter,
On Mon, Jul 8, 2013 at 8:40 PM, Peter Stuge <[email protected]> wrote:
> Joel Holdsworth wrote:
> > SUMP could be replaced with a more conventional RS232 register
> > interface and streaming protocol
>
> If you are going to make something that uses USB in 2013, why on
> earth would you make it so stupid?
>
There is nothing stupid in supporting RS232 (I prefer calling it UART),
this is a pragmatic choice, since this is the most available (and simple)
interface among existing FPGA boards, and one of the aims of the FPGA
project is to enable running a LA on a variety of existing FPGA boards.
At the same time it is important to define an internal API, which will
allow for various host interfaces. This API should be based on common
practices. I will try to describe the needed features in layers, not
protocol layers, more like API wrapper layers, both the number of layers
and the content might be implementation dependent. Access is needed for
configuration, control/status and data storage
1. low level access, close to the hardware (ideal for integration into a
SoC):
1.1. access to configuration registers
Here I think a memory mapped interface (32bit data, Wishbone or AMBA APB or
...) is the correct choice. This registers are simple non volatile
read/write type.
1.2. control (run/stop, clear memory, ...) and status (trigger, data
available, interrupts, ...) registers
Here more complex registers are common (for example for interrupt status,
clear if write 1 and ignore write 0 is commonly used), here at least care
must be taken while organizing the bits into 32bit registers so their
functionality does not collide.
1.3. data storage
Here access is always sequential, in a SoC a DMA would perform bursts of up
to 32 words (as an example).
2. serialization + status (protocol independent common layer)
On one side this layer is accessing memory mapped peripherals. On the other
it is offering a full duplex FIFO interface, practically identical to
FPGALink. So there are two streams of byte sized data. This layer is
actually handling the byte oriented protocol, converting a command into a
memory access, ...
2.1. access to configuration registers
Throughput is not very important here, in a protocol the next sequence
would be appropriate (1B command and read/write bit, 2B address, 4B write
data) and the receiving side (4B read data).
2.2. control (run/stop, clear memory, ...) and status (trigger, data
available, interrupts, ...) registers
One option would be to use the same sequence described above. The use of
dedicated commands is also acceptable. If there is no dedicated signal
interrupt functionality available, a pooling option must be also provided
for checking the status.
2.3. data storage
For USB, UART, SPI, and similar protocols, providing the address for short
bursts might be too much overhead, so larger bursts should be supported.
Providing the memory address at the beginning of the bursts is acceptable
overhead, so there is no need for the protocol to automatically start
sending data without a request just after the storage has been loaded with
samples.
3. actual streaming of data over a wire
Most of the functionality is already handled by the serialization layer.
Now imagine an interface like FPGALink (), the FX2 link is part of the
definition, connecting an UART is trivial (I already wrote and partially
tested the Verilog code), SPI is a bit different, since the slave can not
force data on the master. FTDI chips can be connected as well.
> You are making the number one USB mistake and I think you can do
> a lot better here. As I've said before I would be happy to help
> design a protocol that is actually suitable for USB, so that we
> end up with something that has a chance of achieving decent
> performance.
>
Peter, I have read your previous posts where you were proposing FPGALink,
you can see I am still working in the same direction as you. Please comment.
Regards,
Iztok Jeras
>
>
> //Peter
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> sigrok-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sigrok-devel
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
