Prev: Two PCIe Endpoints in one Virtex-6?
Next: what is the fmax of the simple dual port ram in the altera fpga
From: Nial Stewart on 11 May 2010 04:24
> 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...)


You shouldn't rely in this if you want your designs to be 'portable'.


You should also think about active reset logic for your design so that
you know everything will definitely power up to a known state. What
happens if you have a portion of your design you want to hold in reset
until something else is configured properly?

I have done this to allow a quick simulation of a module and
know that Quartus throws up a warning (although I'm not sure if it does actually
implement the reset value).

Bottom line is you need a reset mechanism in to set these values.



Nial.




From: Martin Thompson on 14 May 2010 04:53
rickman <gnuarm(a)gmail.com> writes:

> 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.

The point is that those assignments *are* used in synthesis by some
tools. XST does it for one. It makes no sense for an ASIC, but for
FPGAs which have a well defined startup condition defined by the
bitstream it makes eminent sense.

Now whether you want to take advantage of it depends on how portable
to ASIC you want your code to be

> 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.

That's another way of getting (part) of the FPGA back to it's
initialised state. But the RAMs will be potentially different. And
be aware that this signal is a) slow and b) connected to asynchronous
(p)reset ports on the FFs, so you can quite feasibly have parts of
your design coming out of reset in one clock cycle and others a tick
later if you assert the GSR willy-nilly.

And then you can do a "normal ASIC-like" reset explicit in your
logic... That is a fundamentally different thing - it's not
"initialisation", it's resetting. It's quite feasible to have a FF
which inits to '1' and has a reset signal to set it to '0'.

Personally I avoid the GSR. I create reset signals which are
synchronous to each of my clocks from a single async reset source and
distribute those to the flipflops that need them explicitly, and use
the synchronously.

I occasionally make use of the startup value of the FFs being
definable (in my resetn synchroniser for example!). I do arrange the
logic to work with them initialising to '0's however, as in the past
when synth tools didn't read the intialisation statements, it ensured
the simulation matched the "default" behaviour of the FPGA flops.

> The declaration assignment only sets the signal value on start up
> which is not the same thing, so it is just ignored.
>

IIRC it *is* the same thing - the INIT state of a FF in the bitstream
also defines its behaviour when the global set/reset (GSR) is
asserted.

> 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.
>

With modelsim you can set up a script to turn off the "numeric_std"
warnings about those states, run for 0 ns (or a few ticks if you need
to get your pipelines filled) and then turn them back on again so you
don't miss any others.

Cheers,
Martin

--
martin.j.thompson(a)trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
From: Alan Fitch on 14 May 2010 07:23
On 14/05/2010 09:53, Martin Thompson wrote:
> rickman<gnuarm(a)gmail.com> writes:
>
>> 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.
>
> The point is that those assignments *are* used in synthesis by some
> tools. XST does it for one. It makes no sense for an ASIC, but for
> FPGAs which have a well defined startup condition defined by the
> bitstream it makes eminent sense.
>
<snip>

Just one word of warning - I've been caught out by this using Mentor
Precision. Precision *does* support initialisation at declaration, but I
had to add an attribute to the (VHDL) code to make it happen.

Quartus and ISE seem be ok. Synplify seems to accept initialisations by
default (i.e. without extra attibutes).

I can't speak for other tools, but I know Synplify will even initialize
ROM contents by reading a file into a constant using a function.

> Now whether you want to take advantage of it depends on how portable
> to ASIC you want your code to be
>

Exactly.

I must admit, I still feel happier having a functional reset pin - and
if you have a functional reset pin then of course that won't use any
initial states, they'll only get applied when the bitstream is downloaded.

I suppose you could design a system where the reset procedure was to
download the bitstream, of course.

regards
Alan

--
Alan Fitch
Senior Consultant

Doulos � Developing Design Know-how
VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project
Services

Doulos Ltd. Church Hatch, 22 Marketing Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: + 44 (0)1425 471223 Email: alan.fitch(a)doulos.com
Fax: +44 (0)1425 471573 http://www.doulos.com

------------------------------------------------------------------------

This message may contain personal views which are not the views of
Doulos, unless specifically stated.
From: Martin Thompson on 17 May 2010 10:46
Andy Peters <google(a)latke.net> writes:

> 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?

Indeed so - given that getting "that out-of-whack" may have involved
(for example) a clock glitch - in which case corrupt BRAMs may be the
result (program code, state machines...), which can only be "reset" by
a bitstream load (or some kind explicit scrubbing in the design).

Cheers,
Martin

--
martin.j.thompson(a)trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.net/electronics.html
From: Nial Stewart on 17 May 2010 11:29
> The point is that those assignments *are* used in synthesis by some
> tools. XST does it for one. It makes no sense for an ASIC, but for
> FPGAs which have a well defined startup condition defined by the
> bitstream it makes eminent sense.
>
> Now whether you want to take advantage of it depends on how portable
> to ASIC you want your code to be


Or whether you want to have completely unpredictable/broken behaviour
if you decide to change FPGA vendors!



Nial.


 |  Next  |  Last
Pages: 1 2
Prev: Two PCIe Endpoints in one Virtex-6?
Next: what is the fmax of the simple dual port ram in the altera fpga