1 |
2 |
madscienti |
TABLE OF CONTENTS
|
2 |
|
|
1) Peripheral Summary
|
3 |
|
|
2) Description of Generated Files
|
4 |
|
|
3) Description of Used IPIC Signals
|
5 |
|
|
4) Description of Top Level Generics
|
6 |
|
|
|
7 |
|
|
|
8 |
|
|
================================================================================
|
9 |
|
|
* 1) Peripheral Summary *
|
10 |
|
|
================================================================================
|
11 |
|
|
Peripheral Summary:
|
12 |
|
|
|
13 |
|
|
XPS project / EDK repository : D:\custom_pulse_generator\standalone_pulse_generator
|
14 |
|
|
logical library name : s3e_onewire_master_v1_00_a
|
15 |
|
|
top name : s3e_onewire_master
|
16 |
|
|
version : 1.00.a
|
17 |
|
|
type : OPB slave
|
18 |
|
|
features : slave attachement
|
19 |
|
|
mir/rst register
|
20 |
|
|
user s/w registers
|
21 |
|
|
|
22 |
|
|
Address Block for User Logic and IPIF Predefined Services
|
23 |
|
|
|
24 |
|
|
User logic slave space service : C_BASEADDR + 0x00000000
|
25 |
|
|
: C_BASEADDR + 0x000000FF
|
26 |
|
|
IPIF Reset/MIR service : C_BASEADDR + 0x00000100
|
27 |
|
|
: C_BASEADDR + 0x000001FF
|
28 |
|
|
|
29 |
|
|
|
30 |
|
|
================================================================================
|
31 |
|
|
* 2) Description of Generated Files *
|
32 |
|
|
================================================================================
|
33 |
|
|
- HDL source file(s)
|
34 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/pcores/s3e_onewire_master_v1_00_a/hdl
|
35 |
|
|
|
36 |
|
|
vhdl/s3e_onewire_master.vhd
|
37 |
|
|
|
38 |
|
|
This is the template file for your peripheral's top design entity. It
|
39 |
|
|
configures and instantiates the corresponding IPIF unit in the way you
|
40 |
|
|
indicated in the wizard GUI and hooks it up to the stub user logic where
|
41 |
|
|
the actual functionalites should get implemented. You are not expected to
|
42 |
|
|
modify this template file except certain marked places for adding user
|
43 |
|
|
specific generics and ports.
|
44 |
|
|
|
45 |
|
|
verilog/user_logic.v
|
46 |
|
|
|
47 |
|
|
This is the template file for the stub user logic design entity, either in
|
48 |
|
|
VHDL or Verilog, where the actual functionalities should get implemented.
|
49 |
|
|
Some sample code snippet may be provided for demonstration purpose.
|
50 |
|
|
|
51 |
|
|
|
52 |
|
|
- XPS interface file(s)
|
53 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/pcores/s3e_onewire_master_v1_00_a/data
|
54 |
|
|
|
55 |
|
|
s3e_onewire_master_v2_1_0.mpd
|
56 |
|
|
|
57 |
|
|
This Microprocessor Peripheral Description file contains information of the
|
58 |
|
|
interface of your peripheral, so that other EDK tools can recognize your
|
59 |
|
|
peripheral.
|
60 |
|
|
|
61 |
|
|
s3e_onewire_master_v2_1_0.pao
|
62 |
|
|
|
63 |
|
|
This Peripheral Analysis Order file defines the analysis order of all the HDL
|
64 |
|
|
source files that are used to compile your peripheral.
|
65 |
|
|
|
66 |
|
|
|
67 |
|
|
- ISE project file(s)
|
68 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/pcores/s3e_onewire_master_v1_00_a/devl/projnav
|
69 |
|
|
|
70 |
|
|
s3e_onewire_master.npl
|
71 |
|
|
|
72 |
|
|
This is the ProjNavigator project file. It sets up the needed logical
|
73 |
|
|
libraries and dependent library files for you to help you develop your
|
74 |
|
|
peripheral using ProjNavigator.
|
75 |
|
|
|
76 |
|
|
s3e_onewire_master.cli
|
77 |
|
|
|
78 |
|
|
This is the TCL command line file used to generate the .npl file.
|
79 |
|
|
|
80 |
|
|
|
81 |
|
|
- XST synthesis file(s)
|
82 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/pcores/s3e_onewire_master_v1_00_a/devl/synthesis
|
83 |
|
|
|
84 |
|
|
s3e_onewire_master_xst.scr
|
85 |
|
|
|
86 |
|
|
This is the XST synthesis script file to compile your peripheral.
|
87 |
|
|
Note: you may want to modify the device part option for your target.
|
88 |
|
|
|
89 |
|
|
s3e_onewire_master_xst.prj
|
90 |
|
|
|
91 |
|
|
This is the XST synthesis project file used by the above script file to
|
92 |
|
|
compile your peripheral.
|
93 |
|
|
|
94 |
|
|
|
95 |
|
|
- Driver source file(s)
|
96 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/drivers/s3e_onewire_master_v1_00_a/src
|
97 |
|
|
|
98 |
|
|
s3e_onewire_master.h
|
99 |
|
|
|
100 |
|
|
This is the software driver header template file, which contains address offset of
|
101 |
|
|
software addressable registers in your peripheral, as well as some common masks and
|
102 |
|
|
simple register access macros or function declaration.
|
103 |
|
|
|
104 |
|
|
s3e_onewire_master.c
|
105 |
|
|
|
106 |
|
|
This is the software driver source template file, to define all applicable driver
|
107 |
|
|
functions.
|
108 |
|
|
|
109 |
|
|
s3e_onewire_master_selftest.c
|
110 |
|
|
|
111 |
|
|
This is the software driver self test example file, which contain self test example
|
112 |
|
|
code to test various hardware features of your peripheral.
|
113 |
|
|
|
114 |
|
|
Makefile
|
115 |
|
|
|
116 |
|
|
This is the software driver makefile to compile drivers.
|
117 |
|
|
|
118 |
|
|
|
119 |
|
|
- Driver interface file(s)
|
120 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/drivers/s3e_onewire_master_v1_00_a/data
|
121 |
|
|
|
122 |
|
|
s3e_onewire_master_v2_1_0.mdd
|
123 |
|
|
|
124 |
|
|
This is the Microprocessor Driver Definition file.
|
125 |
|
|
|
126 |
|
|
s3e_onewire_master_v2_1_0.tcl
|
127 |
|
|
|
128 |
|
|
This is the Microprocessor Driver Command file.
|
129 |
|
|
|
130 |
|
|
|
131 |
|
|
- Other misc file(s)
|
132 |
|
|
D:\custom_pulse_generator\standalone_pulse_generator/pcores/s3e_onewire_master_v1_00_a/devl
|
133 |
|
|
|
134 |
|
|
ipwiz.opt
|
135 |
|
|
|
136 |
|
|
This is the option setting file for the wizard batch mode, which should
|
137 |
|
|
generate the same result as the wizard GUI mode.
|
138 |
|
|
|
139 |
|
|
README.txt
|
140 |
|
|
|
141 |
|
|
This README file for your peripheral.
|
142 |
|
|
|
143 |
|
|
ipwiz.log
|
144 |
|
|
|
145 |
|
|
This is the log file by operating on this wizard.
|
146 |
|
|
|
147 |
|
|
|
148 |
|
|
================================================================================
|
149 |
|
|
* 3) Description of Used IPIC Signals *
|
150 |
|
|
================================================================================
|
151 |
|
|
For more information (usage, timing diagrams, etc.) regarding the IPIC signals
|
152 |
|
|
used in the templates, please refer to the following specifications (under
|
153 |
|
|
%XILINX_EDK%\doc for windows or $XILINX_EDK/doc for solaris and linux):
|
154 |
|
|
proc_ip_ref_guide.pdf - Processor IP Reference Guide (chapter 4 IPIF)
|
155 |
|
|
user_core_templates_ref_guide.pdf - User Core Templates Reference Guide
|
156 |
|
|
|
157 |
|
|
Bus2IP_Clk
|
158 |
|
|
This is the clock input to the user logic. All IPIC signals are synchronous
|
159 |
|
|
to this clock. It is identical to the _Clk signal that is an input to
|
160 |
|
|
the user core. In an OPB core, Bus2IP_Clk is the same as OPB_Clk, and in a
|
161 |
|
|
PLB core, it is the same as PLB_Clk. No additional buffering is provided on
|
162 |
|
|
the clock; it is passed through as is.
|
163 |
|
|
|
164 |
|
|
Bus2IP_Reset
|
165 |
|
|
Signal to reset the User Logic; asserts whenever the _Rst signal does
|
166 |
|
|
and, if the Reset block is included, whenever there is a software-programmed
|
167 |
|
|
reset.
|
168 |
|
|
|
169 |
|
|
Bus2IP_Data
|
170 |
|
|
This is the data bus from the IPIF to the user logic; it is used for both
|
171 |
|
|
master and slave transactions. It is used to access user logic registers.
|
172 |
|
|
|
173 |
|
|
Bus2IP_BE
|
174 |
|
|
The Bus2IP_BE is a bus of Byte Enable qualifiers from the IPIF to the user
|
175 |
|
|
logic. A bit in the Bus2IP_BE set to '1' indicates that the associated byte
|
176 |
|
|
lane contains valid data. For example, if Bus2IP_BE = 0011, this indicates
|
177 |
|
|
that byte lanes 2 and 3 contains valid data.
|
178 |
|
|
|
179 |
|
|
Bus2IP_RdCE
|
180 |
|
|
The Bus2IP_RdCE bus is an input to the user logic. It is Bus2IP_CE qualified
|
181 |
|
|
by a read transaction.
|
182 |
|
|
|
183 |
|
|
Bus2IP_WrCE
|
184 |
|
|
The Bus2IP_WrCE bus is an input to the user logic. It is Bus2IP_CE qualified
|
185 |
|
|
by a write transaction.
|
186 |
|
|
|
187 |
|
|
IP2Bus_Data
|
188 |
|
|
This is the data bus from the user logic to the IPIF; it is used for both
|
189 |
|
|
master and slave transactions. It is used to access user logic registers.
|
190 |
|
|
|
191 |
|
|
IP2Bus_Ack
|
192 |
|
|
The IP2Bus_Ack signal provide the read/write acknowledgement from the user
|
193 |
|
|
logic to the IPIF. For writes, it indicates the data has been taken by the
|
194 |
|
|
user logic. For reads, it indicates that valid data is available. For
|
195 |
|
|
immediate acknowledgement (such as for a register read/write), this signal
|
196 |
|
|
can be tied to '1'. Wait states can be inserted in the transaction by
|
197 |
|
|
delaying the assertion of the acknowledgement. If the IP2Bus_Ack for OPB
|
198 |
|
|
cores will be delayed more than 8 clocks, then the IP2Bus_ToutSup (timeout
|
199 |
|
|
suppress) signal must also be asserted to prevent a timeout on the host bus.
|
200 |
|
|
|
201 |
|
|
IP2Bus_Retry
|
202 |
|
|
IP2Bus_Retry is a response from the user logic to the IPIF that indicates
|
203 |
|
|
the currently requested transaction cannot be completed at this time and
|
204 |
|
|
that the requesting master should retry the operation. If the IP2Bus_Retry
|
205 |
|
|
signal will be delayed more than 8 clocks, then the IP2Bus_ToutSup (timeout
|
206 |
|
|
suppress) signal must also be asserted to prevent a timeout on the host bus.
|
207 |
|
|
Note: this signal is unused by PLB IPIF.
|
208 |
|
|
|
209 |
|
|
IP2Bus_Error
|
210 |
|
|
This signal from the user logic to the IPIF indicates an error has occurred
|
211 |
|
|
during the current transaction. It is valid when IP2Bus_Ack is asserted.
|
212 |
|
|
|
213 |
|
|
IP2Bus_ToutSup
|
214 |
|
|
The IP2Bus_ToutSup must be asserted by the user logic whenever its
|
215 |
|
|
acknowledgement or retry response will take longer than 8 clock cycles.
|
216 |
|
|
|
217 |
|
|
================================================================================
|
218 |
|
|
* 4) Description of Top Level Generics *
|
219 |
|
|
================================================================================
|
220 |
|
|
C_BASEADDR/C_HIGHADDR
|
221 |
|
|
These two generics are used to define the memory mapped address space for
|
222 |
|
|
the peripheral registers, including Reset/MIR register, Interrupt Source
|
223 |
|
|
Controller registers, Read/Write FIFO control/data registers, user logic
|
224 |
|
|
software accessible registers and etc., but excluding those user logic
|
225 |
|
|
address ranges if ever used. When instantiation, the address space size
|
226 |
|
|
determined by these two generics must be a power of 2 (e.g. 2^k =
|
227 |
|
|
C_HIGHADDR - C_BASEADDR + 1), a factor of C_BASEADDR and larger than the
|
228 |
|
|
minimum size as indicated in the template.
|
229 |
|
|
|
230 |
|
|
C_OPB_DWIDTH
|
231 |
|
|
This is the data bus width for On-chip Peripheral Bus (OPB). It should
|
232 |
|
|
always be set to 32 as of today.
|
233 |
|
|
|
234 |
|
|
C_OPB_AWIDTH
|
235 |
|
|
This is the address bus width for On-chip Peripheral Bus (OPB). It should
|
236 |
|
|
always be set to 32 as of today.
|
237 |
|
|
|
238 |
|
|
C_USER_ID_CODE
|
239 |
|
|
This is the ID that will be put into the MIR register, it's mainly used
|
240 |
|
|
for debug purpose to identify the peripheral under test if multiple
|
241 |
|
|
instances exist in the system.
|
242 |
|
|
|
243 |
|
|
C_FAMILY
|
244 |
|
|
This is to set the target FPGA architecture, s.t. virtex2, virtex2p, etc.
|
245 |
|
|
|