Synthesis, Simulation and Verification of the Reference FPGA Code

Mapping of Port Assignment of MachXO3 in Lattice Diamond, Referenced from MachXO2

The reference design from Lattice is based on MachXO2 2000/4000 cs132bga Package, hence the port assignment must be modified. The actual assignment parameters are located in the .lpf file in the project file list.

Some of the Syntax is shown below:

Pin Planning.png

– Design Planning, Lattice

Additional: Block Keywoard

BLOCK
Blocks timing analysis on nets, paths, buses, or component pins that areirrelevant to the timing of the design. If a net is specified, the net and all pathsthrough the specified net will blocked. If a bus is specified, the bus, all nets inthe bus, and all paths through the nets defined by the bus will be blocked. If acomponent pin is specified, any path going through the specified pin of thenamed component will be blocked.The TRACE report will include all paths that are covered with the BLOCKPATH preference, but it will not include details for a BLOCK NET preference.In TRACE, the signal defined in a BLOCK NET preference is removed fromthe timing-graph analysis completely. Because there is no path or coveragerelated to this signal any longer, all paths through the signal are blocked/removed and considered covered.

 

By default, when you start a new Diamond project and implementation,Diamond will automatically create an LPF file using the implementation’sname. This file can be found in the File List view in the LPF Constraint Filessection, and it is set as the active LPF file, which means that it will be used todrive the MAP and PAR processes. The file includes the following BLOCKpreferences by default:BLOCK RESETPATHS;BLOCK ASYNCPATHS;BLOCK RESETPATHS is a global preference that blocks all asynchronous setand reset paths that are through an asynchronous set and reset pin of yourdesign.BLOCK ASYNCPATHS is a global preference. If this preference is not in theLPF file, TRACE will analyze all input-to-register paths (that are not coveredby an INPUT_SETUP preference) to see if they are longer than the period ofthe associated clock. The clock must have a PERIOD or FREQUENCYpreference defined to get the period value. This is not very useful analysis,because few inputs will have the entire clock period from the device pin. Werecommend that users define INPUT_SETUP preferences for all inputs thataccurately reflect the actual board level timing. (See “Case study 4 -INPUT_SETUP” on page 56). The BLOCK ASYNCHPATHS preference isincluded in the LPF by default so that the less useful analysis is not includedin the TRACE report.

 

BLOCK
Provides a means of blocking timing checks onspecific nets, paths (containing the specified net),or path classes reported in the verbose report.RESETPATHS — specifies all asynchronous set/reset paths, through an asynchronous set/reset pinon a design component.ASYNCPATHS — All paths from pads to FF inputswill be blocked for the frequency and periodpreference.

 

RESETPATHS
Specifies all asynchronous set/reset paths, through anasynchronous set/reset pin on a design component. This is in the "ON"condition by default, so when a new project is created in Diamond, theBLOCK RESETPATHS preference will appear in the project's preference file.

ASYNCPATHS
Blocks all paths from pads to FF inputs for the frequencyand period preferences. This is in the "ON" condition by default, so when anew project is created in Diamond, the BLOCK ASYNCPATHS preference willappear in the project's preference file.

JTAGPATHS
Identifies any output signal from "JTCK" of cellmode "JTAG"and blocks all registers driven by this signal when doing FMAX analysis.

 

Modify Constraints using Spreadsheet View

Fortunately, Lattice Diamond offers a GUI view to change constraint settings. In addition, to deal with differential pair signals, the GUI – Spreadsheet View –  allows you to only map the positive pins; the negative ones are mapped automatically.

Spreadsheet View.png
Spreadsheet View with all the mapping for MachXO3L

The following mapping decision is made upon close examination of multiple documentation, including:

  • MachXO2132-PincsBGAPackageMigrationFile.CSV
  • MachXO3256caBGAPinMigration.csv
  • RD1204sonysublvdstocsi2Documentation.pdf, as well as the physical board doc
  • MachXO3LDSIBreakoutBoardSchematics.PDF

For now, all the differential pairs, differential clock are crossed checked and verified. The only problem is the INCK, and probably rstn.

Description Signal MachXO2, 132-Ball csBGA,

Speed Grade -6

MachXO3 MachXO3 (Jack)
  rstn L3 H2 J47
  INCK K1 ? (T7) ? (J5)
  XVS M2
  XHS M1
  CLK_p N6 T9 J4
  CLK_n P6 P9 J6
  CH[0]_p M11 P10 J8
  CH[0]_n P12 R10 J10
  CH[1]_p P8 R7 J9
  CH[1]_n M8 P7 J11
  CH[2]_p P2 R13 J12
  CH[2]_n N2 T14 J14
  CH[3]_p N3 N6 J13
  CH[3]_n P4 L7 J15
  DCK_p A7 C8 J25
  DCK_n B7 A8 J27
  D0_p B5 F7 J29
  D0_n C6 E8 J31
  D1_p A2 C12 J30
  D1_n B3 B12 J32
  D2_p A10 E6 J33
  D2_n C11 D7 J35
  D3_p C12 B13 J34
  D3_n A12 A14 J36
  LPCLK[1] E12 F4
  LPCLK[0] E14 G6
  LP0[1] E13 E1
  LP0[0] F12 F2
  LP1[1] F13 B1
  LP1[0] F14 C2
  LP2[1] G12 C1
  LP2[0] G14 D2
  LP3[1] G13 G2
  LP3[0] H12 G3
       

Problem of INCK

INCK clock on paper is only used for XVS and XHS with is not applicable in master mode. Theoretically, is should not be needed at all in our design.

INCK / Input / Input clock for XVS and XHS. This clock is shared as the input clock to the Sony image sensor
- RD1204

However, in the implementation code, the INCK signal is used by deser.v to perform a series of flip-flop & memory operations, which may affect the system operation. This is to be verified.

Proposed Solution:

  • Tie INCK to some internal clock, run at 27Mhz
  • Modify the logic in the deser.v, to avoid using INCK at all
  • Tie INCK phycially to the i.MX6 27Mhz clock, soldering required

For now, I will rely on simulation trying to figure out what is going on with the INCK signal.

Successful Systhesis

Upon modification of lane_width, bus_width, port assignemt to our MachXO3 application, the verilog code is generated successfully.

Successful Sythesis.png

Simulation of the Sensor Bridge Design

Simulation set up is presented in the simulation folder, which is not loaded into the project by default. Therefore, to run the simulation, manual loading of the *_tb_*.v is needed in Active-HDL.

Progress:

  • deser.v work as intended: the output “q”/”din” is all correct, with 8bits data of each channel generated each time.
  • It seems that the flip-flop logic involving INCK does nothing but to delay the rxready signal by a few clock cycle. Ironically, rxready signal is not being used at all!
  • If the deduction is correct, INCK signal is not useful at all, hence can be removed from the design.
  • Further simulation is in progress

deser_opensync_simulation.png

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s