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 145625

Article: 145625
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 16 Feb 2010 08:56:33 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 9, 3:15=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Symon <symon_bre...@hotmail.com> wrote:
>
> (snip)
>
> > Sure Rick, let's go through it together with some cheap tools (free!)
> > from t'internet. OK, you can get a nice copy of Spice from here. maybe
> > you already have it.
> >http://www.linear.com/designtools/software/
> > At the bottom of this post you will find a model of a PCB with a power
> > plane bypass. I've used lumped components to model it. If you
> > cut'n'paste the text into an editor and save it as 'planes.asc' or
> > somesuch, you should be able to load it into the simulator you download=
ed.
>
> (really big snip)
>
> I think you really need a model of the radial transmission line,
> which I don't see (but could have missed).
>
> See the papers I mentioned in previous posts.

I think I have figured out why you *don't* need to consider a radial
transmission line in models of the PDS.  The transmission line model
is only effective if the length of the line is longer than about 1/6th
of the rising edge of the signal.  For a 0.5 ns rise time pulse the
rising edge is about 3 inches in length on the PWB.  So if you keep
your caps within a half inch of the power pins of the chip, the
transmission line effects are spread over the entire path (or averaged
if you will).  In other words, for adequately short paths, the
electrical path between the power pins and decoupling caps appears as
a lumped capacitance and does not need to be analyzed as a
transmission line.

Does that sound right?

Rick

Article: 145626
Subject: Re: EDK 11,1 on Windows 7, 32 Bit
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 16 Feb 2010 09:21:32 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> Hi
>
> my co-worker has a problem with EDK (used on w7, 32bit)
> OLD project can be built but any new projexcts created stop
> during implementation
>
> xilinx claims that the following tablehttp://www.xilinx.com/ise/ossupport=
/index.htm
>
> is UPTODATE OS support list for Xilinx tools, in that table win7 is
> missing
>
> so what is wrong? is there something wrong with the installation, but
> hey
> why then old projects pass full flow?
>
> any ideas?
>
> Antti

Win7 isn't a supported OS for ISE tools and it is not listed in the
table.

The tools may work under some conditions, but they likely will not
under all conditions as your co-worker found out.

Ed McGettigan
--
Xilinx Inc.


Article: 145627
Subject: Re: rocketio TX delay between sata0 and sata1
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 16 Feb 2010 09:30:21 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 15, 2:08=A0pm, "msegura" <ms_...@usc.edu> wrote:
> Hi, I'm workng with MGT as GT_CUSTOM.
> I use the MGT for transmiting to pulses of .66ns(1/15Ghg).
> I check all the delays with FPGA editor and all was ok, but I mesure the
> pulses at the SATA conector and there are a delay between SATA0 and SATA1
> of 500ps.
> I simplified the program as much as posible and this delay is always
> present.
> The mesurment was made with the same cable lenght.
>
> Same ideas?
> Thansk
> Marcelo
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

The lane-to-lane skew isn't zero and the maximum value is listed in
the device datasheet. For instance with Virtex-5 the GTP value is
855ps.

Ed McGettigan
--
Xilinx Inc.

Article: 145628
Subject: Re: EDK 11,1 on Windows 7, 32 Bit
From: "maxascent" <maxascent@n_o_s_p_a_m.yahoo.co.uk>
Date: Tue, 16 Feb 2010 13:54:10 -0600
Links: << >>  << T >>  << A >>
Have you tried running ISE using Windows 7 compatibilty mode. I found that
some of the programs that I used to run in XP wouldnt run in 7 unless I
used the compatibility mode.

Jon	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145629
Subject: Re: Board layout for FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 16 Feb 2010 20:17:35 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip, I wrote)

>> I think you really need a model of the radial transmission line,
>> which I don't see (but could have missed).

>> See the papers I mentioned in previous posts.
 
> I think I have figured out why you *don't* need to consider a radial
> transmission line in models of the PDS.  The transmission line model
> is only effective if the length of the line is longer than about 1/6th
> of the rising edge of the signal.  For a 0.5 ns rise time pulse the
> rising edge is about 3 inches in length on the PWB.  So if you keep
> your caps within a half inch of the power pins of the chip, the
> transmission line effects are spread over the entire path (or averaged
> if you will).  In other words, for adequately short paths, the
> electrical path between the power pins and decoupling caps appears as
> a lumped capacitance and does not need to be analyzed as a
> transmission line.

It does seem that the previously mentioned papers analyze them
in ways that I wouldn't think would matter.  One even considers
the reflection of other vias.

But, there are a few things that I think should be considered.
The inductance of the via, and the input impedance of the radial
transmission line are proportional to 1/r.  Big vias are better.
A group of vias close enough together, though, should act like
a large via.  (The fields couple such that it isn't the same
as parallel inductors.)

It would seem that one should also be careful not to put the FPGA
right in the center of a large ground plane, such the the edge
reflections come back in phase.  That would be especially bad for
a large circular ground plane.  If the decoupling capacitors were
regularly spaced, that could also cause in-phase reflections.
 
> Does that sound right?

It doesn't seem so far off.  It still seems that radial transmission
line theory isn't taught much at all.   

-- glen

Article: 145630
Subject: Re: What is the basis on flip-flops replaced by a latch
From: -jg <jim.granville@gmail.com>
Date: Tue, 16 Feb 2010 12:36:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 12, 9:05=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> I finally understand the reason when a flip-flops can be replaced by a
> latch.
> I saw the circuits before, but not realized what the basic reason was.
> With the above paper, I now know that the technology is not a new, it
> originated in 1980s.

Even earlier than that.

 Just look at the relative sales volumes of the venerable 74373 vs
74374.
 In all those cases, the latch is used to buy some extra setup time.

 Anywhere you find an ALE pin, you find this principle, and that goes
back a LONG way.

-jg

Article: 145631
Subject: Re: What is the basis on flip-flops replaced by a latch
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Tue, 16 Feb 2010 16:07:07 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 12:36=A0pm, -jg <jim.granvi...@gmail.com> wrote:
> On Feb 12, 9:05=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > Hi,
> > I finally understand the reason when a flip-flops can be replaced by a
> > latch.
> > I saw the circuits before, but not realized what the basic reason was.
> > With the above paper, I now know that the technology is not a new, it
> > originated in 1980s.
>
> Even earlier than that.
>
> =A0Just look at the relative sales volumes of the venerable 74373 vs
> 74374.
> =A0In all those cases, the latch is used to buy some extra setup time.
>
> =A0Anywhere you find an ALE pin, you find this principle, and that goes
> back a LONG way.
>
> -jg

jg,
I checked SN74LV374 TI's manual and couldn't find what you said: ALE
pin.

For time borrowing through a pipelined stages, Intel uses Domino Logic
which was not available until 2000.

Weng

Article: 145632
Subject: Re: What is the basis on flip-flops replaced by a latch
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 17 Feb 2010 00:18:25 +0000 (UTC)
Links: << >>  << T >>  << A >>
Weng Tianxiang <wtxwtx@gmail.com> wrote:
> On Feb 16, 12:36?pm, -jg <jim.granvi...@gmail.com> wrote:

>> Even earlier than that.

>> ?Just look at the relative sales volumes of the venerable 74373 vs
>> | 74374. In all those cases, the latch is used to buy some extra 
>> | setup time.

>> ?Anywhere you find an ALE pin, you find this principle, and that 
>> | goes back a LONG way.

> I checked SN74LV374 TI's manual and couldn't find what you 
> said: ALE pin.

ALE is an output on, for example, many Intel processors.  Address
Latch Enable, such that the address can be latched while the pins
are used for other purposes.

The 8085 shares the data bus with part of the address bus, for example.
With a 74S373 the address is available for decoding long before ALE
goes low.  

-- glen

Article: 145633
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 16 Feb 2010 16:57:44 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 3:17 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, I wrote)
>
> >> I think you really need a model of the radial transmission line,
> >> which I don't see (but could have missed).
> >> See the papers I mentioned in previous posts.
> > I think I have figured out why you *don't* need to consider a radial
> > transmission line in models of the PDS.  The transmission line model
> > is only effective if the length of the line is longer than about 1/6th
> > of the rising edge of the signal.  For a 0.5 ns rise time pulse the
> > rising edge is about 3 inches in length on the PWB.  So if you keep
> > your caps within a half inch of the power pins of the chip, the
> > transmission line effects are spread over the entire path (or averaged
> > if you will).  In other words, for adequately short paths, the
> > electrical path between the power pins and decoupling caps appears as
> > a lumped capacitance and does not need to be analyzed as a
> > transmission line.
>
> It does seem that the previously mentioned papers analyze them
> in ways that I wouldn't think would matter.  One even considers
> the reflection of other vias.
>
> But, there are a few things that I think should be considered.
> The inductance of the via, and the input impedance of the radial
> transmission line are proportional to 1/r.  Big vias are better.
> A group of vias close enough together, though, should act like
> a large via.  (The fields couple such that it isn't the same
> as parallel inductors.)
>
> It would seem that one should also be careful not to put the FPGA
> right in the center of a large ground plane, such the the edge
> reflections come back in phase.  That would be especially bad for
> a large circular ground plane.  If the decoupling capacitors were
> regularly spaced, that could also cause in-phase reflections.
>
> > Does that sound right?
>
> It doesn't seem so far off.  It still seems that radial transmission
> line theory isn't taught much at all.

I am confused.  You say that my analysis is not far off and the whole
(hole) point of my analysis is to show that the radial transmission
line effect is not important.  Then you say you still think the radial
transmission line effect *is* important.

I am pretty sure that the effects of the decoupling caps swamps out
the effect of the reflections.  This is not very scientific and so may
be totally wrong, but it would seem to me that the caps will "mute"
the voltage transitions on the plane as the wave moves by.  If it were
a linear transmission line, the cap would "smear" out the edge of the
wave front.  In the PCB power plane the same thing happens, but it is
likely strongest at the cap and is a weaker effect further away from
the cap.  In the case of a transient, smearing it out reduces the
amplitude which is exactly what it is supposed to do.  So I expect the
wave front never reaches a board edge to cause a significant
reflection.  I will say that when the impedance of a PDS is measured
the very high frequencies often have a sawtooth shape which is likely
due to standing waves on the board.  So there must be some of the
transient that is reflected.

But if you can verify your analysis method by measuring the impedance
of the PDS to be below your requirements at all frequencies, what does
it matter if the power planes form a "radial transmission line"?  You
only need to do enough analysis to get a "good enough" result.  I
would think that if this were an important effect, that would have
been discovered by now.

Rick

Article: 145634
Subject: Re: What is the basis on flip-flops replaced by a latch
From: rickman <gnuarm@gmail.com>
Date: Tue, 16 Feb 2010 17:08:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 7:07=A0pm, Weng Tianxiang <wtx...@gmail.com> wrote:
> On Feb 16, 12:36=A0pm, -jg <jim.granvi...@gmail.com> wrote:
>
>
>
> > On Feb 12, 9:05=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > > Hi,
> > > I finally understand the reason when a flip-flops can be replaced by =
a
> > > latch.
> > > I saw the circuits before, but not realized what the basic reason was=
.
> > > With the above paper, I now know that the technology is not a new, it
> > > originated in 1980s.
>
> > Even earlier than that.
>
> > =A0Just look at the relative sales volumes of the venerable 74373 vs
> > 74374.
> > =A0In all those cases, the latch is used to buy some extra setup time.
>
> > =A0Anywhere you find an ALE pin, you find this principle, and that goes
> > back a LONG way.
>
> > -jg
>
> jg,
> I checked SN74LV374 TI's manual and couldn't find what you said: ALE
> pin.
>
> For time borrowing through a pipelined stages, Intel uses Domino Logic
> which was not available until 2000.


The reason twofold.  One is that the pin was not called ALE on the
latch, it was called C or G or LE or something similar.  ALE is from
the Intel CPUs that require the latch to hold the address bits.  The
other reason is that you are looking at the wrong part.  The 373 part
is the latch and the 374 part is the register.  I am pretty sure the
only difference is the function of the clock input.

The latch is used with these processors for the exact reason you are
looking at latches.  It allows the output of the latch to output a
stable value from the input before the clock edge rather than after.
This was used to speed memory accesses.

Rick

Article: 145635
Subject: Re: Board layout for FPGA
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 17 Feb 2010 01:32:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip, I wrote)

>> But, there are a few things that I think should be considered.
>> The inductance of the via, and the input impedance of the radial
>> transmission line are proportional to 1/r.  Big vias are better.
>> A group of vias close enough together, though, should act like
>> a large via.  (The fields couple such that it isn't the same
>> as parallel inductors.)

>> It would seem that one should also be careful not to put the FPGA
>> right in the center of a large ground plane, such the the edge
>> reflections come back in phase.  That would be especially bad for
>> a large circular ground plane.  If the decoupling capacitors were
>> regularly spaced, that could also cause in-phase reflections.

>> > Does that sound right?

>> It doesn't seem so far off.  It still seems that radial transmission
>> line theory isn't taught much at all.
 
> I am confused.  You say that my analysis is not far off and the whole
> (hole) point of my analysis is to show that the radial transmission
> line effect is not important.  Then you say you still think the radial
> transmission line effect *is* important.
 
> I am pretty sure that the effects of the decoupling caps swamps out
> the effect of the reflections.  This is not very scientific and so may
> be totally wrong, but it would seem to me that the caps will "mute"
> the voltage transitions on the plane as the wave moves by.  

If it works right, the capacitor should be an AC short between the
planes.  If, for example, you had a ring of capacitors around 
a constant radius from a via, then the reflection off those should
come back in phase.  That is pretty much the same as a microwave
cavity resonator.  

> If it were
> a linear transmission line, the cap would "smear" out the edge of the
> wave front.  

A capacitor across a linear transmission line should make a nice
reflection.  A capacitor and series resistor should absorb some
of the AC signal, but ignore the DC voltage.  Though that assumes
ideal capacitors.

> In the PCB power plane the same thing happens, but it is
> likely strongest at the cap and is a weaker effect further away from
> the cap.  In the case of a transient, smearing it out reduces the
> amplitude which is exactly what it is supposed to do.  So I expect the
> wave front never reaches a board edge to cause a significant
> reflection.  I will say that when the impedance of a PDS is measured
> the very high frequencies often have a sawtooth shape which is likely
> due to standing waves on the board.  So there must be some of the
> transient that is reflected.

In a real board with lots of ICs, vias, and bypass capacitors, 
you would hope that the reflections are rarely in phase.  If parts
are placed too regularly on the board, it would seem possible for
some strong resonance to form.  
 
> But if you can verify your analysis method by measuring the impedance
> of the PDS to be below your requirements at all frequencies, what does
> it matter if the power planes form a "radial transmission line"?  

I think it only really matters for a very short distance. For that
distance, though, it should be computed as a radial transmission line.

> You only need to do enough analysis to get a "good enough" result.
> I would think that if this were an important effect, that would have
> been discovered by now.

There have been plenty of cases where effects when unnoticed for
way too long.  If, for example, a board resonance turned out to
be the same as an on-board frequency it could easily be very
significant.  Then an unrelated change would move the resonance,
and the problem would go away without ever being found.

-- glen

Article: 145636
Subject: Re: What is the basis on flip-flops replaced by a latch
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 17 Feb 2010 01:38:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
rickman <gnuarm@gmail.com> wrote:
(snip)
 
> The latch is used with these processors for the exact reason you are
> looking at latches.  It allows the output of the latch to output a
> stable value from the input before the clock edge rather than after.
> This was used to speed memory accesses.

I still remember latches from when I first started learning about
TTL from Popular Electronics.  It was usual to connect a 7490 counter,
a 7475 latch and 7447 BCD to 7 segment decoder together.  You run
the counter, the display counts (maybe too fast to see), and then
latches at the appropriate time.  Sort of like a lap timer in
a race, which counts up, the latch holds the value while the
counter continues on.  After a short time the count continues
on for the next lap.  (I think they do this on olympics races.)

-- glen

Article: 145637
Subject: Re: Data2Mem ? BlockRAM ? Init BMM and MEM
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 17 Feb 2010 01:41:50 +0000
Links: << >>  << T >>  << A >>
On Tue, 16 Feb 2010 13:50:02 +0000, Symon <symon_brewer@hotmail.com> wrote:

>On 2/16/2010 12:45 PM, he wrote:
>> First you should constrain the used BRAMs to fixed locations, so you
>> don't have to recreate a new bmm file after each P&R run.
>> Most probably, you will have to write the BMM file "by hand" (see the
>> link posted by Symon, tell me if theres an automated way ;)
>
>I dimly recall analysing the RBT format, and then writing a perl script 
>that searched through the RBT file for a BRAM with contents beginning 
>"DEADBEEF", or whatever I'd tagged the BRAM with, to automatically 
>update the BMM after a PAR. However, as you point out, constraining the 
>placement was much easier.

Bitgen (at least I think it's Bitgen and not PAR) will update a BMM file for
you, with the latest placements - IF you sing the right incantations first.

The first step is to write a myfile.bmm file without the placements - using one
generated by EDK as an example is a good idea.

The second step is to feed it into "Translate" (if using the GUI) or ngdbuild
(command line) with the right options ... -bd myfile.bmm if I remember
correctly.

Check the ".bld" report file to see if the BMM file was read correctly; if not,
it's not going to report an error via the GUI or console!

Then the BMM magic disappears into the tool flow without trace.

But if the myfile.bmm is still there when Bitgen runs, the earlier magic
reappears and you might see a new myfile_bd.bmm file, annotated with the correct
BRAM placements.

There is documentation on this. But it's so well hidden that the Webcase tech
support team submitted a change request to get some written when I complained I
couldn't find any, even though it was apparently already in existence by then...

- Brian

Article: 145638
Subject: Re: using an FPGA to emulate a vintage computer
From: mac <alexc@theworld.com>
Date: Tue, 16 Feb 2010 21:53:44 -0500
Links: << >>  << T >>  << A >>
Some great stuff here.

Let me add my re-implementation of a New England Digital Able, the first 
commercial single-instruction processor.

<http://sites.google.com/site/macthenaief/Home/retro/able>
<http://sites.google.com/site/macthenaief/Home/retro/fab>

Article: 145639
Subject: Re: Data2Mem ? BlockRAM ? Init BMM and MEM
From: Brian Davis <brimdavis@aol.com>
Date: Tue, 16 Feb 2010 19:01:26 -0800 (PST)
Links: << >>  << T >>  << A >>
Symon wrote:
>
> I dimly recall analysing the RBT format, and then writing a perl script
> that searched through the RBT file for a BRAM with contents beginning
>

I've noticed a more recent ncd -> bmm generation perl script
in the OpenFire distribution that might be useful:

http://www.ccm.ece.vt.edu/~scraven/openfire.html#Download

OpenFire_release/utils/openfire_bram.pl
"
"This program creates a BMM file from an NCD and uses this to read
and
"write initial BRAM contents from a bitstream.
"
"NOTE: XDL and DATA2MEM must be installed and in the user's path.
"
"usage: $0 [-h] [-n NCD_FILE -o BMM_FILE] [-r ROM_FILE -b BITSTREAM]
"
" -h		      : this (help) message
" -n NCD_FILE	      : NCD_FILE containing placed BRAMs (default =
implementation/system.ncd)
" -o BMM_FILE	      : BMM_FILE to create (default = implementation/
openfire.bmm)
" -t top-level module  : name of the top-level OpenFire module
(default = openfire)
" -f ELF_FILE          : ELF file to place in OpenFire memory
(optional)
" -b BITSTREAM         : bitstream to update with BRAM contents
" (default = "implementation/download.bit)
" -x XDL_FILE          : use specified XDL file (w/o flag, generates
own from NCD_FILE)
" -p #                 : number of processors in design; named top-
level_module0, top-level_module1, etc.
"                           (default = 1)
"
"example: $0 -n system.ncd -o system.bmm -f openfire.elf -b
download.bit
"example: $0 -o system.bmm -p 4 -t vtmb_
"

Brian


Article: 145640
Subject: Re: EDK 11,1 on Windows 7, 32 Bit
From: Antti <antti.lukats@googlemail.com>
Date: Tue, 16 Feb 2010 21:10:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > Hi
>
> > my co-worker has a problem with EDK (used on w7, 32bit)
> > OLD project can be built but any new projexcts created stop
> > during implementation
>
> > xilinx claims that the following tablehttp://www.xilinx.com/ise/ossuppo=
rt/index.htm
>
> > is UPTODATE OS support list for Xilinx tools, in that table win7 is
> > missing
>
> > so what is wrong? is there something wrong with the installation, but
> > hey
> > why then old projects pass full flow?
>
> > any ideas?
>
> > Antti
>
> Win7 isn't a supported OS for ISE tools and it is not listed in the
> table.
>
> The tools may work under some conditions, but they likely will not
> under all conditions as your co-worker found out.
>
> Ed McGettigan
> --
> Xilinx Inc.

Hi

and thanks for clarification, I could not belive the table to be
accurate
as of today everybody DOES support w7 already ;) ok maybe not
all companies do, but most other software does run nicely on w7

Antti


Article: 145641
Subject: Re: Board layout for FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 16 Feb 2010 22:04:38 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 8:32=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> rickman <gnu...@gmail.com> wrote:
>
> (snip, I wrote)
>
>
>
> >> But, there are a few things that I think should be considered.
> >> The inductance of the via, and the input impedance of the radial
> >> transmission line are proportional to 1/r. =A0Big vias are better.
> >> A group of vias close enough together, though, should act like
> >> a large via. =A0(The fields couple such that it isn't the same
> >> as parallel inductors.)
> >> It would seem that one should also be careful not to put the FPGA
> >> right in the center of a large ground plane, such the the edge
> >> reflections come back in phase. =A0That would be especially bad for
> >> a large circular ground plane. =A0If the decoupling capacitors were
> >> regularly spaced, that could also cause in-phase reflections.
> >> > Does that sound right?
> >> It doesn't seem so far off. =A0It still seems that radial transmission
> >> line theory isn't taught much at all.
> > I am confused. =A0You say that my analysis is not far off and the whole
> > (hole) point of my analysis is to show that the radial transmission
> > line effect is not important. =A0Then you say you still think the radia=
l
> > transmission line effect *is* important.
> > I am pretty sure that the effects of the decoupling caps swamps out
> > the effect of the reflections. =A0This is not very scientific and so ma=
y
> > be totally wrong, but it would seem to me that the caps will "mute"
> > the voltage transitions on the plane as the wave moves by. =A0
>
> If it works right, the capacitor should be an AC short between the
> planes. =A0If, for example, you had a ring of capacitors around
> a constant radius from a via, then the reflection off those should
> come back in phase. =A0That is pretty much the same as a microwave
> cavity resonator. =A0

You are still talking about the reflections from the caps and I have
already shown that the caps don't cause reflections as long as they
are very close to the vias connecting the power pins.  The wavelength
of the transients are too long so that only a portion of the edge is
ever distributed across the transmission line between the via and the
cap.  The result is that the reflection is insignificant and the cap
acts to suppress the wavefront and not let it pass beyond the region
around the cap.


> > If it were
> > a linear transmission line, the cap would "smear" out the edge of the
> > wave front. =A0
>
> A capacitor across a linear transmission line should make a nice
> reflection. =A0A capacitor and series resistor should absorb some
> of the AC signal, but ignore the DC voltage. =A0Though that assumes
> ideal capacitors.

But not if the transition time of the edge is slow compared to the
transit time to the cap.  The reflection would be the opposite phase,
but much, much smaller in amplitude than the full transient.
Meanwhile the amount of the transient passing the cap would also be
very small because most of the energy is reflected.


> > In the PCB power plane the same thing happens, but it is
> > likely strongest at the cap and is a weaker effect further away from
> > the cap. =A0In the case of a transient, smearing it out reduces the
> > amplitude which is exactly what it is supposed to do. =A0So I expect th=
e
> > wave front never reaches a board edge to cause a significant
> > reflection. =A0I will say that when the impedance of a PDS is measured
> > the very high frequencies often have a sawtooth shape which is likely
> > due to standing waves on the board. =A0So there must be some of the
> > transient that is reflected.
>
> In a real board with lots of ICs, vias, and bypass capacitors,
> you would hope that the reflections are rarely in phase. =A0If parts
> are placed too regularly on the board, it would seem possible for
> some strong resonance to form. =A0

I don't mean to repeat myself endlessly, but I don't think you will
see much of the reflections.  The wave front does not pass the area
around the cap since it is absorbed by the cap.  The reflection from
the cap is opposite in phase as the original transient and is only
displaced a fraction of the width of the transient so it nearly
cancels out in all directions.  The degree to which it cancels out
depends on the time offset of the reflection which is determined by
the spacing between the cap and the power via and the strength of the
reflection which in turn depends on the impedance of the cap at that
frequency.  The reflection is a good thing, not a bad thing.  That is
what reduces the transient!


> > But if you can verify your analysis method by measuring the impedance
> > of the PDS to be below your requirements at all frequencies, what does
> > it matter if the power planes form a "radial transmission line"? =A0
>
> I think it only really matters for a very short distance. For that
> distance, though, it should be computed as a radial transmission line.

I t would seem to me to make more of a difference over a larger
distance where the impedance seen varies much more.  If you think of
it as an impedance that reduces with distance from the power via, it
would create a continuous reflection back to the via, in effect
reducing the amplitude of the transient.  Imagine many, small
reflections with only a very slight difference in phase summing up.
In effect, it would be a lot like a lumped capacitance right at the
via I think.


> > You only need to do enough analysis to get a "good enough" result.
> > I would think that if this were an important effect, that would have
> > been discovered by now.
>
> There have been plenty of cases where effects when unnoticed for
> way too long. =A0If, for example, a board resonance turned out to
> be the same as an on-board frequency it could easily be very
> significant. =A0Then an unrelated change would move the resonance,
> and the problem would go away without ever being found.

If that resonance were causing a problem, I would expect that it would
be noticed and recognized at some point.  Any given board might have
some change made which will cause the problem to "go away", but I
can't believe at this point in time no one would have ever seen this
and recognized it for what it was.  Why make up problems if they don't
exist?

Rick

Article: 145642
Subject: Re: EDK 11,1 on Windows 7, 32 Bit
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Tue, 16 Feb 2010 23:47:54 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 16, 9:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
> On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
>
>
>
>
> > On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
> > > Hi
>
> > > my co-worker has a problem with EDK (used on w7, 32bit)
> > > OLD project can be built but any new projexcts created stop
> > > during implementation
>
> > > xilinx claims that the following tablehttp://www.xilinx.com/ise/ossup=
port/index.htm
>
> > > is UPTODATE OS support list for Xilinx tools, in that table win7 is
> > > missing
>
> > > so what is wrong? is there something wrong with the installation, but
> > > hey
> > > why then old projects pass full flow?
>
> > > any ideas?
>
> > > Antti
>
> > Win7 isn't a supported OS for ISE tools and it is not listed in the
> > table.
>
> > The tools may work under some conditions, but they likely will not
> > under all conditions as your co-worker found out.
>
> > Ed McGettigan
> > --
> > Xilinx Inc.
>
> Hi
>
> and thanks for clarification, I could not belive the table to be
> accurate
> as of today everybody DOES support w7 already ;) ok maybe not
> all companies do, but most other software does run nicely on w7
>
> Antti- Hide quoted text -
>
> - Show quoted text -

ISE 11.1 was released in April while Windows 7 wasn't released until
October.

While smaller companies and academia tend to move faster with Windows
OS upgrades as the tend to use the OS sold with the PC/Laptop larger
companies in constrast don't rapidly upgrade the OS and prefer to stay
with older, stable versions.

A quick survey of other EDA tools shows

Synopsys Synplify Pro - Win XP, Win Vista, Linux, Solaris
Mentor ModelSim PE - Win XP, Win Vista (32)
Mentor ModelSim SE - Win XP, Win Vista (32), Linux (32)
Mentor ModelSim DE - Win XP, Win Vista (32/64), Linux (32/64), Solaris
(32/64)
Altera Quatrus II 9.1 - Win XP, Win Vista, Red Hat 4/5, Suse 9/10,
CentOS 4/5
Lattice ispLever - Win 2K, Win XP, Win Vista (32), Red hat 3/4, Suse
10, Solaris 2.8/10
Actel Libero - Win XP, Win Vista, Red Hat WS 4/5.2

Ed McGettigan
--
Xilinx Inc.

Article: 145643
Subject: Re: EDK 11,1 on Windows 7, 32 Bit
From: Antti <antti.lukats@googlemail.com>
Date: Wed, 17 Feb 2010 05:18:13 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 9:47=A0am, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
> On Feb 16, 9:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
>
>
>
>
> > On Feb 16, 7:21=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote:
>
> > > On Feb 15, 11:10=A0pm, Antti <antti.luk...@googlemail.com> wrote:
>
> > > > Hi
>
> > > > my co-worker has a problem with EDK (used on w7, 32bit)
> > > > OLD project can be built but any new projexcts created stop
> > > > during implementation
>
> > > > xilinx claims that the following tablehttp://www.xilinx.com/ise/oss=
upport/index.htm
>
> > > > is UPTODATE OS support list for Xilinx tools, in that table win7 is
> > > > missing
>
> > > > so what is wrong? is there something wrong with the installation, b=
ut
> > > > hey
> > > > why then old projects pass full flow?
>
> > > > any ideas?
>
> > > > Antti
>
> > > Win7 isn't a supported OS for ISE tools and it is not listed in the
> > > table.
>
> > > The tools may work under some conditions, but they likely will not
> > > under all conditions as your co-worker found out.
>
> > > Ed McGettigan
> > > --
> > > Xilinx Inc.
>
> > Hi
>
> > and thanks for clarification, I could not belive the table to be
> > accurate
> > as of today everybody DOES support w7 already ;) ok maybe not
> > all companies do, but most other software does run nicely on w7
>
> > Antti- Hide quoted text -
>
> > - Show quoted text -
>
> ISE 11.1 was released in April while Windows 7 wasn't released until
> October.
>
> While smaller companies and academia tend to move faster with Windows
> OS upgrades as the tend to use the OS sold with the PC/Laptop larger
> companies in constrast don't rapidly upgrade the OS and prefer to stay
> with older, stable versions.
>
> A quick survey of other EDA tools shows
>
> Synopsys Synplify Pro - Win XP, Win Vista, Linux, Solaris
> Mentor ModelSim PE - Win XP, Win Vista (32)
> Mentor ModelSim SE - Win XP, Win Vista (32), Linux (32)
> Mentor ModelSim DE - Win XP, Win Vista (32/64), Linux (32/64), Solaris
> (32/64)
> Altera Quatrus II 9.1 - Win XP, Win Vista, Red Hat 4/5, Suse 9/10,
> CentOS 4/5
> Lattice ispLever - Win 2K, Win XP, Win Vista (32), Red hat 3/4, Suse
> 10, Solaris 2.8/10
> Actel Libero - Win XP, Win Vista, Red Hat WS 4/5.2
>
> Ed McGettigan
> --
> Xilinx Inc.

We already have 11.4 tools

ok, the situation is not that bad, EDK 11.3 failed on W7/64
but worked somewhat on W7/32 (after some tweaking)
we still may need another vista machine as the client reqests EDK 10.x

Antti







Article: 145644
Subject: what is incorrect about my usage of array with port entity?
From: "brianwfarmer" <brian_farmer@yahoo.com>
Date: Wed, 17 Feb 2010 08:00:59 -0600
Links: << >>  << T >>  << A >>
library ieee;
library work;
use ieee.std_logic_1164.all;

use ieee.numeric_std.all;	


entity delay_line_interleaved is
	generic(	
		numtaps		: integer := 18;
		wordlength_in 	: integer := 14;
		coefflen		: integer := 20
		);
	port(
		-- INPUT PORTS --
		clkin		: in std_logic;
		rst			: in std_logic;
		ena			: in std_logic;
		in_pddc		: in std_logic_vector(wordlength_in-1 downto 0); --enough bits
here and other places to handle number of adds?
		-- OUTPUT PORTS --
		dv_out		: out std_logic;
		x_delay_line	: out array (0 to coefflen-1) of
std_logic_vector(wordlength_in-1 downto 0)
		);
end entity;

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 145645
Subject: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 06:40:42 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi,
Sometimes, when an if statement misses a "else" statement part in a
two-process
method for a state machine, a latch-type state machine would be built.

I always wondering how the state machine is built: using all latches
for the state machine
or using only one latch for the state which misses a "else" statement
part.

Here is the code.

Process_1 : process(RESET, CLK)
begin
   if RESET = '1' then
      State_A <= S0;
   elsif CLK'event and CLK = '1' then
      State_A <= State_NS;
   end if;
end process;

Process_2 : process(...)
begin
   case State_A is
      when S0 =>
         if C01 = '1' then
           State_NS <= S1;
         elsif C02 = '1' then
           State_NS <= S2;  -- missing a "else" part
                            -- a latch is generated
         end if;
      when S1 =>  -- the followings are normal coding
         ...;

      when others =>
         ...;
   end case;
end process

I ask how the state latch S0 is generated.

Here is latch logic equation:
Latch_S0_Data <= '1';
Latch_S0_E <=

Weng

Article: 145646
Subject: Re: How a state machine is constructed using latches?
From: Andy <jonesandy@comcast.net>
Date: Wed, 17 Feb 2010 07:36:35 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
> Hi,
> Sometimes, when an if statement misses a "else" statement part in a
> two-process
> method for a state machine, a latch-type state machine would be built.
>
> I always wondering how the state machine is built: using all latches
> for the state machine
> or using only one latch for the state which misses a "else" statement
> part.

A latch type state machine is not built; the latch is only inserted
into the next state logic. A flip-flop still holds the current state.

I know the following is not the point of your post, but your example
implies that missing "else" statements generate latches.

This is not true.

Missing assignments generate latches. If a driven signal in a
combinatorial process is not assigned a value in a given execution of
the process, then the simulator has to remember what the last
assignment was. The synthesis tool generates a latch to create that
memory.

Similarly for a variable in a combinatorial process, if the variable
is read before it has been written in any given execution of that
process, a latch is created to remember the last assignment.

If I use a combinatorial process (extremely rarely in RTL), I make a
default assignment to every signal & variable driven by the process,
right up front, where it is always executed (and before any variables
are read). In the case of the next state logic, it would simply be
"state_ns <=3D state_a;". That way there is no need to code useless else
statements everywhere (and all the assignments that must otherwise be
included in them).

Andy


Article: 145647
Subject: Re: Data2Mem ? BlockRAM ? Init BMM and MEM
From: saar drimer <saardrimer@gmail.com>
Date: Wed, 17 Feb 2010 07:43:52 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 3:01=A0am, Brian Davis <brimda...@aol.com> wrote:
> I've noticed a more recent ncd -> bmm generation perl script
> in the OpenFire distribution that might be useful:
>
> http://www.ccm.ece.vt.edu/~scraven/openfire.html#Download
>
> OpenFire_release/utils/openfire_bram.pl

I've recently ran into this problem, trying to avoid hard placement so
the tools are less constrained.

Brian Drummond has the right way to do it, I think -- I wish proper
documentation on how to make this happen in commandline existed. The
tools, as they do, do not tell you what's wrong on fail, so it's
mostly guesswork ("right incantations" indeed). The user guide Symon
points to doesn't deal with that type of usage directly. I ran into
trouble particularly when trying to make map accept multiple BRAM
definitions (when/if I iron all the kinks, I'll post a how-to).

Before seeing the above OpenFire script, I've also written a similar
script to do the same...

NCD -> XDL
Extract coordinates(s) of BRAMs by name from XDL
Use data2mem to insert BRAM data into bitstream

...but I consider it a hack.

saar.




Article: 145648
Subject: Re: How a state machine is constructed using latches?
From: Weng Tianxiang <wtxwtx@gmail.com>
Date: Wed, 17 Feb 2010 07:48:06 -0800 (PST)
Links: << >>  << T >>  << A >>
On Feb 17, 7:36=A0am, Andy <jonesa...@comcast.net> wrote:
> On Feb 17, 8:40=A0am, Weng Tianxiang <wtx...@gmail.com> wrote:
>
> > Hi,
> > Sometimes, when an if statement misses a "else" statement part in a
> > two-process
> > method for a state machine, a latch-type state machine would be built.
>
> > I always wondering how the state machine is built: using all latches
> > for the state machine
> > or using only one latch for the state which misses a "else" statement
> > part.
>
> A latch type state machine is not built; the latch is only inserted
> into the next state logic. A flip-flop still holds the current state.
>
> I know the following is not the point of your post, but your example
> implies that missing "else" statements generate latches.
>
> This is not true.
>
> Missing assignments generate latches. If a driven signal in a
> combinatorial process is not assigned a value in a given execution of
> the process, then the simulator has to remember what the last
> assignment was. The synthesis tool generates a latch to create that
> memory.
>
> Similarly for a variable in a combinatorial process, if the variable
> is read before it has been written in any given execution of that
> process, a latch is created to remember the last assignment.
>
> If I use a combinatorial process (extremely rarely in RTL), I make a
> default assignment to every signal & variable driven by the process,
> right up front, where it is always executed (and before any variables
> are read). In the case of the next state logic, it would simply be
> "state_ns <=3D state_a;". That way there is no need to code useless else
> statements everywhere (and all the assignments that must otherwise be
> included in them).
>
> Andy

Andy,
Good point !

Now I ask how the next state latch is generated.

Weng

Article: 145649
Subject: Re: what is incorrect about my usage of array with port entity?
From: "RCIngham" <robert.ingham@n_o_s_p_a_m.gmail.com>
Date: Wed, 17 Feb 2010 10:10:12 -0600
Links: << >>  << T >>  << A >>
VHDL doesn't allow explicitly 2-dimensional arrays as entity ports.
Why?
Because!

You will have to define a 2-D type in a package, and use that instead.

BTW, "library work;" is redundant.

HTH!

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com



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