( ESNUG 273 Item 4 ) --------------------------------------------- [12/5/97]
Subject: (ESNUG 271 #4) How BC Handles Designs That Involve Handshaking
>Maybe it's been a while since I've looked at BC, or maybe BC has improved,
>but here is the scenario that I remember which BC could not tackle and why
>I say that BC fails in the basics of hierarchical design. I code up a BC
>block that may or may not generate a data item on every cycle, so I have a
>signal calle "valid" that accompanies the data output. Then since my blocks
>are symmetrical, my next block can take the input on every cycles, but once
>in a while it can't. So, my next block has a handshaking signal going back
>to the first block called "got_it".
>
>This methodology is followed at nausium.
>
>What BC could not handle is the fact that there was a two-way handshaking
>mechanism (which is very common - like PCI-bus's IRDY# and TRDY# signals),
>where the sender and the reciever both have flow control. BC wanted only
>one of the blocks to be able to control the flow of data, but not both. To
>me that meant that I could design only certain blocks with BC (the ones that
>BC could handle) and the rest with an RTL methodology. That once again may
>be enough of a productivity gain for some "design spaces", and there maybe
>lots of "design spaces" that BC can handle very well, just not the one I
>needed. At the time when I took the BC class I spoke to the BC CAE and he
>admitted that BC couldn't handle stalling or the two-way handshake, but that
>in the future BC would improve and take on more "design spaces". I'm just
>more ready that most to move beyond this RTL-level design methodology that
>we've been crawling with. I'm very glad that Synopsys continues their
>relentless march toward the next level of design tools (good job!) - I just
>wish that it was here already.
>
> - Victor J. Duvanenko
> Truevision
From: [ A Synopsys BC CAE ]
Hi John,
If I understand Victor correctly what he would like is that both blocks have
control over the signal flow. In other words the "producing" block provides
output data along with a data integrity signal specifying whether the output
data is valid or not (i.e. output_data and data_valid).
The "receiving" block then may or may not be able to read this valid
output_data so the "receiving" block is required to acknowledge the receipt
of the "producing" block's output_data. If the "receiving" block does not
acknowledge the receipt of the "producing" block's output_data then the
"producing" block should stall until it does.
There are two basic BC coding approaches to this scenario.
First, "Producing" block produces a data_valid output along with the
output_data itself. (This is very easy to do within BC.)
Verilog
-------
forever begin: main_loop
data_valid <= 1'b0;
d_reg = data;
@(posedge clk);
....
output_data <= calculation(d_reg);
data_valid <= 1'b1;
@(posedge clk);
end // main_loop
VHDL
----
main: loop
data_valid <= `0';
d_reg := data;
wait until clk'event and clk='1';
....
output_data <= calculation(d_reg);
data_valid <= `1';
wait until clk'event and clk= `1';
end loop main;
Second, the "receiving" block needs to let the "producing" block know
whether it received the data. (This is, again, very easy to do in BC.)
Verilog
-------
if ((data_valid == 1'b1 && i_am_ready == 1'b1)
begin
stall_producing_block <= 1'b1;
@(posedge clk);
....process data....
@(posedge clk);
end
else
begin
stall_producing_block <= 1'b0;
@(posedge clk);
end
end if;
VHDL
----
if ((data_valid = '1' and i_am_ready = '1') then
stall_producing_block <= 1'b1;
wait until clk'event and clk= `1';
....process data....
wait until clk'event and clk= `1';
else
stall_producing_block <= 1'b0;
wait until clk'event and clk= `1';
end if;
So, now that I've answered Victor's question, I'd like to ask he and the
other ESNUG BC users a somewhat related handshaking question:
BC allows read operations to take place during any cycle of a superstate.
Therefore, it is necessary to register all of the inputs to a BC process for
the entire duration of the superstate in which they are sampled. The
architectures produced by BC follow this recommendation, because all outputs
of any process scheduled by BC are registered and held for the entire
duration of the next superstate. So there is always a one cycle latency
between an input and output of a BC process.
Now the $64 question:
We (the BC team) have been toying with the idea of allowing users to define
a pragma/compiler directive that causes BC not to register particular
outputs. We have concerns that if users are not careful they can cause
their designs to fail. (For example if I remove the register for my
data_valid signal (above) and not my output_data signal, then my handshaking
protocol will no longer work.)
What do users think? Is this something we should do, and if so why?
- [ A Synopsys BC CAE ]
|
|
