• Nenhum resultado encontrado

UNIVERSIDADE FEDERAL DO PARANÁ Departamento de Engenharia Elétrica Gabriel Casagrande Borba

N/A
N/A
Protected

Academic year: 2021

Share "UNIVERSIDADE FEDERAL DO PARANÁ Departamento de Engenharia Elétrica Gabriel Casagrande Borba"

Copied!
60
0
0

Texto

(1)

UNIVERSIDADE FEDERAL DO PARANÁ Departamento de Engenharia Elétrica

Gabriel Casagrande Borba

MIGRATION AND ANALYSIS OF REAL-NUMBER ANALOG RADIO MODELS FROM WREAL TO SYSTEMVERILOG-AMS AND REAL-NUMBER MODELING

OF PHASE NOISE IN A VCO

Curitiba, PR

2020

(2)
(3)

Gabriel Casagrande Borba

MIGRATION AND ANALYSIS OF REAL-NUMBER ANALOG RADIO MODELS FROM WREAL TO SYSTEMVERILOG-AMS AND REAL-NUMBER MODELING

OF PHASE NOISE IN A VCO

Projeto apresentado como requisito à obtenção de nota da disciplina TEX003 - PROJETO DE ENGENHA- RIA ELÉTRICA PARA DUPLA DIPLOMAÇÃO do curso de Engenharia Elétrica com ênfase em Eletrotéc- nica, Eletrônica e Telecomunicações.

Orientador: Prof. Dr. André Augusto Mariano Coorientador: Ph.D. Chantal Gunther

Curitiba, PR

2020

(4)

Gabriel Casagrande Borba

MIGRATION AND ANALYSIS OF REAL-NUMBER ANALOG RADIO MODELS FROM WREAL TO SYSTEMVERILOG-AMS AND REAL-NUMBER MODELING

OF PHASE NOISE IN A VCO

Trabalho de Conclusão de Curso apresentado ao curso de Engenharia Elétrica da Universidade Federal do Pa- raná como requisito à obtenção do grau de Engenheiro Eletricista, pela seguinte banca examinadora:

Orientador: Prof. Dr. André Augusto Mariano

Aprovado em: / / .

Prof. Dr. André Augusto Mariano Orientador

Prof. Dr. Bernardo R. B. de Almeida Leite Departamento de Engenharia Elétrica,

UFPR

Prof. Dr. Luis H. A. Lolis

Departamento de Engenharia Elétrica, UFPR

Curitiba, PR

(5)

AGRADECIMENTOS

Ao meu supervisor de estágio, Mickael Lucas pela valiosa troca de conhecimento durante a realização deste projeto.

Ao meu orientador, Prof. Dr. André Augusto Mariano, pelo acompanhamento, dedi- cação e motivação ao longo deste trabalho e toda a formação.

Aos professores Prof. Dr. Bernardo R. B. de Almeida Leite e Prof. Dr. Luis Henrique Assumpção Lolis pela orientação e dedicação durante projetos de iniciação científica e PET.

À coordenadora de relações internacionais da ENSICAEN Chantal Gunther e toda sua equipe, pelo apoio durante os anos de estudo neste estabelecimento.

Aos meus pais, pelo apoio incondicional, paciência e encorajamento durante todos

os anos de formação.

(6)
(7)

RESUMO

As aplicações de sinais mistos estão entre os segmentos de mercado de crescimento mais rápido na indústria de semicondutores. Um setor muito importante no AMS é o de modelagem e verificação. A verificação de um SoC de sinal misto envolve muitos níveis diferentes de abstração.

O inconveniente de usar simuladores SPICE é que eles são muito lentos para simulações em nível de chip, a menos que seja usado de forma seletiva. A fim de alcançar velocidades de simulação razoáveis, os projetistas empregam modelagem analógica, que já é até 100 vezes mais rápida do que a SPICE. A modelagem em números reais (RNM) é significativamente mais rápida que a modelagem analógica, e seu uso está sendo cada vez mais difundido no domínio da modelagem e verificação. Neste trabalho, é apresentado um método de migração para alternar entre wreal e SystemVerilog. Scripts em Python foram criados para aplicar o método de migração a fim de migrar um sistema de rádio completo, bem como validar sua robustez. Além disso, é apresentado um modelo de ruído de fase em número real em um VCO. A ferramenta de migração apresenta o funcionamento desejado, podendo realizar a migração de modelos únicos ou mesmo vários modelos por vez. O funcionamento destas ferramentas foi validado através de simulações realizadas com ambos os modelos em wreal e SystemVerilog e constatando que os resultados são os mesmos do ponto de vista funcional, bem como na análise de consumo de memória e recursos de tempo. Quanto à modelagem de ruído de fase no VCO, foi possível conceber um modelo robusto cujo comportamento aproxima-se bastante do real, sendo possível notar a presença das 3 pincipais componentes de ruído de fase em osciladores: jitter, wander e flicker. Entretanto, ainda é preciso aprimorar a precisão deste último.

Palavras-chave: Analog-Mixed Signal (AMS), Modelagem e verificação, Modelagem em nú-

meros reais (RNM), ruído de fase, wreal, SystemVerilog

(8)
(9)

ABSTRACT

Mixed-signal applications are among the fastest growing market segments in the semi-conductor industry. A very important sector in AMS is modeling and verification. Verification of a mixed- signal SoC involves many different levels of abstraction. The inconvenience of using SPICE simulators is that it is too slow for chip-level simulations, unless used selectively. In order to achieve reasonable simulation speeds, designers employ analog-modeling, which is already up to 100 times faster than SPICE. Real-Number modeling (RNM) is significantly faster than analog-modeling, and its use is being increasingly disseminated in the modeling and verification domain. In this work, a migration method for switching between wreal and SystemVerilog is presented. Python scripts were created to apply the migration method in order to migrate a full radio system, as well as validating its robustness. Additionally, a real-number model of phase noise in a VCO is presented. The model ensures first-time right analog functionality and performance. The migration tool shows the desired operation and can perform the migration of single models or even several models at a time. The operation of these tools has been validated through simulations performed with both wreal and SystemVerilog models and finding that the results are the same from a functional point of view, as well as in the analysis of memory consumption and timing resources. As for the phase noise modeling in the VCO, it was possible to design a robust model whose behavior is very close to reality, being possible to notice the presence of the 3 main components of phase noise in oscillators: jitter, wander and flicker.

However, it is still necessary to improve the accuracy of the latter.

Keywords: Analog-Mixed Signal (AMS), Modeling & Verification, Real-Number Modeling

(RNM), Phase Noise, wreal, SystemVerilog

(10)
(11)

LIST OF FIGURES

Fig. 1 – Model accuracy versus performance gain in mixed-signal (S. BALASUBRA-

MANIAN, P. HARDEE, CADENCE DESIGN SYSTEMS, s.d.) . . . . 16

Fig. 2 – NXP Caen Site - Campus Effiscience. Taken from: Web - July 2020. . . . . 17

Fig. 3 – Example of an application of UDT in SystemVerilog - Current limit check in a LDO . . . . 19

Fig. 4 – Lune - GEN5 Radio System schematic . . . . 20

Fig. 5 – Phase detector core precharge cell simulation results for both wreal and System- Verilog models . . . . 24

Fig. 6 – Migration script GUI . . . . 25

Fig. 7 – Main function flowchart . . . . 29

Fig. 8 – textInputs_and_amsbind_migration.py GUI . . . . 31

Fig. 9 – tb_and_agent_migration_vams2sv.py GUI . . . . 32

Fig. 10 – Batch-mode migration script GUI . . . . 32

Fig. 11 – PLL Macro block symbol . . . . 33

Fig. 12 – PLL Macro block schematic . . . . 34

Fig. 13 – Locking scenario of synthesizer macro block. Simulation comparison between wreal and SystemVerilog . . . . 35

Fig. 14 – Calibration and Modulation scenario of synthesizer macro block. Simulation comparison between wreal and SystemVerilog . . . . 36

Fig. 15 – Comparison between transmission scenario simulation results for wreal and SystemVerilog, respectively . . . . 37

Fig. 16 – Comparison between reception scenario simulation results for wreal and Sys- temVerilog, respectively . . . . 38

Fig. 17 – Comparison between baseband reception scenario simulation results for wreal and SystemVerilog, respectively . . . . 38

Fig. 18 – . . . . 39

Fig. 19 – Phase noise spectrum of an oscillator (R. B. STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005) . . . . 40

Fig. 20 – Development of non-accumulative timing deviations (TDEV) (R. B. STAS- ZEWSKI, C. FERNANDO, P. T. BALSARA, 2005) . . . . 41

Fig. 21 – Development of an accumulative TDEV . . . . 42

Fig. 22 – Flicker noise modeling . . . . 43

Fig. 23 – Random variable verification . . . . 46

Fig. 24 – Logarithmic plot of PSD of phase noise . . . . 47

Fig. 25 – XO 32 Mhz simulation results comparison between wreal and SystemVerilog . 53

Fig. 26 – RXIF simulation results comparison between wreal and SystemVerilog . . . . 55

(12)
(13)

LIST OF TABLES

Table 1 – Timing and memory resources comparison between wreal and SystemVerilog - Locking Scenario . . . . 34 Table 2 – Timing and memory resources comparison between wreal and SystemVerilog

- modulation Scenario . . . . 35

Table 3 – Comparison between simulation results and reference values . . . . 47

(14)
(15)

TABLE OF CONTENTS

1 INTRODUCTION . . . . 15

1.1 Project Contextualization . . . . 15

1.1.1 Mixed-Signal Block and IC-Level Verification . . . . 15

1.2 NXP Semiconductors . . . . 16

1.2.1 The company . . . . 16

1.2.2 The Caen site . . . . 17

2 WREAL TO SYSTEMVERILOG REAL MIGRATION . . . . 19

2.1 Motivation . . . . 19

2.2 Objectives . . . . 20

2.3 Single-block manual migration . . . . 21

2.3.1 Main syntax modifications . . . . 21

2.3.1.1 Constants

. . . .

22

2.3.1.2 Standard disciplines and constant include files

. . . .

22

2.3.1.3 Types and disciplines

. . . .

22

2.3.1.4 Mathematical and system functions

. . . .

23

2.3.2 Manual migration of phase detector core precharge cell . . . . 24

2.4 Python Migration Script . . . . 24

2.4.1 User interface setup . . . . 25

2.4.2 Main function and flowchart . . . . 26

2.4.2.1 open_file( ) function

. . . .

30

2.4.2.2 get_file_name( file ) function

. . . .

30

2.4.2.3 make_output_file_path_single( file ) function

. . . .

30

2.4.2.4 make_design_info_section( output_file ) function

. . . .

30

2.4.2.5 line_num_for_phrase_in_file( text, file_name) function

. . . .

30

2.4.2.6 delete_line( file_name, line_number ) function

. . . .

30

2.4.2.7 insert_line(file_name, line_number, string ) function

. . . .

30

2.4.2.8 read_line( file_name, line_number) function

. . . .

31

2.4.2.9 replace_string( file_name, data_to_find, data_to_replace ) function

. . . .

31

2.4.2.10 log_message( ) function

. . . .

31

2.4.2.11 view_output( file_name ) function

. . . .

31

2.4.3 Other migration scripts . . . . 31

2.4.3.1 textInputs_and_amsbind_migration.py

. . . .

31

2.4.3.2 testbench_and_agent_creation_SV.py

. . . .

31

2.4.3.3 tb_and_agent_migration_vams2sv.py

. . . .

32

2.4.3.4 Migration_batch.py

. . . .

32

2.5 Migration of Macro-Block : PLL . . . . 33

(16)

2.5.1 Macro block simulation results . . . . 34

2.6 Complete migration of radio system . . . . 36

2.6.1 RFFE simulation scenarios . . . . 37

2.6.2 Migration of LDO (Low-dropout) cells . . . . 37

2.6.3 Migration of remaining blocks . . . . 37

3 REAL-NUMBER MODELING OF PHASE NOISE IN A VCO . . . . . 39

3.1 Motivation and Objectives . . . . 39

3.2 Bibliographic development . . . . 39

3.2.1 Time-domain modeling of phase noise . . . . 40

3.2.2 Jitter modeling . . . . 40

3.2.3 Wander modeling . . . . 42

3.2.4 Flicker modeling . . . . 42

3.3 VCO Model Modifications . . . . 43

3.4 Post processing of simulation data . . . . 45

3.4.1 Phase Noise calculation and Power Spectral Density . . . . 46

4 CONCLUSION . . . . 49

Referências . . . . 51

ANEXO A – XO SIMULATION RESULTS . . . . 53

ANEXO B – RXIF SIMULATION RESULTS . . . . 55

ANEXO C – PSD CALCULATION MATLAB SCRIPT . . . . 57

(17)

15

1 INTRODUCTION

1.1 Project Contextualization

Mixed-signal applications are among the fastest growing market segments in the semiconductor industry. Driven by growth opportunities in mobile communication, networking, automobile, medical and several other sectors, many silicon vendors have started refocusing their businesses on RF, high-performance analog and mixed-signal designs. Due to this trend, most system-on-chip (SoC) designs these days are mixed-signal.

As the demand for integration grows, SoC designers are adding more and more analog circuitry and importing large Mixed-Signal Intellectual Property (MSIP). This poses challenges for SoC verification, such as incomplete SoC and System-level verification and uncertainties in verification coverage. (S. BALASUBRAMANIAN, P. HARDEE, CADENCE DESIGN SYSTEMS, s.d.)

1.1.1 Mixed-Signal Block and IC-Level Verification

Verification of a mixed-signal SoC involves many different levels of abstraction.

Generally speaking, the most accurate standard for analog IP verification would be SPICE for transistor-level simulation. The inconvenience is that it is too slow for chip-level simulations, unless used selectively. In order to achieve reasonable simulation speeds, designers employ analog-modeling, which is already up to 100 times faster than SPICE.

Analog and analog mixed-signal models are typically written in languages such as:

• Verilog-AMS: A mixed-signal modeling language based on the IEEE 1364 Verilog stan- dard that defines analog and digital behavior, and provides both continuous-time and event-driven modeling semantics;

• Wreal: a Verilog-AMS based language extended with real number nettypes (wire real).

• SystemVerilog-AMS: This language is extended with real number nettypes and custom user-defined nettypes, such as IEEE 1800-2012 SV-DC extensions, also known as SV- RNM.

Figure 1 depicts the trade-offs between simulation accuracy and performance amongst

different languages and pure digital simulation. These numbers can significantly differ depending

on the application. Note that pure digital can only represent analog signals as single logic values,

but it can sometimes suffice for simple connectivity checks in Mixed-Signal SoCs.

(18)

16

Fig. 1 – Model accuracy versus performance gain in mixed-signal (S. BALASUBRAMANIAN, P. HARDEE, CADENCE DESIGN SYSTEMS, s.d.)

Real-Number Modeling allows the representation of electrical parameters (e.g. vol- tage levels, current levels, etc.), for instance, as discrete, floating point real numbers, describing the block as a signal flow model, making it possible to simulate it in a digital solver at higher speeds. The great advantage of RNM lies in top SoC verification, where all electrical signals can be represented by real numbers, allowing designers to stay within the digital simulation environment, thus enabling regressions to cover full chip functionality and still maintaining high simulation performance.

1.2 NXP Semiconductors 1.2.1 The company

NXP Semiconductors is a global semiconductors manufacturer. Headquartered in Eindhoven (Netherlands), the company has operations in over 30 countries, with more than 100 facilities. One of the world’s largest semiconductor manufacturers, NXP counts with approxi- mately 29,000 employees, of which 9,000 are engineers related to Research and Development (R&D), which is reflected in the 9,000 issued and pending patent families owned by the company.

Its main businesses are secure connected devices, secure interface and infrastructure, secure identification, solutions and automotive.

Formerly the semiconductors branch of Phillips, the company was sold in 2006 to

a consortium, being renamed to NXP Semiconductors. NXP was co-inventor of the Near-Field

Communication technology (NFC) alongside Sony. To this day, the company is a leading manu-

facturer of NFC chips and after merging with Freescale Semiconductors in 2015, NXP became a

(19)

17 leader in the semiconductor solutions in the automotive industry. (NXP SEMICONDUCTORS, 2020)

1.2.2 The Caen site

My internship was conducted in the Caen site of NXP (Fig. 2), which is the second largest NXP site in France. This site accommodates more than 280 employees, most of which are related to Research & Development activities in the radio-frequency (RF), Microcontroller and Infrastructure & Mobile domains.

Fig. 2 – NXP Caen Site - Campus Effiscience. Taken from: Web - July 2020.

The Caen site is the base of operation of three Business Lines (BLs) within NXP: BL

Secure Transaction & Identification (BL STI), BL Smart Antenna Solutions (BL SAS) and BL

Microcontroller. The latter has multiple teams on the site, one of them being the Connectivity

Team, which is also present in the Sophia-Antipolis site and the team I integrated for the duration

of my internship.

(20)
(21)

19

2 WREAL TO SYSTEMVERILOG REAL MIGRATION

2.1 Motivation

What then would be the interest of switching between Wreal and SystemVerilog- AMS, given that they are both Real-Number, Verilog based languages?

It is a growing tendency in the verification domain to switch to SystemVerilog, not only because it is a more recent standard, but most importantly, it is vendor independent (standard driven, implemented by EDA vendors like Cadence, Synopsis, etc.).

From the technical point of view, this migration to SystemVerilog can be justified by its better integration in the verification flow. The Universal Verification Methodology (UVM) is SystemVerilog based and its class library brings much more automation to the language such as sequences and data automation features (compare, packing, copy, etc.).

Another important feature of SystemVerilog is the intrinsic support for assertions.

The behaviour of a system can be written as an assertion that should be true at all times. Hence, assertions are used to validate the behaviour of a system defined as properties, and can also be used in functional coverage. Furthermore, SystemVerilog is an universal language (from behavioural to RTL and verification).

This transition could also offer new possibilities in modeling, such as the implemen- tation of user-defined types (UDT/nettypes), which are custom types for wires that present the possibility of having more than one value per wire at a time, which is something that cannot be done in Wreal. An example is presented in Figure 3, where it is possible to see each wire has voltage and current levels.

Fig. 3 – Example of an application of UDT in SystemVerilog - Current limit check in a LDO

This would be interesting having seen that in this specific example, current consump-

tion per supply domain would be immediately available. Other applications this feature could

help bring together is the possibility to obtain values for amplitude and frequency values for

clocked signals, for instance, and the possibility of the implementation of bidirectional switches

(available from Cadence and not Wreal).

(22)

20

2.2 Objectives

Having gone through what drives the need to switch to this new standard, the first step is to establish the main goals of this project. The main objective is to migrate all models inside a full radio system designed by NXP (Fig. 4), including complex blocks such as phase-locked loop, RF Front End (RFFE), LDOs and analog-to-digital converters.

Fig. 4 – Lune - GEN5 Radio System schematic

As each of these blocks are composed of over 60 sub-models each, another important

goal to this project would be to automate the migration process. This way, the work developed in

this project could be reused in future work with ease by anyone.

(23)

21 2.3 Single-block manual migration

In order to construct an algorithm for the automatic migration of these models, all modifications that need to be done have to be previously determined. To that intent, a manual migration of a cell is proposed.

The first cell to be migrated was chosen based on complexity. An important com- ponent of a phase-locked loop is the phase detector. A simple yet adequate cell to start off the establishment of the necessary modifications would be the pre-charger of this phase detector.

The steps to be executed when migrating a model are as follows:

1. Determine all syntax changes;

2. Creation of a "systemVerilog"cellview;

3. Apply necessary syntax changes;

4. Run the simulation with the cell’s corresponding testbench in wreal;

5. Run the simulation with the same testbench, but using the new "systemVerilog"model;

6. Verify that both simulations render the same results;

7. If results aren’t the same, backtrack to wreal model and verify eventual functionality modifications and standard nettype declarations;

8. Validate model migration and check-in the new model in the database.

2.3.1 Main syntax modifications

In this section, the necessary syntax changes will be discussed. In (J. SYMONS, I. M. DE LA ROSA, M. BARNASCONI, J. WESTENDORP, 2016), a modification list when migrating from one language to the other is presented. The main differences in syntax are seen in the following model structures:

• Constants;

• Standard disciplines and constant include files;

• Port types and disciplines;

• Compiler directives and built-in functions.

(24)

22

2.3.1.1 Constants

The first noticeable difference between wreal and SystemVerilog is in the way constants are represented. SystemVerilog doesn’t recognise real number scalers such as m, µ, n and so on. They must be replaced with the equivalent engineering notation: e-3, e-6, e-9 and so on.

Another issue is the way time constants are represented. In Wreal, delay is dimensi- onless and is expressed in "ticks", or the number of time units defined in the timescale directive.

In SystemVerilog, time can be dimensionless but the recommended usage is to define a time unit. This unit acts as an operator that computes the number of time ticks. The example coding displayed below is equivalent.

Listing 1 – Wreal Example coding

1 ‘ t i m e s c a l e 1 ns /1 ps

2 ‘ d e f i n e T I C K 1.0 E -9

3 r e a l d e l a y = 1 n ;

5 #1;

6 #(1 n / ‘ T I C K ) ;

7 #( d e l a y / ‘ T I C K ) ;

Listing 2 – Equivalent in SV Real

1 ‘ t i m e s c a l e 1 ns /1 ps

2 //

3 t i m e d e l a y = 1.0 e - 0 9 ;

5 #1;

6 #1 ns ;

7 #( d e l a y *1 s ) ;

2.3.1.2 Standard disciplines and constant include files

Verilog-AMS uses "disciplines"to further describe the port type. A port type can be wire real and have either a vreal or ireal discipline associated to it, whether it is a voltage or current that needs representation, for instance. The Verilog-AMS discipline include files have no equivalent in SystemVerilog-AMS. Include statements for such files should be removed when migrating, and as the work environment used in this project is Cadence, the Cadence SV package should be imported. This is necessary because it contains functionalities that are equivalent to the wreal net type from Verilog-AMS. The coding below exemplifies this modifications.

Listing 3 – Wreal Example coding

1 i n c l u d e " d i s c i p l i n e s . v a m s " ;

2 i n c l u d e " c o n s t a n t s . v a m s " ;

Listing 4 – Equivalent in SV Real

1 i m p o r t c d s _ r n m _ p k g : : * ;

2 //

2.3.1.3 Types and disciplines

In Verilog-AMS, a net should have a type and potentially a discipline specified. If the

discipline is not specified, the default discipline is assumed. In SystemVerilog, on the other hand,

the distinction between types and disciplines does not exist. If the specification of both type

(25)

23 and discipline is present, SV interprets it as a double definition and accuses an error. Therefore, all disciplines declarations should be removed and port types should be adapted accordingly.

Wires and registers are to be changed to ’logic’. This is done so that the compiler can resolve the declaration to either a net or variable, based on its first use.

The wreal replacement should include the resolution functions available in the Cadence RNM package. This facilitates migration, as variables and nets shouldn’t need to be redefined. There are three resolution functions to be included: the replacements for the wreal type and the vreal and ireal disciplines. The coding in listings 5 and 6 shows the net type resolution functions declarations.

Listing 5 – Wreal Example coding

1 w r e a l r v a r ; // t y p e

3 w r e a l v n e t ; // t y p e

4 v r e a l v n e t ; // d i s c i p l i n e

6 w r e a l i n e t ; // t y p e

7 i r e a l i n e t ; // d i s c i p l i n e

Listing 6 – Equivalent in SV Real

1 n e t t y p e r e a l w r e a l w i t h C D S _ r e s _ w r e a l 1 d r i v e r ;

2 n e t t y p e r e a l v r e a l w i t h C D S _ r e s _ w r e a l a v g ;

3 n e t t y p e r e a l i r e a l w i t h C D S _ r e s _ w r e a l s u m ;

5 w r e a l r v a l ;

6 v r e a l v n e t ;

7 i r e a l i n e t ;

2.3.1.4 Mathematical and system functions

Just as in Verilog-AMS, SystemVerilog has several built-in mathematical functions which are equivalent to the functions of the standard C math library. The change here is as subtle as adding a "$"prefix before calling the function. Also, the $abstime system function has been renamed to $realtime. Listings 7 and 8 illustrate this change.

Listing 7 – Wreal Example coding

1 ‘ d e f i n e M _ T W O _ P I 6 . 2 8 3 1 8

2 ‘ d e f i n e F 1.0 M

4 sin ( ‘ M _ T W O _ P I * ‘F * $ a b s t i m e )

Listing 8 – Equivalent in SV Real

1 ‘ d e f i n e M _ T W O _ P I 6 . 2 8 3 1 8

2 ‘ d e f i n e F 1.0 e6

4 $ s i n ( ‘ M _ T W O _ P I * ‘F *

$ r e a l t i m e )

(26)

24

2.3.2 Manual migration of phase detector core precharge cell

As seen in the beginning of this section, after evaluating the necessary changes to be executed, a manual migration of a simple model is done. A new cellview is created and the migrated coding is inserted. As depicted in figure 5, simulation results for both wreal and SystemVerilog simulations are the same, thus validating the modifications to this model.

All simulations were conducted using the SimVision tool (by Cadence) and the xrun/irun command.

(a) wreal simulation results

(b) SystemVerilog simulation results

Fig. 5 – Phase detector core precharge cell simulation results for both wreal and SystemVerilog models

After a first model has been migrated, an algorithm can be established in order to automate the process. In the next section, the functions used in the migration script will be discussed.

2.4 Python Migration Script

The reason for the choice of the Python language over other options such as C, for instance, is based on the fact that it supports file handling and allows users to read and write files, along with many other file handling options. The concept of file handling has stretched over various other languages, but the implementation is either complicated or lengthy, but alike other concepts of Python, this concept here is also easy and short. Python treats file differently as text or binary and this is important. Each line of code includes a sequence of characters and they form text file. Each line of a file is terminated with a special character, called the EOL or End of Line characters like comma (,) or newline character. It ends the current line and tells the interpreter a new one has begun. (C. LENKA, 2018)

In this section, the structure of the script created to automate the migration progress

is discussed. The script’s complete code is available in the appendices section if further analysis

(27)

25 is needed. All functions used in this part will be explained and the main structure can be seen in the flowchart available in Figure 7.

In order to facilitate comprehension, the analysis will start with the main function and proceed with each secondary function afterwards.

2.4.1 User interface setup

As this program will be reused by others in the future, it should be as user-friendly as possible. Therefore, a Graphical User Interface (GUI) was put in place. In this subsection it is depicted how the user interface was setup.

For ease-of-use reasons, the tkinter package was used. It allows easy implementation of classic GUI elements such as labels, buttons, entry widgets and more. The information that needs to be displayed in such an interface in this case would be the file path for both input and output files, a log of what has been done by the script, a button that allows the user to choose a file (through the file explorer), two text entry widgets, one for the user to input his/her name and one for the user to specify the input file location via text (in this case the button wouldn’t be used). Another button is setup to initiate file migration and lastly, a ’View Output File’ button is available after migration has finished. The final result is displayed in Figure 6.

Fig. 6 – Migration script GUI

Listing 9 – GUI label setup example

1 f i l e _ l a b e l f r a m e _ i n = L a b e l F r a m e ( root , f o n t =( ’ h e l v e t i c a ’ ,10 , " b o l d " ) , bd =2.5 , t e x t = ’ S o u r c e F i l e p a t h : ’ )

2 f i l e _ l a b e l f r a m e _ i n . p l a c e ( r e l w i d t h = 0 . 7 3 7 5 , r e l h e i g h t =0.15 , r e l x

=0.25 , r e l y = 0 . 0 )

(28)

26

In listing 9 it is possible to see that parameters such as font, position and size are configured. This code is specific to the ’Source File path’ label. The rest of the interface setup can be seen in the appendices section.

2.4.2 Main function and flowchart

The flowchart depicted in Figure 7 explains how the main function operates and the way the algorithm works. A number of smaller functions are called and they will be discussed in the following subsections. As we can see from the flowchart, the program creates a copy of the input file in the same folder and starts doing modifications on it in a certain order. This script is based on the modeling methodology developed at Caen’s NXP site and depends on this standard quite highly. In order to work properly, the model should be coded as in listing 10.

Listing 10 – Modeling Standard methodology

1 /* - - - -

2 - - - -

3 D e s i g n I n f o r m a t i o n

4 - - - -

6 D a t e of c r e a t i o n : yyyy - mm - dd

7 O r g a n i z a t i o n : NXP S e m i c o n d u c t o r s , BL M I C R / C o n n e c t i v i t y IP

8 A u t h o r : ...

9 D e s i g n U n i t : " b l o c k n a m e " , " c e l l n a m e " , " w r e a l "

10 - - - -

11 D e s i g n N o t e s

12 - - - -

13 w r e a l v e r s i o n s c h e m a t i c v e r s i o n : a u t h o r ( D a t e ) c o m m e n t s

15 v e r s i o n 1.1 v e r s i o n 1.6 : A u t h o r N a m e ( dd / mm / y y y y ) c o m m e n t

16 - - - */

17 // S c h e m a t i c V e r s i o n : 1.6

19 // - - - -//

20 // S t a n d a r d I n c l u d e s

21 // - - - -//

22 ‘ i n c l u d e " s h a r e d . v a m s "

24 // - - - -//

25 // G l o b a l s S e t t i n g s

26 // - - - -//

27 ‘ t i m e s c a l e 1 ps / 1 ps // c h a n g e to y o u r p r e f e r e n c e s

28 ‘ u n d e f t i c k

(29)

27

30 // - - - -//

31 // M o d u l e h e a d e r & i n t e r f a c e d e f i n i t i o n

32 // - - - -//

33 m o d u l e m o d u l e _ n a m e ( a , b , c ... ) ;

34 // p o r t d i r e c t i o n s ( input , output , i n o u t )

36 i n p u t ...

38 // p o r t t y p e s ( reg , wire , w r e a l )

40 w r e a l ...

42 // p o r t d i s c i p l i n e s ( logic , e l e c t r i c a l , vreal , i r e a l )

44 v r e a l ...

46 // - - - -//

47 // D e f i n i t i o n s of l o c a l v a r i a b l e s ( w i r e / reg / w r e a l / r e a l )

48 // - - - -//

50 // - - - -//

51 e n d m o d u l e

53 // - - - -

54 // U n d e f i n e s ( if l o c a l d e f i n e is u s e d )

55 // - - - -

57 ‘ u n d e f t i c k

(30)

28

This script uses functions that identify certain key words present in this specific sections, such as ’//port types’, for instance in order to locate code pieces that are to be changed in a certain way. Therefore, when migrating models from wreal to SystemVerilog with the help of this script, the model in which it is to be applied has to follow the coding style depicted above.

This is used for the identification of each section, such as the separation of the port directions, types and disciplines in order to store port names and their respective types and disciplines in vectors so to compare them and create a port types section that is coherent with the wreal model, and also be able to erase the port disciplines section without trouble. This has presented a certain challenge, because not all models necessarily follow the same order when declaring port types and disciplines, so a simple vector comparison does not work. It was necessary to compare vector elements one by one to see if they have the same name and adjust their type in order to match the input file. Also, some port disciplines are commented in the wreal model and should not be taken into consideration when comparing vectors. To deal with this situation, another comparison needs to be done, but this time evaluating beforehand if the string that is to be compared has a comment prefix (’//’). All these problems were properly solved, the latest one being the adaptation of buses. When declaring logic buses, the port name is preceded with an array declaration (for the number of bits the bus allocates, for instance) in the format in listing 11.

The problem is that for wreal arrays, the discipline specification switches the order in which the array specification is positioned. This cannot be solved by vector comparing because the port name wouldn’t be the same. The way to automate this was to split the string of the line containing the port declaration at every ’[’ character, this way the ports that contain tables would be turned into an array of size 2. The regular ports would have size equal to 1. Then, the 1-sized arrays are excluded and the same is done with the disciplines section. Then we can compare both of these vectors to see if they would be either vreal or ireal and add them to the final port type declaration vector.

Listing 11 – logic bus and wreal array declaration

1 // p o r t t y p e s

2 l o g i c [ 7 : 0 ] c l k _ s i g n a l ;

3 w r e a l b i a s _ v a r c a p _ v i 1 [ 1 1 : 0 ] ;

5 // d i s c i p l i n e s

6 l o g i c [ 7 : 0 ] c l k _ s i g n a l ;

7 v r e a l [ 1 1 : 0 ] b i a s _ v a r c a p _ v i 1 ;

(31)

29

Fig. 7 – Main function flowchart

This algorithm works fine for the majority of the models used in the radio system

at stake. There is currently one manual modification that has to be verified each time: the

(32)

30

engineering units format (m, µ, n, p ...). You cannot change this values automatically because these letters are also present in variable names and if changed, the variable names would also change.

Let’s now proceed to the secondary functions used in the script.

2.4.2.1 open_file( ) function

A simple function that opens a dialog box for the user to select a file to migrate. This function is part of the ’os’ package and is associated with the ’Choose File’ button of the user interface. Additionally, it stores the file path in an array called ’files’.

2.4.2.2 get_file_name( file ) function

A function that takes the file path as an input parameter and extracts the file name.

2.4.2.3 make_output_file_path_single( file ) function

A function that sets the output file path. It takes the input file location as an input parameter and truncates it at each ’/’ character, turning it into a vector. Then, it calls the pop(-1) function to erase the last element of the vector (or the input file name) and replaces it with

’verilog.sv’. The vector is then concatenated using the ’/’ as a linker in order to properly create the SystemVerilog output file path.

2.4.2.4 make_design_info_section( output_file ) function

This function creates the comment section in the header which contains information about the design, such as the date of creation, author, schematic version, model version and comments in the format seen from lines 1 to 19 in listing 10. It uses the ’datetime’ package functions to recover automatically the date and time of creation and recovers schematic version from input file.

2.4.2.5 line_num_for_phrase_in_file( text, file_name) function

A function that looks for text argument and returns line number of first located text entry.

2.4.2.6 delete_line( file_name, line_number ) function

A function that deletes a line from a file at the given line number.

2.4.2.7 insert_line(file_name, line_number, string ) function

A function that inserts a specific string in a specific line given by the user.

(33)

31 2.4.2.8 read_line( file_name, line_number) function

A function that reads the line’s content character by character.

2.4.2.9 replace_string( file_name, data_to_find, data_to_replace ) function

A function that searches the file for a specific string and replaces it with a user provided string.

2.4.2.10 log_message( ) function

A function that constructs a log message based on what changes it has done to the wreal file. Each operation has a flag associated to it that defines what messages are displayed.

The intent of this function is to assist in debugging.

2.4.2.11 view_output( file_name ) function

A function that is associated with the ’View Output File’ button from the GUI. Calls the ’os’ package functions to open a file in the Windows version and the ’subprocess’ package on Unix to open the file with nedit.

2.4.3 Other migration scripts

2.4.3.1 textInputs_and_amsbind_migration.py

This script was created in order to automatically adapt simulation configuration files such as the ’textInputs’ files, which contain the models’ file path in the database and the

’.amsbind.scs’ file which contains the configuration of which cellviews are to be used in the simulation and their instantiation. This script is much simpler than the previously described script, because the only modification needed is to switch all model views from wreal to System- Verilog, something as simple as finding all ’wreal’ strings in the text file and replacing it with

’systemVerilog’. A user interface was also setup for ease-of-use purposes (see figure 8).

Fig. 8 – textInputs_and_amsbind_migration.py GUI

2.4.3.2 testbench_and_agent_creation_SV.py

This script is an adaptation of a previously developed Python script created to

automatically create testbenches for wreal simulations. As SystemVerilog and wreal are both

(34)

32

Verilog-based languages, adaptation is quite simple. The modifications are only syntax-related, which have been previously discussed in section 2.3. No user interface is available for this script.

Execution is done via command line through the command:

1 t e s t b e n c h _ a n d _ a g e n t _ c r e a t i o n _ S V . py - i i n p u t f i l e n a m e - m m o d u l e n a m e

2.4.3.3 tb_and_agent_migration_vams2sv.py

This script was created with the intent of automatically migrating existing testbenches and agents written in wreal. As in the testbench creation script, modifications are as simple as replacing a few strings to adapt to the syntax of SystemVerilog. A user interface was also setup (see figure 9).

Fig. 9 – tb_and_agent_migration_vams2sv.py GUI

2.4.3.4 Migration_batch.py

Essentially, the batch-mode migration script is exactly the same as the original migration script, but it takes as input a block directory instead of a single model. It performs the same modifications to the files but it scans a block directory for ’.vams’ files to perform the migration on. A GUI is also available for this script and is shown in Figure 10.

Fig. 10 – Batch-mode migration script GUI

(35)

33 2.5 Migration of Macro-Block : PLL

The next step was to use the Python migration script in order to fully migrate a macro block and check simulation results vs wreal. The first macro block to be migrated in the migration process is the synthesizer, or phase locked loop (PLL). Figure 12 displays the macro block schematic. There are over 60 wreal models inside this macro block and all of them need to be migrated so that an analysis on the comparison of simulation results for this block can be done.

Fig. 11 – PLL Macro block symbol

(36)

34

Fig. 12 – PLL Macro block schematic

The blocks inside this schematic compose a classic analog PLL with some additional functionalities: the signal comes into the phase detector, goes through a loop filter and into the VCO. Then, the signal goes through a frequency divider and back into the phase detector.

With the help of the migration script, all models in the synthesizer were successfully migrated and added in the database. Then, the verification of the simulation results needs to be done. To do so, we create a new simulation using a copy of the old files and applying the necessary changes in them so that they can use the newly written SystemVerilog files. We run the simulation using the same testbench (in wreal) for both cases, which is good for evaluating language compatibility.

2.5.1 Macro block simulation results

Two simulation scenarios were evaluated: a locking scenario and a modulation scenario. Simulation results for both of them are depicted from Figures 13 to 14.

Another analysis that was done is the timing and memory resources comparison.

Table 1 contains information on these parameters for the locking scenario. Table 2 displays information on the modulation scenario.

Item wreal SV Real

- Time Memory Time Memory

Compilation 4.2s 71.9MB 3.7s 71.9MB Elaboration 0.7s 84.9MB 0.7s 84.8MB Simulation 2.2s 148.2MB 2.1s 148.2MB

Table 1 – Timing and memory resources comparison between wreal and SystemVerilog - Locking

Scenario

(37)

35

Item wreal SV Real

- Time Memory Time Memory

Compilation 4.1s 71.9MB 3.9s 71.9MB

Elaboration 0.7s 84.9MB 0.7s 84.8MB

Simulation 102.2s 148.2MB 104.8s 148.2MB

Table 2 – Timing and memory resources comparison between wreal and SystemVerilog - modu- lation Scenario

We can infer from these results that the block migration was successful, as simulation results are coherent, from a functional point of view (see figures 13 and 14) to the timing and memory resources comparison. As only standard nettypes have been used, there should be no significant change from one simulation to the other, and results seem to prove that.

(a) wreal simulation results - locking scenario

(b) SystemVerilog simulation results - locking scenario

Fig. 13 – Locking scenario of synthesizer macro block. Simulation comparison between wreal

and SystemVerilog

(38)

36

(a) wreal simulation results - modulation scenario

(b) SystemVerilog simulation results - modulation scenario

Fig. 14 – Calibration and Modulation scenario of synthesizer macro block. Simulation compari- son between wreal and SystemVerilog

2.6 Complete migration of radio system

After validating the migration of the PLL, it is possible to pass onto the other blocks of the radio system. The next macro block to be migrated was the RFFE (RF Front-End). The RFFE is a complex block that contains over 90 models that compose other complex blocks such as a low noise amplifier (LNA), a sliced cascode power amplifier (PA), a mixer, the DC bus and a Balun interface.

The migration script was used for every model within this macro block and verified individually, as there are some modifications that have to be done by hand (not all wreal models followed the same methodology).

Detailing of simulation scenarios is not the focus of this project, so the main objective

of this section is to put in perspective the effectiveness of the migration script, which was used

(39)

37 for the migration of over 200 models (full radio system).

2.6.1 RFFE simulation scenarios

Three scenarios were simulated for the RFFE block: a transmission scenario, a reception scenario and a baseband reception scenario. The baseband simulations allow complex signals, and are a lot faster than RF simulations, because simulations at higher frequencies take more time. Simulation results are depicted in Figures 15 to 17.

2.6.2 Migration of LDO (Low-dropout) cells

A low dropout regulator or LDO is a DC linear voltage regulator that can regulate the output voltage even when the supply voltage is very close to the output voltage. (P. HOROWITZ, W. HILL , 1989)

There are several LDOs that are used in this radio system. They are present in almost every block, in order to isolate blocks from one another.

Although they are present in almost every block, there are only a few models that compose them, the difference between all of them being the way they are configured and connected to the blocks. All of the models have been migrated through the migration script and migration is supposed successful, given that the macro-blocks in which they are present have the same simulation results in wreal and SystemVerilog.

2.6.3 Migration of remaining blocks

All simulation comparisons between wreal and SystemVerilog are available in the appendices section, and through them it is possible to see that results are coherent for all cases, meaning migration is successful.

(a) RFFE transmission scenario (wreal)

(b) RFFE transmission scenario (SystemVerilog)

Fig. 15 – Comparison between transmission scenario simulation results for wreal and SystemVe-

rilog, respectively

(40)

38

(a) RFFE reception scenario (wreal)

(b) RFFE reception scenario (SystemVerilog)

Fig. 16 – Comparison between reception scenario simulation results for wreal and SystemVerilog, respectively

(a) RFFE baseband reception scenario (wreal)

(b) RFFE baseband reception scenario (SystemVerilog)

Fig. 17 – Comparison between baseband reception scenario simulation results for wreal and

SystemVerilog, respectively

(41)

39

3 REAL-NUMBER MODELING OF PHASE NOISE IN A VCO

3.1 Motivation and Objectives

The aim of this part of the project is to improve the existing VCO model’s coverage (functional and performance verification), and ensure first-time right analog functionality and performance. The objective is to replicate the modeling proposed in (R. B. STASZEWSKI, C.

FERNANDO, P. T. BALSARA, 2005) and adapt it to the needs of an existing VCO used in the radio system.

The modeling presented is well-suited to investigate phase noise in large system- on-chip systems where traditional RF and simulation tools do not work effectively. (R. B.

STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005)

3.2 Bibliographic development

Phase noise is defined as the noise arising from the random phase fluctuations that occur in a signal. These fluctuations are caused by time domain instabilities called as ’phase jitter’. Phase noise is the noise spectrum that is seen spreading out on either side of a signal as a result of the phase jitter. In most radio receiver applications the phase noise is quoted in terms of single sideband phase noise. The phase noise spreads out equally either side of the carrier but only one side is measured - hence the name single sideband phase noise (EVERYTHING RF, 2019). Figure 18a illustrates this explanation.

A voltage-controlled oscillator (VCO) is an electronic oscillator whose oscillation frequency is controlled by a voltage input. The applied input voltage determines the instantaneous oscillation frequency. If we analyse Figure 18b, the voltage-modulated capacitance C creates an output signal whose frequency varies as a function of C.

In oscillators such as a VCO, phase noise is normally characterized in the frequency domain and is a composite of three noise contributors: white noise and coloured noise (1/f

2

, 1/f

3

, etc).

(a) Single sideband phase noise - Taken from: Web - August 2020

(b) Classical VCO topology - Taken from: Web - Au- gust 2020

Fig. 18

(42)

40

The approach depicted in (R. B. STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005) is a time-domain, event-driven model of phase noise. The contributors are: white noise (or non-accumulative jitter), wander noise (or 1/f

2

accumulative jitter) and flicker noise (or integrated 1/f coloured noise). Figure 19 depicts their behaviour.

Fig. 19 – Phase noise spectrum of an oscillator (R. B. STASZEWSKI, C. FERNANDO, P. T.

BALSARA, 2005)

3.2.1 Time-domain modeling of phase noise

The phase noise is modeled through jitter and wander constructs. The white noise or flat electronic noise (1/f

0

) is modeled as non accumulative jitter and the upconverted thermal noise (1/f

2

) is modeled as accumulative wander. The flicker noise is obtained by passing white noise through several low-pass filters with different cut-off frequencies and overlapping their outputs.

3.2.2 Jitter modeling

The way in which white noise is modeled is by calling a random variable that follows a Gaussian distribution, storing its value at each iteration and subtracting the previous value from the current one. This is a variable that has a mean of zero and a determined standard deviation, a parameter that has to be known.

Figure 20 illustrates the modelling principle for the timing jitter. The timestamps are the ideal equidistant rising-edge events of an oscillator operating at frequency f

0

= 1/T

0

. The ideal oscillator output might pass through a physical buffer that adds random fluctuations through its delay. The actual timestamps of the physical buffer output could be described as an additive random error at each occurrence of the ideal timestamp. If the random error is due to the thermal noise, then the edge TDEVs are modeled as additive white Gaussian noise (AWGN).

(R. B. STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005)

(43)

41

Fig. 20 – Development of non-accumulative timing deviations (TDEV) (R. B. STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005)

The timing deviation TDEV

j

for the jitter is the difference between the actual timestamps t

j

[i] and the ideal timestamps at i · T

0

(see equations 1 and 2).

t

j

[i] = i · T

0

+ ∆t[i] (1)

T DEV

j

[i] = ∆t[i] (2)

The period deviation p

1

[i] = t

j

[i] − t

j

[i − 1] is statistically twice the variance of the timestamp deviation. This is due to the fact that an instantaneous period is perturbed from both sides and makes the neighboring errors not entirely independent. The period deviations could be modeled by passing the timestamp deviations through a 2-tap finite-impulse response (FIR) filter with {1,1} coefficients.

The relationship between the time and frequency domains of the jitter could be obtained as follows. The noise floor L is a single-sided spectral density. It needs to be multiplied by two in order to arrive at the S

φ

[rad

2

/Hz] in 3. Since the flat spectrum of the jitter in the discrete-time model extends to the Nyquist frequency, S

φ

is multiplied by f

0

/2 in order to arrive at the total power [rad

2

]. The rms jitter [rad] is its square root value. The radian-unit quantity is converted to the timestamp deviation [sec] by multiplying it by the normalizing factor of T

0

/2π. The above results in 4, where T

0

is the fundamental oscillating period, f

0

is the fundamental oscillating frequency and L is the single-sided phase noise power spectral density.

(R. B. STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005) L{∆ω} = S

φ

(∆ω)

2 (3)

σ

∆t

= T

0

2π ·

q

L · f

0

(4)

For Bluetooth, which is the case of this model, if we consider that the noise floor is at

-150 dBc/Hz and that the oscillating frequency is equal to 2.4 GHz, we can infer that T

0

=417 ps

and L = 10

−150/10

= 10

−15

rad

2

/Hz. Substituting, we have a standard deviation of 103 fs. This

figure corresponds to a 613 kHz frequency deviation. It reveals that one standard deviation of the

jitter is several times higher than the full symbol frequency deviation of 160 kHz.

(44)

42

3.2.3 Wander modeling

Figure 21 represents the modeling principle for the wander contributor, which is also called "accumulative jitter". This could be visualized by a physical oscillator of nominal period T

0

, whose actual period varies slightly from one cycle to another, due to thermal noise effects that are internal to the oscillator. Unlike the jitter case, each transition timestamp depends on all previous period deviations. This acknowledges the fact that the ideal timestamps exist only in theory and the only memory of a given transition is the previous transition timestamp.

Fig. 21 – Development of an accumulative TDEV

The timing deviation TDEV

w

for the wander is the difference between the actual timestamps t

w

[i] and the ideal timestamps at i · T

0

(see equations 5 and 6).

t

w

[i] = i · T

0

+

i

X

l=1

∆T [l] (5)

T DEV

w

=

i

X

l=1

∆T [l] (6)

Equation 7, based on (T. C. WEIGANDT, B. KIM, AND P. R. GRAY, 1994) repre- sents the standard deviation of the wander contributor, where T

0

is the fundamental oscillating period, f

0

is the fundamental oscillating frequency and L(∆ω) is the single-sided phase noise power spectral density in the frequency offset of ∆ω.

σ

∆T

= ∆f

f

0

·

q

T

0

·

q

L(∆ω) (7)

For Bluetooth, for a frequency offset of 500 kHz, f

0

=2.4 GHz, T

0

=417 ps and L = 10

−112/10

= 6.3 · 10

−12

rad

2

/Hz, it results in a standard deviation of 11 fs.

3.2.4 Flicker modeling

Flicker 1/f noise is usually modeled in the time-domain by means of FIR and IIR filters (N. J. KASDIN, 1995). Filter coefficients depend on the type of noise that is modeled.

The main disadvantage is that for high sampling rates, if the 1/f noise has to be described

over multiple decades, the number of filter coefficients becomes very large: a filter operating at

(45)

43 1 GHz would require 100.000 filter coefficients in order to describe the 1/f noise to 1 kHz (R.

B. STASZEWSKI, C. FERNANDO, P. T. BALSARA, 2005). To counter this problem, the 1/f noise is obtained by passing white noise through several first order low-pass IIR filters (Figure 22). This yields an output of slope equal to 10 dB/dec which is upconverted by the oscillator, yielding the final 30 dB/dec slope of the phase noise.

(a) Model for1/f noise generation (b) Composite response of low-pass filters

Fig. 22 – Flicker noise modeling

In order to calculate the standard deviation of the random variable used in the 1/f noise generation, we use equation 8 based on (R. B. STASZEWSKI, C. FERNANDO, P. T.

BALSARA, 2005):

σ

∆T,1/f

= ∆f

c,1

f

0

·

q

T

0

·

q

2L(∆ω

c,1

) (8) Five filters are used in the implementation and they have the respective cut-off frequencies: f

c,1

=100 Hz, f

c,2

=1 kHz, f

c,3

=10 kHz, f

c,4

=100 kHz, f

c,5

=1 MHz

If we substitute f

0

=2.4 Ghz, T

0

=417 ps, ∆f

c,1

=100 Hz and if we consider that for the offset frequency of ∆ω

c,1

=-50 dB, we find that σ

∆T,1/f

=3.8 fs.

3.3 VCO Model Modifications

In order to adapt the current functional VCO model to include this modifications, every half-period of the VCO output signal, the noise variables are updated. In (R. B. STAS- ZEWSKI, C. FERNANDO, P. T. BALSARA, 2005), a VHDL model is presented, in which the random variables are randomized and either updated or accumulated. The IIR filter equations are also updated with newer values of the input white noise and their outputs are summed in order to achieve the flicker noise contribution.

The fist step is the creation of such random variables. As the characteristic of the

variables needed is to follow a Gaussian distribution, it is possible to use the built-in Gaussian

distribution function from SystemVerilog (see listing 13). This function calls a random integer

(46)

44

following a Gaussian distribution of mean equal to the second argument (mean) and standard deviation equal to the third argument (std_dev). The variables created use a standard deviation of 103.000.000, 11.000.000 and 3.800.000 seconds, respectively, which are then multiplied by 1e-21 in order to achieve the desired deviation in the order of femtoseconds (103, 11 and 3.8).

In order to randomize the variables, the seed (first argument in $dist_normal() function) needs to be randomized. To do so, a class was created in which there are 3 constraint-based random properties that generate random integers. Additionally, a task for randomizing and verifying if randomization was successful is put in place. Listing 12 exemplifies this structures.

Listing 12 – randseed class declaration and do_randomize() task

1 c l a s s r a n d s e e d ;

2 r a n d int s e e d _ j ;

3 r a n d int s e e d _ w ;

4 r a n d int s e e d _ f ;

5 c o n s t r a i n t s e e d _ J _ v a l u e { s e e d _ j i n s i d e {[ -2 e32 :2 e32 ] } ; }

6 c o n s t r a i n t s e e d _ W _ v a l u e { s e e d _ w i n s i d e {[ -2 e32 :2 e32 ] } ; }

7 c o n s t r a i n t s e e d _ F _ v a l u e { s e e d _ f i n s i d e {[ -2 e32 :2 e32 ] } ; }

8 e n d c l a s s

9 r a n d s e e d r a n d v a r = new () ;

10 t a s k d o _ r a n d o m i z e () ;

11 ok = r a n d v a r . r a n d o m i z e () ;

12 if(! ok )

13 $ d i s p l a y( " R a n d o m i z a t i o n f a i l u r e .\ n " ) ;

14 e n d t a s k

Listing 13 – $dist_normal() function

1 j i t t e r = 1 e - 2 1 * $ d i s t _ n o r m a l ( r a n d v a r . seed_j , 0 , 1 0 3 0 0 0 0 0 0 ) ;

2 w a n d e r = 1 e - 2 1 * $ d i s t _ n o r m a l ( r a n d v a r . seed_w , 0 , 1 1 0 0 0 0 0 0 ) ;

3 x = 1 e - 2 1 * $ d i s t _ n o r m a l ( r a n d v a r . seed_f , 0 , 3 8 0 0 0 0 0 ) ;

The ’x’ variable is the input white noise for the IIR filters, which follow equation 9:

y

k

[i] = (1 − a

k

)y

k

[i − 1] + a

k

· A

−(k−1)

x[i] (9) where k is the filter index (1,2,3,4,5), A is the linear value of the attenuation factor given by A = 10

AdB20

(where A

dB

= slope · r and r =

fc,k+1f

c,k

= 10) and a

k

is given by equation 10. As the desired slope has an inclination of 10 dB/dec, we have A = 10

5

.

a

k

= 2π · f

c,k

f

s

(10)

where f

s

=2.4 GHz.

(47)

45 The sum of all filter outputs composes the flicker noise contributor. If we add it to the wander contributor and the jitter contributor, at every half-period of the VCO output signal, we have the coding depicted in listing 14:

Listing 14 – All 3 noise contributors modeling

1 a l w a y s #( T h a l f p e r _ v c o *1 s ) b e g i n // P h a s e n o i s e

2 d o _ r a n d o m i z e () ;

3 // p r e v i o u s v a l u e s a v e for non - a c c u m u l a t i v e c o n t r i b u t i o n

4 j i t t e r _ p r e v = j i t t e r ;

5 j i t t e r = 1 e - 2 1 * $ d i s t _ n o r m a l ( r a n d v a r . seed_j , 0 , 1 0 3 0 0 0 0 0 0 ) ;

6 w a n d e r = 1 e - 2 1 * $ d i s t _ n o r m a l ( r a n d v a r . seed_w , 0 , 1 1 0 0 0 0 0 0 ) ;

7 x = 1 e - 2 1 * $ d i s t _ n o r m a l ( r a n d v a r . seed_f , 0 , 3 8 0 0 0 0 0 ) ;

8 // IIR F i l t e r s for 1/ f n o i s e g e n e r a t i o n

9 y _ 1 _ p r e v = y _ 1 _ a c t u a l ;

10 y _ 1 _ a c t u a l = (1 - a_1 ) * y _ 1 _ p r e v + a_1 *( A * * 0 ) * x ;

11 y _ 2 _ p r e v = y _ 2 _ a c t u a l ;

12 y _ 2 _ a c t u a l = (1 - a_2 ) * y _ 2 _ p r e v + a_2 *( A **( -1) ) * x ;

13 y _ 3 _ p r e v = y _ 3 _ a c t u a l ;

14 y _ 3 _ a c t u a l = (1 - a_3 ) * y _ 3 _ p r e v + a_3 *( A **( -2) ) * x ;

15 y _ 4 _ p r e v = y _ 4 _ a c t u a l ;

16 y _ 4 _ a c t u a l = (1 - a_4 ) * y _ 4 _ p r e v + a_4 *( A **( -3) ) * x ;

17 y _ 5 _ p r e v = y _ 5 _ a c t u a l ;

18 y _ 5 _ a c t u a l = (1 - a_5 ) * y _ 5 _ p r e v + a_5 *( A **( -4) ) * x ;

19 // p i n k n o i s e

20 f l i c k e r = y _ 1 _ a c t u a l + y _ 2 _ a c t u a l + y _ 3 _ a c t u a l + y _ 4 _ a c t u a l + y _ 5 _ a c t u a l ;

21 // add all c o n t r i b u t o r s

22 p e r i o d _ v a r i a t i o n = p e r i o d _ v a r i a t i o n + j i t t e r - j i t t e r _ p r e v + w a n d e r + f l i c k e r ;

23 end

3.4 Post processing of simulation data

In this section, the data analysis from simulation is discussed. In order to verify that

the random variables are generated properly, the instantaneous variable value is saved in every

positive edge of the VCO signal. The variables saved are the jitter value, the wander value and the

time variable (’$realtime’). This way, we have the timestamps of each positive edge of the output

signal (which is used for the phase-noise calculation) and it is possible to plot the histograms

of the random variables in order to validate that they are indeed Gaussian distributions. Figure

23 depicts the histograms of simulation values and the theoretical distribution, as well as exact

values for mean and standard deviation from simulated data.

Referências

Documentos relacionados

If a university has connections of very high quality, then it will be more difficult to increase not only q but also h (without decreasing q), because increasing the number

Quanto à escolha do tema da dissertação, “Contribuição para o estudo da imunossupressão associada à quimioterapia, em cães”, foram tidos em conta diversos factores

É, pois, uma família monogâmica, ainda que possam acontecer monogamias sucessivas de casamento/divórcio, sendo a família conjugal também uma família educacional. Na sociedade

O USO INTEGRADO DA TV E VÍDEO NA EDUCAÇÃO INFANTIL DA ESCOLA MUNICIPAL ELSO PAULO SEVERNINI1 THE INTEGRATED USE OF TV AND VIDEO IN CHILDREN'S EDUCATION OF THE MUNICIPAL SCHOOL

No módulo 2, são abordados os intervenientes na atividade económica, ou seja, agentes económicos, de acordo com as funções desempenhadas (Famílias, Estado, Empresas

nally, we acknowledge the enduring support for the construction and operation of the LHC and the CMS detector provided by the following funding agencies: the Austrian Federal Min-

Este instrumento permitiu-nos registar as observações de forma controlada e sistematizada, como tão bem ilustra Sousa (2005) quando se refere à

Ainda relativamente à valorização e concretização da colaboração e reflexão profissional promovidas em estudos de aula, Quaresma e Ponte (2015) acrescentam que a participação