Per, Russ, I changed the title for more descriptive name of the topic we are dealing with. I inserted my notes below. Shabtay >-----Original Message----- >From: Per Bojsen [mailto:bojsen@zaiqtech.com] >Sent: Monday, June 20, 2005 6:25 PM >To: Shabtay Matalon >Cc: vreeland@broadcom.com; itc@eda.org >Subject: RE: ITC Meeting Minutes for May 26th > >Hi Shabtay and Russ, > >> We use some terms differently which may cause some confusion. For >> example, you use the term "streaming vs. purely alternating" below by >> defining streaming mode as what I call concurrent. > >`Streaming' is normally taken to mean that each end of the conduit run >concurrently. A good example is streaming video. The server is sending >video data concurrently with the viewer showing the video. >So, with the standard definition of `streaming', concurrency is implied and >inseparable. [Shabtay] I proposed using the term concurrent to contrast with alternating as it clearly distinguishes the two use models. For example, concurrent use model can support concurrent data generation that is not halted (such as streaming video), but may also cover scenarios that stall (wait) for various reasons. Therefore concurrent covers all scenarios of data generation or consumption that run concurrently with the hardware side. It has also been quite common to use the term streaming even when the stream is being stopped. For example, in pure in-circuit emulation, you may produce stream of video at a high rate, and consume it on the emulator at a lower rate by implementing speed matching hardware (the term Speed Bridge is common used) using some handshake. This did not preclude naming the interface as streaming (see more on this below). Do you both agree that using "concurrent" as the reciprocal to alternating is a better name? > >> I simply contrast concurrent vs. alternating indicating whether the HW >> side and the SW side take turns or run at the same time (aka >> concurrently). I separate this use model from "streaming" meaning >> delivery of multiple transactions in a batch by my definition. > >In contrast to streaming, batch delivery of messages can occur even if both >sides are not running concurrently. In SCE-MI 1.1, for instance, it is >possible for an implementation to allow multiple input messages to a given >port to be transferred to the hardware side in a batch. However, this is >not really possible on the output side as it would violate the ordering >requirements. That is, it is not possible for output messages with >different cycle stamps. Messages that arrive at the same port during the >same cycle stamp, i.e., when the controlled clocks are stopped, could be >batched. > >So I'm thinking Shabtay is referring to possibly allowing a use model where >output messages can be batched even if they arrive at different cycle >stamps. [Shabtay] Correct. Assume that a cycle stamp defines the time a message is delivered. Or even assume that the message embodies various cycle stamp values read explicitly by means that the infrastructure provides. The end user may determine the level of batching required by its testbench environment for output messages on a given interface (same may apply on the producing side). The messages will arrive on each channel in order, but multiple output messages will arrive at the same time, each message with continuously increasing cycle stamp values. In SCE-MI 1.1 this is not allowed. This is similar to streaming but not quite the same as batching >can occur without concurrency. It would then merely be a way to optimize >the use of the physical channel between the hardware and software sides. [Shabtay] Batching of massages indeed allows optimizing the transport layer for performance. If we yet want to use the term streaming, I would suggest that we narrow its definition to mean a) It runs in concurrent mode only b) It batches messages throughout the session. Alternatively, we may choose to use the term streaming more loosely to denote any batching of messages that occurs in alternating or concurrent use model. I personally don't have an issue with both options, as long as we eliminate ambiguities in the terms that we use. > >Per > >Received on Tue Jun 21 11:13:07 2005
This archive was generated by hypermail 2.1.8 : Tue Jun 21 2005 - 11:13:10 PDT