參考http://sp1.wikidot.com/linuxia32mmu
Linux 作業系統原本是在 IA32 (x86) 處理器上設計的，由於 IA32 具有 MMU 單元，因此大部分的 Linux 都預設支援虛擬記憶體機制。然而，在許多的嵌入式處理器中，並沒有 MMU 單元，於是有 Jeff Dionne 等人於 1998 年開始將 Linux 中的 MMU 機制去除並改寫，後來釋出了不具有 MMU 的 µClinux 版本。
曾經有一段時間，嵌入式的系統開發者必須決定應使用具有 MMU 的 Linux 或不具 MMU 的 µClinux，但是後來在2.5.46版的 Linux 中，決定將 µClinux 納入核心中，所以後來的 Linux 核心已經包含了 µClinux 的功能，可以選擇是否要支援 MMU 單元。
由於 Tovarlds 最早是在 IA32 (x86) 中發展出 Linux 作業系統的，因此 Linux 的記憶體管理機制深受 x86 處理器的影響。要瞭解 Linux 的記憶體管理機制，首先必須先理解 x86 的MMU 記憶體管理單元。
wiki可參考
http://zh.wikipedia.org/wiki/%E5%86%85%E5%AD%98%E7%AE%A1%E7%90%86%E5%8D%95%E5%85%83
2011年9月10日 星期六
PrimeTime再了解(十)
Timing Exception
Max / Min Delay
Max / Min delay
set_max_delay 8.5 -from [get_ports {A}] -to [get_ports {Z}]
set_min_delay 0.0 -from [get_ports {A}] -to [get_ports {Z}]
一般沒有timing model的instance
DC/PT會視為沒有 delay
set_max_delay 6.5 -from [get_pins {RAM/CLK}] –to [get_pins {FF2/D}]
set_min_delay 0.0 -from [get_pins {RAM/CLK}] –to [get_pins {FF2/D}]
Max / Min Delay
Max / Min delay
set_max_delay 8.5 -from [get_ports {A}] -to [get_ports {Z}]
set_min_delay 0.0 -from [get_ports {A}] -to [get_ports {Z}]
一般沒有timing model的instance
DC/PT會視為沒有 delay
set_min_delay 0.0 -from [get_pins {RAM/CLK}] –to [get_pins {FF2/D}]
2011年9月9日 星期五
Zet processor
http://zet.aluzina.org/index.
Zet processor is an open implementation of the so widely used IA-32 architecture (generally called x86). This project is very new but it can be synthesized in a configurable device such an FPGA or CPLD, or made as a custom ASIC. Five different FPGA boards are currently supported.
This project is quite complex and is in a very early stage of development. Only the 16-bit part (ie. the 8086/80186) is supported, see Zet status for more information. It can boot successfully MS-DOS 6.22, FreeDOS 1.1 and run Microsoft Windows 3.0 and other MS-DOS games.
Zet processor is an open implementation of the so widely used IA-32 architecture (generally called x86). This project is very new but it can be synthesized in a configurable device such an FPGA or CPLD, or made as a custom ASIC. Five different FPGA boards are currently supported.
This project is quite complex and is in a very early stage of development. Only the 16-bit part (ie. the 8086/80186) is supported, see Zet status for more information. It can boot successfully MS-DOS 6.22, FreeDOS 1.1 and run Microsoft Windows 3.0 and other MS-DOS games.
PrimeTime再了解(九)
PrimeTime graphical user interface (GUI)
有兩個方法
1. Unix shell下直接使用
2. 在pt shell下使用
pt_shell> gui_start
有兩個方法
1. Unix shell下直接使用
pt_shell -gui
2. 在pt shell下使用
pt_shell> gui_start
2011年9月8日 星期四
PrimeTime再了解(八)
PrimeTime Add-On Features
PrimeTime PX accurately analyzes full-chip power
dissipation of cell-based designs. It provides vector-free and vector-based peak power
and average power analysis. The vectors to PrimeTime PX are either RTL or gate-level
simulation results in Value Change Dump (VCD) format or Switching Activity Interchange
Format (SAIF). PrimeTime PX provides multi-VDD and power domain analysis. It also
has an integrated graphical user interface (GUI) for visual power debugging. For more
information, see the PrimeTime PX User Guide.
PrimeTime SI (signal integrity) adds crosstalk
analysis capabilities to PrimeTime static timing analyzer. PrimeTime SI calculates the
timing effects of cross-coupled capacitors between nets and includes the resulting delay
changes in the PrimeTime analysis reports. It also calculates the logic effects of crosstalk
noise and reports conditions that could lead to functional failure. For more information,
see the PrimeTime SI User Guide.
PrimeTime VX increases the accuracy of timing
analysis by considering the statistical variation and distribution of process parameters.
PrimeTime VX accurately determines the timing behavior of a circuit under varying
parameters such as channel length, threshold voltage, and interconnect wire thickness.
Given a set of variation-aware cell libraries and interconnect data, PrimeTime VX
analyzes path timing behavior under all combinations of parameter variations. For more
information, see the PrimeTime VX User Guide.
PrimeTime PX accurately analyzes full-chip power
dissipation of cell-based designs. It provides vector-free and vector-based peak power
and average power analysis. The vectors to PrimeTime PX are either RTL or gate-level
simulation results in Value Change Dump (VCD) format or Switching Activity Interchange
Format (SAIF). PrimeTime PX provides multi-VDD and power domain analysis. It also
has an integrated graphical user interface (GUI) for visual power debugging. For more
information, see the PrimeTime PX User Guide.
PrimeTime SI (signal integrity) adds crosstalk
analysis capabilities to PrimeTime static timing analyzer. PrimeTime SI calculates the
timing effects of cross-coupled capacitors between nets and includes the resulting delay
changes in the PrimeTime analysis reports. It also calculates the logic effects of crosstalk
noise and reports conditions that could lead to functional failure. For more information,
see the PrimeTime SI User Guide.
PrimeTime VX increases the accuracy of timing
analysis by considering the statistical variation and distribution of process parameters.
PrimeTime VX accurately determines the timing behavior of a circuit under varying
parameters such as channel length, threshold voltage, and interconnect wire thickness.
Given a set of variation-aware cell libraries and interconnect data, PrimeTime VX
analyzes path timing behavior under all combinations of parameter variations. For more
information, see the PrimeTime VX User Guide.
2011年9月7日 星期三
PrimeTime再了解(七)
Timing Models
PrimeTime supports the use of timing models to represent chip submodules. A timing model
contains information about the timing characteristics, but not the logical functionality, of a
submodule.
PrimeTime can generate a timing model from a submodule netlist, and then use that model
in place of the original netlist for timing analysis at higher levels of hierarchy. This technique
makes whole-chip analysis run much faster.
Another use of timing models is to protect intellectual property, you can provide the
timing model without the original netlist.
1. Quick timing model. This is an approximate timing model created in PrimeTime using a
sequence of PrimeTime commands. This type of model is useful early in the design
cycle, when a netlist is not yet available for a submodule.
2. Extracted model. This is a timing-only model extracted by PrimeTime from a gate-level
netlist. This type of model discards all of the logic of the original netlist and replaces it
with a set of timing arcs between clocks, inputs, and outputs.
3. Interface logic model. This is a structural timing model extracted by PrimeTime from a
gate-level netlist. This type of model preserves the interface logic of the original netlist
and discards the internal register-to-register logic that has already been verified at the
module level.
4. Liberty model. This is a timing model defined in a descriptive language, either written
manually or translated from a timing description in another form.
PrimeTime supports the use of timing models to represent chip submodules. A timing model
contains information about the timing characteristics, but not the logical functionality, of a
submodule.
PrimeTime can generate a timing model from a submodule netlist, and then use that model
in place of the original netlist for timing analysis at higher levels of hierarchy. This technique
makes whole-chip analysis run much faster.
Another use of timing models is to protect intellectual property, you can provide the
timing model without the original netlist.
1. Quick timing model. This is an approximate timing model created in PrimeTime using a
sequence of PrimeTime commands. This type of model is useful early in the design
cycle, when a netlist is not yet available for a submodule.
2. Extracted model. This is a timing-only model extracted by PrimeTime from a gate-level
netlist. This type of model discards all of the logic of the original netlist and replaces it
with a set of timing arcs between clocks, inputs, and outputs.
3. Interface logic model. This is a structural timing model extracted by PrimeTime from a
gate-level netlist. This type of model preserves the interface logic of the original netlist
and discards the internal register-to-register logic that has already been verified at the
module level.
4. Liberty model. This is a timing model defined in a descriptive language, either written
manually or translated from a timing description in another form.
2011年9月6日 星期二
ATPG再了解(十六)
TetraMAX Pattern Formats
Write Verilog
TetraMAX supports two forms of Verilog:
• A multifile data table format
• Single file all-in-one format
Both forms of Verilog enable you to select either serial or parallel application of scan shift as
specified by the -serial or the -parallel option. The default selection is the parallel application
of scan shift.
Verilog single-file format contains Verilog test bench and all patterns for input and expected
data output.
Verilog multifile table format uses a testbench with an instantiated design and a small
sequencer state machine along with files containing primary input forces, primary output
measures, scan load/unload data, and state machine sequencer codes to provide process
control.
The -format Verilog option writes patterns in the Verilog format. See the
write_patterns command in the TetraMAX online help for details.
Write STIL
The Verilog testbench is written either with a serial or a parallel application of scan shift as
specified by the -serial or the -parallel option. By default, no selection of the option writes
as serial form of the testbench with a STIL pattern file.
The -format stil option writes patterns in the proposed IEEE-1450.1 Standard Test
Interface Language (STIL) for Digital Test Vectors format. For more information on the
proposed IEEE-1450.1 STIL for Digital Test Vectors format (extension to the 1450.0-1999
standard), see Appendix E STIL Language Format in the TetraMAX ATPG User Guide. This
format can be both written and read; however, only a subset of the language written by
TetraMAX is supported for reading back in.
The -format stil99 option writes patterns in the official IEEE-1450.0 Standard Test
Interface Language (STIL) for Digital Test Vectors format. This format may be both written
and read, but only the subset of the language written by TetraMAX is supported for reading
back in.
Note:
You must use a 1450.0-compliant DRC procedure as input when to write output in stil99
format.
If your design contains PI pin equivalency, use the -stil99 option when writing patterns for
Verilog DPV. The syntax generated when using the -stil option is part of the proposed IEEE
1450.1 extensions to STIL 1450-1999; it is not yet supported with the external applications
such as Verilog DPV.
If you select -format stil or stil99, TetraMAX generates a STIL file with a name in the
filename <pfile>.<ext> in which you specified write_patterns <pfile>.<ext>.
Write Verilog
TetraMAX supports two forms of Verilog:
• A multifile data table format
• Single file all-in-one format
Both forms of Verilog enable you to select either serial or parallel application of scan shift as
specified by the -serial or the -parallel option. The default selection is the parallel application
of scan shift.
Verilog single-file format contains Verilog test bench and all patterns for input and expected
data output.
Verilog multifile table format uses a testbench with an instantiated design and a small
sequencer state machine along with files containing primary input forces, primary output
measures, scan load/unload data, and state machine sequencer codes to provide process
control.
The -format Verilog option writes patterns in the Verilog format. See the
write_patterns command in the TetraMAX online help for details.
Write STIL
The Verilog testbench is written either with a serial or a parallel application of scan shift as
specified by the -serial or the -parallel option. By default, no selection of the option writes
as serial form of the testbench with a STIL pattern file.
The -format stil option writes patterns in the proposed IEEE-1450.1 Standard Test
Interface Language (STIL) for Digital Test Vectors format. For more information on the
proposed IEEE-1450.1 STIL for Digital Test Vectors format (extension to the 1450.0-1999
standard), see Appendix E STIL Language Format in the TetraMAX ATPG User Guide. This
format can be both written and read; however, only a subset of the language written by
TetraMAX is supported for reading back in.
The -format stil99 option writes patterns in the official IEEE-1450.0 Standard Test
Interface Language (STIL) for Digital Test Vectors format. This format may be both written
and read, but only the subset of the language written by TetraMAX is supported for reading
back in.
Note:
You must use a 1450.0-compliant DRC procedure as input when to write output in stil99
format.
If your design contains PI pin equivalency, use the -stil99 option when writing patterns for
Verilog DPV. The syntax generated when using the -stil option is part of the proposed IEEE
1450.1 extensions to STIL 1450-1999; it is not yet supported with the external applications
such as Verilog DPV.
If you select -format stil or stil99, TetraMAX generates a STIL file with a name in the
filename <pfile>.<ext> in which you specified write_patterns <pfile>.<ext>.
2011年9月5日 星期一
ATPG再了解(十五)
Verilog DPV Testbench Overview
The Verilog direct pattern validation (Verilog DPV) testbench is a tool that lets you directly
simulate and validate STIL test patterns generated by TetraMAX and Boundary-scan test
vectors generated by BSD Compiler.
The tool eliminates the need to generate intermediate formats or additional simulator
constructs.
Verilog DPV testbench consists of a set of PLI tasks that function with the Verilog simulator.
In TetraMAX, issue a write_patterns <pfile.ext> -format [stil | stil99]
command to generate the Verilog testbench. For example:
test> write_patterns pfile.stil -format stil99
The name of the generated testbench file, in this case, would be pfile_stildpv.v, where
TetraMAX replaces the file extension (here, “.stil”), with “_stildpv.v”. Verilog DPV.
TetraMAX generates a Verilog-formatted testbench that contains an instance of the device
to be tested and includes appropriate connections to the Verilog DPV testbench interface.
The testbench contains the necessary calls to the Verilog DPV testbench PLI tasks.
When you run the Verilog simulation, Verilog DPV testbench applies STIL-formatted test
data as stimulus to the design and validates the design’s response against the
STIL-specified expected data. The simulation results ensure both the logical operation and
timing sensitivity of the final STIL test patterns generated by TetraMAX.
Verilog DPV testbench validates the simulated device response against the timed output
response defined by STIL. For windowed data, it confirms that the output response is stable
within the windowed time region.
Note:
1. To use Verilog DPV, you must have access to GCC (GNU Compiler Collection) 3.2.2 and
ld: Software Generation Utilities - 5.9-1.388.
2. Verilog DPV might not work on unsupported operating platforms or simulators. See the
release notes for a list of supported platforms and simulators.
The Verilog direct pattern validation (Verilog DPV) testbench is a tool that lets you directly
simulate and validate STIL test patterns generated by TetraMAX and Boundary-scan test
vectors generated by BSD Compiler.
The tool eliminates the need to generate intermediate formats or additional simulator
constructs.
Verilog DPV testbench consists of a set of PLI tasks that function with the Verilog simulator.
In TetraMAX, issue a write_patterns <pfile.ext> -format [stil | stil99]
command to generate the Verilog testbench. For example:
test> write_patterns pfile.stil -format stil99
The name of the generated testbench file, in this case, would be pfile_stildpv.v, where
TetraMAX replaces the file extension (here, “.stil”), with “_stildpv.v”. Verilog DPV.
TetraMAX generates a Verilog-formatted testbench that contains an instance of the device
to be tested and includes appropriate connections to the Verilog DPV testbench interface.
The testbench contains the necessary calls to the Verilog DPV testbench PLI tasks.
When you run the Verilog simulation, Verilog DPV testbench applies STIL-formatted test
data as stimulus to the design and validates the design’s response against the
STIL-specified expected data. The simulation results ensure both the logical operation and
timing sensitivity of the final STIL test patterns generated by TetraMAX.
Verilog DPV testbench validates the simulated device response against the timed output
response defined by STIL. For windowed data, it confirms that the output response is stable
within the windowed time region.
Note:
1. To use Verilog DPV, you must have access to GCC (GNU Compiler Collection) 3.2.2 and
ld: Software Generation Utilities - 5.9-1.388.
2. Verilog DPV might not work on unsupported operating platforms or simulators. See the
release notes for a list of supported platforms and simulators.
3. The validation of DPV testbench for IDDQ STIL patterns is not supported.
Then, to simplify the procedures, point the environment variable STILDPV_HOME to the
stildpv directory where you installed Verilog DPV testbench. For example, in a typical
Synopsys installation using csh, the command is:
setenv STILDPV_HOME $SYNOPSYS/<platform>/stildpv
where $SYNOPSYS is the Synopsys software installation directory.
The operations in the following sections use the STILDPV_HOME environment variable to
designate the location of Verilog DPV testbench code.
請參考網址 http://www.blogger.com/post-edit.g?blogID=3719279094522729974&postID=4888427122763162222
Then, to simplify the procedures, point the environment variable STILDPV_HOME to the
stildpv directory where you installed Verilog DPV testbench. For example, in a typical
Synopsys installation using csh, the command is:
setenv STILDPV_HOME $SYNOPSYS/<platform>/stildpv
where $SYNOPSYS is the Synopsys software installation directory.
The operations in the following sections use the STILDPV_HOME environment variable to
designate the location of Verilog DPV testbench code.
請參考網址 http://www.blogger.com/post-edit.g?blogID=3719279094522729974&postID=4888427122763162222
PrimeTime再了解(五)
Major Type of Timing Constraints
Clock Constraints
Create Clock
Create generated Clock
Clock Frequency, Waveform , Latency, Uncertainty
Boundary Timing Constraints
Input Delay, Input Transition , Driving Cell
Output Delay, Output Loading
Timing Exception Constraints
False path
Multi-cycle Path
Min/Max Delay
Case Analysis
Design Rules Constraints
Max_fanout, Max_transition, Max_capacitance
Pre vs Post-Layout Clock Constraints
Clock Constraints
Create Clock
Create generated Clock
Clock Frequency, Waveform , Latency, Uncertainty
Boundary Timing Constraints
Input Delay, Input Transition , Driving Cell
Output Delay, Output Loading
Timing Exception Constraints
False path
Multi-cycle Path
Min/Max Delay
Case Analysis
Design Rules Constraints
Max_fanout, Max_transition, Max_capacitance
Clock Gating Check Constraint
Pre vs Post-Layout Clock Constraints
2011年9月4日 星期日
PrimeTime再了解(四)
Clock Gating Check
What happens If the C gate net has a longer than expected delay?
PT automatically performs gating checks if clock gating logic exists
Setup and hold constraints are set to zero
Apply specific setup and hold constraints using “set_clock_gating_check”
請參考下面的constraint
create_clock -period 10 [get_ports CLK]
set_clock_gating_check -setup 0.5 -hold 0.4 [get_clocks CLK]
What happens If the C gate net has a longer than expected delay?
PT automatically performs gating checks if clock gating logic exists
Setup and hold constraints are set to zero
Apply specific setup and hold constraints using “set_clock_gating_check”
請參考下面的constraint
create_clock -period 10 [get_ports CLK]
set_clock_gating_check -setup 0.5 -hold 0.4 [get_clocks CLK]
訂閱：
文章 (Atom)