Re: Mixed clocked/combinatorial coding styles

On Aug 27, 11:45 am, KJ <kkjenni...@xxxxxxxxxxxxx> wrote:
On Aug 27, 8:16 am, rickman <gnu...@xxxxxxxxx> wrote:



On Aug 26, 4:52 pm, KJ <kkjenni...@xxxxxxxxxxxxx> wrote:

On Aug 26, 3:09 pm, rickman <gnu...@xxxxxxxxx> wrote:

If you are using a programmable device that
does not have a global power-on reset signal, then you are either
using a very small device (CPLD) or you are using one I have never
heard of.

I'm sure you've heard of Altera, Stratix, Cyclone, etc. Lattice
sometimes, Xilinx less so.

The point is that a global power on reset for the device is not needed
in order to get the flops and memory into a known state at the point
where configuration ends. I know this has been said several times and
you seem to dispute that for some reason but it is the truth.

This seems to be the crux of the discussion. I posted why I think the
GSR is required to initialize the FFs in FPGAs. Why do you think the
GSR is *not* needed to initialize the FFs in FPGAs?

Forgetting for a moment the set of device I/O pins that are required
to load any bitstream into the device and are basically dedicated I/O
for the bitstream load function, all I'm saying is
1. No *other* external I/O pin is *required* to initialize the FPGA
in order to implement an initial condition on a signal that happens to
be the output of a flip flop or memory (i.e. signal xyz: std_ulogic :=
'1';). If the device (and tool set) supports initial values then flip
flop #234 which contains signal 'xyz' will be set to a '1' at the
moment when the device switches over to user mode and starts
functioning as I've described in the HDL. (Later I'll get into if the
device/tools do not meet the condition).
2. I wouldn't use a device input that performs a device wide reset
because in order to do so the trailing edge of such an input signal
would have to be synchronized to each of the clocks internal to the
device. From a practical standpoint about the only way to get this
would be to disable the clock input to the device until some time
after that device wide reset signal goes inactive. What you're doing
here though is shifting the burden off chip to the PCBA just so you
can take advantage of what it does for you inside the FPGA.
Apparently you see this as something 'free' to be taken advantage of
and in some instances it might be. In general though there will be
some cost to be incurred to implement your requirements. As an
example, any other part on the PCBA that intends to use that same osc
as a clock input had better be able to cope with the clock shutting
off during the period of time when the FPGA is getting reset. What if
it can't cope with it? You'll need multiple clocks (one gated to the
FPGA, one not) and there will now be clock skew now between those
two...does the clock skew matter? Yeah, sometimes it does when the
two devices are expected to be receiving the 'same' clock.

First, you have made assumptions about the design to be used in the
FPGA that may or may not be correct for any given design.

The GSR signal does not *have* to be sync'd to the clock in order to
be useful. If you have a FSM which is waiting for an input and you
know for a fact that the input is not asserted on powerup, then you
don't have to worry about the FFs in the FSM all being released on the
same clock cycle. That is one example of when you don't need to sync
the GSR to the clock, there are others.

So as a designer, you have choices.

Regardless, I have already explained how you can use the GSR so that
it *is* sync'd to the system clock. Then the clock does not have to
be held and the GSR utility is "free" consuming no additional
resources. But I still don't get your point? Regardless of how the
FFs in an FPGA are initialized, you still have the problem of how to
synchronize their startup. I think you are glossing over the details
of how this happens. It happens when GSR is released. Check the data
sheets for the parts you are using. If that doesn't work for you,
then you need to make other arrangements. But for a large percentage
of designs, the GSR can be used to both set the initial state and to
synchronize the startup of the chip. If this is not done by the GSR
signal, what does control the startup timing of the chip?


You can argue that putting a reset signal in all of the code now chews
up some logic resources (it does) and can hurt clock cycle performance
(it could) but I've only found this to be any sort of issue on designs
where *everything* gets reset (i.e. control and data path) for no
reason instead of just resetting the much more limited set of control
signals and state machines that need it.

You keep saying stuff like this but it is not true. The global reset
is "global" and dedicated. It is *allways* used. You have two
choices, control it, or let it default to initializing all of the FFs
to zeros.


So the bottom line here is that that there is a cost to be paid for
using the device wide reset pin and that cost could be evaluated on a
design by design basis. While there can be a logic/performance cost
to not using it, I've found that simply resetting only what needs to
be brings that cost down to 0 in many cases (i.e. when the input to
the LUT would not have been used) What I've found so often though is
that using the device wide reset pin costs more than it's worth so I
don't use it.

I don't get what you mean by all of your cost stuff. What you
explained above for cost is the startup of the chip, not the initial
conditions. If you don't control GSR, how do you control the startup
of the chip? When you reset what you want reset, how does that
happen? Doesn't that have a cost?


I do always have some reset input pin to a design (in case there was
some doubt that I only rely on end of config to get me off to the
correct starting point).

Ahhh, how do you control this??? How do you get your freshly
configured design all started on the same clock cycle?

But that reset input goes into the 'D' input
of one flip flop which is the first flop of a shift register and it
goes to the async reset of every flop of that shift register. There
is one of these shift registers for each internal clock in the
device. The outputs of the shift registers become the reset signals
that get distributed to the design. That reset signal though has no
requirement to go active at the end of configuration, it need only go
active when something on the board decides that the FPGA needs to be
reset.

This is using a *LOT* of resources that may be unnecessary. I'm not
clear on why you use multiple outputs from the shift register. I use
one output as the async reset to the entire design. This is then
mapped to the GSR signal by the software and my entire design is
released from reset synchronous to the clock and on the same clock
cycle. Since it uses the GSR signal, the chip ORs its own end of
configuration reset in with the one from the shift register and all is
right with the world.

Yes, if you have multiple clocks in the design, then this is not
viable. But I seldom have multiple clocks that require this sort of
reset release. Instead I try to use a single clock throughout the
chip and sync other clock domains at the I/O point. This eliminates
the need for multiple clock domains in most cases.


Given that, even if the device/tools doesn't happen to support initial
values I wouldn't need to change anything in the RTL code as a
result. What that would mean is that there would be a requirement now
on this reset input to be active for some period of time after the
device is configured. Ysing the device wide reset you wouldn't change
your code either so there is no (dis)advantage either way from the
perspective of writing code.

Except that your solution is using a lot more of the chip and
especially the routing resources.


If you want me to say it again... The configuration memory is loaded
from the config stream. This uses a significant number of transistors
and directly controls static signals in the logic elements and routing
matrix. Once configured, these elements do not change. The only
exception to this that I am aware of are the config elements in the
LUTs of a Xilinx device when used as a shift register. Otherwise they
are static and their construction is very different from the FFs in
the logic elements.

I'm not quite sure what you're getting at here, but it seems that
you're missing the fact that the configuration bitstream also contains
initial value contents of flops and memory (How do you think a read
only memory would get implemented? Discrete logic would work, but for
performance you might want to take advantage of the internal RAM
blocks that the FPGA has).

The configuration bitstream *doesn't* contain initial values for FFs.
You keep referring to memory. Memory is not the same as the logic
element FFs. Memory can be initialized by the configuration stream.
The LUTs can be initialized by the configuration stream. But the FFs
in the logic elements can only be initialized by the GSR. As I have
tried to explain, the GSR is ***always*** a part of release from
configuration. So there is no need for the extra transistors inside
the chip to make the FF state part of the configuration stream. If
you don't believe me, ask Peter Alfke. I bet he can clear this up.

I am happy to admit that I could be wrong about this. But I am very
confident I am not. I would be happy to hear Peter set the record
straight.


The FFs are initialized by the GSR which is routed to the set/reset
under control of the config memory. This logic *has* to exist in
order for the GSR to function even if you don't use it. Then to add
additional logic that will set the initial state of the FF on
configuration would be superfluous.

There is no additional logic to set the initial state of the FF on
configuration. It simply changes some zeros to ones in the
configuration bitstream.

So how do the zeros and ones in the bitstream get into the FFs???
That would require that the FF have a mux on the D input and that the
clock have a mux to clock it from the bitstream clock. Just think of
how much extra logic that would require on every FF in the design.


Have you seen anything that contradicts this? Can you cite a
reference? Just saying it is "the truth" is not really useful.

I believe I've said way more than just 'the truth' prior to this
post. Refer to the configuration guide for the device you're
interested in, or the Altera reference I provided earlier and/or
Altera's Quartus manual for what it has to say about initial values.

Does any of these docs actually say that the FFs are directly
controlled by the configuration bitstream or does it say that the FFs
can be initialized using the GSR signal with the set/reset *selected*
by the configuration stream???

I think you have been reading between the lines. But then I am more
familiar with the Xilinx parts than the innerds of the Altera parts.
Although, I will say that on the ACEX 1K parts, there was no
configuration loading of the FFs. The FFs were ***always*** reset by
the GSR and the tools would invert the use of the signal if you wanted
the initial state to be a 1.

Can you quote something that clearly says what you are saying?

Rick
.