Prev: repeting outputs of counter
Next: Register Now: FPGA Camp Bangalore, INDIA. May'21
From: rickman on 13 May 2010 17:21
On May 11, 3:11 am, Christopher Head <ch...(a)cs.ubc.ca> wrote:
> On Mon, 10 May 2010 23:31:23 -0700 (PDT)
>
> backhus <goous...(a)googlemail.com> wrote:
>
> [snip]> Also you have no reset scheme, just default assignments in the
> > declarations.
> > Xilinx ISE can handle that, but other tools ignore it.
>
> [snip]
>
> Sorry for hijacking the thread, but... do you mean that if I write this
> code:
>
> signal foo : std_ulogic_vector(3 downto 0) := "1010";
>
> I would *not* normally expect the FPGA to power up with "1010" in the
> signal!? I've only ever worked with Xilinx FPGAs using ISE, so I
> assumed it worked everywhere; is this not the case? (kind of nice to
> know in case I do some day end up using a different make of FPGA...)
>
> Chris

I can't say for sure, but I think the reason *why* declaration
assignments are not used in synthesis is because they are not
associated with any sort of signal. If you want FFs in an FPGA to
initialize to a known state, this has to be done on the power up reset
which is normally done through a global Set/Reset signal. The
synthesis tools understand this signal and the fact that it can be
driven externally as well as by a power up reset. The declaration
assignment only sets the signal value on start up which is not the
same thing, so it is just ignored.

I find that to prevent warnings in functions like std_match I do need
declaration assignments so that there are no 'u'/'x'/'-' states in
buses at simulation startup when everything gets run. After that
signals have values according to the code. This can mask missing
reset assignments, but I believe the tools I am using give a warning
on such things, it's not a very loud warning. It often hides in all
the other warnings I need to ignore.

Rick
From: Andy Peters on 14 May 2010 18:40
On May 14, 4:23 am, Alan Fitch <alan.fi...(a)spamtrap.com> wrote:
>
> I suppose you could design a system where the reset procedure was to
> download the bitstream, of course.

I suppose it depends on the complexity of the design, but it seems to
me that if something's so out of whack that it needs an explicit reset
to get going again, perhaps a total system reset that includes
reloading the bitstream is in order?

-a
First  |  Prev  | 
Pages: 1 2
Prev: repeting outputs of counter
Next: Register Now: FPGA Camp Bangalore, INDIA. May'21