( ESNUG 274 Item 6 ) --------------------------------------------- [12/10/97]
Subject: (ESNUG 271 #4 273 #4) How BC Handles Designs With Handshaking
>> Maybe it's been a while since I've looked at BC, or maybe BC has improved,
>> but here's 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 / may not generate a data item on every cycle, so I have a
>> signal called "valid" that accompanies the data output. Since my blocks
>> are symmetrical, my next block can take 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".
From: [ A Synopsys BC CAE ]
> 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.) ...
From: Oren Rubinstein <oren@gigapixel.com>
The code for the "producing" block is not checking the "i_am_ready" signal,
so it doesn't do what is required.
From: [ A Synopsys BC CAE ]
> 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.)
From: Oren Rubinstein <oren@gigapixel.com>
The code for the "receiving" block doesn't seem to generate the "i_am_ready"
signal, unless it's the inversion of "stall_producing_block"
More to the point, in order to be able to do double data pacing a la PCI, you
would need what is called "fast handshaking" in BC terminology, except:
1. You can't do fast handshaking for both input and output at the same time
2. Fast handshaking requires an additional clock after the "fast" one
Therefore, the best you can do with BC is one data on every other clock.
Just to clarify, here is a timing diagram of what PCI needs:
_ _ _ _ _ _
CLOCK _| |_| |_| |_| |_| |_| |_
__ _______ __
IRDY# \_______/ \___/
__ ___ __
TRDY# \_______/ \_______/
^ ^ ^
| | |
Data transfers
BC won't be able to do the second data transfer in the diagram, because it
needs at least one clock after the first data.
From: [ A Synopsys BC CAE ]
> 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?
Yes, because the tool should not restrict the designers.
You have to assume people know what they're doing (if they don't, there
are so many ways to do bad designs that one more won't matter)
- Oren Rubinstein
GigaPixel Corp.
|
|
