enjoy-digital / litesata Goto Github PK

Generating the 150MHz refclk from a PLL is not yet working with Artix7 (while it is with Kintex7). While this is not recommended, that would still be useful to easily add SATA on some Artix7 boards.

Add DMA frontend, similar to the LiteSDCard DMA frontend (https://github.com/enjoy-digital/litesdcard/blob/master/litesdcard/frontend/dma.py) to allow integration with LiteX and BIOS.

Adding/Finishing ECP5 support would be interesting since could provide a FOSS solution (Core + Toolchain) for a SATA controller and would also be directly useful for projects like Linux-on-LiteX-VexRiscv or Linux-on-LiteX-Rocket now that @gsomlo developed a Linux driver.

The steps for this are:

• Making sure LiteICLink bench design on ECP5 works correctly at SATA linerate (1.5Gbps or 3.0Gbps), on the ECPIX-5 or Versa. (IIRC this has already been tested but would be good to re-verify).
• Get OOB initialization sequence working with ECP5 transceiver (Validate generation/detection of TX/RX Idle and then create a proper FSM for the OOB initialization sequence). On Xilinx FPGA, we were relying on some internal logic already present in the transceiver for OOB but this is not present on the ECP5 transceiver, so we have to do it.
• Integrate the ECP5 transceiver wrapper (from LiteICLink) + specific OOB logic as a LiteSATA PHY (with similar interface than the Xilinx PHYs).
• Verify/debug operation on hardware with Litescope probes on OOB, TX/RX datas.
• Get Link-Up at 1.5Gbps. (SATA1).
• Get BIST example working.
• Get LiteX integration working.
• Get LiteX/Linux integration working.
• Try to get SATA2 support (3.0Gbps)

The main missing part is probably the OOB initial sequencing:
https://www.researchgate.net/publication/295010956/figure/fig2/AS:330628831694855@1455839464365/OOB-Initialization-Sequence.png

Some initial tests have been done to generate/receive COMRESET/COMINIT/COMWAKE in the ecp5 branch: https://github.com/enjoy-digital/litesata/tree/ecp5 but the integrated electrical idle detection feature of the ECP5 was apparently not fast enough to detect/generate the OOB sequencing correctly. With ECP5 transceiver, it's possible to use the transceiver's IOs as regular IOs driven by user logic; more information for this is available here: https://lab.ktemkin.com/post/serdes-lfps/ We should probably use this for the OOB sequencing.

After ALIGN, when we are sending CONT, we need to repeat the last primitive before sending the next CONT.

Currently we are doing this:
PRIM-PRIM-CONT-CONT-ALIGN-ALIGN-CONT-CONT-CONT...

and should do this:
PRIM-PRIM-CONT-CONT-ALIGN-ALIGN-PRIM-PRIM-CONT-CONT....

• Add PHY.
• Finish/Debug TX startup fsm. (PHINIT not working)
• Finish/Debug RX startup fsm. (ADD DRP Reconfig)
• Verify/Debug OOB initialization.
• Verify/Debug Link layer.

LiteICLink simplifies the use of transceivers with FPGAs and is already used by others cores to handle the lower layers(for example in LiteJESD204B and with the USB3 PIPE). LiteSATA was created before LiteICLink, so directly instantiates the transceiver's primitives and the initialization logic. Switching to LiteICLink would simplify PHYs a lot (only the SATA specific part would be handled) and would also simplify adding support for new FPGA families: Artix7, ECP5, Ultrascale(+).

Dear litesata authors,

I came across your litesata IP and decided to test it. I was able to modify Python code, but for integration I would like to use more standard flow, it means to use the generated litesata Verilog backend. I used Verilog code generated by .examples/make.py build-core that is 'bist' design, but the further-described behaviour would be the same for other examples as well. I tried to setup the litesata simulation in Vivado XSIM, but I ran into troubles with the following error:

FATAL_ERROR: Iteration limit 10000 is reached. Possible zero delay oscillation detected where simulation time can not advance. Please check your source code. Note that the iteration limit can be changed using switch -maxdeltaid.
Time: 0 ps  Iteration: 10000

After double-checking everything and hours of eyeballing into the Verilog netlist I found the signals which are set and read in the same process causing the zero delay oscillation in the simulation:

line 2927:
transport_tx_sink_ready <= link_litesatalinktx_sink_sink_ready;
// if (((transport_tx_sink_valid & transport_tx_sink_last) & transport_tx_sink_ready)) begin
// should be changed to something like this:
if (((transport_tx_sink_valid & transport_tx_sink_last) & link_litesatalinktx_sink_sink_ready)) begin

around line 3174:
command_tx_sink_ready <= transport_tx_sink_ready;
// if ((command_tx_sink_valid & command_tx_sink_ready)) begin
// should be changed to something like this:
if ((command_tx_sink_valid & transport_tx_sink_ready)) begin

After these changes, the zero delay oscillations disappear and simulation time may proceed.

I think this should be corrected in the migen code even though this may not be a problem for the synthesis...

Thank you for your effort,
Michael

See #30.

To get back LiteSATA working, we had to remove reset_less property of payload on LiteX's streams: https://github.com/enjoy-digital/litex/blob/master/litex/soc/interconnect/stream.py#L73 Understand why and revert the workaround in LiteX.

This would be useful to avoid polling in the Linux drivers.

Please visit https://github.com/enjoy-digital/litex/wiki/Feedback-Contribution-Support.

Current linux-on-litex driver is not working on actual multi sector implementation. Is new driver exists?
Great thanks for great project.

I am trying to run the LiteSATA bench file provided for the Nexys Video (xc7a200t-sbg484-1). The board is new and does not have anything connected to it, and I am building / loading the bitstream to the FPGA with the following over USB programming interface:

./nexys_video.py --pll-refclk --build --load from the /litex/litesata/bench directory.

Since there is no external clock provided for the transceiver, I am attempting to use the internal 150 MHz PLL reference clock. I have tried this with both Gen 1 and Gen2 SATA. The bitstream is built and loaded successfully using the Vivado toolchain, however once the program starts, only a single LED0 lights up, signifying that the TX, RX, and Ready signals are never initialized. I am unsure as to why SATA does not initialize, is an external 150MHz clock required? Does a hard drive need to be attached to the SATA RX/TX lines for the SATA core to initialize?

I have attached my bench file, along with the terminal output below. Please let me know if there is a solution discernible from these, or if you need more information. Thanks!

nexys_video_bench.txt
terminal_output-Nexys_Video.txt

I've tried to generate a sata core for ultrascale device using script under bench directory.
And there is a serial port in the top module. so what command should I send to the port to let it run?
and what's the baudrate?