FPGA Central

Two related signals control a process. The process is launched if Sig1 or
Sig2 is active. This does not mean OR logic. I bring an illustration of a
register just to make it clear.
You have a register that can be in loaded or in empty state. It accepts data
(becomes LOADED) when is EMPTY and WRITE input is active. At a clock edage
when register is being loaded it responds with ACK signal, releasing data
provider. That is, ACK is active when WRITE and EMPTY = '1'. There are two
options when to load data FFs of the register:
- when EMPTY = '1', that is when reg. contains no valid data; or
- when ACK = '1', i.e. reg. responds the fact it loads data.
Logically, the device will function equvalently. The pseudo-code:

entity:
WRITE: in std_logic
ACK: out std_logic
DIN, DOUT: std_logic_vector;

architecture
EMPTY: std_logic;

begin
ACK <= EMPTY and WRITE;

@CLK: -- the option1:
if ACK then
DOUT <= DIN;

@CLK: -- the option2:
-- if EMPTY then
-- DOUT <= DIN;



This is dilemma that I think is very typical in HW (In SW you would use the
variable/flag that is most recently used and is most likely cached).
Preference of one signal to another does not affect behaviuor, it affects
tracing and ethernal HW considerations (size/frequency) ultimately. From
one point of view, I would choose the most frequently used signal because
its trace is broader available on PCB/PLD. On the other hand, if a signal is
frequently used this means that the greater number of destinations enforced
by its longer trace cause a high load of the signal.

Are PCB/FPGA considerations the same regarding this problem? Which general
rule do you use? Does this issue deserve any attention at all? Do you see
the issue?

Thanks.

In article <[email protected]>,
[email protected] says...
> Two related signals control a process. The process is launched if Sig1 or
> Sig2 is active. This does not mean OR logic. I bring an illustration of a
> register just to make it clear.
> You have a register that can be in loaded or in empty state. It accepts data
> (becomes LOADED) when is EMPTY and WRITE input is active. At a clock edage
> when register is being loaded it responds with ACK signal, releasing data
> provider. That is, ACK is active when WRITE and EMPTY = '1'. There are two
> options when to load data FFs of the register:
> - when EMPTY = '1', that is when reg. contains no valid data; or
> - when ACK = '1', i.e. reg. responds the fact it loads data.
> Logically, the device will function equvalently. The pseudo-code:
>
> entity:
> WRITE: in std_logic
> ACK: out std_logic
> DIN, DOUT: std_logic_vector;
>
> architecture
> EMPTY: std_logic;
>
> begin
> ACK <= EMPTY and WRITE;
>
> @CLK: -- the option1:
> if ACK then
> DOUT <= DIN;
>
> @CLK: -- the option2:
> -- if EMPTY then
> -- DOUT <= DIN;
>
>
>
> This is dilemma that I think is very typical in HW (In SW you would use the
> variable/flag that is most recently used and is most likely cached).
> Preference of one signal to another does not affect behaviuor, it affects
> tracing and ethernal HW considerations (size/frequency) ultimately. From
> one point of view, I would choose the most frequently used signal because
> its trace is broader available on PCB/PLD. On the other hand, if a signal is
> frequently used this means that the greater number of destinations enforced
> by its longer trace cause a high load of the signal.
>
> Are PCB/FPGA considerations the same regarding this problem? Which general
> rule do you use? Does this issue deserve any attention at all? Do you see
> the issue?

If I understand the question (it is confusing) you want to know *which*
option to use to enable the register, ACK or WRITE. Since ACK is EMPTY
*AND* WRITE, ACK is at least one gate delay later than EMPTY. If the
logic doesn't matter (WRITE was irrelevant) I'd normally opt to take
the faster signal to improve the setup time. ...but perhaps I don't
see the issue.

--
Keith

> If I understand the question (it is confusing) you want to know *which*
> option to use to enable the register, ACK or WRITE.
ACK or EMPTY, you cannot load a register if it is loaded.

> I'd normally opt to take the faster signal to improve the setup time.
....but perhaps I don't
> see the issue.
This is an option, thanks. I do not take it into consiteration since setup
time is the longest way the signal travels. As I have both signals (ACK and
EMPTY) anyway, there is no additional gate delay. However, if reg loading
controlling signal turns out to appear at the longest trace this option may
gain sense. But (I may mistake) in modern HW traces play as an important
role as the gates. If a signal is available at a certain part of a design
then why to trace another one?

So, any other options?

In article <[email protected]>,
[email protected] says...
> > If I understand the question (it is confusing) you want to know *which*
> > option to use to enable the register, ACK or WRITE.
> ACK or EMPTY, you cannot load a register if it is loaded.

Ah, my mistake.

> > I'd normally opt to take the faster signal to improve the setup time.
> ...but perhaps I don't
> > see the issue.
> This is an option, thanks. I do not take it into consiteration since setup
> time is the longest way the signal travels. As I have both signals (ACK and
> EMPTY) anyway, there is no additional gate delay.

But in your equations you have:

ACK <= EMPTY and WRITE;

....which infers a gate and thus at least a gate delay between ACK and
EMPTY.

> However, if reg loading
> controlling signal turns out to appear at the longest trace this option may
> gain sense. But (I may mistake) in modern HW traces play as an important
> role as the gates. If a signal is available at a certain part of a design
> then why to trace another one?

This is an unknown in this problem. If this is a big problem, I'd do
it both ways and let synthesis/PAR work out the best solution. This is
often done, though I don't think I've done it at this low of a level
(usually different implementations of larger blocks).

>
> So, any other options?

Let the software do its thing. ;-)

--
Keith

> But in your equations you have:
> ACK <= EMPTY and WRITE;
> ...which infers a gate and thus at least a gate delay between ACK and
> EMPTY.
Yes, but in the example the ACK signal is calculated for another purpose (to
inform data provider that we consume the data). Thus, I have this data delay
in any case, whether control loading by EMPTY or ACK.

>
> > However, if reg loading
> > controlling signal turns out to appear at the longest trace this option
may
> > gain sense. But (I may mistake) in modern HW traces play as an important
> > role as the gates. If a signal is available at a certain part of a
design
> > then why to trace another one?
>
> This is an unknown in this problem. If this is a big problem, I'd do
> it both ways and let synthesis/PAR work out the best solution. This is
> often done, though I don't think I've done it at this low of a level
> (usually different implementations of larger blocks).
May be this is not a big problem, but lots of small problems is always a one
big problem. Bad style means you have small errors/drawbacks throughout your
code. As I'm relatively young to HW I try to develop a good style.


> Let the software do its thing. ;-)
Load the reg with *don't care* when it is empty and with data input on ACK?
Good idea. But synthesier placer, router are still different tools. From the
sithesier point of view, there is no difference in delay controlling the
load. I don't stop wonder how intelligent sometems morern tools can be, but
in general they are stupid. Optimization task is NP-complete, it is always
better to simplify SW can optimize a design replacing its parts as far as
behafviur is the same.

**** Let the software do its thing *****
if ACK then
DATA_REG <= DATA
elsif EMPTY then
DATA <= '-';
-- else hold value
end if;

thanks.

In article <[email protected]>,
[email protected] says...
> > But in your equations you have:
> > ACK <= EMPTY and WRITE;
> > ...which infers a gate and thus at least a gate delay between ACK and
> > EMPTY.
> Yes, but in the example the ACK signal is calculated for another purpose (to
> inform data provider that we consume the data). Thus, I have this data delay
> in any case, whether control loading by EMPTY or ACK.

Sure, but the slack for this register will be better, allowing easier
PAR and perhaps allowing a better solution for something else. There
is no point in making things worse.

> > > However, if reg loading
> > > controlling signal turns out to appear at the longest trace this option
> may
> > > gain sense. But (I may mistake) in modern HW traces play as an important
> > > role as the gates. If a signal is available at a certain part of a
> design
> > > then why to trace another one?
> >
> > This is an unknown in this problem. If this is a big problem, I'd do
> > it both ways and let synthesis/PAR work out the best solution. This is
> > often done, though I don't think I've done it at this low of a level
> > (usually different implementations of larger blocks).
> May be this is not a big problem, but lots of small problems is always a one
> big problem. Bad style means you have small errors/drawbacks throughout your
> code. As I'm relatively young to HW I try to develop a good style.

Good plan. Be consistent with your style and white-space too. Lots of
comments also make for a good style. I always spend a lot of time
making things easy to read. It *undoubtedly* will save me time next
week figuring what the hell I just did.
>
> > Let the software do its thing. ;-)
> Load the reg with *don't care* when it is empty and with data input on ACK?

No. Don't use "don't cares" in synthesizable logic. The "don't care"
state isn't realizable and the synthesizer may puke.

You should also have a reset clause in your process.

> Good idea. But synthesier placer, router are still different tools. From the
> sithesier point of view, there is no difference in delay controlling the
> load.

That depends on your toolset. The toolset I used had delays built into
the synthesizer. They weren't always of great use because, as you
note, wiring delay is significant and the synthesizer can't know where
PAR puts things. OTOH, if your PHB is rich (I had a virtually
unlimited budget ;-) there are physical synthesis tools out there that
can do a much better job before PAR.

> I don't stop wonder how intelligent sometems morern tools can be, but
> in general they are stupid. Optimization task is NP-complete, it is always
> better to simplify SW can optimize a design replacing its parts as far as
> behafviur is the same.

The problem is that your synthesizer doesn't have all the information
needed to do the job you're asking it to do. You need timing feedback
from the PAR tools.
>
> **** Let the software do its thing *****
> if ACK then
> DATA_REG <= DATA
> elsif EMPTY then
> DATA <= '-';
> -- else hold value
> end if;

Ack! ;-) You're using ACK as your clock and it's going to produce a
level sensitive latch (not good in most technologies). (or did you just
leave out the clock?)

It's also rather unlikely that your target technology has a '-' level.

What I meant by "letting the software do its thing" was implement it
both ways and see which does a better job. Let the software tell you
where the negative slack is, then fix it. This sort of thing is likely
going to be highly implementation dependant. There is unlikely a "best
way", other than not to shoot yourself (before you need to ;-).

--
Keith