Assessment and debugging of ATMEL ATF 280 Development

Assessment and debugging of ATMEL ATF 280 Development kit and suitability for ESA IP cores Javier Galindo TEC-EDM 27/09/2011

Outline • Experience learning the ATMEL development kit. • Exposition about the work done with the Hurri. CANe IP core. • Exposition about the work done with the Space. Wire-b ESA Codec IP core -2 -

Motivationof the Study • ATF 280 F first In-house design experiences o In-house evaluation of ATMEL FPGA Development Kit and Tools through small designs: new Atmel FPGA user learning curve • Study the suitability of ESA IP Cores within the ATMEL ATF 280 FPGA and its Tools (Hurri. CANe and Space. Wire Codec) o Assess the feasibility and performance of these IPs in the European FPGA technology ATF 280 -3 -

Study Flow I 1. Review of ATMEL Architecture and General ATF 280 Features – Expertise and work already done by ESA with ATMEL FPGAs 2. Review of work already done with ATF 280 1. Analysis of developed designs, In-house and by Industry 2. Tricks, bugs and problems found which are not well explained in ATMEL documentation. 3. At first glance, promising device -4 -

Study Flow II 1. Understanding of ATMEL Tool flow – Non trivial; Compilation of different applications. – Lack of “good” documentation and EXAMPLES!!! – In-house Know How; thanks to Mrs F. Decuzzi 2. Implementation of simple test designs 1. Start with simple designs to become familiar with tool flow 2. Correlate documentation with reality -5 -

Study Flow III 5. Implementation of ESA IP Cores 1. Use of Hurri. CANe (Data Link Layer); small and interesting IP core 2. Use of Space. Wire Codec; small and interesting IP core 3. Future; CANOpen, Space Wire, Small processor or LEON 6. Results analysis and comparison with other technologies 1. Validation and verification of the designs 2. Problem analysis and results 3. Comparison and conclusions -6 -

Outline • Experience learning the ATMEL development kit. • Exposition about the work done with the Hurri. CANe IP core. • Exposition about the work done with the Space. Wire-b ESA Codec IP core -7 -

Development. Kits – Initial Prototype – – – – ATF 280 Silicon Revision F Compact PCI mother board EEPROM, SDRAM, SRAM memories AT 17 LV 040 configuration memory is used instead of AT 69170 E. Configurable clock generator LEDs, buttons and a LCD display Serial RS 232 and LVDS drivers Initial prototype – Current Development Kit – – – – ATF 280 Silicon Revision F Compact PCI mother board EEPROM, SRAM memories 4 x AT 17 LV 010 configuration memory is used instead of AT 69170 E. Configurable clock generator and external clock inputs LEDs and buttons Serial RS 232 and LVDS drivers Development Kit -8 -

Simple Test. Designs • Test of simple designs to become familiar with the tools. – Simple combinational circuits – Up and Down Counters – Frequency Dividers – Hard Macros with dummy State Machines – Simple UART access to On-Chip RAM -9 -

Objectives – Behaviour of the tools with hierarchical designs – Clock resources management – Hard. Macro detection and mapping – LPM detection and mapping – Placing capabilities – Routing capabilities – Simulation and analysis features – Functionality of the development kit blocks – Usability of the ATF 280 with ESA IP cores -10 -

Tech. Comparison Considerations 1. Synthesis Technology comparisons purpose: – Check consistency of the results obtained with the Atmel design flow and other FPGA technologies – The purpose is not to have a full benchmark – Important note; – The technologies compared belong to different technology nodes and some (Altera Cyclone 2 and Xilinx Virtex 4) are commercial • Altera Cyclone: 90 nm TSCM, commercial • Xilinx Virtex-4: 90 nm UMC, commercial • Microsemi RTAX : 150 nm, rad tolerant -11 -

Frequency. Divider. Area Frequency Divider; Technology Comparison ATMEL – ATF 280 ALTERA – Cyclone II ACTEL – RTAX 1000 XILINX – Virtex 4 FIGARO Report Correlation among technologies -12 -

Frequency. Divider. Timing Frequency Divider; Technology Comparison ATMEL – ATF 280 ALTERA – Cyclone II ACTEL – RTAX 1000 XILINX – Virtex 4 FIGARO Report ATMEL shows speed problems -13 -

Down Counter Notes Down Counter; Notes – Complex tool flow. Non integration of all the tools in only one software application. – – – Integration of IDS Figaro in Precision is not working. Old version. – – – Complicated tracking of signals due to renaming. – Incomplete area and timing reports due to black boxes; number of Core Cells consumed by Black Box is not estimated in Synthesis – Post Synthesis simulation not fully available. Post Place and Route simulation possible but under development. Lack of “good” documentation and EXAMPLES!!! Tricks, bugs and problems found which are not well explained in ATMEL documentation. Mesh in different documents in the users group. LPM mapping and Hard. Macros mapping is functional and desirable. Needed more detailed explanation and status in current soft release. -14 -

Frequency. Divider. Notes Frequency Divider; Notes – – – Hierarchy Flattening Mandatory. Problems routing different clock domains in same die areas. – Using the 8 DKit LEDs with different clock domains almost impossible. – Solution not always feasible; use not registered outputs. Optimization problems. Fan. Out switch already working. Atmel shows clear speed problems, analysis of reasons needed. – Characterization ongoing. Repeaters? – Needed deeper study of ATMEL timing analysis, not clear results. Bugs being fixed. Not optimal placing induces not optimal routing; waste of resources regarding other technologies. RAM allocation problems; max @ width is 8 = 256 Bytes per block without glue logic. Simulation libraries? -15 -

ATMEL Development. Kit I After the verification and validation of the simple designs the following conclusions were achieved; – Lack of good documentation for the Development Kit and Tools. – Last DK relase has only info about Prototype Kit. Improvement needed; clarify tools status and compile bugs and tricks in one single document. Efficient Rad. Hard Hotline support. – DK absence of sample designs, only self test bit stream without documentation. – DK absence of LCD Display as in the prototype. – DK absence of AT 69170 E Configuration Memory – Space. Programmer has no native drivers for 64 bit Windows Versions, useless. IDS Figaro compatible only up to Windows Vista. -16 -

ATMEL Development. Kit II After the verification and validation of the simple designs the following conclusions were achieved; – Speed problems of ATMEL device; still valid for small/medium designs not very fast. – Place and Route capabilities to be improved dramatically. – Simulation libraries and documentation improvement needed – Appreciable effort in enhancing the tools and supporting users shown, good way for future. -17 -

ATMEL Development. Kit – Gone through the learning curve of using the FPGA design tools (including lab equipment); focusing the ATF 280 FPGA – FPGA still valid for some “small” designs – Several days/weeks of work with ATMEL validated in only one XILINX work day. -18 -

Outline • Experience learning the ATMEL development kit. • Exposition about the work done with the Hurri. CANe IP core. • Exposition about the work done with the Space. Wire-b ESA Codec IP core -19 -

Hurry. CANe. Tests – Hurry. CANe – ESA IP Core implementing the DATA LINK LAYER of BOSCH 2. 0 A and B CAN standard. – Well spread controller – Includes an AMBA APB wrapper, not used in these test. – Lower Layer for CCPIP IP Core. Work done with it but stable version not yet released for synthesis. -20 -

Hurry. CANe. Setups Two test setups used; – Single CAN Node, SCN; ESA Hurry. CANe IP Core Simple CAN node which sends packets when board push buttons are pressed and switch on and off LEDs depending on the received packet. – CAN-UART Bridge; Bridge with a CAN interface and a Serial UART interface. LCD to monitor traffic. Enables more extensive testing -21 -

Simple CANNode, SCN Simple CAN Node to asses IP core functionality with ATMEL FPGAs. – Only Data Link Layer implemented controlled with dummy state machines. – Computer emulated CAN network to send packets to the node and monitor packet received from the node. – LEDs and push buttons to control node. – 1 Mbps CAN link speed. – Internal or external PCB clock. – Synthesis performed with Precision RTL 2010 a U 2. – Place & route performed with Figaro IDS 9. 0. 3. – ATMEL Development Kit used. -22 -

SCN Setup 1. Physical Layer Driver for CAN Voltage levels in protoboard. 2. Used 65 HVD 251 from TI (CAN V levels, not RS 485) Up to 1 Mbp 3. Vector CANoe software package to simulate CAN network nodes and monitor traffic. 4. PCMCIA Card with optocoupled physical layer drivers. Design validated and verified ✔ -23 -

SCN Details – Design fits and works in ATF 280 – Most complicated step; learning of Vector CANoe software package. Powerful tool but time consuming to be learnt. – Internal and external clock tested up to 20 Mhz. No need for higher speeds, max CAN speed is 1 Mbps, achievable with less than 20 Mhz. – Very low design frequency due to long combinatorial paths of the IP core (Specially expensive in time for ATMEL FPGAs). – Not functional problem but detailed analysis needed. IP core works without big issues -24 -

SCN Problems IP core Usable with ATF 280 Estrange problem with encapsulated transistor burnt after an On Off On cycle. DK not damaged but component need to be replaced. -25 -

CAN UARTBridge – Hurry. CANe – ESA IP Core implementing the DATA LINK LATER of BOSCH 2. 0 A and B CAN standard interfacing Open. Cores simple serial UART 96008 N 1. – Dummy LCD display controlled with simple state machine to monitor traffic. -26 -

CAN-UART Setup 1. Physical Layer Driver for CAN Voltage levels in protoboard. Equivalent to SCN including; Serial port on computer with Putty as terminal 2. Used 65 HVD 251 from TI (CAN V levels, not RS 485) Up to 1 Mbp 3. Vector CANoe software package to simulate CAN network nodes and monitor trafic. 4. PCMCIA Card with optocoupled physical layer drivers. 5. Serial port on computer with Putty as terminal. Design validated and verified ✔ -27 -

CAN-UART Results. Area Technology Comparison ATMEL – ATF 280 ALTERA – Cyclone II ACTEL – RTAX 1000 XILINX – Virtex 4 FIGARO Report (FANOUT = 100) -28 -

CAN-UART Results. Timing Technology Comparison FANOUT impact: not too large for this design ATMEL – ATF 280 ALTERA – Cyclone II FANOUT = 100 FANOUT = 30 ACTEL – RTAX 1000 XILINX – Virtex 4 FIGARO Report FANOUT = 30 -29 -

CAN-UART Results. FGEN 2 Technology Comparison FIGARO Report Where are the FGEN 2? ? (In the lpms? ? ) PRECISION Report -30 -

CAN-UART Results Repeaters Delay in the nets: very high for ATF 280 (for many 4 ns), characterization required. ATMEL – ATF 280 XILINX – Virtex 4 -31 -

CAN-UART Results Design validated and verified ✔ – CAN traffic and Serial traffic monitored on LCD. – FGEN 2 problem identified on Precision reports. – Fan. Out doesn’t change results significantly. – Technology Gap between Atmel and other technologies. – Mature expertise with Atmel tools assessed. – ESA CAN IP Core simple and useful, even with ATF 280 -32 -

Outline • Experience learning the ATMEL development kit. • Exposition about the work done with the Hurri. CANe IP core. • Exposition about the work done with the Space. Wire-b ESA Codec IP core -33 -

Sp. W Codec – Implementation of Uo. D Space Wire Codec ESA IP – According to standard ECSS-E-ST-50 -12 C – High-speed serial protocol for links and networks used onboard spacecraft. – Up to 400 Mbits/sec, bi-directional and full-duplex. – Application information is sent along a Space. Wire link in discrete packets. – Control and time information can also be sent along Space. Wire links. -34 -

Sp. W Codec Info – Space. Wire CODEC is responsible for making a connection with the Space. Wire interface at the other end of a link. – Managing the flow of data across the link. – The interface transmits and receives Space. Wire characters which can be link characters (L-Char) or normal characters (N-Char). – L-Chars are characters that are used to manage the flow of data across a link (NULL & FCT). – N-Chars are the characters that are used to pass information across the link (data characters, EOP, EEP and time-codes). -35 -

Sp. W Approach – Three Sp. W ESA IPs available; – Sp. W-b; Sp. W alone codec. – Sp. W-AMBA; Sp. W codec with AMBA interface. – Sp. W-RMAP; Sp. W codec with Remote Memory Access Protocol (RMAP) extensions. – Planned to start with Sp. W RMAP IP; standard mechanism for reading from, and writing to memory in a remote Space. Wire node. – Preliminary analysis shown problems mapping RMAP memories inside FPGA. – Only 115 -Kbits of user-configurable SRAM. – Limited usability of this RAM due to Figaro IDS. Glue logic routing problems – Finally first approach with Space. Wire CODEC alone and later continue with RMAP mapping memories outside FPGA. -36 -

Sp. W Codec IP – Very versatile IP core with many configuration options; – Valuable for experienced user / Confusing for newcomer – Main options are; – Pipelined to increase transmission speed or non pipelined to save area. – DDR outputs or SDR outputs depending the on required data rate and the users selected technology. – TX clock configuration options to allow an independent TX clock and default system clock therefore greatly increasing the achievable data rate and decoupling the TX logic from the system clock logic. – Internal variable data rate generation. – Configurable receive buffer size. Internal FCT credit counter operations are handled internally. – No functional example available in documentation. Only Sp. W RMAP Xilinx implementation sample. – Only generic wrapper available with a TX FIFO and RX memory. -37 -

Sp. W Codec Configuration – First approach with a basic configuration; Fixed 10 Mbps TX rate. – Two clock domains; – System and TX clocks common clock at 10 Mhz. – RX recovered clock. – No DDR outputs – Small TX and RX FIFOs; 16 words of 9 bits. – Loopback of data inside FPGA – Establish a running link with Brick Tool – Tests the standard with Sp. W Conformance Tester – Monitoring traffic with Sp. W router -38 -

Sp. W Codec Simulation. I – First problems with the available simulation test bench; – Verification test bench useful only with the codec itself. – Runs different codec configuration tests. – Monitors Sp. W traffic and internal signals of the codec. – Wrapper on top doesn’t allow configuration changes and hides internal signals. -39 -

Sp. W Codec Simulation. II – Decided to simulate codec itself post Synthesis and Post P&R – P&R requires some GENERICS to be defined, problem to simulate all tests as logic synthesis removes unused logic. – Simulation only of the selected configuration. – Lack of documentation to select specific test. – Manual modification of synthesis and simulation scripts. – Not available Modelsim Post Synthesis ATMEL libraries. – Short help guide and libraries received upon request. – Manual Post Synthesis. vhd and libraries modification requried. – Same problem with Post Place and Route simulation – Some test failed due to RX clock recovery. -40 -

Sp. W Codec Hardware Setup – Basic design; Fixed 10 Mbps TX rate, two domain clocks Nice surprise; The official Development Kit had the wrong Sp. W receptacle. Back to ATMEL prototype. -41 -

Sp. W Codec Clock Recovery I – Critical Clock Recovery; Constraint design. – Sp. W has timing constrains for recovery. – Microsemi (ACTEL) application note suggest manual routing. – Previous ATMEL Sp. W desing (V. Carlier IAS/ORSAY) routed manually. TX 20 Mbps/RX 120 Mbps – Our design; low speed, 10 Mbps, automated routing could work -42 -

Sp. W Codec Clock Recovery II – Recovered Clock is a Derived Clock – ATMEL suit doesn’t initially allow Derived Clocks – New release while working fixed that problem. – ATMEL suit doesn’t allow STA for clock falling edges – We assume that the same engine is used for STA and Time Driven P&R – Figaro puts effort in optimizing paths with falling edges, leaving rest of design non optimized. – Really poor low performance in results, max clocks around 10 Mhz – Non Time Driven P&R gives similar results – Next step hardware validation of the design -43 -

Sp. W Codec First Results – Initial configuration was 2 Sp. W instances of the Codec connected in loopback mode inside the FPGA. – The link was running for a few useconds before disconnect error of the brick – The link was stablished with other hardware Working with Sp. W router, Conformance Tester and Link Analyzer. (Thanks to TEC-EDP) – Link Active but Nchar traffic was not loopbacked – Next step debugging with Logic Analyzer (Thanks to TEC-EDD) -44 -

Sp. W Codec Debugging I Periodic Disconnect Error -45 -

Sp. W Codec Debugging II – When mapping out signals random behavior of the design. – Random effort trying to debug the functionality of the P&R. – Some times affected even the current consumption of the board. – 210 m. A regular design vs 400 m. A in some working instances – Waiting issue answer of ATMEL Help line – Possible damage of the board discarded after manual analysis of resources used in designs that shown estrange current behavior. – Corruption of the bitstream discarded after comparison between bitstreams in DK memory and computer. – Assumption for possible timing related problems with P&R Simpler design with only one codec. -46 -

Sp. W Codec Debugging III – Less random behavior of the development kit – Ass before link established normally. – Loopback of characters. – Not fully functional – Characters not in order. – Unknown characters – Problem in TX or RX? – New design with UART – Monitor RX character and clock domain – Monitor TX and system clock domain -47 -

Sp. W Codec Debugging IV – With this last configuration RX domain validated – UART monitors RX characters, some improvements needed – Automated P&R for RX clock recovery at low speed valid – Work being done in the TX and system clock domain – UART not well connected to TX FIFO or timing problem? – New iteration in STA of the design; estrange behavior of IDS Figaro when changing Constraint for STA with a fix P&R – Re-running STA relaxing some strong constraints produces improvement in timing performance --- Correct – Re-running STA rising some strong constraints produces improvement in timing performance --- Non correct? ? – Probably related to falling edge clocks. Not clear answer from ATMEL help line, still under investigation. -48 -

Sp. W Codec Results Area FIGARO Report Mentor Precision for ATMEL – ATF 280 -49 -

Sp. W Codec Results. Timing Mentor Precision for ATMEL – ATF 280 FIGARO Report -50 -

CAN-UART Results Design not yet validated and verified – Further work need to be developed – ESA Sp. W-b IP Core powerful but complex – Lack of examples – Not easy simulation of designs, only the codec – Automated routing for low speed valid – ATMEL main problem timing; possible to synthesize Sp. W with ATMEL but tricky -51 -

ATF 280 Timing Charact. A Timing Characterization is being developed Correlate simulations with real Hardware. ATMEL timing issues related to net delays? Repeaters? Last library updates doesn’t add big penalty when routing repeaters Further analysis required -52 -

ATF 280 DK Conclusions – Non trivial tool flow, compilation of several vendor software; – self learning the software will not give the same results as experimented users could get, help needed. – Lack of application examples and some documentation. Only self test bit stream with the FPGA, need to ask for samples. – Lack of centralized document with tips and tricks for new users. – Old dated manuals and tutorials, 2002, lots of changes. – Fast and good support from ATMEL Rad. Hard Hotline; efficient and fast solutions answers and help. -53 -

ATF 280 DK Conclusions – Old errors and problems still reproduced. Need to be fixed. – Routing problems due to non optimal Placement, specially registered outputs and clock resources on mixed clock domains. – LPM and Macros seen as black boxes, no timing or area resources report in Synthesis step. – FGEN 2 estrange behavior. – Improve Atmel timing reports and correlation with Precision and reality. – Not support for falling clock edges in STA or Timing driven P&R, STA. -54 -

ATF 280 DK Conclusions – Strong differences between ATMEL and other technologies. – Not always comparable; XTMR overhead or other techniques avoided with Rad. Hard by design architecture from ATMEL; – Valid comparison in terms of speed – Non equivalent comparison in terms of Area due to different radiation features. – Not suitable FPGA for “big” designs but still valid for small/medium designs. – Problem with the Development Kit, Transistors burnt with only switching on-off-on, Sp. W receptacles. – Space. Programmer without native drivers for 64 bit Windows Versions, useless. FIGARO not working under windows 7. -55 -

Hurri. CANe. Conclusions – IP core easy to use and learn. – Not big requirements in terms of area and clock. – Fastest configuration, 1 Mbps, running even in ATF 280 – Possible upgrade in clocks? Increase of system clock speed. Nowadays worst case is ATF 280, in the future ATF 450? – Stable design, well documented. Lack of info about ATMEL FPGA. – Complement to higher levels of CAN stack, next ESA CCIPC IP. -56 -

Sp. W Codec Conclusions – IP core versatile and powerful. – Not easy to use and configure. – Lack of some examples of configuration. – Some status signals in the IP core could be replaced for debug. – Not big requirements in terms of area. Tricky P&R for the clock recovery. – Not yet working with ATMEL. -57 -

Global Conclusions Atmel on the good path. ATF 280 still valid for some designs. Improvements on the tools would give more usability. More work need to be done. Atmel Users Group Forum needs to be stimulated and updated. -58 -

THANKS FOR YOUR TIME QUESTIONS? -59 -

YOUR TIME

Down Counter Area Down Counter; AREA Precision Vs IDS ATMEL IDS MENTOR PRECISION MENTOR Similar Results PRECISION

Down Counter Timing Down Counter; TIMING Precision Vs IDS MENTOR PRECISION ATMEL IDS Not So Accurate Correlation

Down Counter Macros Down Counter; AREA and TIMING VHDL Vs IDS Hard Macros VHDL HARD MACROS Hard. Macros perform much better

CAN-UART IDSFigaro

Registered. Outputs