Re: Mixed clocked/combinatorial coding styles
- From: rickman <gnuarm@xxxxxxxxx>
- Date: Thu, 21 Aug 2008 09:53:36 -0700 (PDT)
On Aug 21, 9:19 am, KJ <kkjenni...@xxxxxxxxxxxxx> wrote:
On Aug 21, 8:32 am, rickman <gnu...@xxxxxxxxx> wrote:
On Aug 21, 2:01 am, Kim Enkovaara <kim.enkova...@xxxxxx> wrote:
Of course with FPGAs also initial values can be used and then no reset
is connected to the FF. The initial value comes from the configuration
file in that case.
But this requires the global set reset signal. That is how the FFs
get their initial state.
No, implementing an initial value does not require *any* signal in the
design source files. Maybe we're delving into an area where the tools
that you're using don't (or you think they don't) support initial
values in the source code or something and in order to get those
intial values that tools requires you to code it as if it was an async
reset.
If xyz is a flip flop output and one can say...
signal xyz: std_ulogic := '1';
and signal xyz gets initialized at configuration time then the tools
support the VHDL language standard as it applies to defining initial
values.
If instead you have to say...
if (Reset = '1') then
xyz <= '1';
...
in order to get xyz initialized at configuration time then the tools
do not support the VHDL language standard as it applies to defining
initial values and the above code is the work around that might
help...but still it's a work around to a tool limitation, not some
fundamental principle.
I am not aware that initial values of signals is part of a VHDL
standard for synthesis. In fact, I was under the impression that
there is no "standard" for what parts of the language were supported
for synthesis. Am I wrong about this? Are initial value assignments
a required construct for synthesis support? I know they have not been
historically.
own signal, but it is active regardless of your code. But if you want
to control the state of the FF on power up, then you need to use a
register template with an async reset.
Not always. You can also use the FFs without any reset and give initial
values for the signals. Most synthesizers can transfer those values
to configuration image.
I don't think this is the rule. If you want to write portable code,
you need to use a reset as part of the clocked process.
Not really. If you're talking about portability to tools that don't
support initial value specification then you could still find yourself
at the mercy of having to supply an external I/O pin to ultimately
give you the reset at the end of configuration. Now this tool
limitation work around is requiring additional PCBA support that would
not otherwise be required.
If you want your part to come out of configuration cleanly, then you
have to provide a way to synchronizing the end of the internal reset
to the system clock. I have yet to find a way to do this without
proving that external reset pin, even if it is just tied high (or
low).
Maybe the perceived problem of synchronizing the end of reset is a red
herring. I have never seen a problem with it. But if you consider
how FSM and counters work, it is entirely possible that they will not
start up properly when reset in the default async manner.
Obviously all this only applies to devices that have a defined powerup/
end configuration state available but which *tools* don't support
initial value specification now-a-daze?
That has been a large number of tools and FPGA devices by my
experience. Can you state that there are no tools that don't support
this feature?
Rick
.
- Follow-Ups:
- References:
- Mixed clocked/combinatorial coding styles
- From: Jonathan Bromley
- Re: Mixed clocked/combinatorial coding styles
- From: rickman
- Re: Mixed clocked/combinatorial coding styles
- From: Jonathan Bromley
- Re: Mixed clocked/combinatorial coding styles
- From: rickman
- Re: Mixed clocked/combinatorial coding styles
- From: KJ
- Re: Mixed clocked/combinatorial coding styles
- From: rickman
- Mixed clocked/combinatorial coding styles
- Prev by Date: Re: Mixed clocked/combinatorial coding styles
- Next by Date: Re: Mixed clocked/combinatorial coding styles
- Previous by thread: Re: Mixed clocked/combinatorial coding styles
- Next by thread: Re: Mixed clocked/combinatorial coding styles
- Index(es):
Relevant Pages
|