Subject: Re: SystemVerilog and channels
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Aug 06 2002 - 11:31:39 PDT
Christian Burisch wrote:
>
> At 12:47 PM 8/1/02 -0700, Kevin Cameron wrote:
>
>> Christian Burisch wrote:
>>
>> > Hi Guys,
>> >
>> > .....
>> >
>> > 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;
>>
>> There was also "channel <= out" for a non-blocking write.
>>
>> > 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.
>>
>> I'm not sure what you mean by "stuck". There is a difference between
>> "stuck" as in "blocked" which is probably OK, and "stuck" as in "deadlocked"
>> which means your design is broken.
>
>
> "Stuck" as in "caught in a jam" :-)
> In your first high level model the architect uses a zero delay write to
> transmit data to the channel. When the design is refined to use a real
> interface, both the reads and write will take time.
I still don't see a problem with that, abstract modelling nearly always has
bogus timing.
>> > 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.
>>
>> I don't think I asked for that. The suggested syntax adds a protocol type
>> to the channel which dictates the minimum packet size, it only blocks
>> if you deliberately overread. The following code would not block:
>>
>> channel byte data;
>> byte buff[100];
>> integer i = 0;
>> always @(data) begin
>> buff[i++] = data;
>> if (i == 100) begin // full
>> // process it...
>> i = 0;
>> end
>> end
>
>
> Here is the SystemVerilog Version.
> First define a channel with the byte type inside it:
>
> interface channel;
> byte data;
> bit valid=0;
>
> task transmitbyte(input byte d);
> wait(valid == 0);
> data = d;
> valid = 1;
> endtask
>
> task receivebyte(output byte d);
> wait(valid == 1);
> d = data;
> valid = 0;
> endtask
> endinterface
>
> Then your code becomes:
>
> channel c;
> byte buff[99:0];
> integer i = 0;
> always begin
> c.receivebyte(buff[i++]);
> if (i == 100) begin // full
> // process it...
> i = 0;
> end
> end
>
> But actually, this receives bytes in packets of 100, so a better place
> to put the read loop is inside the interface:
>
> First define a packet:
>
> typedef byte[99:0] packet;
>
> Then add this task to the interface channel:
>
> task automatic receivepacket(output packet p);
> for (int i=0; i <= 99; i++)
> receivebyte(p[i]);
> endtask
>
> Then your code becomes:
>
> channel c;
> packet p;
> always begin
> c.receivepacket(p);
> // process it...
> end
> end
>
> But the channel needs to talk to something, typically the packet transmission
> would happen in another module, so we need to use the interface channel to
> connect the modules:
>
> module kevin(channel c);
> packet p;
> always begin
> c.receivepacket(p);
> // process it...
> end
> end
> endmodule
>
> You have now separated the communication (interface) and the processing
> of the data (module).
But it was seperate already in my version, and I didn't have to write the interface
definition.
I agree entirely that you can implement FIFO data channels in interfaces or modules
but the point of the "channel" construct I described was to bridge between
languages as much as between processes (e.g. SV to C++,Perl..), so the question
below still stands if you do a straight interface implementation.
>> - when you refine that the "@(data)" would probably just become an
>> "@(clock)". It helps to have an asynchronous definition because the
>> synthesis tools don't see an artificial dependency on a clock and just
>> see the data flow.
>>
>> > 2) Interaction with SystemC
>> > A SystemVerilog interface is a natural place to make a connection to
>> > other languages, such as C/C++ or SystemC.
>>
>> But what mechanism do you plan to use to access the SV Interface from C++?
>
.....
Kev.
-- National Semiconductor 2900 Semiconductor Drive, Mail Stop A1-520, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Tue Aug 06 2002 - 11:39:53 PDT