1 / 31

RAMP Common Interface

RAMP Common Interface. Krste Asanovic Derek Chiou Joel Emer. General Requirements. Provide a language agnostic environment that facilitates sharing of modules

andres
Download Presentation

RAMP Common Interface

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. RAMP Common Interface Krste Asanovic Derek Chiou Joel Emer

  2. General Requirements • Provide a language agnostic environment that facilitates sharing of modules • Provide a modeling standard to facilitate the representation of time in the model target system that is independent of the host cycle time • Provide a reusable set of ‘unmodel’ services that can be used by different projects • Provide an underlying communication standard that can be used to specify standard interfaces • Facilitate the creation of a specific set of modules that can be shared and that communicate via standard interfaces

  3. Key infrastructure components • Modeling core architecture • Modeling time • Implementing inter-module data communication • Simulation control and support infrastructure (unModel) • simulation control • communication to front-end or control processor • simulation support • stats, events, assertions, knobs... • Virtual Platform • Local memory access • Shared memory access • Host to FPGA communication channel

  4. Target and Host RTL Model RTL Target RTL Unmodel RTL Platform RTL Host RTL

  5. Translation from Target RTL to Model RTL • Start (conceptually) with final RTL • Partition design into units and channels • All inter-unit communication goes over channels • Channels have fixed latency • they are a systolic pipeline • latency set by what was mapped into the channel Unit Channel Representation as a bipartite graph

  6. Translation from Target to Model (2) • Change representation of time from edges to tokens • Encapsulate data sent on an edge into a timing token • data on the timing channel is 1-1 mapping of original data signals • Replace each channel with a timing token channel • timing channel is a FIFO that transports timing tokens, e.g., A-ports • Convert unit to sink and source tokens by abiding by the following: • Unit waits for tokens on all inputs and reads them • Performs same computation as it did • Dequeues all input tokens • Sends a token on all outputs • Note: channel must be initialiized • Proof of equivalence to be provided

  7. Distributed Timing Example D Unit B Target: Unit A Pipeline target channel implemented as distributed FIFO with at least L buffers Latency L Host: RDYs Start Start RDY D D UnitB Unit A ENQ DEQ Done Done DEQs

  8. Retiming to simply host model • A shift register in the RTL can be converted into a timing token channel with the same latency. • A perfectly systolic computation in the RTL can be converted into a timing token channel with the same latency and the functionality of the pipeline must be moved into the 'unit'. In general any retiming that exposes a series of shift registers allows one to convert the shift registers into a timing token channel. 1 Multiply Multiply 2 1 Retimed Tokenized Target Tokenized Target

  9. Definition: firing •  A token-machine unit firing corresponds to the modeling of a single target machine cycle in that unit. • A token-machine unit firing comprises: • Reading one token from each input channel • Compute based on tokens and internal state • Writing one token to each output channel

  10. Multi-cycle host units • The reads of all input tokens and writes of all output tokens can each be in different host cycles (while still reading each input and writing each output once each modelled cycle) • A firing can be implemented by reading all token inputs, computing and writing all token outputs using multiple host cycles • This is an example of a 'multi-cycle firing‘ and is what allows target cycle accounting to be independent of host cycles. 2 TokenizedTarget Host Multi-cycle host

  11. Pipelined Host Units • Multiple firings of a single token-machine unit can be overlapped (e.g., pipelined) so long as: • the token firing rules are maintained and  • any inter-firing data dependencies internal to the token-machine unit are also maintained. • Consequence is that multiple target cycles are in flight in a host unit at the same time.

  12. Multiplexed host units • Firings from distinct target units can be multiplexed on a single host unit • The multiplexed unit has a distinct copy of state for each target unit being modeled • The multiplexed unit must read tokens from channels associated with the proper target unit. • This might be accomplished by multiplexing the channels themselves. Probably simple if all communication in each target unit is to the same token machine unit port Unit 1 Channel Unit 2 Tokenized Target Host

  13. Basic channel interface A FIFO interface… • Send:  • out notFull; • in [n:0] enq_data; • in enq_en; • Recv: • out notEmpty; • out[n:0] first; • in deq;

  14. Channel Interface Variants Parallel channels (same source and dest and same latency) can be combined into a single timing channel - this reduces flow control overhead Communication on wide channels might be fragmented or packetized across multiple host cycles and internally reassembled into one token. Unit sees flow control at fragment level, but channel guarantees delivery at the token level.

  15. Multiple clock domains Simple cross clock domain communication can be handled with rate matchers at fast end of channel. Unit A – 100 MHz Unit B – 66 MHz Channel

  16. Channel No Message • Often as part of the process of abstracting a design into a model there is a situation where a communication is viewed as not happening… • For example, • To accommodate this situation an channel may include explicit transmission of a 'no message' token data enable

  17. Units Servers Interface Layers Buffering Model domain unModel domain Flow Control Timing Services Direct + Client/Server One-wayClient/Server Point-to-pointOne-to-manyMany-to-one Logical Topology communication domain Point-to-pointRing TreeBus Physical Network Physical Link Intra-FPGA Inter-FPGACPU-to-FPGA dedicated channel TDM (multithreaded) channel

  18. FAST connectors RDL channels “Soft connections” Units Multi-layer implementations Buffering Flow Control A-ports Timing Presentation Logical Topology Physical Network Physical Link

  19. Logical Topology Semantics • Represents host-level inter-module communication • Supports both model and unmodel traffic • Latency may be more than one host cycle • Multiple patterns to be supported • One-to-one • One-to-many • Many-to-one • Must be expressible in multiple languages •  Bluespec, Verilog...

  20. Pattern Examples • 1-to-1 • Timing channels • 1-to-many • “run” command broadcast from controller • Many-to-one • assertion violation reporting

  21. Logical Topology Endpoint Interface Endpoints are simply FIFOs Send:    out notFull;   in [n:0] enq_data; in enq_en; Recv:      out notEmpty;      out[n:0] first;      in deq;    Clocking endpoint has same clock as module connected to it cross host clock domain communication must be supported Conifguration Meta-information connection name connection direction connection pattern

  22. Logical Topologies/Physical Interconnect Intra-FPGAlink Example: shared ring Bd 4 As 1 Ad 3 2 Asat station 1 communicates with Adat station 2 Bs Bsat station 2 communicates withBdat station 4

  23. Units Servers Interface Layers Buffering Model domain unModel domain Flow Control Timing Services Connections One-wayClient/Server Point-to-pointOne-to-manyMany-to-one Logical Topology communication domain Point-to-pointRing TreeBus Physical Network Physical Link Intra-FPGA Inter-FPGACPU-to-FPGA dedicated channel TDM (multithreaded) channel

  24. Physical Network Characteristics • Host-level communication fabric • Reliable transmission • Deadlock Free • Includes buffering for meeting above requirements • Additional buffering is provide at higher layers

  25. Physical Link Interface Semantics • Host-level communication channel • FIFO-style interface • Decoupled input/output • Error-free (reliable delivery) • Uni-directional • Point-to-point • Packet description (TBD) • Indeterminate (but finite) latency

  26. Units Servers Interface Layers Buffering Model domain unModel domain Flow Control Timing Services Connections One-wayClient/Server Point-to-pointOne-to-manyMany-to-one Logical Topology communication domain Point-to-pointRing TreeBus Physical Network Physical Link Intra-FPGA Inter-FPGACPU-to-FPGA dedicated channel TDM (multithreaded) channel

  27. UnModel Support Services Run control Units can be commands to start, stop, etc… Dynamic parameters Units can be configured at runtime Statistics Unit can collect and report event counts Event logging Unit can log a series of events for each cycle Assertions Unit can do runtime checks of invariants and report violations

  28. Service Organization Global Controller GlobalControl LocalControl StatController ParamController Stat DynamicParam Unit Host CPU

  29. Servers and services interface • Service interface is implemented via separate input and output channels that handle requests and responses • Each input/output pair forms a service which implements multiple methods • Request / response is in-order for a single service • Synchronization between calls to different services must be provided by clients. • We provide serializability of operations.

  30. Build process • Handling logical endpoint connections • Would like to avoid requiring parents to need to specify connections • Bluespec: use static elaboration, e.g., “soft connections” • Verilog: use TBD preprocessor • Who maps logical connections to physical networks? • Locally • Globally • 'Static' build parameters • 'Dynamic' run parameters

  31. Backup

More Related