1 /* This file is part of the program psim.
3 Copyright (C) 1994-1996, Andrew Cagney <cagney@highland.com.au>
5 This program is free software; you can redistribute it and/or modify
6 it under the terms of the GNU General Public License as published by
7 the Free Software Foundation; either version 2 of the License, or
8 (at your option) any later version.
10 This program is distributed in the hope that it will be useful,
11 but WITHOUT ANY WARRANTY; without even the implied warranty of
12 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
13 GNU General Public License for more details.
15 You should have received a copy of the GNU General Public License
16 along with this program; if not, write to the Free Software
17 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
27 The core device, positioned at the top of the device tree that
28 models the architecure being simulated, acts as an interface
29 between the processor engines and the modeled devices.
31 On the one side the processor engines issue read and write requests
32 to the core (each request further catagorised as being for an
33 instruction or data subunit) while on the other side, the core is
34 receiving address configuration and DMA requests from child
37 In the below a synopsis of the core object and device in PSIM is
38 given, details of the object can be found in the files
39 <<corefile.h>> and <<corefile.c>>.
45 At the heart of the interface between devices and processor engines
46 is a single core object. This object, in turn, has two children:
48 o a core device which exists in the device tree and provides
49 an interface to the core object to child devices.
51 o a set of access maps which provide an efficient
52 interface to the core object for the processor engines.
58 typedef struct _core core
;
59 typedef struct _core_map core_map
;
68 (core
*) core_from_device
75 /* Core map management:::
77 The core ojbect manages two different types of address maps:
79 o raw-memory - the address range can be implemented using
80 a simple byte array. No device needs to be notifed of
81 any accesses to the specified memory range.
83 o callback - Any access to the specified address range
84 should be passed on to the associated device. That device
85 can in turn resolve the access - handling or aborting or
88 For callback maps it is possible to further order them by
89 specifiying specifying a callback level (eg callback + 1).
91 When the core is resolving an access it searches each of the maps
92 in order. First raw-memory and then callback maps (in assending
93 order of level). This search order makes it possible for latter
94 maps to overlap earlier ones. For instance, a device that wants to
95 be notified of all accesses that are not covered by raw-memory maps
96 could attach its self with an address range of the entire address
99 In addition, each attached address map as an associated set of
100 access attributes (readable, writeable, executable) which are
101 verified as part of resolving each access.
112 unsigned nr_bytes
, /* host limited */
113 device
*device
); /*callback/default*/
117 At present there is no method for removing address maps. That will
118 be implemented in a future release.
120 The operation of mapping between an address and its destination
121 device or memory array is currently implemented using a simple
122 linked list. The posibility of replacing this list with a more
123 powerfull data structure exists.
130 The device that corresponds to the core object is described
131 separatly in the devices section.
137 Providing an interface between the processor engines and the core
138 object are the access maps (core_map). Three access maps are
139 provided, one for each of the possible access requests that can be
140 generated by a processor.
148 A processor being able to request a read (or write) or write
149 operation to any of the maps. Those operations can either be
150 highly efficient (by specifying a specific transfer size) or
151 generic (specifying a parameterized number of bytes).
153 Internally the core object takes the request, determines the
154 approperiate attached address space that it should handle it passes
160 (core_map
*) core_readable
164 (core_map
*) core_writeable
168 (core_map
*) core_executable
171 /* Variable sized read/write
173 Transfer (zero) a variable size block of data between the host and
174 target (possibly byte swapping it). Should any problems occure,
175 the number of bytes actually transfered is returned. */
178 (unsigned) core_map_read_buffer
185 (unsigned) core_map_write_buffer
192 /* Fixed sized read/write
194 Transfer a fixed amout of memory between the host and target. The
195 memory always being translated and the operation always aborting
196 should a problem occure */
198 #define DECLARE_CORE_WRITE_N(N) \
200 (void) core_map_write_##N \
202 unsigned_word addr, \
207 DECLARE_CORE_WRITE_N(1)
208 DECLARE_CORE_WRITE_N(2)
209 DECLARE_CORE_WRITE_N(4)
210 DECLARE_CORE_WRITE_N(8)
211 DECLARE_CORE_WRITE_N(word
)
213 #define DECLARE_CORE_READ_N(N) \
215 (unsigned_##N) core_map_read_##N \
217 unsigned_word addr, \
221 DECLARE_CORE_READ_N(1)
222 DECLARE_CORE_READ_N(2)
223 DECLARE_CORE_READ_N(4)
224 DECLARE_CORE_READ_N(8)
225 DECLARE_CORE_READ_N(word
)
This page took 0.033351 seconds and 4 git commands to generate.