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 107425

Article: 107425
Subject: Re: Spartan-4 ?
From: John_H <johnhandwork@mail.com>
Date: Mon, 28 Aug 2006 14:04:16 GMT
Links: << >>  << T >>  << A >>
Antti wrote:
> New low cost families other than from Xilinx are known to be coming
> this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> an Spartan-4 yet, is there a hope at all that there will be modern low
> cost family from Xilinx too?
> 
> Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> Spartan-3E only has small members, eg not replacement for S3
> 
> so we have vacuum in the place of Spartan-4 !
> 
> I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4
> coming this autumn?
> 
> Antti

I don't know about positioning but

http://tinyurl.com/fvup6

(or 
http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=23856)

Article: 107426
Subject: Re: Style of coding complex logic (particularly state machines)
From: "rickman" <gnuarm@gmail.com>
Date: 28 Aug 2006 07:23:16 -0700
Links: << >>  << T >>  << A >>
KJ wrote:
> rickman wrote:
> > The fanout of an async reset in an FPGA is not an issue because the
> > signal is a dedicated net.
> My point was that if timing is not met due to the large fanout, that
> the typical fitter will allow for the fanout to be limited by the user
> if necessary.  But to directly answer the original question, 'no' I
> haven't had reset signal fanout as a problem but if I did I know I
> could fix it by limiting the fanout on the fitter side without having
> to change the source code.  But I also tend to reset only those things
> that really need resetting which, by itself, cuts down on the fanout as
> well.

I don't know exactly what you mean by fanout.  If a sync reset has to
go to 100 FFs, then there is nothing you can do to tell the fitter to
change that.  The async reset is free, or actually already paid for, so
if it does the job why not use it?


> > That is what I addressed above.  Whether the circuit will malfunction
> > depends on the circuit as well as the inputs preset.  It is often not
> > hard to assure that one or the other prevents the circuit from changing
> > any state while the reset is released.
> >
> But simply synchronizing the reset in the first place will do that as
> well...two different approaches to the problem, each equally valid.

Both valid, but typically I find the async reset takes less effort and
resources.  Only a small portion of my typical design has to be
controlled coming out of reset.


> Agreed, but one can also view these locally generated resets as simply
> synchronized versions of the original reset.  In fact, the synthesizer
> would probably do just that seeing that you have (for example) 4 places
> throughout the design where you've generated a local reset which is
> simply the raw reset signal brought into a flip flop chain (I think
> that's what you're describing).  So it would take those four instances
> and probably generate a single shift chain and local reset signal to
> send to those 4 places.  So all you've really done is written the
> source code for the local reset 3 more times than is needed.  Had you
> taken the view that the reset input to those 4 places must be a
> synchronized reset signal in the first place you probably would've
> written the reset shift chain logic one time at a top level and
> connected it up to those four inputs yourself and not written it on the
> receiver side.

Yes, that is exactly how I think of it, a local sync'd reset.  Putting
it where it is needed is both very clear and saves resources.  I never
use this in place of the async reset, but rather to supplement it for
synchronization.  Much of the logic has to be reset, but very little of
it has to be synchronously released from reset.


> > This is not a problem when you use the dedicated reset net.
> I agree, but I was referring more to the reset signal distribution on a
> board rather than inside an FPGA.

I understand, but noise still can upset a sync reset.  This is just not
a workable solution to noise.


> > Even though there are FFs that do not need a reset, it does not hurt to put
> > the entire device in a known state every time.
> OK, it doesn't 'hurt', but it doesn't 'help' either in the sense that
> both approaches would meet the exact same requirements of the
> functional specification for that part.

I don't agree.  By globally resetting the device, you have handled all
FFs so that if your requirement misses one, you don't find out about it
after the unit is in the field.


> > It is not hard to miss a FF that needs to be reset otherwise.
> Inside the FPGA it doesn't matter since if you discover something that
> you now realize needs to be reset you re-route and get a new file.  Not
> routing it to a part on a board and then discovering you need it is a
> bit more of an issue.  Resolving that issue by routing reset to every
> part and then using it asynchronously is where problems have come up
> when there are a lot of parts on the board.

The question is when do you find out about the missing reset?  It is
easy for this sort of thing to slip totally through testing and only
show up in the users's hands.


> > Personally I think the noise issue is a red herring.
> If it's a red herring than I can safely say that I have slayed several
> red herrings over my career...but actually not many of late....not
> since a certain couple designers moved on to to greener pastures to be
> brutally honest.

I assume you mean board designers who were not producing quiet boards?


> > If you have noise
> > problems on the board, changing your reset to sync will not help in
> > general.  You would be much better off designing a board so it does not
> > have noise problems.
> Maybe.  But remember the scenario when you're brought in to fix a
> problem with an existing board that you trace back to some issue with
> reset.  In that situation, a programmable logic change is more likely
> the more cost effective solution.

I am in a fairly long thread in comp.arch.embedded about how to design
boards so that you don't have SI and EMI issues.  I think this sort of
problem should be dealt with before you make the board, not after it is
in the field.  Too many engineers learn to cover their butts rather
than to produce good designs.  I am tired of working that way and not
really knowing if my design will work before it is shipped.  The one
universal rule I learned very early on is that you can not prove a
product works correctly by testing.  It has to be designed to work
correctly by using design methods based on understanding what you are
doing.  I have never seen a board noise issue that could be fixed by an
FPGA design change.


Article: 107427
Subject: EDK 6.3 project file growth
From: =?ISO-8859-15?Q?Michael_Sch=F6berl?= <MSchoeberl@mailtonne.de>
Date: Mon, 28 Aug 2006 16:30:41 +0200
Links: << >>  << T >>  << A >>
Hi ...

I had an EDK project which took longer and longer to load. In the 
begining this was tolerable as there were not many changes but this got 
worse and finally the project took over 1 hour to load.


I found out that my .xmp project file has grown to 12 MBytes (containing 
the same lines with LockAddr: again and again). Deleting most of those 
lines helped but the file started to grow again!

what is wrong with that? how can I stop this? ... did anyone at Xilinx 
ever use their tools for a real project?


bye,
Michael

Article: 107428
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Aug 2006 07:33:28 -0700
Links: << >>  << T >>  << A >>
Rick,

Via in pad (basically no trace) is best.  Placement is not critical, as
long as you have via in pad, and planes.

But even so, the diameter of the vias, and their lengths can be
critical, and still be the dominant factor.

It is all about the lop that is formed (see the HK sparse chevron
presentations, as I think he said it best).

Do you need a broad low impedance?  I would say that it is most unusual
that a pcb has to work over all frequencies.  The system is usually
designed with a finite number and range of clocks (33 MHz, 266 MHz, 78
MHz, for example).  I would counter that rather than a flat broad low
impedance, you could do better to target just the frequencies you care
about.

High loss/low loss is a red herring:  I have never seen a case where the
type of capacitor made any difference at all.  I would be interested if
anyone has made a board where high loss/loss loss caps actually made a
measurable difference,

Austin

rickman wrote:
> Austin Lesea wrote:
>> To the subject at hand:  placing additional caps across existing caps
>> does not reduce the noise (unless the dominant cause is lack of adequate
>> capacitance).
>>
>> The reason why the noise is bad is that the L (as in Ldi/dt) is most
>> likely the largest, and most dominant factor, in the form of the via and
>> traces to the bypass capacitor.
>>
>> Many times people have placed additional caps on top of the the existing
>> caps and wondered why the noise is not reduced:  well, you did not
>> change the L in the equation, did you.  So why did you expect V to change?
>>
>> You may have moved the resonant frequency (more often not), but often
>> people make the mistake of assuming that a 0.1uF requires a 0.01uF and a
>> 0.001uF in parallel.  You can see that if the series L is dominant, you
>> haven't even moved the frequency by more than a few percent by the small
>> amount of additional capacitance.
> 
> What do you think about the idea that if the caps are connected
> directly to good low impedance power planes that the location of the
> caps are not critical at all.  I have been discussing this in
> comp.arch.embedded and have not gotten much negative feedback except
> some claim that more is always better and that multiple values are not
> needed.
> 
> A recent SI/EMI class I took says that you can put a relatively small
> number of caps pretty much anywhere on the board as long as they are
> coupled to the power planes with no traces, just the via.  This gives a
> very low impedance connection to the planes and the planes give a very
> low impedance connection to the chip.  It was also shown that to get a
> low impedance over a broad bandwidth multiple values are needed to push
> the impedance down and the parallel resonance up.  High loss capacitors
> (X7R/X5R vs. C0G) were also recommended to reduce the signficance of
> the parallel resonance.
> 
> Does any of this sound correct to you?  It was sure convincing in the
> class and appears to be a very sure way of getting low noise on the
> power planes and thereby on the chip power pins!
> 

Article: 107429
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Aug 2006 07:41:10 -0700
Links: << >>  << T >>  << A >>
Uwe,

The on-chip capacitors are a compromise.  They are intended to improve
the energy storage (reduce supply sag, reduce jitter, etc.) but they are
not intended to be the entire solution, nor should they affect the
overall PDS design.  Given that we have room for maybe 16 total
capacitors, and their values (each) is ~0.1uF, they are at best useful,
and at worst, provide little improvements at all.

Since we can not choose these values for a specific operation frequency,
they may be useful for only some frequencies, and not useful at others.

We have worked with customers who wish to completely model everything,
and when we supply the geometric model (suitable for Ansoft, or other
E&M tool), we also supply the capacitors for that package being modeled.

I would say that for the 0.1% of customers who are pushing the part to
its absolute limits in their design, that these capacitors may be
important, and they may be required (as input values) in order to
properly optimize/design the rest of the PDS.

If you desire more information about a particular package, please
contact your FAE, who will be able to contact the factory to get the
values, and on what supplies, the internal capacitors are.

Austin






Uwe Bonnes wrote:
> Austin Lesea <austin@xilinx.com> wrote:
> 
> 
>> To the subject at hand:  placing additional caps across existing caps 
>> does not reduce the noise (unless the dominant cause is lack of adequate 
>> capacitance).
> 
>> The reason why the noise is bad is that the L (as in Ldi/dt) is most 
> ...
> 
> On that subject:
> The webpages for Spartan 5 talk about "Virtex-5 sparse chevron packaging
> effectively positions bypass capacitors on-substrate"
> 
> I didn't find any further information about these capacitors.

Article: 107430
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Aug 2006 07:45:25 -0700
Links: << >>  << T >>  << A >>
Kolja,

I think you are doing extremely well if your cap inductance is dominant.

I have seen many cases where the vias and traces to the capacitors are
more than 1 nH.

Many do not realize just how bad a small diameter via going through half
a pcb can be.

Austin

Kolja Sulimma wrote:
> Austin Lesea schrieb:
> 
>> You may have moved the resonant frequency (more often not), but often
>> people make the mistake of assuming that a 0.1uF requires a 0.01uF and a
>> 0.001uF in parallel.  You can see that if the series L is dominant, you
>> haven't even moved the frequency by more than a few percent by the small
>> amount of additional capacitance.
> 
> Larger caps can contribute a significant portion to the L. In that case
> the second capacitor helps because you reduce part of the L by adding a
> smaller L in parallel to a portion of the big L.
> The inductance for an SMT capacitor is in the range of 50pH to 3000pH.
> This is about the same range as vias of various sizes.
> 
> Kolja Sulimma

Article: 107431
Subject: Re: synchronisation on rising and falling edges
From: "Andy" <jonesandy@comcast.net>
Date: 28 Aug 2006 07:55:43 -0700
Links: << >>  << T >>  << A >>
Synplicity can infer DDR IOB input registers, but there are two
outputs, one for each clock.

If you need DDR functionality inside the FPGA (not in the IOBs), the
only way I know of is two roll your own DDR flop from two SDR flops and
3 xor gates:

ddr: process (clk, rst) is
variable qr, qf : std_logic;
begin
if rst = '1' then
  qr := '0';
  qf := '0';
elsif rising_edge(clk) then
  qr := d xor qf;
elsif falling_edge(clk) then
  qf := d xor qr;
end if;
q <= qr xor qf;
end process;

Synplicity handles the above just fine, but Mentor Precision does not
(it implements it incorrectly, with no warning!). ISE does not accept
it. I think Quartus will take it.
If your synthesis tool does not like the above, then split it out into
separate processes:

signal qr, qf: std_logic;

re: process (rst, clk) is
begin
if rst = '1' then
  qr <= '0';
elsif rising_edge(clk) then
  qr <= d xor qf;
end if;
end process;

fe: process (rst, clk) is
begin
if rst = '1' then
  qf <= '0';
elsif falling_edge(clk) then
  qf <= d xor qr;
end if;
end process;

q <= qr xor qf;

Andy


Sylvain Munaut <SomeOne@SomeDomain.com> wrote:
> > I have a little problem and I need some help.
> >
> > I program a controller for a DDR-SDRAM on a FPGA-Board (Virtex 4, Xilinx).
> >
> > For the synchronisation signal I need a process that is case sensitiv on
> > both edges.
> >
> > But the following commands are not synthesizeable:
> >
> > " if DQS'event then..."
>
> You need to instanciate the DDR IOB flip flop by hand, you can't infer
> them from
> VHDL. Look at the templates in ISE for examples.
>
> And btw, are you gonna drive directly the IOB FF clk input from the DQS
> signals ???
>
>
> > " if (DQS'event and DQS = '1') and (DQS'event and DQS = '0') then..."
>
> Hum ... the logic reduction of the condition you put is "if false then"
> ...
> 
> 
>      Sylvain


Article: 107432
Subject: Re: EDK 6.3 project file growth
From: "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
Date: Mon, 28 Aug 2006 16:59:31 +0200
Links: << >>  << T >>  << A >>
In a related note, I had ISE 8 creating GB and GB of project folders, during 
the wonderful conversion process from ISE 7 to 8...

It got in an endless loop upgrading a snapshot, as it automatically 
generated a sub folder with a new snapshot.. which was upgraded... giving 
another sub folder with a snapshot... which was upgraded... and so on until 
some hours later the harddrive was full.

Excellent.
Good luck bug hunting.
Ben




"Michael Sch÷berl" <MSchoeberl@mailtonne.de> wrote in message 
news:44f2fe03$1@news.fhg.de...
> Hi ...
>
> I had an EDK project which took longer and longer to load. In the begining 
> this was tolerable as there were not many changes but this got worse and 
> finally the project took over 1 hour to load.
>
>
> I found out that my .xmp project file has grown to 12 MBytes (containing 
> the same lines with LockAddr: again and again). Deleting most of those 
> lines helped but the file started to grow again!
>
> what is wrong with that? how can I stop this? ... did anyone at Xilinx 
> ever use their tools for a real project?
>
>
> bye,
> Michael 



Article: 107433
Subject: Re: Spartan-4 ?
From: "Antti" <Antti.Lukats@xilant.com>
Date: 28 Aug 2006 08:01:15 -0700
Links: << >>  << T >>  << A >>
John_H schrieb:

> Antti wrote:
> > New low cost families other than from Xilinx are known to be coming
> > this autumn (Cyclone-3, MAX3, LatticeXP2) but there is no advance info
> > an Spartan-4 yet, is there a hope at all that there will be modern low
> > cost family from Xilinx too?
> >
> > Spartan-3 is 'not for new designs' as there is no price roadmap for it,
> > Spartan-3E only has small members, eg not replacement for S3
> >
> > so we have vacuum in the place of Spartan-4 !
> >
> > I wonder if that vacuum will be filled with Cyclone-3 or is Spartan-4
> > coming this autumn?
> >
> > Antti
>
> I don't know about positioning but
>
> http://tinyurl.com/fvup6
>
> (or
> http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=23856)

Thanks John,
its only visible from 8.2 SP2

but here is quick link to Spartan3A libraries guide :)
http://toolbox.xilinx.com/docsan/xilinx82/books/docs/s3adl/s3adl.pdf

it looks like the ICAP and therefore self-reconfiguration is added to
Spartan-3A, but it still lacks the SPI or NOR flash configuration that
is available on S3e.

those the Spartan3A may be the replacement part for Spartan-3 meaning
that Spartan-4 is possible even further away from being available, I
was
expecting Spartan-4 announcement of prelim info in 6 months from now,
but guess we have to wait more.

actually no, the Spartan3e is partial downgrade from s3e ?
only xc3s50a, xc3s200a, xc3s400a, xc3s700a, xc3s1400a
so no large Spartan3a devices either :(

is the Spartan-3 family really the last big low cost Xilinx FPGA ??

http://xilant.com/index.php?option=com_content&task=view&id=28&Itemid=1
I wrote down the non-NDA info about Spartan3A

there is now DNA port as direct primitive, to be linked with the
genetic what?

Antti


Article: 107434
Subject: Re: high level languages for synthesis
From: fpga_toys@yahoo.com
Date: 28 Aug 2006 08:21:44 -0700
Links: << >>  << T >>  << A >>

KJ wrote:
> Whether you get the concise code or the bloated code for a particular
> hardware design I've found is simply a function of
> - The skill level of the person with the hardware design language that they
> are using.
> - The skill level of the person in hardware design.

This is certainly one of several key determinates, as is the specific
task and experience with it.

> I could be wrong, but I haven't seen anything to indicate that the actual
> language used itself is an important factor.

Here we differ, even if just discussing VHDL/Verilog, in how FSM's are
best constructed for clarity.  I've read nearly 100 different coding
styles, too many very difficult to issolate just exactly what the FSM
really is.

This is one area where language design makes a significant difference
in maintainability. FSM's in C are just a natural byproduct of the
for/do/while construction coupled with if/then/else constructions (or
switch/case/break/continue if supported). Here, the C language is about
describing flow control (the task at hand), not about describing
instantiation (where flow control must be designed by construction).
While it might be possible to build indirect FSM's as you do in
VHDL/Verilog using C constructs, it's certainly not the native style of
any C coder, even those that are also hardware trained.

But again ... language is something of a religious war ... the real
topic is reducing expression complexity, which is greatly abused by
nearly all VHDL/Verilog designs I've read. This variation is certainly
visible in the current thread on FSM construction, and the clearly
different ideas about how this should be expressed.


Article: 107435
Subject: Re: Arbiter design problem?
From: "Doug MacKay" <dmackay@gmail.com>
Date: 28 Aug 2006 08:31:19 -0700
Links: << >>  << T >>  << A >>
bazarnik@hotmail.com wrote:
> <snip>
>
> Obviously request will be active for several clock cycles.
> This is beacuse some waiting time for acknowledge is necessary.
> (If not then why would we need arbiter?)
>
> <snip>
>
> Cheers,
> Przemek

Not so obvious.  Some arbiters contain logic to queue incoming requests
and (for example) will interpret 4 continuous cycles of request
assertion as 4 separate requests.

This can be useful if your arbitration logic requires multiple cycles
while being expected to handle a new request every cycle.


Article: 107436
Subject: Re: placing addiional caps across existing caps to reduce noise
From: fpga_toys@yahoo.com
Date: 28 Aug 2006 08:40:10 -0700
Links: << >>  << T >>  << A >>

Austin Lesea wrote:
> Many do not realize just how bad a small diameter via going through half
> a pcb can be.

Ahmen ....


Article: 107437
Subject: Re: Problem with netlister in System Generator
From: "sivakanth.telasula@gmail.com" <sivakanth.telasula@gmail.com>
Date: 28 Aug 2006 08:49:35 -0700
Links: << >>  << T >>  << A >>
Hello,

The suggestion you have made didn't work. I couldn't find a suitable
solution even in the answers database of xilinx.

Sivakanth

g.bernocchi@gmail.com wrote:
> sivakanth.telasula@gmail.com ha scritto:
>
> > Hello,
> >
> > I am newbie learning Xilinx system generator.
> >
> > I have made a simple down sampler program which will just downsample
> > the incoming signal and presents it as downsampled version.
> >
> > The simulink simulation runs well, but when I try to create a HDL
> > netlist, the process  just hangs in "Running Netlister".
> >
> > Can someone help with this issuse and can provide a solution.
> >
> > Sivakanth.
>
> Hi,
>
> Try to restart Matlab and delete the '.\netlist' directory. My design
> (with sysgen 8.1) work correctly.


Article: 107438
Subject: Re: Style of coding complex logic (particularly state machines)
From: "KJ" <Kevin.Jennings@Unisys.com>
Date: 28 Aug 2006 09:00:31 -0700
Links: << >>  << T >>  << A >>
rickman wrote:
> KJ wrote:
> > rickman wrote:
> I don't know exactly what you mean by fanout.  If a sync reset has to
> go to 100 FFs, then there is nothing you can do to tell the fitter to
> change that.
Yes you can.  If for example, the timing analysis failed because of
reset then you can tell the fitter to limit fanout to say, 20.  Then
what the fitter would do is replicate the flip flop that generates the
reset signal so that there are 5 of them and distribute those 5
(logically identical) resets to those 100 loads.

We can debate the extra resource usage of those 4 extra flops or that
maybe there wouldn't have been 100 in the first place, but I think
we've both made our points already.

> The async reset is free, or actually already paid for, so
> if it does the job why not use it?
At what point do you want to find out that the answer to the question
"if it does the job..." turns out to be "No, it doesn't do the job"
because the designer of some hunk of code that you're integrating in
didn't pay as close attention to resets as they should have and that
the way that the code 'used' the reset, while implying it could be
asynchronous really was not the case and that it needed to be
synchronous after all?  (Either that or 'fix' the errent hunk of code
of course).

> > But simply synchronizing the reset in the first place will do that as
> > well...two different approaches to the problem, each equally valid.
>
> Both valid, but typically I find the async reset takes less effort and
> resources.  Only a small portion of my typical design has to be
> controlled coming out of reset.
And unless that small portion is actually 'zero' you'll need some
synchronizer somewhere.  In that case, I've found that resources
differences is neglibile or non-existent.  I'll accept that you may
have seen differences and I don't want to get into the nitty gritty but
I'll bet that those differences that you saw were pretty small as well.
 If not, then to what did you attribute the large difference would be
interesting to know.

As for effort, the only effort I see in either case is the coding which
is identical.  It's just a question of where you physically put the "if
(Reset = '1) then"....or is there some other effort that you mean?

> > > This is not a problem when you use the dedicated reset net.
> > I agree, but I was referring more to the reset signal distribution on a
> > board rather than inside an FPGA.
>
> I understand, but noise still can upset a sync reset.  This is just not
> a workable solution to noise.
I'm not sure what solution you're referring to.  All I'm saying is that
use of a synchronous reset is less susceptible to a noise issue than an
asynchronous one because it requires the noise to be somewhat
coincident with the clock in order for it to have any effect.  On a
given board design though that coincidence will tend to either be near
0 or near 100%....but those near 0 ones don't need to be fixed because
they're not broken if used synchronously.

> > > Even though there are FFs that do not need a reset, it does not hurt to put
> > > the entire device in a known state every time.
> > OK, it doesn't 'hurt', but it doesn't 'help' either in the sense that
> > both approaches would meet the exact same requirements of the
> > functional specification for that part.
>
> I don't agree.  By globally resetting the device, you have handled all
> FFs so that if your requirement misses one, you don't find out about it
> after the unit is in the field.
Only if your requirement is that the flip flop be set to the state that
you happened to have coded for it and not the other state.  In any
case, it's not sporting to say that one design approach is better
because it has a chance that it just happened to code correctly for a
missing requirement.  Actual reset signal requirements are usually
pretty benign and in many cases NOT coding it as a matter of course
could lead one to finding this missing requirement earlier....during
simulation.  The scenario I'm thinking of here is that OK, the
functional requirements has an as yet unidentified reset state.  Based
on that I code the design and do not do anything to signal 'ABC' as a
result of reset.  During simulation I find that I just can't get signal
'ABC' into the proper state (since it is an unknown at the end of
reset) and that I need to because the logic tree that it feeds into
requires 'ABC' to be in the proper state.  In that situation the
simulation has immediately hit on to the missing functional requirement
and you can investigate, whereas coding to a specific value you have
the chance of getting it right or not and not finding out until product
is in the field.  Starting with 'U' states in simulation and seeing
your system simulation model drive the 'U' out as a result of signals
other than 'reset' is a good indicator of things I've found.

>
> > > It is not hard to miss a FF that needs to be reset otherwise.
> > Inside the FPGA it doesn't matter since if you discover something that
> > you now realize needs to be reset you re-route and get a new file.  Not
> > routing it to a part on a board and then discovering you need it is a
> > bit more of an issue.  Resolving that issue by routing reset to every
> > part and then using it asynchronously is where problems have come up
> > when there are a lot of parts on the board.
>
> The question is when do you find out about the missing reset?  It is
> easy for this sort of thing to slip totally through testing and only
> show up in the users's hands.
>
Simulation and the 'U' value in the std_logic type is the key here I've
found to getting all initialization issues properly identified really
early on, long before prototypes.

>
> > > Personally I think the noise issue is a red herring.
> > If it's a red herring than I can safely say that I have slayed several
> > red herrings over my career...but actually not many of late....not
> > since a certain couple designers moved on to to greener pastures to be
> > brutally honest.
>
> I assume you mean board designers who were not producing quiet boards?
>
And that then had problems that needed to be fixed.

>
> > > If you have noise
> > > problems on the board, changing your reset to sync will not help in
> > > general.  You would be much better off designing a board so it does not
> > > have noise problems.
> > Maybe.  But remember the scenario when you're brought in to fix a
> > problem with an existing board that you trace back to some issue with
> > reset.  In that situation, a programmable logic change is more likely
> > the more cost effective solution.
>
> I am in a fairly long thread in comp.arch.embedded about how to design
> boards so that you don't have SI and EMI issues.  I think this sort of
> problem should be dealt with before you make the board, not after it is
> in the field.
Totally agree.  But being realistic here, if you DO have boards out in
the field with this problem, there is also the issue of what is the
cost effective way to fix the problem from the perspective of both your
company and your customer?

> Too many engineers learn to cover their butts rather
> than to produce good designs.  I am tired of working that way and not
> really knowing if my design will work before it is shipped.  The one
> universal rule I learned very early on is that you can not prove a
> product works correctly by testing.
Agreed.

> It has to be designed to work
> correctly by using design methods based on understanding what you are
> doing.  I have never seen a board noise issue that could be fixed by an
> FPGA design change.
Here's a hypothetical one (but not far from what I've seen) for you
then.  You've got a 'blip' on reset where it gets above threshold and
that lasts for...maybe 1 ns at the receiver.  You trace it down and
find out exactly what output switching condition is causing the blip to
happen.  You can also characterize and analyze it to say that it will
never be able to couple and cause this blip to exist for more than 2
ns.  On the receiver you have a clocked device that receives this reset
signal.

The 'proper' solution of course is to re-route the board to get the
reset away from the noise initiator, guard it appropriately,
etc.....the 'soft' design change is to change the code in the receiving
device to ignore resets that last for only two clocks or less (or
whatever works for you).  Granted, the reset response of the device has
been degraded (by that clock cycle or two) but in many cases, that's OK
as well.  You need to investigate it of course to validate but under
the right circumstances it would work just as flawlessly as the PCB
re-route.

The point being that just because a solution does not tackle the root
cause does not necessarily imply that it is in any way less robust.
And I'll also accept that in some (possibly many) situations there may
be no 'soft' solution...if you'll also accept that in some (possibly
many) situations that there really might.

Now, you've got "N" boards in the field.  What is the 'best' solution,
not only from the perspective of your company (presumably the 'soft'
update is easier to distribute) but from your customers as well (who
would have down time to swap out the PCBA....oops, that board is in a
deep sea sensor?  On the way to Mars?  Inside average Joe user's PC?)

KJ


Article: 107439
Subject: Re: high level languages for synthesis
From: fpga_toys@yahoo.com
Date: 28 Aug 2006 09:18:54 -0700
Links: << >>  << T >>  << A >>

Robin Bruce wrote:
> A final point is that we really need to nail down this fallacy that an
> FPGA-targeting C-syntax HLL is somehow inherently sequential. It's not.
> The compiler determines that.

Take Robin's example, one thing that compilers need, is a hint about
available resources. That for-loop can easily be unrolled by a fair
factor and each instance executed in parallel. Even with N a variable,
it can lop the loop into large parallel chunks, and finish the last
increment with a partial chunk execution.


> FPGAs are best for algorithms where there are large data sets.

I disagree here ... they can also easily replicate MANY instances of
small parallel processes as they can replicate parallel instances of
any other data handling code block. For example, the code block of a
typical MPI parallel process can be replicated on FPGA
dozens/hundreds/thousands of times, that would require huge clusters of
machines for a sequential instruction set processor.

> They offer the best performance when the
> algorithms (or their main computational loops) are pipelinable.

Best? not clear ... but pipelining is certainly an advantage for
getting clock rate up. Another alternative is pure async construction,
or better yet, fully async FPGA fabrics.

>   for(i=0; i<N; i++){
>
>     sigma_local = sigma[i];
>     mu_local = mu[i];
>     x_local = x[i];
>
>     sigma_sqr = sigma_local * sigma_local;
>
>     dif_x_mu = x_local - mu_local;
>     dif_x_mu_sqr = dif_x_mu * dif_x_mu;
>
>     phi[i] = (1.0 / (sigma_local * ROOT_2PI)) * expf(-( dif_x_mu_sqr /
> (2 * sigma_sqr) ));
>
>   }

There are a lot of things a good compiler can do here to improve
synthesis and performance, IF the compiler is tuned for doing FP based
data algorithms. Those are optimizations, that would never be put into
a pure hardware description language, as they would seldom be needed.
As such the optimizations in the compiler are leveraged across many
applications.

If this code block was the kernel of simulation engine, with thousands
of cells, it would be best for the compiler to implement this bit/digit
serial, using a data flow linkage to avoid the multiplier expansion.
Literially run thousands in parallel, with a word length latency in
clocks.

In many cases, C programers use variables instead of constants. There
is a clear advantage for FPGA compilers to be presented with constants
instead. This favors using maifest constants at compile time, rather
than per run constants in the data. Frequently a recompile is faster
than the resulting code fully parameterized.


Article: 107440
Subject: Question on Virtex-4 CLB
From: Andreas Ehliar <ehliar@lysator.liu.se>
Date: Mon, 28 Aug 2006 16:20:45 +0000 (UTC)
Links: << >>  << T >>  << A >>
If I look in the FPGA editor there seems to be one element
in the CLB of a Virtex-4 that is odd as compared to previous
FPGA generations that I have looked at in the FPGA editor.

The CLB looks something like this in ASCII art:

    +-------------+
    |             |           +--+
    |             |           |  |
    |             |           |  |    +-----+
    |             |           |  |    |SLICE|
    |             |           |  |    |     |
    |             |           |  |    +-----+
    |             |           |  |
    |             |           |  |    +-----+          
    |             |           |  |    |SLICE|
    |             |           |  |    |     |
    |             |           |??|    +-----+
    |  Switchbox  |           |??|
    |             |           |  | +-----+
    |             |           |  | |SLICE|
    |             |           |  | |     |
    |             |           |  | +-----+
    |             |           |  |
    |             |           |  | +-----+
    |             |           |  | |SLICE|
    |             |           |  | |     |
    |             |           |  | +-----+
    |             |           |  |
    |             |           +--+             
    +-------------+


The box with question marks just seems to rearrange the wires so that
they are grouped according to function at the switchbox.
Is that all there is to it?

/Andreas

Article: 107441
Subject: Re: Style of coding complex logic (particularly state machines)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 28 Aug 2006 09:35:31 -0700
Links: << >>  << T >>  << A >>
Eli Bendersky wrote:

> I also try to avoid variables for another reason (in addition to the
> ones you stated). Somehow, when variables are used I can't be 100% sure
> if the resulting code is synthesizable, because it can turn out not to
> be.

If you mean that a variable does not always infer a register I agree.
If you mean that synthesis does not always produce a netlist that
simulates the same as the code, I disagree.

> Additionally, since I do use signals, variables create the mixup of
> "update now" and "update later" statements which make the process more
> difficult to understand. With signals only it's all "update later".

I agree, and this is exactly why
I do not declare any signals for synthesis.

       -- Mike Treseler

Article: 107442
Subject: Semi-OT: Free (USA) tube of Philips CPLDs
From: zwsdotcom@gmail.com
Date: 28 Aug 2006 09:52:24 -0700
Links: << >>  << T >>  << A >>
Amongst my junk I found a tube of 25 PZ5032CS10A44 32-macrocell CPLDs
in PLCC44 package.

Datasheet at
<http://www.ife.tugraz.at/datashts/Philips/pz5032.pdf#search=%22pz5032%22>

You pay postage, you get the chips.


Article: 107443
Subject: Re: Question on Virtex-4 CLB
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Aug 2006 10:10:57 -0700
Links: << >>  << T >>  << A >>
Andreas,

I would like to educate the newsgroup:  FPGA_editor has a highly
simplified graphical visual representation of the chip that is the
'software view' of the world -- it has very little basis in the actual
hardware.

I often have people ask me questions about the editor view, only to have
to remind them that it does not represent the schematics.

For example, there is no such thing as a "switchbox."  It doesn't even
exist.

That said, improvements or changes in FPGA_editor may be done for
reasons having nothing to do with the actual architecture, or hardware.
 Or they may be a way to represent a new architectural or hardware
feature in a simplified fashion.

Austin

Andreas Ehliar wrote:
> If I look in the FPGA editor there seems to be one element
> in the CLB of a Virtex-4 that is odd as compared to previous
> FPGA generations that I have looked at in the FPGA editor.
> 
> The CLB looks something like this in ASCII art:
> 
>     +-------------+
>     |             |           +--+
>     |             |           |  |
>     |             |           |  |    +-----+
>     |             |           |  |    |SLICE|
>     |             |           |  |    |     |
>     |             |           |  |    +-----+
>     |             |           |  |
>     |             |           |  |    +-----+          
>     |             |           |  |    |SLICE|
>     |             |           |  |    |     |
>     |             |           |??|    +-----+
>     |  Switchbox  |           |??|
>     |             |           |  | +-----+
>     |             |           |  | |SLICE|
>     |             |           |  | |     |
>     |             |           |  | +-----+
>     |             |           |  |
>     |             |           |  | +-----+
>     |             |           |  | |SLICE|
>     |             |           |  | |     |
>     |             |           |  | +-----+
>     |             |           |  |
>     |             |           +--+             
>     +-------------+
> 
> 
> The box with question marks just seems to rearrange the wires so that
> they are grouped according to function at the switchbox.
> Is that all there is to it?
> 
> /Andreas

Article: 107444
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "rickman" <gnuarm@gmail.com>
Date: 28 Aug 2006 10:15:42 -0700
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
> Rick,
>
> Via in pad (basically no trace) is best.  Placement is not critical, as
> long as you have via in pad, and planes.
>
> But even so, the diameter of the vias, and their lengths can be
> critical, and still be the dominant factor.
>
> It is all about the lop that is formed (see the HK sparse chevron
> presentations, as I think he said it best).

Where exactly is the loop you are referring to?  Some would say it is
back to the chip through the power pins.  It appears to me that it only
has to include the power planes.  If it is back to the chip, then
placement should be critical.

I understand what you are saying, but I think the Ritchey method is
very simple and effective.  The range of change in the inductance of
the various via placements is not so large that it swamps out the
inductance of the cap which I would say dominates.  In any event, if
you just use a range of cap values to provide multiple SRFs you end up
with a very broad low impedance power plane.  This was shown both in
simulation and in measurements.


> Do you need a broad low impedance?  I would say that it is most unusual
> that a pcb has to work over all frequencies.  The system is usually
> designed with a finite number and range of clocks (33 MHz, 266 MHz, 78
> MHz, for example).  I would counter that rather than a flat broad low
> impedance, you could do better to target just the frequencies you care
> about.

Ritchey also discussed this, since knowing your frequency range is
actually critical to any power decoupling approach.  He showed that the
IO noise for a series damped transmission line can be calculated
assuming a current profile of the rise time limiting the slew (max
freq) and the duration controlled by the roundtrip delay (min freq).
This trapezoid has a given spectral profile which is not controlled by
the clock at all.  So even if the entire design is run from the same
clock you can expect a lot of power noise to show at a wide range of
frequencies.


> High loss/low loss is a red herring:  I have never seen a case where the
> type of capacitor made any difference at all.  I would be interested if
> anyone has made a board where high loss/loss loss caps actually made a
> measurable difference,

I can't say a design failed because of low loss caps, but Ritchey had
very clear measurements that showed a strong ESR peak where the caps
resonated with the plane.  By using caps with a higher ESR the
resonance was damped out and the impedance "hole" was eliminated.

BTW, one of your people was in the class.  He seemed to get a lot from
it too.  I have misplaced his card or I would ask you to say hi to him
for me.  He seemed like a good guy!   :^)


Article: 107445
Subject: Re: Question about library update in Modelsim
From: Mike Treseler <mike_treseler@comcast.net>
Date: Mon, 28 Aug 2006 10:16:04 -0700
Links: << >>  << T >>  << A >>
fl wrote:

> I modified the source of that resource library. I found
> that my simulation did not reflect my changes even I refreshed that
> resource library. The only way is to totally delete that library and
> recreat it. Do you have method to update a user defined library?

Compile the library first and then files
that use the library.

         -- Mike Treseler

Article: 107446
Subject: Re: Style of coding complex logic (particularly state machines)
From: Duane Clark <junkmail@junkmail.com>
Date: Mon, 28 Aug 2006 17:19:59 GMT
Links: << >>  << T >>  << A >>
KJ wrote:
> ...
> The drawback of signals is that take longer simulation time...wasted
> time too.  I'm trying to resurrect the test code that I had comparing
> use of variables versus signals but I seem to remember about a 10% hit
> for signals...

I would be interested in whether anyone has theories on why variables 
would simulate faster than signals. And whether this behavior has been 
seen on different simulators, or only Modelsim.

Article: 107447
Subject: Re: RocketIO over cable
From: "vt2001cpe" <vt2001cpe@gmail.com>
Date: 28 Aug 2006 10:23:50 -0700
Links: << >>  << T >>  << A >>
Perhaps I did not phrase my question correctly. Assume a hypothetical
system where raw captured data from an ADC is streamed from one box to
another. The two boxes are connected via some sort of RocketIO link
over copper. Ideally, I would like to transmit just the raw samples,
but it seems some sort of overhead will be required to keep the link
established and aligned. In the event that bit errors occur, and a
comma character is falsly detected by the receiver, what happens? For
example, will the receiver try to realign and continue pumping out
data, now misaligned by the false comma, until the real comma is
detected? Or will the receiver raise an error flag, but not try and
realign. I am more interested in maintaining the throughput, and less
concerned that data is "correct". That having been said, I would like
to have correct data, but I do not think I can afford the overhead of
error correction.

Any insight or suggestions?
--Dennis

Ed McGettigan wrote:
> vt2001cpe wrote:
> > Thank you everyone for your quick and informative responses! In the
> > event of a large number of bit errors, is it possible for a comma
> > character to be incorrectly introduced? What would the effect be? Will
> > the CRC fail and put the state machine into an error state, or will
> > data continue to transmit, unaware?
>
> It is possible to generate more than a single bit error in the same
> 8b10b word, but with a well designed link this is very unlikely to
> occur.  In any case your transmitter is completely unaware that an
> error actually occurred and will happily continue transmitting. It's
> your receiver logic needs to be able to handle any errors that happen.
>
> The worst case that could happen is that the error generates a comma
> character that is out of alignment with the previous alignment.  This
> would cause a constant stream of errors until a correct comma character
> is received and the link realigns to the correct 8b10b word. All of
> this is fairly standard stuff and has been around for decades in
> many different protocols.
>
> Since it doesn't look like you have a particular protocol in mind. I
> would suggest that you take a look at the light weight Aurora protocol
> http://www.xilinx.com/aurora  Even if you decide to not use it, you
> should be able to learn a lot from it.
> 
> Ed McGettigan
> --
> Xilinx Inc.


Article: 107448
Subject: Re: RocketIO over cable
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Mon, 28 Aug 2006 19:41:55 +0200
Links: << >>  << T >>  << A >>
vt2001cpe schrieb:
> Perhaps I did not phrase my question correctly. Assume a hypothetical
> system where raw captured data from an ADC is streamed from one box to
> another. The two boxes are connected via some sort of RocketIO link
> over copper. Ideally, I would like to transmit just the raw samples,
> but it seems some sort of overhead will be required to keep the link
> established and aligned. In the event that bit errors occur, and a
> comma character is falsly detected by the receiver, what happens? For
> example, will the receiver try to realign and continue pumping out
> data, now misaligned by the false comma, until the real comma is
> detected? Or will the receiver raise an error flag, but not try and
> realign. I am more interested in maintaining the throughput, and less

It will detect a code error and raise a flag. Dependig on configuration 
the receiver will try to realign or just continue sampling data. Usually 
a state machine will keep a look at the code error flag and force a 
realign after 3 consecutive errored codes. Iam not sure if this state 
machine is already implemented inside the MGTs, probably you have to 
create it yourself using FPGA logic. Should be no big deal.

Regards
Falk

Article: 107449
Subject: Re: RocketIO over cable
From: Austin Lesea <austin@xilinx.com>
Date: Mon, 28 Aug 2006 10:58:55 -0700
Links: << >>  << T >>  << A >>
vt2001cpe,

http://www.xilinx.com/products/design_resources/conn_central/grouping/aurora.htm

details the Aurora protocol, which should be lightweight enough that it
does not burden your data transfers.

You need something to: keep track of connection state, bond more than
one MGT together (to get more bandwidth), deal with errors, organize
data into frames, perform flow control, encode/decode in 8b/10b or
84b/66b, etc.

Using the MGT all by itself is starting from scratch, and you will
eventually have to decide how to deal with all of the items I mentioned
above.

Thus, the reason why we created Aurora, and offer it license free, with
supported IP.

Enjoy,

Austin

vt2001cpe wrote:
> Perhaps I did not phrase my question correctly. Assume a hypothetical
> system where raw captured data from an ADC is streamed from one box to
> another. The two boxes are connected via some sort of RocketIO link
> over copper. Ideally, I would like to transmit just the raw samples,
> but it seems some sort of overhead will be required to keep the link
> established and aligned. In the event that bit errors occur, and a
> comma character is falsly detected by the receiver, what happens? For
> example, will the receiver try to realign and continue pumping out
> data, now misaligned by the false comma, until the real comma is
> detected? Or will the receiver raise an error flag, but not try and
> realign. I am more interested in maintaining the throughput, and less
> concerned that data is "correct". That having been said, I would like
> to have correct data, but I do not think I can afford the overhead of
> error correction.
> 
> Any insight or suggestions?
> --Dennis
> 
> Ed McGettigan wrote:
>> vt2001cpe wrote:
>>> Thank you everyone for your quick and informative responses! In the
>>> event of a large number of bit errors, is it possible for a comma
>>> character to be incorrectly introduced? What would the effect be? Will
>>> the CRC fail and put the state machine into an error state, or will
>>> data continue to transmit, unaware?
>> It is possible to generate more than a single bit error in the same
>> 8b10b word, but with a well designed link this is very unlikely to
>> occur.  In any case your transmitter is completely unaware that an
>> error actually occurred and will happily continue transmitting. It's
>> your receiver logic needs to be able to handle any errors that happen.
>>
>> The worst case that could happen is that the error generates a comma
>> character that is out of alignment with the previous alignment.  This
>> would cause a constant stream of errors until a correct comma character
>> is received and the link realigns to the correct 8b10b word. All of
>> this is fairly standard stuff and has been around for decades in
>> many different protocols.
>>
>> Since it doesn't look like you have a particular protocol in mind. I
>> would suggest that you take a look at the light weight Aurora protocol
>> http://www.xilinx.com/aurora  Even if you decide to not use it, you
>> should be able to learn a lot from it.
>>
>> Ed McGettigan
>> --
>> Xilinx Inc.
> 



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