Serial Ata Fpga

1. Communications Pr…
2. Serial Ata Fpga Tutorial

Hello this will be an experts questions:) You should be familiar with the following topics. Xilinx Multi-Gigabit-Transceivers (MGTs), especially the 7-Series GTX/GTH transceivers (GTXE2CHANNEL). Serial-ATA Gen1, Gen2 and Gen3, especially Out-of-Band (OOB) communicationQuestion:How should a GTXE2 be configured for Serial-ATA?OOB signaling is not working neither RXElectricalIdle nor ComInit.

Introduction:I implemented a SATA controller for my final bachelor project, which supports multiple vendor/device platforms (Xilinx Virtex-5, Altera Stratix II, Altera Stratix IV). Now it's time to port this controller to the next device family: Xilinx 7-Series devices, by name a Kintex-7 on a KC705 board.The SATA controller has a additional abstraction layer in the physical layer, which is based on SAPIS and PIPE 3.0. So to port the SATA controller to a new device family, I have only to write a new transceiver wrapper for a GTXE2 MGT.As of Xilinx's CoreGenerator doesn't support the SATA protocols in the CoreGen wizard, I started a transceiver project from scratch and applied all necessary settings as far as they are asked by the wizard. After that I copied the GTXE2COMMON instantiation into my wrapper module, ordered the generics and ports into a meaning full schema.As a third step I connected all unconnected ports (the wizards doesn't assign all values!!) to their default values (the default from UG476 or zero if not defined).In step 4 I checked all generics and ports again against the UG476 if they are compatible to the SATA settings. After that I connected my wrapper ports to the MGT and inserted cross-clock modules if necessary.As of the KC705 board has no 150 MHz reference clock, I program the Si570 to supply this clock as 'ProgUserClock' after each board 'bootup'. The MGT is in powerdown mode (P2) while this reconfiguration.

When the Si570 is stable, the MGT is powered up, the used Channel PLL (CPLL) locks after ca. 6180 clock cycles.

This CPLLLocked events releases the GTXTX RXReset wires, which cause a GTXTX RXResetDone event after additional 270 1760 cycles (all cycles @ 150 MHz - 6,6 ns).This behavior can be seen in chipscope, captured with a stable, uninterrupted auxiliary clock (200 MHz, slightly oversampled).So the GXTE2 seams to be powered-up, operational and all clocks are stable. GTXE2 ports to control the OOB signaling:The MGT has several ports for OOB signaling. $begingroup$ Yes I know this AR:) It offers only different CDR tuning parameters to support SSC.

As of now, I'm using SATA Gen1 in my tests and I assigned the appropriate parameter from that list. As far as I can see, bit synchronization, comma detection and byte alignment is working in the loopback tests. But the CDR unit is far behind the OOB circuit, which is my current problem:) In parallel to this question I'm writing a simulation: testbench phy-layer GTXE2 GTXE2 phy-layer testbench $endgroup$–Aug 15 '14 at 16:02. So I think I found some answers to the problem and want to share them.I started to simulate the GTXE2CHANNEL hardmacro. The simulation is behaving as 'false' as the hardware.

So I tried to simulate the MGT in Verilog and used an instance template from here:This template simulates ElectricalIDLE conditions and OOB sequences nearly correct. So I started to diff both solutions:.TXPDELECIDLEMODE, which is a port to choose the behavior of TXElectricalIDLE is not working as expected. So now I'm using the synchronous mode.PCSRSVDATTR is a unconstrained bitvector generic of 48 bit. If you have a look into the wrapper code of the secureip GTXE2CHANNEL component, you will find a conversion from bitvector = stdlogicvector = string. Internally all generics are treated as DOWNTO ranged. So it's important to pass a DOWNTO constant to the GTXE2 generics!So now you could ask why is he using to-ranged constants and generics?Xilinx ISE up to the latest version 14.7 has a major bug in handling vectors of user defined types in unconstrained generics. The default direction of vectors is TO.

If you are passing vectors of enums as DOWNTO to unconstrained generics into a component, ISE is reversing the vector elements and 'emits' a TO ranged vector in the components!!This is especially 'funny' if the design hierarchy, which uses this generic, is not a balanced tree.If you are using enums of 2 elements, the problem is not existent - maybe this enum is mapped to a boolean. Which bugs are left?. TXComFinish is still not acknowledging the send OOB sequences. I have to investigate this two bug fixes in synthesis and measure the OOB sequences with a scope - this may last some days:)Edit 1 - more bugs:There is an other bug in the reset behavior of the GTXE2. If GTXE2 is used with output clock dividers set to 1 (TX and RXRateSelection = '000') than the GTXE2 boots up and emits only 3 clock cycles (with wrong clock period) on TXOutClock. After that TXOutClock is 'X'.

Communications Pr…

If you reset the GTXE2 after that wrong output it boots up a second time with now error and a correct clock on TXOutClock.Additionally to this bug, the GXTE2 ignores all assigned resets (CPLL as well as TX/RXRESETs) until 'X' can be seen on TXOutClock. So you MUST wait for circa 2.5 us to issue a reset.If you are using clock dividers with 2 or 4 (8 and 16 are not tested yet) this problem will not occur. Edit 2 - problems solved:Solution for Bug 1:I have added a timeout counter whose timeout depends on the current generation (clock frequency) and the current COM sequence which is to be send. If the timeout is reached I generate my own TXComFinished signal. Don't or the timeout signal with the original TXComFinished signal from GTX, because sometimes this signal is high while COMWAKE is to be send, but this finished strobe belongs still to the previous COMRESET sequence!Solution for an other Bug:RXElectricalIDLE is not glitch free!

To solve this problem I added an filter element on this wire, which suppresses spikes on that line.So currently my controller is running at SATA Gen1 with 1.5 GHz on a KC705 board with a SFP2SATA adapter and I think this question is solved.

Serial Ata Fpga Tutorial

Hello this will be an experts questions:) You should be familiar with the following topics. Xilinx Multi-Gigabit-Transceivers (MGTs), especially the 7-Series GTX/GTH transceivers (GTXE2CHANNEL). Serial-ATA Gen1, Gen2 and Gen3, especially Out-of-Band (OOB) communicationQuestion:How should a GTXE2 be configured for Serial-ATA?OOB signaling is not working neither RXElectricalIdle nor ComInit. Introduction:I implemented a SATA controller for my final bachelor project, which supports multiple vendor/device platforms (Xilinx Virtex-5, Altera Stratix II, Altera Stratix IV).

Now it's time to port this controller to the next device family: Xilinx 7-Series devices, by name a Kintex-7 on a KC705 board.The SATA controller has a additional abstraction layer in the physical layer, which is based on SAPIS and PIPE 3.0. So to port the SATA controller to a new device family, I have only to write a new transceiver wrapper for a GTXE2 MGT.As of Xilinx's CoreGenerator doesn't support the SATA protocols in the CoreGen wizard, I started a transceiver project from scratch and applied all necessary settings as far as they are asked by the wizard. After that I copied the GTXE2COMMON instantiation into my wrapper module, ordered the generics and ports into a meaning full schema.As a third step I connected all unconnected ports (the wizards doesn't assign all values!!) to their default values (the default from UG476 or zero if not defined).In step 4 I checked all generics and ports again against the UG476 if they are compatible to the SATA settings. After that I connected my wrapper ports to the MGT and inserted cross-clock modules if necessary.As of the KC705 board has no 150 MHz reference clock, I program the Si570 to supply this clock as 'ProgUserClock' after each board 'bootup'. The MGT is in powerdown mode (P2) while this reconfiguration.

When the Si570 is stable, the MGT is powered up, the used Channel PLL (CPLL) locks after ca. 6180 clock cycles. This CPLLLocked events releases the GTXTX RXReset wires, which cause a GTXTX RXResetDone event after additional 270 1760 cycles (all cycles @ 150 MHz - 6,6 ns).This behavior can be seen in chipscope, captured with a stable, uninterrupted auxiliary clock (200 MHz, slightly oversampled).So the GXTE2 seams to be powered-up, operational and all clocks are stable. GTXE2 ports to control the OOB signaling:The MGT has several ports for OOB signaling. Why is this off-topic?

Stackoverflow has questions for VHDL/Verilog designers. There are tags for FPGA, Xilinx, SATA, RTL and Virtex. The electrical engineering site from stack exchange has only a few questions to these topics, so stackoverflow is better. And the Xilinx forums are no help to specific and in most cases 'bug' related questions. There are many people out there trying to implement serial protocols with MGTs - so maybe we can share some experiences on OOB signaling.–Aug 14 '14 at 20:38. It's off-topic because it's not a programming question, and you've asked nothing that is programming (code) related in this question. Because your question is geared to the hardware side of things, it's not appropriate here according to the guidelines.

(Previous questions existing doesn't mean that a new one is appropriate; guidelines change over time, and sites exist now that didn't exist when began. Current guidelines are maintained in the pages, and are what govern question appropriateness at the time.)–Aug 15 '14 at 2:17. So I think I found some answers to the problem and want to share them.I started to simulate the GTXE2CHANNEL hardmacro. The simulation is behaving as 'false' as the hardware. So I tried to simulate the MGT in Verilog and used an instance template from here:This template simulates ElectricalIDLE conditions and OOB sequences nearly correct.

So I started to diff both solutions:.TXPDELECIDLEMODE, which is a port to choose the behavior of TXElectricalIDLE is not working as expected. So now I'm using the synchronous mode.PCSRSVDATTR is a unconstrained bitvector generic of 48 bit.

If you have a look into the wrapper code of the secureip GTXE2CHANNEL component, you will find a conversion from bitvector = stdlogicvector = string. Internally all generics are treated as DOWNTO ranged.

So it's important to pass a DOWNTO constant to the GTXE2 generics!So now you could ask why is he using to-ranged constants and generics?Xilinx ISE up to the latest version 14.7 has a major bug in handling vectors of user defined types in unconstrained generics. The default direction of vectors is TO. If you are passing vectors of enums as DOWNTO to unconstrained generics into a component, ISE is reversing the vector elements and 'emits' a TO ranged vector in the components!!This is especially 'funny' if the design hierarchy, which uses this generic, is not a balanced tree.If you are using enums of 2 elements, the problem is not existent - maybe this enum is mapped to a boolean. Which task are still open?. TXComFinish is still not acknowledging the send OOB sequences.

I have to investigate this two bug fixes in synthesis and measure the OOB sequences with a scope - this may last some days:)Edit 1:Solution for Bug 1:I have added a timeout counter whose timeout depends on the current generation (clock frequency) and the current COM sequence which is to be send. If the timeout is reached I generate my own TXComFinished signal. Don't or the timeout signal with the original TXComFinished signal from GTX, because sometimes this signal is high while COMWAKE is to be send, but this finished strobe belongs still to the previous COMRESET sequence!Solution for an other Bug:RXElectricalIDLE is not glitch free! To solve this problem I added an filter element on this wire, which suppresses spikes on that line.So currently my controller is running at SATA Gen1 with 1.5 GHz on a KC705 board with a SFP2SATA adapter and I think this question is solved.