Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 134850

Article: 134850
Subject: Re: XST bug on illigal states of a FSM ?
From: Evan Lavelle <nospam@nospam.com>
Date: Wed, 03 Sep 2008 22:18:44 +0100
Links: << >>  << T >>  << A >>
On Wed, 03 Sep 2008 13:43:44 -0600, Kevin Neilson
<kevin_neilson@removethiscomcast.net> wrote:

>Evan Lavelle wrote:
>> On Wed, 3 Sep 2008 08:00:31 -0700 (PDT), tullio
>> <tullio.grassi@gmail.com> wrote:
>...
>> 
>> The good news is that your RTL works....
>> 
>> Now get a Verilog netlist out of  XST, and repeat the test with the
>> netlist rather than 'test1.v'. If the test now fails, XST is broken.
>> ...
>If XST doesn't pass the test, that doesn't mean it is broken in this 
>case.  An extracted FSM is not supposed to be identical to RTL.  That is 
>the whole idea of FSM extractors.  They take the RTL and recode it, 
>possible using a different encoding, and also removing logic related to 
>moving to a default state.  You can turn off the extractor, but you 
>wouldn't want to.

Can you back up the "also removing logic related to moving to a
default state"?

The original RTL is very specific; it describes what to do if the
state is not 001, 010, or 100 (which, BTW, requires a tiny amount of
logic). If the synthesiser doesn't do this, then it's broken.
Specifying a global one-hot option (which, IIRC, is the default
anyway) doesn't give the synth carte blanche to find any sequential
case statements and to remove the default branch.

Besides, how would XST know that this was an FSM anyway? If the docs
are to be believed, it needs to find a state register which is reset,
and (for Verilog) which is either "an integer or a set of defined
parameters". None of these conditions are true in this case.

Yes, if you have an identifiable state register, and you ask the synth
to recode it, then you can get differences in pre- and post-synth
simulation, *if* you expect specific values on your state register.
But, if you want the synthesiser to recode, your simulation should be
testing against enumerated or parameterised values anyway. That's not
the problem the OP is seeing here; he thinks he's losing logic.

Your counter example isn't relevant. Let's assume that the counters
actually are identical, and the synthesiser can determine that it's
impossible for either count1 or count2 to leave the range [0,135]. In
this hypothetical case, the synthesiser is permitted to change the
terminal count logic, *because the change is not observable*. The
synthesiser can do anything it wants, as long as the simulation
semantics of the original code is preserved, or you specifically
request a change in semantics - register retiming, state register
recoding, whatever. This is *not* true of the OP's case; the loss of
logic - if it has actually happened - has changed the behaviour of the
code.

-Evan

Article: 134851
Subject: Strange Spartan2 behaviour
From: nico@puntnl.niks (Nico Coesel)
Date: Wed, 03 Sep 2008 22:33:14 GMT
Links: << >>  << T >>  << A >>
I'm working on a Spartan2 design which runs on a PCI card or a PCI
Express card (through a PCI-express to PCI bridge chip). Besides the
PCI express or PCI interface the design is almost the same for both
boards.

In some specific type of PCs (mostly server chassis) the design quits
working right away or after a while. Some of the internal
statemachines quit even when the option 'Safe implementation' is
turned on. In most PCs (say 99.9%) the design works okay though. 

The timing is not very tight. The place&route report shows 8ns timing
margin on the 33MHz PCI clock which also clocks the internal logic. So
I suspect no problems there. 

On the PCI board the Spartan2 is powered by a LM1086 1.5A linear
regulator, on the PCI Express board the Spartan2 is powered by the
PC's 3.3V directly. Core power (2.5V) is provided by another LM1086
regulator. Bypassing consists of 4 4.7uf tantalum caps (2 for 2.5V and
2 for 3.3V) and about 10 100nf ceramic caps (0805 or 0603) again half
for 3.3V and the other half for 2.5V. The PCB is a 4 layer board with
power and ground planes.

Someone already implemented some safeguards around the statemachines
as a quick hack which seems to work. This more or less rules out
corruption of the configuration bits.

Any ideas where to look for? 

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Article: 134852
Subject: Re: Strange Spartan2 behaviour
From: Mike Treseler <mtreseler@gmail.com>
Date: Wed, 03 Sep 2008 15:59:41 -0700
Links: << >>  << T >>  << A >>
Nico Coesel wrote:

> In some specific type of PCs (mostly server chassis) the design quits
> working right away or after a while. 

> Any ideas where to look for? 

unregistered inputs
latch warnings
missing external timing constraints

      -- Mike Treseler

Article: 134853
Subject: Re: what is the maximum number of DDR controllers
From: ghelbig <ghelbig@lycos.com>
Date: Wed, 3 Sep 2008 16:43:00 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 3, 12:10=A0am, Qingbo <qing...@gmail.com> wrote:
> one can generate on a Virtex-5 device?
>
> Thanks,
> Qingbo

I would think that the number of available DLLs would be the limiting
factor.  That, and (as Brian mentioned) the number of I/O pins.

G.

Article: 134854
Subject: Re: Inferring dual-port RAM in Spartan-3A Starter Kit FPGA?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 04 Sep 2008 01:22:07 +0100
Links: << >>  << T >>  << A >>
On Wed, 3 Sep 2008 09:18:32 -0700 (PDT), "jack.harvard@googlemail.com"
<jack.harvard@googlemail.com> wrote:

>On 3 Sep, 16:54, John_H <newsgr...@johnhandwork.com> wrote:
>> On Sep 3, 7:21 am, "jack.harv...@googlemail.com"<jack.harv...@googlemail.com> wrote:
>>
>> <snip>> Dual-port RAM support is only for Virtex-2 Pro families and newer, and
>> > is not intended for older devices. If you target one of the newer
>> > devices, the correct type of RAM is inferred.
>>
>> <snip>
>>
>> What device are you working with?  V2Pro is getting a bit long in the
>> tooth by now.
>
>It's a Spartan3A.

Which is younger than the V2Pro.
The AR# you gave referred to the Spartan-2 family.
You may still be in luck.

But it's only worth pushing on that rope for so long. Then concede
defeat; save time and instantiate the primitive component directly.

- Brian


Article: 134855
Subject: Re: Strange Spartan2 behaviour
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 04 Sep 2008 01:30:46 +0100
Links: << >>  << T >>  << A >>
On Wed, 03 Sep 2008 22:33:14 GMT, nico@puntnl.niks (Nico Coesel) wrote:

>I'm working on a Spartan2 design which runs on a PCI card or a PCI
>Express card (through a PCI-express to PCI bridge chip). Besides the
>PCI express or PCI interface the design is almost the same for both
>boards.
>
>In some specific type of PCs (mostly server chassis) the design quits
>working right away or after a while. Some of the internal
>statemachines quit even when the option 'Safe implementation' is
>turned on. In most PCs (say 99.9%) the design works okay though. 
>
>The timing is not very tight. The place&route report shows 8ns timing
>margin on the 33MHz PCI clock which also clocks the internal logic. So
>I suspect no problems there. 

Have you confirmed that the PCI clock is actually 33MHz?

On some machines (mostly server motherboards) PCI can be switched to
66MHz (or 100 or 133 for PCI-X). I have observed a machine booting at
33MHz and switching to 66MHz during the BIOS startup (it was
controllable via a BIOS setting).

- Brian

Article: 134856
Subject: Re: need fast FPGA suggestions
From: przemek klosowski <przemek.klosowski@gmail.nospam>
Date: Thu, 04 Sep 2008 02:48:41 GMT
Links: << >>  << T >>  << A >>
On Tue, 26 Aug 2008 15:24:49 -0700, Andrew FPGA wrote:
> I can see how to get to 220MHz, but beyond that I don't
> know. The longest carry chain is 10 bits.
> 

Everybody is assuming an arithmetic counter with carrys, but that
can be worked around. It's possible to implement the counter using
something carry-less and very fast, e.g. a LFSR; the counting is
a little complicated and has to be done offline (effectively it
involves a discrete logarithm calculation, but it's doable for some
LFSRs). I think the original application allows for calculating the 
target count offline.

-- 
		Przemek Klosowski, Ph.D. <przemek.klosowski at gmail>

Article: 134857
Subject: Re: XST bug on illigal states of a FSM ?
From: gael.paul@gmail.com
Date: Wed, 3 Sep 2008 21:13:03 -0700 (PDT)
Links: << >>  << T >>  << A >>
Evan,

XST isn't broken, and the FSM optimization is legit. In fact, every
commercial FPGA synthesis tool (Synplify, Precision, QIS, XST, etc)
will perform the same FSM optimization, unless explicitly instructed
not to (typically by tagging the FSM as 'safe').

What we're looking at is called 'dead code elimination'. The synthesis
tools performs a boolean reachability analysis on the state register.
In the Verilog code, there is *no* assignment that ever assigns a
value other than 001, 010, and 100 to the state register. Within the
Verilog semantic, the state register will *never* reach any value
other than these 3. The default clause is thus rightfully ignored and
no 'recovery' logic is generated. As a matter of fact, in absence of
SEUs, your design will *never* get into any other state than these 3.
From a Verilog semantic standpoint, the RTL and the synthesized
netlist are fully equivalent. One can certainly complain that the
Verilog (and VHDL) semantic have no room for SEUs, but that's the way
it is.

Note that this optimization is orthogonal to the state encoding. Also,
while this optimization is frequent for FSMs, it actually also applies
to random logic, although the reachability analysis is often more
difficult to perform.

 - gael


Article: 134858
Subject: Re: Strange Spartan2 behaviour
From: Jochen <JFrensch@harmanbecker.com>
Date: Thu, 4 Sep 2008 00:11:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
We had an issue with a "ground bounce" (Spartan3 design) in the bank
containing the PCI-interface, which 'triggered' the asynchonous reset
of the PCI-core...

Do you use async resets ?

/Jochen

Article: 134859
Subject: Re: XST bug on illigal states of a FSM ?
From: Evan Lavelle <nospam@nospam.com>
Date: Thu, 04 Sep 2008 08:40:01 +0100
Links: << >>  << T >>  << A >>
Gael -

I hadn't noticed the initial condition on the register, so I missed
this; my apologies to X for casting aspersions.

The OP's original question was "is there a more formal way to prove it
[to confirm that the RTL and netlist are different]". In this case, he
probably has to do it by simulation, since formal analysis is likely
to show no difference, so the TB is still required to show that a
transformation has taken place. Still, a useful reminder of the
pitfalls of comparing pre- and post-synth results.

-Evan


Article: 134860
Subject: Re: Open source licenses for hardware
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 04 Sep 2008 09:40:37 +0200
Links: << >>  << T >>  << A >>
Jon Beniston wrote:
>>  The choice of the GPL
>> for the OpenSparc is similar - it effectively restricts its use to
>> evaluation and academic work
> 
> Not if they used the LGPL, it isn't.
> 

They use the GPLv2, not the LGPL.

One other point that I did not mention earlier for both GPL'ed code and 
LGPL'ed code is that it is perfectly possible to make and sell devices 
that use GPL'ed IP - as long as *all* the IP in the device is GPL'ed.

I think it is very reasonable to say that the bitstream for a single 
FPGA device is a single "work", and that the license for that "work" is 
not affected by the licenses of any other "work", including other FPGA 
designs and software running on the FPGA, at least as long as you are 
talking about a complete design with a specific interface.

Thus it is quite possible to use, for example, the OpenSparc 
commercially in an FPGA - as long as the rest of your code on the same 
device is also GPL'ed.  When the GPL'ed IP already forms a major part of 
your design, this will make perfect sense.  The trouble only comes if 
you want most of your design to have a closed source license, with only 
parts of it under the (L)GPL.


The main difference between the LGPL and GPL is commonly summarised as 
saying that you can dynamically link code of any license with LGPL'ed 
code.  You can't statically link non-(L)GPL'ed code with LGPL'ed code. 
This has been discussed and argued back and forth in the world of 
embedded software for years before it was a major topic in FPGA design, 
and the conclusion is that very few embedded software developers will 
touch LGPL'ed code unless they are happy with a completely open source 
program, or their system is large enough to support a more general OS 
with dynamic linking (such as an embedded Linux system) - for statically 
linked software, the LGPL and GPL are the same.  Since placing and 
routing in an FPGA is directly equivalent to static linking in software, 
I can't see that there is any distinction between them.

Some links showing other people's opinions on the use of the LGPL in 
embedded software:

<http://lists.kde.org/?l=kde-policies&m=103813752610289&w=2>
<http://listas.apesol.org/pipermail/sdl-libsdl.org/2006-January/053814.html>


Article: 134861
Subject: Re: Strange Spartan2 behaviour
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 04 Sep 2008 08:55:27 +0100
Links: << >>  << T >>  << A >>
On Wed, 03 Sep 2008 22:33:14 GMT, nico@puntnl.niks (Nico Coesel)
wrote:

>In some specific type of PCs (mostly server chassis) the design quits
>working right away or after a while. Some of the internal
>statemachines quit even when the option 'Safe implementation' is
>turned on. In most PCs (say 99.9%) the design works okay though. 

Random data point from the mediaeval era:  I had almost identical
symptoms with a video processing card, about 15 years ago, in 
ISA bus.  I eventually tracked it down to glitches on the bus 
reset line, so narrow that all the old-style ISA cards missed
it, but the fast-ish FPGAs on my board would sometimes see it.

I don't suppose it's the same issue for you.  But it's weird
how this kind of thing rears its head from time to time.
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

Article: 134862
Subject: EDK frequency problem
From: fmostafa <fatma.abouelella@ugent.be>
Date: Thu, 4 Sep 2008 01:21:11 -0700 (PDT)
Links: << >>  << T >>  << A >>
hi every body,

Iam using EDK 9.2 in a small project for the uart  , and i started the
project with 100 mhz for the processor and 50 mhz for buses , and i
want to change the frequency for the buses to 66 mhz , i did this
before for 33 mhz , but in the case of 66 mhz nothing work, all i did
i change the C_CLKDV_DIVIDE  to 1.5 instead of 2 and the uart
frequency to 66666667 instead of 50000000
and the  c_plb_clk_period_ps to 14999 instead of 20000 , is there
anything else i have to change

thanks
FATMA

Article: 134863
Subject: Re: XST bug on illigal states of a FSM ?
From: gael.paul@gmail.com
Date: Thu, 4 Sep 2008 01:37:26 -0700 (PDT)
Links: << >>  << T >>  << A >>
Evan,

Formal verification (Logic Equivalence Checking) will indeed declare
the RL and post-synthesis netlist equivalent. Simulation will also
produce the same outputs, unless the state register is manually put
into a 'illegal' state using a force command, as suggested and
demonstrated by you and other posters. Unfortunately, these cases are
only identifiable through log file inspection and schematic
inspection. Synplify's log file specifically warns when others/default
clause are ignored. In addition, Synplify features a message viewer
with filtering capabilities. This allows thorough users to build once
for all a filter that zooms in on important messages, without
scrolling through hundreds of messages.

I would also take the opportunity to suggest inserting a reset signal
in this FSM. If it wasn't for the initial value, and its automatic
translation to an INIT property by the synthesis tool, the FSM would
most likely be stuck for ever... In general, I don't recommend relying
on power-up initialization. Such implicit code is hardly portable, and
incompatible with 'safe' designs; resolving a lock-up would require a
complete power cycle, including configuration. I find the absence of
reset in this FSM paradoxal since the original poster was concerned
with illegal state arising from SEUs ;~)

- gael



Article: 134864
Subject: Re: Open source licenses for hardware
From: Jon Beniston <jon@beniston.com>
Date: Thu, 4 Sep 2008 02:02:51 -0700 (PDT)
Links: << >>  << T >>  << A >>

> > Not if they used the LGPL, it isn't.
>
> They use the GPLv2, not the LGPL.

Yep - my mistake.

> The main difference between the LGPL and GPL is commonly summarised as
> saying that you can dynamically link code of any license with LGPL'ed
> code. =A0You can't statically link non-(L)GPL'ed code with LGPL'ed code.
> This has been discussed and argued back and forth in the world of
> embedded software for years before it was a major topic in FPGA design,
> and the conclusion is that very few embedded software developers will
> touch LGPL'ed code unless they are happy with a completely open source
> program, or their system is large enough to support a more general OS
> with dynamic linking (such as an embedded Linux system) - for statically
> linked software, the LGPL and GPL are the same. =A0Since placing and
> routing in an FPGA is directly equivalent to static linking in software,
> I can't see that there is any distinction between them.

So partial reconfiguration in an FPGA to load the the LGPLed code
would be ok?

Jon

Article: 134865
Subject: Hide VHDL code.
From: Pablo <pbantunez@gmail.com>
Date: Thu, 4 Sep 2008 02:24:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
I am trying to use XST to create a "black box" from a VHDL core. The
output NGC file fails when I try to include it in a Xilinx ISE design.
Does anyone know the way to create a black box from a file.vhd?

best regards.

Article: 134866
Subject: Re: XST bug on illigal states of a FSM ?
From: tullio <tullio.grassi@gmail.com>
Date: Thu, 4 Sep 2008 02:48:23 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thanks to all answers. I had never appreciated that the verilog
default clause is ignored unless I turn on the "safe"  synthesis
option.
So in fact I don't need to prove that the machine does not recover
from illigal states, because recovering is not guaranteed without
"safe" option.
Maybe the last comment from Gael is the most relevant to my case. In
fact in the real hardware I observe a mis-behavior
compatible with an illigal state immediately after FPGA configuration
(about 1 time in 600 cycles), as if the initial value is not set
properly.
I often have FSMs that don't need any external reset and I have not
coded it to save resouces.
I guess I will either add a reset and/or explicitly code the unwanted
states as suggested by Jim.
I'll post the results.

 Tullio


On 4 sep, 10:37, gael.p...@gmail.com wrote:
> ...
>
> I would also take the opportunity to suggest inserting a reset signal
> in this FSM. If it wasn't for the initial value, and its automatic
> translation to an INIT property by the synthesis tool, the FSM would
> most likely be stuck for ever... In general, I don't recommend relying
> on power-up initialization. Such implicit code is hardly portable, and
> incompatible with 'safe' designs; resolving a lock-up would require a
> complete power cycle, including configuration. I find the absence of
> reset in this FSM paradoxal since the original poster was concerned
> with illegal state arising from SEUs ;~)
>
> - gael


Article: 134867
Subject: Re: XST bug on illigal states of a FSM ?
From: Gael Paul <gael.paul@gmail.com>
Date: Thu, 4 Sep 2008 03:42:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
Tullio,

> I had never appreciated that the verilog default clause
> is ignored unless I turn on the "safe" =A0synthesis option.
This statement is too broad. I would modify it by saying that
"unreachable default clauses are ignored by synthesis tools".

If the default clause is part of an FSM, then one can force the
synthesis tool to implement recovery logic by tagging the FSM as
'safe' (exact syntax varies from tool to tool). The actual recovery
circuitry will vary from tool to tool, but in most cases it will put
the FSM back into its reset/initial state. Note that this still does
*not* implement the actual default clause (which could point to any
legal state, and possibly set some output indicating an SEU has
happened). To implement the actual default clause, you would need to:
 - use an enumerated type for the state vector, explicitly declaring
all illegal states (the numer of which will depend on the desired
encoding scheme)
 - turn off FSM extraction (locally or globally)
 - for some tools, set an attribute that disables sequential
optimization for the state register

> So in fact I don't need to prove that the machine does not recover
> from illigal states, because recovering is not guaranteed without
> "safe" option.
Correct.

> Maybe the last comment from Gael is the most relevant to my case. In
> fact in the real hardware I observe a mis-behavior
> compatible with an illigal state immediately after FPGA configuration
> (about 1 time in 600 cycles), as if the initial value is not set
> properly.
> I often have FSMs that don't need any external reset and I have not
> coded it to save resouces.
> I guess I will either add a reset and/or explicitly code the unwanted
> states as suggested by Jim.
So, your search for recovery logic was in fact a workaround for a
hardware misbehavior. Adding a reset will surely resolve your problem.
I guess your intermittent problem demonstrates that power-up
initialization is not 100% reliable.

 - gael


Article: 134868
Subject: Re: XST bug on illigal states of a FSM ?
From: "KJ" <kkjennings@sbcglobal.net>
Date: Thu, 4 Sep 2008 07:15:47 -0400
Links: << >>  << T >>  << A >>

"tullio" <tullio.grassi@gmail.com> wrote in message 
news:e8e8899d-614f-4021-ab60-056545c3d260@b30g2000prf.googlegroups.com...
> So in fact I don't need to prove that the machine does not recover
> from illigal states, because recovering is not guaranteed without
> "safe" option.

As pointed out previously though, 'recovery' is usually hiding a symptom of 
the real underlying problem and even if the state machine 'recovers' the 
things that depend on it may not.

> In
> fact in the real hardware I observe a mis-behavior
> compatible with an illigal state immediately after FPGA configuration
> (about 1 time in 600 cycles), as if the initial value is not set
> properly.

This is a timing problem, the most likely cause is a setup time violation on 
some input relative to the clock when you're coming out of reset.  For 
example, what do you have in your design to protect you for when the part 
finishes configuration?  The end of configuration is generally totally 
asynchronous to any free running oscillator clock input that you may have to 
the design.  Unless the input clocks to the design are stopped during and 
slightly after configuration it is darn near impossible to bring the part 
reliably out of configuration and into a working state.  That's the reason 
that the first task of the design is to generate a synchronized internal 
reset to the rest of the design and THEN start doing it's thing.

1 in 600 failures is almost always a symptom of timing problems, find that 
to fix your design.  The other possible cause of such seemingly random 
function is power supply issues.

> I often have FSMs that don't need any external reset and I have not
> coded it to save resouces.

It's a false savings...and this design is an example of why that is.

> I guess I will either add a reset and/or explicitly code the unwanted
> states as suggested by Jim.

I'd suggest getting to the root cause of your design issue (it's not whether 
the state machine is 'safe' or not), it's most likely timing and the lack of 
a synchronized reset.  Otherwise, you're just guessing and coming to 
incorrect conclusions that 'seem' to work this time but will fail you next 
time (just like the way that the lack of designing in a reset as a general 
practice has failed you on this design).

Good luck,

Kevin Jennings 



Article: 134869
Subject: Re: Hide VHDL code.
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Thu, 04 Sep 2008 13:36:34 +0100
Links: << >>  << T >>  << A >>
On Thu, 4 Sep 2008 02:24:50 -0700 (PDT), Pablo <pbantunez@gmail.com>
wrote:

>I am trying to use XST to create a "black box" from a VHDL core. The
>output NGC file fails when I try to include it in a Xilinx ISE design.
>Does anyone know the way to create a black box from a file.vhd?
>
>best regards.

First thing to check is that the output NGC file was synthesised without
I/O buffers on its internal ports. There are synthesis options for this.

That would certainly cause it to fail when included in another design...

- Brian

Article: 134870
Subject: Re: Open source licenses for hardware
From: David Brown <david@westcontrol.removethisbit.com>
Date: Thu, 04 Sep 2008 14:48:43 +0200
Links: << >>  << T >>  << A >>
Jon Beniston wrote:
>>> Not if they used the LGPL, it isn't.
>> They use the GPLv2, not the LGPL.
> 
> Yep - my mistake.
> 
>> The main difference between the LGPL and GPL is commonly summarised as
>> saying that you can dynamically link code of any license with LGPL'ed
>> code.  You can't statically link non-(L)GPL'ed code with LGPL'ed code.
>> This has been discussed and argued back and forth in the world of
>> embedded software for years before it was a major topic in FPGA design,
>> and the conclusion is that very few embedded software developers will
>> touch LGPL'ed code unless they are happy with a completely open source
>> program, or their system is large enough to support a more general OS
>> with dynamic linking (such as an embedded Linux system) - for statically
>> linked software, the LGPL and GPL are the same.  Since placing and
>> routing in an FPGA is directly equivalent to static linking in software,
>> I can't see that there is any distinction between them.
> 
> So partial reconfiguration in an FPGA to load the the LGPLed code
> would be ok?
> 

That would be fine, as far as I can tell.  The idea is that the end user 
should be able to get hold of the source code for the LGPL'ed part, 
modify it (or get an updated version), and use that modified version in 
the complete system.  If you can arrange for that to be possible using 
partial reconfiguration, that should be okay.

Article: 134871
Subject: Re: Quartus II priority 19 under Linux
From: "H. Peter Anvin" <hpa@zytor.com>
Date: Thu, 04 Sep 2008 07:18:35 -0700
Links: << >>  << T >>  << A >>
David Brown wrote:
> Petter Gustad wrote:
>> Why does Quartus run with lowest priority level (19) under Linux? It
>> also seems like if you nice quartus_sh to some higher priority when
>> you start it the sub-processes (like qartus_map etc) will still have
>> priority 19. I find this a little odd. Is there a reason for this?
>>
> 
> I'd imagine the idea is that you can continue working with other 
> programs while the long-running processes run in the background.  Modern 
> Linux kernels typically have schedulers that automate this (giving 
> higher priority to short-running interactive processes), but there is no 
> harm in running something like Quartus at low priority unless you are 
> simultaneously running another process that tries to use all available 
> processing time.

It really hurts you if you have server machines with "cycle-scraper" 
processes (often verification jobs) that administratively have lower 
priority than Quartus.

You want to be able to control this behaviour.

	-hpa

Article: 134872
Subject: Re: FPGA on a DIMM module, performing encryption
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Thu, 4 Sep 2008 14:18:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
MikeWhy (boat042-nospam@yahoo.com) wrote:
: <randomdude@gmail.com> wrote in message 
: news:fdde256c-a1dd-4e7c-bae5-3f7b949f7004@x41g2000hsb.googlegroups.com...
: > My main idea at the moment is an encrypting DIMM module, intended to
: > protect against 'cold boot' attacks, and the scenario that an attacker
: > is presented with a freshly-turned-off machine with some juicy secret
: > still in a DIMM module, which they can then remove, throw in to some
: > socket, and dump.

: Perhaps the first order of business is to establish that this is a viable 
: attack.  Can someone really do that? SDRAM refresh cycles are on the order 
: of <10 usec, otherwise data would be lost. I would think much simpler and 
: more severe "attacks" would be available once you gained physical control of 
: the machine. Cutting out the living and still beating heart idea tops them 
: all in complexity.

SDRAM can last a surprisingly long time - I have a board that stores an 
image in some, and if you turn it off for a few mins and turn it back on, 
the image is still recognisable - if badly corrupted.  Corruption starts 
within microsecconds but isn't instant or total.

Regards
Chris

Article: 134873
Subject: Re: Is it possible to do incremental synthesis and placement?
From: ajwitz <horowitz@ibiquity.com>
Date: Thu, 4 Sep 2008 07:26:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sep 3, 5:01=A0pm, Marvin <marvin....@gmail.com> wrote:
> Svenn,
>
> Try using SmartGuide for incremental place and route.
>
> http://toolbox.xilinx.com/docsan/xilinx9/help/iseguide/html/ise_using...
>
> On Sep 2, 10:09=A0am, Mike Treseler <mtrese...@gmail.com> wrote:
>
>
>
> > Svenn Are Bjerkem wrote:
> > > In a fairly large design I am doing some debugging on the system boar=
d
> > > directly. When I discover a mistake and modify the vhdl code, the
> > > whole design goes through synthesis and place-and-route. Many parts o=
f
> > > the design are never touched by my modifications, and I wonder if it
> > > is possible to speed up the debug-modify-compile
>
> > I finish the debug-modify-compile loop in simulation.
> > Even though simulation requires significant time on the front end,
> > debugging typos and changes is quick and straightforward.
>
> > =A0 =A0 =A0 =A0-- Mike Treseler- Hide quoted text -
>
> - Show quoted text -

SmartGuide might work for you but using partitions is a better
approach - SmartGuide does not always work and the tool can redo P&R
for all the modules since it just uses the previous run as a guide...


Article: 134874
Subject: Re: XST bug on illegal states of a FSM ?
From: Mike Treseler <mtreseler@gmail.com>
Date: Thu, 04 Sep 2008 08:00:57 -0700
Links: << >>  << T >>  << A >>
KJ wrote:

> As pointed out previously though, 'recovery' is usually hiding a symptom of 
> the real underlying problem and even if the state machine 'recovers' the 
> things that depend on it may not.

Yes. That is the main point.
I would call this attribute "clean" rather than "safe".

A counter is "safe" in the sense that
any forced value will eventually be returned to zero.
But that doesn't mean that a controller
waiting on some count will work acceptably
in the event of such an upset.

As Kevin explains, if this upset is happening
on the bench, a design error is a more
likely cause than gamma rays.


       -- Mike Treseler




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search