fastmodel,dev: Replace the reset port with a Signal*Port<bool>.
The ResetRequestPort and ResetResponsePort have a few problems: 1. A reset signal should happen during the time a reset is asserted, or in other words the device should stay in reset and not doing anything while reset is asserted. It should not immediately restart execution while the reset is still held. 2. These names are misleading, since there is no response. These names are inherited from other port types where there is an actual response. There is a new generic SignalSourcePort and SignalSinkPort set of port classes which are templated on the type of signal they propogate, and which can be used in place of reset ports in c++. These ports can still have a specialized role which will ensure that only reset ports are connected to each other for a form of type checking, although the underlying c++ instances are more interoperable than that. Change-Id: Id98bef901ab61ac5b200dbbe49439bb2d2e6c57f Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/66675 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Yu-hsin Wang <yuhsingw@google.com> Tested-by: kokoro <noreply+kokoro@google.com>
This commit is contained in:
@@ -36,9 +36,7 @@ Source('dma_device.cc')
|
||||
Source('dma_virt_device.cc')
|
||||
|
||||
SimObject('IntPin.py', sim_objects=[])
|
||||
|
||||
SimObject('ResetPort.py', sim_objects=[])
|
||||
Source('reset_port.cc')
|
||||
|
||||
DebugFlag('IsaFake')
|
||||
DebugFlag('DMA')
|
||||
|
||||
Reference in New Issue
Block a user