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 104775

Article: 104775
Subject: Re: component instantiation ISE7.1
From: "MM" <mbmsv@yahoo.com>
Date: Wed, 5 Jul 2006 23:55:41 -0400
Links: << >>  << T >>  << A >>
Gary,

It seems you are thinking as if you were writing software. VHDL is a
hardware description language. You need to understand what hardware you are
trying to create. You have a separate write and read processes, which
essentially describe behaviour of a bunch (because you have more than a
single bit) of D flip-flops. The write process describes what is applied to
the D input and the read process what happens to the Q output. Thus, when
you see slv_reg in the write process on the left side of the assignment it
represents the D-input of the flip-flop, while when you see it on the right
side in the read process it represents the Q output of the same flip-flop,
i.e. stored content of the register.

/Mikhail







"gary" <rgarik@yahoo.com> wrote in message
news:3LWdnRqUwL34_zHZnZ2dneKdnZydnZ2d@giganews.com...
> >Gary,
> >
> >h doesn't have a source in your code. You need to add something like
> this:
> >h <= slv_reg0;
> >Or just use slv_reg0 instead of h as input to your inverter and in the
> read
> >process.
> >
> >/Mikhail
> >hey,
>       In user_ip.vhd file i used the following instantation in user logic
> implementation
>  h<=slv_reg0;
>  k<=slv_reg1;
> again synthesis is going on well but the same errors what i posted in my
> first message are coming again.
>
> And in the second method i disabled h & k signals directly i assigned
> portmap(slv_reg0,slv_reg1) in following way
> ------------
> component inverter
> port( s : in std_logic_vector(0 to 31);
>            t : out std_logic_vector(0 to 31));
>  end component;
>
>    ---attribute box_type : string;
>     --attribute box_type of inverter : component is "black_box";
>
> begin
>
> we: inverter
>   port map(slv_reg0,slv_reg1);
> ----------------------------
> while synthesis following errors are generated....
>
> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal <slv_reg1<9>>
> Sources are:
>    Output signal of OBUF instance <we/t_9_OBUF>
>    Output signal of FDRE instance <slv_reg1_9>
>
> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
> <slv_reg1<13>>
> Sources are:
>    Output signal of OBUF instance <we/t_13_OBUF>
>    Output signal of FDRE instance <slv_reg1_13>
>
> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
> <slv_reg1<21>>
> Sources are:
>    Output signal of OBUF instance <we/t_21_OBUF>
>    Output signal of FDRE instance <slv_reg1_21>
>
> ERROR:Xst:528 - Multi-source in Unit <user_logic> on signal
> <slv_reg1<27>>
> Sources are:
>    Output signal of OBUF instance <we/t_27_OBUF>
>    Output signal of FDRE instance <slv_reg1_27>
> ----------------for all 0 to 31----------------------------
> /gary
>
>
>
>
>



Article: 104776
Subject: How much time does it need to sort 1 million random 64-bit/32-bit integers?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 5 Jul 2006 20:58:08 -0700
Links: << >>  << T >>  << A >>
Hi,
Can I find a website that lists the time for sorting 1 million
64-bit/32-bit random data using the fastest software sorting algorithm
in a PC?

Thank you.

Weng


Article: 104777
Subject: Re: How much time does it need to sort 1 million random 64-bit/32-bit integers?
From: Richard Heathfield <invalid@invalid.invalid>
Date: Thu, 06 Jul 2006 04:08:15 +0000
Links: << >>  << T >>  << A >>
Weng Tianxiang said:

> Hi,
> Can I find a website that lists the time for sorting 1 million
> 64-bit/32-bit random data using the fastest software sorting algorithm
> in a PC?

Apparently not.

Note that, even if you could, such results would be highly 
hardware-dependent (although the /relative/ ordering of various sorting 
algorithms should be fairly consistent on any given platform). PCs vary 
wildly in performance characteristics. The first PC I used was an Atari ST, 
running at - what was it, 8 MHz? The first IBM-compatible I used was an 
8088 running at - er, I forget, but it was in the 8-12MHz range, I think. 
The first PC I /owned/ was an 80386-SX running at 20MHz. Whoa, that baby 
was *fast*. Currently, I'm using a PIII which is probably a brazillion 
times faster than the 386. The term "a PC" doesn't mean a lot when it comes 
to benchmarking.

I suggest you just write up the algorithms yourself, or grab them off the 
Net, and try them on your own hardware.

Beware of the results being corrupted by caching. Do not measure I/O times. 
Do each test a few hundred times.

-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Article: 104778
Subject: Re: stable reset in fpga
From: saumyajit_tech@yahoo.co.in
Date: 5 Jul 2006 21:28:59 -0700
Links: << >>  << T >>  << A >>

Mike Lewis wrote:
> "mk" <kal*@dspia.*comdelete> wrote in message
> news:2iqma2the96cnlaujjgi40c5fv4tngc05o@4ax.com...
> > On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote:
> >
> >>2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in
> >>the reset ckt. I am afraid, it vilaotes the basic rule of
> >>controllability of DFT.  I should be able to control the state of all
> >>the FFs from a single reset pin out side the chip.  is not it true ?
> >
> > You can always insert control points after your reset logic so that
> > when you enable test the flops become externally controllable again.
> > It's easy to do this with current scan insertion tools.
>
> I thought we were talking about FPGAs ... the DFT logic for the FPGA is
> already in the FPGA and is completely independant of the design that you put
> in the FPGA. You don't use scan insertion tools for FPGAs .. that's ASIC
> land.
>
> Mike

Yes Mike, you are right.  There is no point in talking abut DFT logic
in the FPGAs.  Even I have mentioned this point in my post.

I was expecting some comment on the first point that I had mentioned
(regarding the Reset).

1) Here, I assume that the reset we are talking about is the Power ON
Reset which is connected to a switch (or equivalent ckt) in the board.
If this is the case, then the reset period is much more  higher than
some miliseconds.

In case the dcm lock pin is being used as the core reset, then also we
should not be much worried about the reset pulse width.  As the DCM
needs number of clock cycles before getting locked.

any expert comments on this is highly appreciated.

Regards,
Saumyajit


Article: 104779
Subject: DDR Controller problems
From: David <simianfever@gmail.com>
Date: Wed, 5 Jul 2006 22:29:43 -0700
Links: << >>  << T >>  << A >>
Hi All,

I'm trying to get a DDR controller fo r the Micron MT46V16M16TG-75 up and running on a Memec V2MB1000 dev board but not having much luck so far.

I initially tried the Opencores ddr_sdr which seemed to be sending the correct signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written - presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail.

In the last couple of days I've been trying a similar thing in EDK 8.1 - I downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated.

Thanks,

David

Article: 104780
Subject: Re: stable reset in fpga
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 5 Jul 2006 22:36:24 -0700
Links: << >>  << T >>  << A >>
The length of the asynchronous signal is not the issue. Make it several
minutes long, and you still face the issue of asynchronous
de-assertion, which can laeve some flip-flops being reset longer than
others. And potentially several clock ticks longer than others if the
system clock rate is high.
So, use SRL16 to avoid that problem...
Peter Alfke, Xilinx (from home)
=========
saumyajit_tech@yahoo.co.in wrote:
> Mike Lewis wrote:
> > "mk" <kal*@dspia.*comdelete> wrote in message
> > news:2iqma2the96cnlaujjgi40c5fv4tngc05o@4ax.com...
> > > On 5 Jul 2006 00:07:24 -0700, saumyajit_tech@yahoo.co.in wrote:
> > >
> > >>2) My point number 2 is reagrding putting some logic( SRL16, FFs..) in
> > >>the reset ckt. I am afraid, it vilaotes the basic rule of
> > >>controllability of DFT.  I should be able to control the state of all
> > >>the FFs from a single reset pin out side the chip.  is not it true ?
> > >
> > > You can always insert control points after your reset logic so that
> > > when you enable test the flops become externally controllable again.
> > > It's easy to do this with current scan insertion tools.
> >
> > I thought we were talking about FPGAs ... the DFT logic for the FPGA is
> > already in the FPGA and is completely independant of the design that you put
> > in the FPGA. You don't use scan insertion tools for FPGAs .. that's ASIC
> > land.
> >
> > Mike
>
> Yes Mike, you are right.  There is no point in talking abut DFT logic
> in the FPGAs.  Even I have mentioned this point in my post.
>
> I was expecting some comment on the first point that I had mentioned
> (regarding the Reset).
>
> 1) Here, I assume that the reset we are talking about is the Power ON
> Reset which is connected to a switch (or equivalent ckt) in the board.
> If this is the case, then the reset period is much more  higher than
> some miliseconds.
>
> In case the dcm lock pin is being used as the core reset, then also we
> should not be much worried about the reset pulse width.  As the DCM
> needs number of clock cycles before getting locked.
>
> any expert comments on this is highly appreciated.
> 
> Regards,
> Saumyajit


Article: 104781
Subject: Re: How much time does it need to sort 1 million random 64-bit/32-bit
From: Mark McDougall <markm@vl.com.au>
Date: Thu, 06 Jul 2006 16:21:13 +1000
Links: << >>  << T >>  << A >>
Weng Tianxiang wrote:

> Can I find a website that lists the time for sorting 1 million
> 64-bit/32-bit random data using the fastest software sorting algorithm
> in a PC?

Given that you can't even find the relevant usenet newsgroup to ask this 
question... I highly doubt it.

That aside...

The "fastest" algorithm is going to depend on a few things; for example 
the actual 'randomness' of the data (its distribution), the format of 
said data and the results (e.g. do you need to sort in-place?), and the 
implementation of the algorithm (by which I mean, is the algorithm 
optimal for implementation in a typical PC?).

You definitely won't find any answers on the absolute time required by a 
"PC" - whatever that is. And even if you did, the answer would be 
obsolete in about a week's time.

You really need to find one or two candidate algorithms and then 
implement them on your chosen platform to get any meaningful solution to 
your problem.

Regards,

-- 
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

Article: 104782
Subject: Re: Incorporating CoreGen files in EDK 8.1 peripheral
From: =?ISO-8859-1?Q?Johan_Bernsp=E5ng?= <xjohbex@xfoix.se>
Date: Thu, 06 Jul 2006 08:29:07 +0200
Links: << >>  << T >>  << A >>
Jim Wu wrote:
> You may have already done this, but I thought to point it out anyway:
> 
> Make sure that the core netlist (edn, etcc) is in the directory like
> this
> 
> pcores/your_core_v_1_00a/netlist
> 
> And the bbd file should have lines like below:
> FILES
> your_netlist_names
> 
> HTH,
> Jim
> http://home.comcast.net/~jimwu88/tools/
> 
> 
> Guru wrote:
>> Hi folks,
>>
>> I have a problem and I need a clean solution:
>> I created an OPB peipheral which includes AsyncFIFO (created with FIFO
>> generator). I have included the edn (tried also with ngc) in bbd file
>> and a VHDL wrapper (original, created by CoreGen). During build I get
>> the following error:
>> ERROR:NgdBuild:604 - logical block 'imam_0/imam_0/FIFO' with type
>>    'async_fifo' could not be resolved. A pin name misspelling can cause
>> this, a
>>    missing edif or ngc file, or the misspelling of a type name. Symbol
>>    'async_fifo' is not supported in target 'virtex4'.
>> I did managed to overcome the problem somehow several times by changing
>> bbd and netlist filenames, but the problem comes to the surface every
>> time I clean all the EDK project files.
>>
>> Guru
> 

Hi Guru,

I solved that problem (when I experienced it) by adding the line
OPTION STYLE = MIX
to my mpd file.

/Johan

-- 
-----------------------------------------------
Johan Bernspång, xjohbex@xfoix.se
Research engineer

Swedish Defence Research Agency - FOI
Division of Command & Control Systems
Department of Electronic Warfare Systems

www.foi.se

Please remove the x's in the email address if
replying to me personally.
-----------------------------------------------

Article: 104783
Subject: Re: Altium Live Desing Eval and Linux
From: eric <erixx@gmx.net>
Date: Thu, 06 Jul 2006 09:02:00 +0200
Links: << >>  << T >>  << A >>
Ok, thanks. If linux wont work,
what about ECOS, VxWorks,....?
Do You have an Idea?

Eric


Antti schrieb:
> eric schrieb:
> 
>> Is there an implementation of Linux for the
>> Live Design Eval Board(Xilinx). May be a version of
>> uCLinux for Mircoblaze?
>>
>> Thx
>>
>> Eric
> 
> Hi Eric,
> 
> The Live Design Eval Board has only 1MB of RAM, there are some reports
> getting mb-uclinux working with small (less than 4MB) memory but there
> is no 'get it working in 1MB solution' - this is one problem.
> 
> You can make a Microblaze design that is 'uclinux ready' and test it on
> livedesign board, but you should use EDK for that in order to have the
> supported peripheral in place (OPB_INTC, OPTB_Timer, OPB_UARTLITE)
> 
> An interesting thing would of course be microblaze uclinux system
> design without EDK using Altium Designer as SoC tool - unfortunatly
> such a design does not exist - well the SDRAM support was added to
> Altium Designer only in the release 6.3 (from 26 June 2006?), so there
> is defenetly no uclinux that would work on system made with Altium
> Designer.
> 
> Antti
> http://antti-brain.com
> 

Article: 104784
Subject: Re: Weird timing failure
From: saumyajit_tech@yahoo.co.in
Date: 6 Jul 2006 00:09:07 -0700
Links: << >>  << T >>  << A >>
In addition to the above options, I have some more in my mind.

1) Try using the guided file.
If you have the old set up( Which meets the timing), then use it as a
guided file for the new set -up. You will have various modes of using
guided file, like exact, ....You have to choose the proper option.

2) The next option that comes to mind is "give proper constarint to the
path which is failing".

Regards,

Saumyajit


Gabor wrote:
> JL wrote:
> > Hello,
> >
> > I am using Xilinx ISE 7.1 and VHDL for a project deployed in a Virtex2
> > FPGA. I place&route and then I run the static timing analyzer. Results
> > throw a timing constrain not met (see below). The weird thing is that
> > it happens after I removed some logic from the project, without adding
> > anything new. My understanding is that adding new logic could make
> > place&route harder, but removing logic would give us more room to find
> > a better allocation of resources. Any hints?
>
> Depending on how much you constrain the internals of a design, you
> may see improvement when the design becomes smaller.  However in
> a relatively unconstrained placement, the placer starts with a seed and
> pseudorandomly starts to place the components.  Because of the nature
> of this placement, any change can affect the timing in any direction.
>
> My suggestion if you have a design that once met the timing and
> then does not after removing logic, is to try a different setting for
> the "Starting Placer Cost Table" under the properties for place&route.
> You may need to select Advanced properties display to see this.
> This number is the seed for starting the pseudorandom placement.
> Changing it can often help your results.  If after one or two tries you
> still don't meet timing, you can use multipass place&route, which
> automates the process of "Cost Table" selection.
> 
> Good Luck,
> Gabor


Article: 104785
Subject: Re: Altium Live Desing Eval and Linux
From: "Antti" <Antti.Lukats@xilant.com>
Date: 6 Jul 2006 00:41:30 -0700
Links: << >>  << T >>  << A >>
eric schrieb:

> Ok, thanks. If linux wont work,
> what about ECOS, VxWorks,....?
> Do You have an Idea?
>
> Eric
>

1 VxWorks only supports PPC not MicroBlaze
2 eCos is not ported to MicroBlaze either

so both of them will not work on the live design eval board

uC/OS would defenetly work, for some while ago I tested it on
Microblaze, I think I got it all fitted into BRAMs, with 1MB SRAM you
should have no problems

Antti
http://antti-brain.com


Article: 104786
Subject: Re: Chaos in FF metastability
From: "Daniel Lang" <invalid@invalid.caltech.edu>
Date: Thu, 6 Jul 2006 00:42:32 -0700
Links: << >>  << T >>  << A >>

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message 
news:uocla2t93lffghk9705huv57gviq6gega9@4ax.com...
> "rickman" <spamgoeshere4@yahoo.com> wrote:
>
>>What feature about the CMOS latch makes it impossible to oscillate?  My
>>understanding is that there are two nodes with logic driving them to
>>opposite polarities.  If the FF is driven into metastability the two
>>nodes can be driven to the same state which due to the logic, is
>>unstable.  since there is a delay from the input to the output of each
>>node, it should be possible for each node to drive the other to  the
>>opposite state, then  both nodes will be in the other state and drive
>>the other node to the original state, etc.  What prevents this in CMOS
>>logic?
>
> Disclaimer: naive understanding exposed herein, without benefit
> of clear understanding of control theory :-)
>
> Roughly, I think it's because the CMOS latch circuit has only 2 gain
> stages in its loop, and both of them have delays that are dominated
> by an RC effect (first-order) and, by comparison, its time delays are
> negligible.  So the whole thing is quite highly damped. By contrast,
> TTL latch circuits often had rather more gain stages, I think.  If you
> simply cross-couple a pair of bipolar transistors you get an
> embarrassingly slow circuit; TTL used all kinds of tricks to make
> it faster - remember that NPN transistors were cheap, but just
> about any other kind of component on TTL was troublesome
> to make.
>
> If you use an ordinary digital simulator to model a two-inverter
> feedback loop, and give each inverter a pure time delay, it's
> easy to make the thing oscillate  by prodding it appropriately.
> But if the two inverting gain stages have a first-order RC-type
> lag that swamps their propagation delay, an analog simulation
> will show the thing settling monotonically after any disturbance from
> its metastable "balance point".
>

If you have studied Op-amps, which have negative feedback instead
of positive feedback, you are probably familiar with the bode plot.
http://en.wikipedia.org/wiki/Bode_plot

The key to stabilizing the op-amp is to insure that the feedback
gain (open loop gain/closed loop gain) drops below unity before
the additional phase shift reaches 180 degrees.  For instance,
take a look at the Open Loop Gain and Phase plots on page 7:
http://cache.national.com/ds/LM/LMH6624.pdf
In this case, the phase shift reaches 180 degrees at about 250
MHz while the gain is still 10dB.  If you use this op-amp in
a unity gain application, it will oscillate (hence the
recommendation to use it for gains of 10 or greater).

A similar analysis applies to flip-flops.  The main difference
is that here the feedback is positive (-360 degrees) and so
latching to one side or the other is a stable state.  If
you get an additional -360 degrees of phase shift before
the open loop gain reaches zero, the device can oscillate
at that freqency if stimulated properly.

2 gain stages with single pole RC roll-off will have a maximum
additional phase shift of -180 degrees.  Cascading 4 or more
gain stages will usually ensure that the phase shift exceeds
-360 degrees before unity gain is reached due to the presence
of higher order poles & wire delays.

Daniel Lang



Article: 104787
Subject: Re: Chaos in FF metastability
From: Jonathan Bromley <jonathan.bromley@MYCOMPANY.com>
Date: Thu, 06 Jul 2006 09:12:37 +0100
Links: << >>  << T >>  << A >>
Daniel Lang <invalid@invalid.caltech.edu> wrote:

>If you have studied Op-amps, which have negative feedback instead
>of positive feedback, you are probably familiar with the bode plot.

Yup.  Studied, used, taught about :-)

>The key to stabilizing the op-amp is to insure that the feedback
>gain (open loop gain/closed loop gain) drops below unity before
>the additional phase shift reaches 180 degrees.

Indeed.  That's a nice simple explanation that's often missing
from the textbooks.

>A similar analysis applies to flip-flops.  The main difference
>is that here the feedback is positive (-360 degrees) and so
>latching to one side or the other is a stable state.  If
>you get an additional -360 degrees of phase shift before
>the open loop gain reaches zero, the device can oscillate
>at that freqency if stimulated properly.

OK, thanks for that insight - the (rather obvious) point I'd
missed was that you need an extra *360deg* of phase
shift to get the thing to oscillate, not 180deg.

>2 gain stages with single pole RC roll-off will have a maximum
>additional phase shift of -180 degrees.  Cascading 4 or more
>gain stages will usually ensure that the phase shift exceeds
>-360 degrees before unity gain is reached due to the presence
>of higher order poles & wire delays.

OK.  Thanks for the nice and appropriate description.
-- 
Jonathan Bromley, Consultant

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

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

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

Article: 104788
Subject: Re: DDR Controller problems
From: "PeterSmith1954@googlemail.com" <PeterSmith1954@googlemail.com>
Date: 6 Jul 2006 01:35:21 -0700
Links: << >>  << T >>  << A >>
David wrote:
> Hi All,
>
> I'm trying to get a DDR controller fo r the Micron MT46V16M16TG-75 up and running on a Memec V2MB1000 dev board but not having much luck so far.
>
> I initially tried the Opencores ddr_sdr which seemed to be sending the correct signals to the RAM when I checked with a scope, but DQS was not being strobed during the read cycle and the controller was reading back the last value written - presumably because of the bus capacitance. After reading a few discussions I got the idea that my external clock might be skewed, but I was unsure of how to calculate the necessary phase shift as I have no idea how long the feedback trace is (the feedback and clock pins are right next to each other on the package however so I would imagine it would be pretty short). I tried various speculatory values for the phase shift to no avail.
>
> In the last couple of days I've been trying a similar thing in EDK 8.1 - I downloaded the XBD files for the board from Avnet and set up a simple memory test project using the OPB DDR controller. The test passes for the flash memory and then freezes when it gets to the DDR and returns neither a pass or a fail. I'm kinda stuck here and unsure what to try next - is it possible that there's a problem with the board? Any help you guys could give me would be much appreciated.
>
> Thanks,
>
> David

If DQS is not being strobed during the read cycle, then a number of
things may be wrong:

1. Clocks completely wrong relative to command. If this were the case,
the initial setup of the mode and extended mode registers in the DDR
would fail.

2. Address/data/command/clock skew. You already alluded to this and it
would easily cause even the setup to fail.

Something that is unknown is whether your writes are succeeding - and
that's not possible to know if you don't get a read strobe.

I would suggest, however, that if you don't even get a read strobe, the
DDR is either :

a. Not properly connected (check your UCF pin locations)
b. Defective.
c. Not being given a proper read cycle command
d. Not being properly initialised.
e. Not getting precharged (some DDR won't respond with read strobes
unless precharge has been done in the last n cycles). See a typical DDR
datasheet (micron does the best ones) for details.

For d, make sure you are actually initialising the device
Others could implicate clock/data/address/command skew.


I do not know your level of knowledge with DDR itself, but I can assure
you (having laid down DDR on my own boards, using chips as well as
using sticks) that the slightest thing wrong in connectivity will
render it useless.

Cheers

PeteS


Article: 104789
Subject: Re: Incorporating CoreGen files in EDK 8.1 peripheral
From: "Guru" <ales.gorkic@email.si>
Date: 6 Jul 2006 02:10:02 -0700
Links: << >>  << T >>  << A >>
Actually I have done all of that that what you suggested.

The problem is actually that during synthesis async_fifo.ngc is not
copied to project/implementation/my_peripheral_0_wrapper directory. If
I copy it manually the it works, otherwise not - weird behaviour. Maybe
synthesis on the fly can help, since Xilinx peripherals are done that
way (fifo in opb_ddr for instance).

Guru


Article: 104790
Subject: Re: Inferring multiple-DSP48 pipelined multiplier in VHDL
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 6 Jul 2006 02:53:03 -0700
Links: << >>  << T >>  << A >>
OK,

so if I've understood this properly, instead of registering the inputs
by differing amounts in order to account for the PREG cascade at the
outputs, everything is getting (pointlessly) registered by the same
amount at the input, and then summed together combinatorily at the
output of DSP48s, followed by some more pointless registering occurs at
the output?

My interest in this is fairly academic really... The design from which
this question arose has a 35x35 multiplier generated using CoreGen, so
it works fine. It would be useful from a design methodology perspective
to have the ability to infer the DSP48s in such a simple manner. It
would make autogenerating VHDL for different pipelined multiplier
structures a walk in the park. I'm not necessarily of the opinion that
this should be possible today, just that it would be really nice and
when I came across sources that suggested it was possible to do this in
a high performance manner I decided to try it. (XtremeDSP for Virtex-4
FPGAsUser Guide, www.xilinx.com/bvdocs/userguides/ug073.pdf
& Philippe Garrault, Accelerate design performance with HDL coding
practices)

I've been really impressed with both the informal (via Ben Jones) and
formal (via tech support) reaction to me bringing this up with Xilinx,
so even if this has all come from me being a bit naive about the
capabilities of XST, there seem to be people in Xilinx who believe that
we should be able to be so naive and expect good performance at the
same time.

Still very much a beginner,

Robin

>Ray Andraka wrote:
> Robin Bruce wrote:
>
> > Martin,
> >
> >
> >>Have you had a look in FPGA editor to see what's going on?
> >
> >
> > This is where I myself look dim: I did open up the NCD file in the FPGA
> > Editor. I didn't really know what to do to tell if the right
> > registering was occurring. All I could see was that all 4 DSP48s were
> > instantiated together in a little row. I've never used FPGA editor
> > before. I'm more familiar with PlanAhead for looking at that sort of
> > thing, but I don't have that on my laptop, my current working platform.
> >
> >
> >>Is it actually this bit of code that limits the timing?
> >
> >
> > Well, all I can say is that I don't think so. It could very well be
> > though, but I've tried writing the VHDL in very different ways, guided
> > by things I've found in one or two guides to instantiating the DSP48s
> > in VHDL. Every way I write the VHDL, the same performance is obtained.
> > The thing is that I can see that the synthesis tool is making some kind
> > of effort to pipeline the thing.
> >
> > This is the critical path that comes out of the synthesis report if
> > this means anything to anyone:
> >
> >   Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> >                                 Gate     Net
> >     Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
> >     ----------------------------------------  ------------
> >      DSP48:CLK->PCOUT47    1   4.399   0.000  mult_inst/Mmult__n00001
> > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> >      DSP48:PCIN47->PCOUT47    1   2.363   0.000
> > mult_inst/Mmult__n00002
> > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> >      DSP48:PCIN47->PCOUT47    1   2.363   0.000
> > mult_inst/Mmult__n00003
> > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> >      DSP48:PCIN47->P35     1   2.270   0.534  mult_inst/Mmult__n00004
> > (mult_inst/Mmult__n0000_s_69)
> >      FD:D                      0.391          mult_inst/Mmult__n0000_0
> >     ----------------------------------------
> >     Total                     12.320ns (11.786ns logic, 0.534ns route)
> >                                        (95.7% logic, 4.3% route)
> >
> > Cheers,
> >
> > Robin
> >
>
> Your design is not inferring the P register, so the adders are
> combinatorial.  The adders get connected in a daisy chain.  You may have
> to recode your RTL to reflect that, as the synthesizer is not really
> smart enough to push around the registers to the degree necessary to
> deal with differing latencies among the adder inputs.


Article: 104791
Subject: Simulation problem for the DDR controller
From: "subint" <subin.82@gmail.com>
Date: 6 Jul 2006 03:17:00 -0700
Links: << >>  << T >>  << A >>
Hi,
  I am using the DDR controller(generated by MIG1.5) for the ddr
MT46V32M16 -6 for the board V4MBlx60. I am getting the expected result
in simulation with the hdl code generated by the MIG.But when i tried
to simulate the post-par model of the code all interfaces to the ddr
are driven with x.Any idea.
thanks in advance
subin


Article: 104792
Subject: Re: How much time does it need to sort 1 million random 64-bit/32-bit
From: Kolja Sulimma <news@sulimma.de>
Date: Thu, 06 Jul 2006 12:20:26 +0200
Links: << >>  << T >>  << A >>
Weng Tianxiang schrieb:
> Hi,
> Can I find a website that lists the time for sorting 1 million
> 64-bit/32-bit random data using the fastest software sorting algorithm
> in a PC?

That depends on a lot of parameters, but I can give you one datapoint as
an example:
- Sorting 16777216 pair wise different 24-bit numbers takes no time at all.

Kolja Sulimma

Article: 104793
Subject: Re: How much time does it need to sort 1 million random 64-bit/32-bit integers?
From: "Weng Tianxiang" <wtxwtx@gmail.com>
Date: 6 Jul 2006 05:35:49 -0700
Links: << >>  << T >>  << A >>
Hi,
Actually I read the related article in a website that lists the timing
run by the author, but I couldn't find it again.

For example, he lists times in parallel with number of data, the
frequency of his computer and all related parameters that may affect
the performance, he also lists the performances using different
algorithms to do a comparison and made some conclusions.

Thank you.

Weng


Article: 104794
Subject: Re: Chaos in FF metastability
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 6 Jul 2006 05:37:54 -0700
Links: << >>  << T >>  << A >>
Jim Granville wrote:
> rickman wrote:
> > But you have not responded as to why the FF can not oscillate.  The FF
> > is more than just a penl standing on end or a ball on a hill.  A FF is
> > a dynamic system with feedback and delays.  My schooling taught me that
> > with the right combination of delay and gain (or the wrong combination)
> > it can oscillate.  What makes these FFs different?
> >
> > The pen analogy is not a lot different from the pendulum.  Yet a
> > pendulum can be chaotic!  I think the pen is only good as a first order
> > approximation.  For this sort of issue, the analogy requires further
> > scrutiny.
>
> Put this into a Spice pgm, and try it.

Two reasons why I can't... 1) I don't have Spice  2)  I don't have
"this".


> In fact, (good) spice should be able to show the settling-time-extension
> effects of metastability quite well. It would need carefull sweep
> of the drive voltage, at the instant the clock does the hand-over.

I am sure it can, but several posts here claim that CMOS FFs can't
oscillate and I am asking how people know this is a true fact.
Obviously simulating it or hooking up a test circuit can't prove it
won't oscillate.  That can only prove it won't oscillate under those
conditions.


> The FF I am used to, is Analog transmission gates, around single
> CMOS INV/OR gates - two forming the regenerative latch.
>
> These simple 'unbuffered' CMOS structures have finite analog gain, even
> at their peak, in the linear region. (unlike TTL ones )

Why do you call this "unbuffered"?  Don't the gates create gain and
delay?  The more I think about this, the more I am starting to believe
that a FF is capable of chotic behavior.

> To build an oscillator, you must hold them in the linear region (DC),
> and provide phase shift at some other frequency, where the loop
> gain is still over unity.

I don't think that is true.  The TTL FFs (or coupled inverters) that
oscillate don't remain in the linear region.  They peg the rails and
the delays cause them to peg to the other rail when the feedback takes
effect.

> Yes, there are parasitics all around, but the FF lacks the linear-bias
> mechanism, so it cannot sustain oscillation.
>
> I am sure some would look pretty knarly, as they settled, and may not
> be monotonic, but these times will be very short.
> During this settling time, they will also be at their most sensitive to
> crosstalk effects.


Article: 104795
Subject: Re: "Large" memory array in VHDL
From: "Ricardo" <rtafas@gmail.com>
Date: 6 Jul 2006 06:25:58 -0700
Links: << >>  << T >>  << A >>
The FPGA and RAM datasheet are very good starting points. The
interface, well, the IO pins are there just for that purpouse.

You may try google, opencores, hamburg hdl archive...

Regards,


Alex escreveu:

> Thanks to everyone who has replied.
>
> Can anyone point me to a good resource on learning to interface the
> FPGA with a RAM chip?  I'm using VHDL for everything in the FPGA.  The
> more example VHDL I can see, the better.
>
> This is a project that landed in my lap that I'm having to learn a lot
> for as I go.  The more resources I have to learn how to use this FPGA
> and VHDL, the better.
> 
> Thank you.
> 
> Alex McHale


Article: 104796
Subject: FPGA interpolated FIR implementation
From: "Dario" <dario.locci@gmail.com>
Date: 6 Jul 2006 06:40:02 -0700
Links: << >>  << T >>  << A >>
Hi everyone!
I write here, after having googled for some days, because I'm looking
for some advices. I'm working, for my thesi, on a lowpass FIR filter
for its implementation in a Altera FPGA (my tutor is on holiday and I
haven't idea of exact model of this, but I think it is a very good
board).
Now, I choose to design an Interpolated filter, with a cascade of 2 FIR
with symmetric transposed structure. I've discard direct form structure
because the filter is long (about 100taps) and I need a clock frequency
of about 50MHz. I know there are others structures, like second order
cells, or bufferized direct form, but I think transposed choice is
better for area occupation and pipeline improvements. Is it correct?

Then, the filter is a base band filter, with 2 input signals, real part
and imaginary part. I think to develop the filter for real part and
replicate it for the imaginary part. Are there better ways to do this?

And, last but not least, I would use RADn or other algorithm for
avoiding multiplicators, because the filter is with constant
coefficients. Did some of you use any of these algorithms?

Thank you very much to all the people to answer this message.
Best regards
Dario

PS: I'm sorry for my written English...


Article: 104797
Subject: Re: Xilinx ML461 memory board, whats the real story?
From: "lecroy7200@chek.com" <lecroy7200@chek.com>
Date: 6 Jul 2006 07:27:27 -0700
Links: << >>  << T >>  << A >>
Peter,
You were right, I had to go thru the FAE to get the files.  I received
them today and started comparing them with what was on the original CD
included with the board.  There appears to be a few extra files on the
CD, but most of the files seem the same.  If I load FPGA 4 into ISE 7,
it still errors out in the mapper.   I had tried to build this with
version 6 last summer as well when we first purchased the board.

Is there an inside verion of the projects for all four FPGAs that will
build without errors and work(exorcise the memory) or was this similar
to the LCD display / memory test?


Article: 104798
Subject: Re: Inferring multiple-DSP48 pipelined multiplier in VHDL
From: "Robin Bruce" <robin.bruce@gmail.com>
Date: 6 Jul 2006 08:23:00 -0700
Links: << >>  << T >>  << A >>
Guys,

Given feedback I've had from Xilinx, It seems that this is something
that should be possible today but isn't. Apparently a bugfix has been
made that should fix this and it will be released with ISE 9.1

Robin

Robin Bruce wrote:
> OK,
>
> so if I've understood this properly, instead of registering the inputs
> by differing amounts in order to account for the PREG cascade at the
> outputs, everything is getting (pointlessly) registered by the same
> amount at the input, and then summed together combinatorily at the
> output of DSP48s, followed by some more pointless registering occurs at
> the output?
>
> My interest in this is fairly academic really... The design from which
> this question arose has a 35x35 multiplier generated using CoreGen, so
> it works fine. It would be useful from a design methodology perspective
> to have the ability to infer the DSP48s in such a simple manner. It
> would make autogenerating VHDL for different pipelined multiplier
> structures a walk in the park. I'm not necessarily of the opinion that
> this should be possible today, just that it would be really nice and
> when I came across sources that suggested it was possible to do this in
> a high performance manner I decided to try it. (XtremeDSP for Virtex-4
> FPGAsUser Guide, www.xilinx.com/bvdocs/userguides/ug073.pdf
> & Philippe Garrault, Accelerate design performance with HDL coding
> practices)
>
> I've been really impressed with both the informal (via Ben Jones) and
> formal (via tech support) reaction to me bringing this up with Xilinx,
> so even if this has all come from me being a bit naive about the
> capabilities of XST, there seem to be people in Xilinx who believe that
> we should be able to be so naive and expect good performance at the
> same time.
>
> Still very much a beginner,
>
> Robin
>
> >Ray Andraka wrote:
> > Robin Bruce wrote:
> >
> > > Martin,
> > >
> > >
> > >>Have you had a look in FPGA editor to see what's going on?
> > >
> > >
> > > This is where I myself look dim: I did open up the NCD file in the FPGA
> > > Editor. I didn't really know what to do to tell if the right
> > > registering was occurring. All I could see was that all 4 DSP48s were
> > > instantiated together in a little row. I've never used FPGA editor
> > > before. I'm more familiar with PlanAhead for looking at that sort of
> > > thing, but I don't have that on my laptop, my current working platform.
> > >
> > >
> > >>Is it actually this bit of code that limits the timing?
> > >
> > >
> > > Well, all I can say is that I don't think so. It could very well be
> > > though, but I've tried writing the VHDL in very different ways, guided
> > > by things I've found in one or two guides to instantiating the DSP48s
> > > in VHDL. Every way I write the VHDL, the same performance is obtained.
> > > The thing is that I can see that the synthesis tool is making some kind
> > > of effort to pipeline the thing.
> > >
> > > This is the critical path that comes out of the synthesis report if
> > > this means anything to anyone:
> > >
> > >   Data Path: mult_inst/Mmult__n00001 to mult_inst/Mmult__n0000_35
> > >                                 Gate     Net
> > >     Cell:in->out      fanout   Delay   Delay  Logical Name (Net Name)
> > >     ----------------------------------------  ------------
> > >      DSP48:CLK->PCOUT47    1   4.399   0.000  mult_inst/Mmult__n00001
> > > (mult_inst/Mmult__n00002_PCIN_to_mult_inst/Mmult__n00001_PCOUT_47)
> > >      DSP48:PCIN47->PCOUT47    1   2.363   0.000
> > > mult_inst/Mmult__n00002
> > > (mult_inst/Mmult__n00003_PCIN_to_mult_inst/Mmult__n00002_PCOUT_47)
> > >      DSP48:PCIN47->PCOUT47    1   2.363   0.000
> > > mult_inst/Mmult__n00003
> > > (mult_inst/Mmult__n00004_PCIN_to_mult_inst/Mmult__n00003_PCOUT_47)
> > >      DSP48:PCIN47->P35     1   2.270   0.534  mult_inst/Mmult__n00004
> > > (mult_inst/Mmult__n0000_s_69)
> > >      FD:D                      0.391          mult_inst/Mmult__n0000_0
> > >     ----------------------------------------
> > >     Total                     12.320ns (11.786ns logic, 0.534ns route)
> > >                                        (95.7% logic, 4.3% route)
> > >
> > > Cheers,
> > >
> > > Robin
> > >
> >
> > Your design is not inferring the P register, so the adders are
> > combinatorial.  The adders get connected in a daisy chain.  You may have
> > to recode your RTL to reflect that, as the synthesizer is not really
> > smart enough to push around the registers to the degree necessary to
> > deal with differing latencies among the adder inputs.


Article: 104799
Subject: Re: Inferring multiple-DSP48 pipelined multiplier in VHDL
From: "Andy" <jonesandy@comcast.net>
Date: 6 Jul 2006 08:49:32 -0700
Links: << >>  << T >>  << A >>
It may take a little effort and time to infer complex things using RTL,
but the simulation performance has always been well worth the effort
for me. Simulating the instantiated primitives is _very_ slow compared
to RTL.

Andy


MM wrote:
> Robin,
>
> IMHO, trying to get inferring of anything more complex than a flip-flop, or
> perhaps an adder, to work is a waste of time. Just instantiate what you
> need...
> 
> /Mikhail




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