Subject: Copyright Clarification
From: Christian Burisch (burisch@co-design.com)
Date: Mon Aug 05 2002 - 15:52:19 PDT
Hi again,
I sent this e-mail a few days ago, one of the interface examples contained
a SUPERLOG queue
statement, which is not part of SystemVerilog (nor the SUPERLOG ESS subset
that was originally
donated by Co-Design to Accellera.) This was only for explanation purposes.
The Copyright on the queue syntax is owned by Co-Design.
Thanks,
Christian
>>Date: Thu, 01 Aug 2002 17:52:58 +0100
>>To: sv-ec@server.eda.org
>>From: Christian Burisch <burisch@co-design.com>
>>Subject: SystemVerilog and channels
>>
>>
>>Hi Guys,
>>
>>Dave Kelf forwarded the thread proposing channels in SystemVerilog. Some
>>comments:
>>
>>First of all Stuart hit the nail on the head that there is some nomenclature
>>confusion, because sometimes the same term is used in SystemVerilog/SUPERLOG
>>and SystemC with different meanings.
>>
>> >From: "Stuart Swan" <stuart@cadence.com>
>> >SystemC 2.0 SystemVerilog
>> >----------- -------------
>> >channel interface
>> >interface modport
>>
>>I propose to use the SystemVerilog terminology by default and state
>>explicitely
>>if you mean something else, like "SystemC channels" or "SystemC interfaces".
>>
>>In SystemVerilog and SUPERLOG a module encapsulates implementation, while
>>an interface encapsulates communication.
>>
>>Different levels of abstractions are possible in both modules and interfaces.
>>You can have a module at an architectural level, at RTL or at gate level,
>>similarly you can model the communication in an interface with a cycle
>>accurate protocol or at higher, more abstract levels.
>>
>>The easiest thing you can do with an interface is just to use it as a wire
>>bundle.
>>So an interface is to a wire in SystemVerilog like a struct is to
>>an int in C/C++/SystemVerilog/SUPERLOG, a means of grouping the data.
>>
>>You can also include the way the data is sent and received in the interface,
>>i.e. its protocol.
>>In this case an interface is to a wire like a class is to an int in C++
>>or SUPERLOG,
>>a means of grouping the data and the protocol.
>>
>>(I am using the term protocol to include the sequence of data being
>>exchanged, not
>>just the data types.)
>>
>>The tasks and functions inside the interface and class are referred to as
>>"methods"
>>in OO parlance.
>>
>>For the former use you can look at a wire as the simplest built in interface.
>>There is no built in interface for the latter usage.
>>
>>What you are suggesting amounts to defining a "channel" in SystemVerilog as
>>the simplest possible built in interface.
>>
>>Sounds like a good idea and we did consider this a few years ago, but we
>>didn't do it for reasons that I'll outline below.
>>
>>Here is an interface in SystemVerilog with a read and write task which block.
>>It is unidirectional, if you need bidirectional, then just use 2 of them.
>>The data_type is parameterizable, (this is what you call "interface" in
>>SystemC.)
>>
>>interface channel;
>>
>> parameter type data_type = bit;
>> data_type data;
>> bit valid;
>>
>> task write(input data_type d);
>> wait(valid == 0);
>> data = d;
>> valid = 1;
>> endtask
>>
>> task read(output data_type d);
>> wait(valid == 1);
>> d = data;
>> valid = 0;
>> endtask
>>
>>endinterface
>>
>>You can add queuing functionality by including a fixed length FIFO,
>>if you want:
>>
>>interface channel;
>>
>> parameter type data_type = bit;
>> parameter int max = 10;
>> data_type fifo[max:0];
>> int num=0, high=0, low=0;
>>
>> task write(input data_type d);
>> wait(num <= max);
>> fifo[high++]=d;
>> if (high > max) high = 0;
>> num++;
>> endtask
>>
>> task read(output data_type d);
>> wait(num > 0);
>> d = fifo[low++];
>> if (low > max) low = 0;
>> num--;
>> endtask
>>
>>endinterface
>>
>>With SUPERLOG you can also have unbounded queues very easily:
>>
>>interface channel;
>>
>> parameter type data_type = bit;
>> data_type q[0:$];
>>
>> task write(input data_type d);
>> q = {q, d};
>> endtask
>>
>> task read(output data_type d);
>> wait(q.$num > 0);
>> d = q[0];
>> q = q[1:$];
>> endtask
>>
>>endinterface
>>
>>Note that this example uses SUPERLOG queues which are not
>>included as part of SystemVerilog, as when the initial
>>SUPERLOG ESS donation was executed, this higher level behavior
>>was not specified as part of the implementation requirements.
>>The use of queues within interfaces does allow additional
>>functionality as requested by Kevin.
>>
>>
>>The reason we did not include a built in interface (which you may want to
>>call "channel") which has this functionality is because we would have to
>>define names for the write and read tasks inside, which is quite clunky.
>>
>>We did consider allowing interfaces to be used in assigments, similarly
>>to Kevin's suggestion. Then we can do away with the read and write task names
>>in their calls.
>>
>>i.e. instead of
>>channel.write(out);
>>channel.read(in);
>>
>>you could write:
>>channel = out;
>>in = channel;
>>
>>But of course this syntax would be terrible, because each line could be
>>blocking, so looking at the code fragment you would not be able to see that.
>>Verilog assigments are in zero time, so we should not mess with that.
>>(and the parser would go schizo too)
>>
>>We could make both of the methods functions (instead of tasks i.e. no timing
>>inside), and use Kevin's method of triggering off the interface to supply the
>>timing for one of them:
>>
>>channel = out;
>>@(channel) in = channel;
>>
>>This works, but only if you remain at the abstract level. When you refine
>>the interface to something real (PCI, SCSI etc) then suddenly both read
>>and write take time and you are stuck.
>>
>>In your posts you talked about three different uses of interfaces.
>>They are, in order of importance,
>>
>>1) System Modelling
>> Here you define a system at a high level and you must be able
>> to refine it down to lower levels of abstraction. For this reason we
>> don't want a built-in interface where the read and/or the write must
>> be a (zero delay) function.
>>
>>2) Interaction with SystemC
>> A SystemVerilog interface is a natural place to make a connection to
>> other languages, such as C/C++ or SystemC.
>>
>>3) Multiprocessing Software
>> Actually I agree with you that SUPERLOG/SystemVerilog may turn out
>> to be interesting for multiprocessing software, but this is a long
>> way away in the future, (even though there is a research project about
>> this at a university).
>> In any case I believe that Occam is not a good role model for that.
>>
>>I hope this made sense and that I explained our reasoning behind making
>>interfaces as they are.
>>
>>Regards,
>>
>>Christian
This archive was generated by hypermail 2b28 : Mon Aug 05 2002 - 15:07:48 PDT