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:
– 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.
The following mapping decision is made upon close examination of multiple documentation, including:
- RD1204sonysublvdstocsi2Documentation.pdf, as well as the physical board doc
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
|INCK||K1||? (T7)||? (J5)|
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.
- 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.
Upon modification of lane_width, bus_width, port assignemt to our MachXO3 application, the verilog code is generated successfully.
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.
- 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