Fixed grant bug
Just becasue we have a grant id doesn't mean that anything has actually been granted...
This commit is contained in:
parent
a58c908763
commit
d552934b95
4 changed files with 140 additions and 130 deletions
|
@ -14,16 +14,14 @@ import FIFOF
|
|||
import SpecialFIFOs
|
||||
import Printf
|
||||
|
||||
busRequestToAddr :: BusRequest -> Addr
|
||||
busRequestToAddr req = case req of
|
||||
BusReadRequest (ReadRequest addr _) -> addr
|
||||
BusWriteRequest (WriteRequest addr _) -> addr
|
||||
|
||||
-- Create a Bus Module that supports multiple clients and servers
|
||||
-- Creates a Bus Module that supports multiple clients and servers
|
||||
-- submitting requests and simultaneously returning responses.
|
||||
-- Responses can be consumed by clients out of order as all client
|
||||
-- submitted requests are tagged - and servers keep that tag
|
||||
-- when responding.
|
||||
-- Responses can be consumed by clients out of order(useful when some
|
||||
-- servers respond before others) as all client submitted requests are
|
||||
-- tagged with tags that are unique for the duration of the transaction
|
||||
-- - and well-behaved servers should keep that tag when responding.
|
||||
|
||||
-- Explicitly inform the compiler that log2 n <= log2(n + 1)
|
||||
mkBus :: (Add n (TLog numServers) (TLog (TAdd numServers 1)))
|
||||
=> (Addr -> Maybe (MkServerIdx numServers))
|
||||
-> Module (Bus inFlightTransactions numClients numServers)
|
||||
|
@ -32,13 +30,15 @@ mkBus serverMap = do
|
|||
tagEngineByClientVec :: Vector numClients (TagEngine inFlightTransactions)
|
||||
tagEngineByClientVec <- replicateM mkTagEngine
|
||||
|
||||
-- There are `numClients` clients, each of which needs its own arbiter as
|
||||
-- there are up to `numServer` servers that may wish to submit a response
|
||||
-- to a given client. Furthermore the rule that routes client requests to
|
||||
-- servers makes for another potential requestor as it may determine that
|
||||
-- a request is unmappable and instead opt to form and submit a
|
||||
-- `BusError UnMapped` response directly to a client response arbiter. Thus
|
||||
-- we must arbit between a total of `numServers + 1` requestors.
|
||||
-- There are `numClients` clients, each of which needs its own client
|
||||
-- response arbiter as there are `numServer` servers that may wish to
|
||||
-- submit a response to a given client. Furthermore the rule that routes
|
||||
-- client requests to servers makes for another potential submitter to
|
||||
-- the client response arbiter as it may determine that a request is
|
||||
-- unmappable and simply bypass submitting the request to a server,
|
||||
-- instead opting to form a `BusError UnMapped` response to be submitted
|
||||
-- directly to a client response arbiter. Thus the client response arbiter
|
||||
-- must arbit between a total of `numServers + 1` requestors.
|
||||
responseArbiterByClient :: Vector numClients (Arbiter.Arbiter_IFC (TAdd numServers 1))
|
||||
responseArbiterByClient <- replicateM (mkArbiter False)
|
||||
|
||||
|
@ -48,9 +48,6 @@ mkBus serverMap = do
|
|||
requestArbiterByServer :: Vector numServers (Arbiter.Arbiter_IFC numClients)
|
||||
requestArbiterByServer <- replicateM (mkArbiter False)
|
||||
|
||||
dummyVar :: Reg(Bool)
|
||||
dummyVar <- mkReg False
|
||||
|
||||
-- Queues to hold requests from clients
|
||||
clientRequestQueues :: Vector numClients (FIFOF (TaggedBusRequest inFlightTransactions))
|
||||
clientRequestQueues <- replicateM (mkSizedBypassFIFOF (valueOf inFlightTransactions))
|
||||
|
@ -59,8 +56,11 @@ mkBus serverMap = do
|
|||
clientResponseQueues :: Vector numClients (FIFOF (TaggedBusResponse inFlightTransactions))
|
||||
clientResponseQueues <- replicateM (mkSizedBypassFIFOF (valueOf inFlightTransactions))
|
||||
|
||||
-- The following two vectors of FIFOs make it easier to push/pull data to/from internal
|
||||
-- server methods:
|
||||
-- The following two vectors of single depth FIFOs make it easier to push/pull data
|
||||
-- to/from internal server methods as they provide back-pressure in both directions,
|
||||
-- and behave as a wire when queue is empty.
|
||||
-- If looking at the example bus.drawio diagram, the following two vectors effectively
|
||||
-- correspond to the two arrows going from the blue box to the servers.
|
||||
consumeRequestQueues :: Vector numServers (
|
||||
FIFOF (
|
||||
MkClientTagType numClients,
|
||||
|
|
Reference in a new issue