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 105200

Article: 105200
Subject: Re: ISE 8.2 WebPack does not support Virtex-5 at all?
From: "John_H" <johnhandwork@mail.com>
Date: Mon, 17 Jul 2006 20:23:23 GMT
Links: << >>  << T >>  << A >>
Sounds like a tough newsgroup day for you, Antti.  I hope tomorrow is a much 
better experience.  At home I switched to "thunderbird" (a netscape/mozilla 
offshoot) and have had a decent time with posting there.

"Antti Lukats" <antti@openchip.org> wrote in message 
news:e9gkdo$sfn$1@online.de...
> "Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag 
> news:e9gj1o$pqj$1@online.de...
>> WebPack and SP1 are available but it looks like the ISE WebPack does not 
>> support any Virtex-5 devices at all? I did assume smallest Virtex-5 would 
>> be supported. what a pity.
>>
>> Antti
>>
> ops, I posted incorrectly as reply. sorry.
> and another ops, 5 seconds ago claimed that I already said sorry, but that 
> sorry was sent to the OP only not as reply to me wrong posting
>
> Antti
> 



Article: 105201
Subject: Re: Need for reset in FPGAs
From: "PeteS" <PeterSmith1954@googlemail.com>
Date: 17 Jul 2006 13:50:46 -0700
Links: << >>  << T >>  << A >>
Andy wrote:
> It is important to have a reset that is synchronously deasserted
> relative to every clock used.  These may be fully syncrhonous resets or
> asynchronous resets that have the trailing edge syncrhonized.
>
> The reason for this is that if a reset input is not syncrhonized to the
> same clock as the circuitry being reset, then all flops in the circuit
> will not come out of reset on the same clock, which, unless it is
> handled very carefully, will cause problems that can be very hard to
> debug.
>
> Whether or not you have a separate reset, or are only resetting on
> configuration, the above requirements hold true.
>
> Andy
>
>
> Nial Stewart wrote:
> > "Thomas Reinemann" <thomas.reinemann@aucotronics.de> wrote in message
> > news:e981ph$ur5$1@news.boerde.de...
> > > Hello,
> > > usually a reset signal is applied to put the FFs of an FPGA into a known
> > > state. Just some days ago I had a discussion. Someone's point of view
> > > is, that a reset is not necessary, since the FF's output will be always
> > > zero, after applying the voltage. Does this happen in FPGAs really,
> > > especially in a Spartan3?
> > > Bye Tom
> >
> >
> > If you use any form of PLL/DLL in your design I don't think you can
> > be sure of what's going to happen until it's locked. This can throw
> > logic/state machines into complete disarray.
> >
> > I generate a synchronous reset which de-activates some period
> > after all my PLLs have locked.
> >
> >
> >
> > Nial

One of my current designs has a AC97 and GSM modem PCM interface to a
Bluetooth link, multiplexed. This link may obviously be switched from
one to the other (yes, I play system sounds across bluetooth ;) at any
time. i.e. relatively asynchronous events. The other thing is GSM PCM
data is 8k frame rate, AC97 can be up to 192k, variable rate (you have
to extract valid data) so there are retimers for the data stream, which
is simple enough if you only have one source; with two or more it
becomes imperative to ensure clean switching.

I have to make sure when I switch into either mode that the state
machine for data reframing is in a known state, so at every switch I
assert an synchronous reset to the retimer - in reality the switching
signal is synchronised to the frame generator so I am guaranteed to
switch cleanly from one input to the other and change the rates at
which I retime.

Reset costs one pin and saves untold misery

Cheers

PeteS


Article: 105202
Subject: Re: ISE 8.2 WebPack does not support Virtex-5 at all?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 18 Jul 2006 09:45:29 +1200
Links: << >>  << T >>  << A >>
Antti Lukats wrote:
> WebPack and SP1 are available but it looks like the ISE WebPack does not 
> support any Virtex-5 devices at all? I did assume smallest Virtex-5 would be 
> supported. what a pity.

Antti
  Someone in Xilinx should send you whatever is needed, to work with 
Virtex-5 :) [Peter?]

  More generally, I can only guess they are trying to throttle demand
from the wider user base (to Xilinx, the "great unwashed"), for parts 
that are still very green.

  Problem is, that mindset can get you into trouble : if users cannot
even synthesise an older design, to see how fast a V5 might be, then V5
goes off their radar pretty quickly.

[ It also means the bugs in V5 will hang about longer....  ]

  If Lattice and Altera DO allow the newest-process leading-devices to
be timed, in their free tools, then Xilinx can loose out, and never 
realise it is happening.
  This type of voting with the feet, is done silently.

-jg


Article: 105203
Subject: Re: Development Boards -Your chance to suggest features
From: "John Adair" <g1@enterpoint.co.uk>
Date: 17 Jul 2006 14:56:50 -0700
Links: << >>  << T >>  << A >>
The older names Broaddown, Raggedstone, Swinyard, Hollybush are hills
in the local Malvern Hills chain and if you search around you can even
see pictures of them on other websites. Moel-Bryn is the ancient celtic
name for Malvern or "Bald Hill" as far as I understand. We even have
remains on the hills of iron age fortifications to go with all that.

The newer names we are now taking from the Galloway hills in southern
Scotland. So far we are using Tarfessock and as of a couple of days ago
Darnaw. We might even give some prizes for correct pronounciation when
we get the more difficult one. Tarfessock is a bit of a mouthful
already but there is much interesting to come yet. I'm sure were going
to have lots of fun.

John Adair
Enterpoint Ltd.

Martin Thompson wrote:
> "John Adair" <g1@enterpoint.co.uk> writes:
>
> > It's now been christened and had the obligatory bottle of Champers
> > smashed. Darnaw1 is the name to look for.
> >
>
> Go on John, enlighten us :-) Where do you get your names from?  Do you
> just open a random OS (that's Ordnance Survey for non-Brits - not
> operating system!) map and stick your finger on a remote village or
> something?
>
> Cheers,
> Martin
>
> --
> martin.j.thompson@trw.com
> TRW Conekt - Consultancy in Engineering, Knowledge and Technology
> http://www.trw.com/conekt


Article: 105204
Subject: Virtex 4, LVDS I/O: Sanity check please
From: "Marc Reinig" <Marco@newsgroups.nospam>
Date: Mon, 17 Jul 2006 16:30:22 -0700
Links: << >>  << T >>  << A >>
I have a project where I will have a large array of V4 FPGAs.  Each chip is 
intended to connect to its four orthogonal neighbors with no intervening 
logic.  I would like the number of bus connections between chips in any 
direction in the array to be 150 (600 total I/O per chip).  The connections 
will be bi-directional.  The distance between chips will be the minimum I 
can have with sockets, heat sinks (with individual fans), good layout and 
noise control.  Some of the lines, what ever is necessary, will be used for 
clock and framing for the bus data signals.  I would like to use DDR. 
During bus transfers, all the lines on opposite sides of the chip will be 
operating and the other two sides will be quiescent.  I'm hoping for a bus 
clock of 150 MHz.


Comments? ;=)

Marco
________________________
Marc Reinig
UCO/Lick Observatory
Laboratory for Adaptive Optics



Article: 105205
Subject: Re: 2048 input or gate ?
From: "rickman" <spamgoeshere4@yahoo.com>
Date: 17 Jul 2006 18:39:46 -0700
Links: << >>  << T >>  << A >>
Symon wrote:
> "Ben Jones" <ben.jones@xilinx.com> wrote in message
> news:e9gfcl$4mg1@cliff.xsj.xilinx.com...
> >
> > Hope this makes sense... perhaps someone can take it a step further and
> > work
> > out where the 56 levels thing really comes from (and thus deduce what this
> > particular synthesis tool believes the LUT:CY speed ratio is!).
> >
> > Cheers,
> >
> >        -Ben-
> >
> Hi Ben,
> Thanks for that, it made sense to me. I think we might need to know what
> part the design was in because the carry chain length is limited by the
> number of rows in the FPGA. Smaller parts have smaller maximum length
> chains. Also, as a BTW, I see from the datasheet that the ORCY structure
> that was in V2PRO has been dropped from the V4. That made wide gates even
> faster.

It makes some sense, but I think the fastest approach is to use
combinations in layers.  With the large discrepancy in speed, it makes
sense to use a lot of input in a single carry chain.  But the carry
chain is by nature serial and the delays keep adding.  The delays with
LUTs can be done in parallel using a pyramid structure.  I think the
fastest approach would be to combine the two in a pyramid of LUTs and
carry chains like they have been discussing above.

One way to compare the two is to consider building up from a single
LUT.  With four inputs to a LUT, you can combine four single LUTs to
another LUT for 16 inputs with two LUT delays.  Using the 12:1
approximation for the ratio of delays in the two, you can combine 12
LUTs for 48 inputs and get two LUT delays using the carry chain.
Clearly this is faster on the first level.

So let's consider increasing the size by a factor of four by combining
four, 48-input carry chains using a LUT.  This will give 192 inputs
with three LUT delays.  To do that in a longer carry chain, you would
get 5 LUT delays.  So clearly it is better at some point to break the
carry chains and combine their outputs with a LUT.  I am assuming that
you can not run one carry chain into another without using a LUT.  In
fact, I seem to recall that to get an output from a carry chain you
need to use a LUT.  So maybe my delay calculations are flawed since the
12:1 ration does not account for the required end of chain LUT.  In
fact, I am pretty sure that makes the carry chain slower than a pyramid
of LUTs.

Anyone know the details of connecting the output of the carry chain in
V4 parts?


Article: 105206
Subject: Re: OPB or FSL?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Tue, 18 Jul 2006 13:10:17 +1000
Links: << >>  << T >>  << A >>
Hi Christian,

FSL is awesome, but remember that the CPU must handle every piece of data in the
channel.  Putting the CPU in the datapath is something high-speed designers
usually try to avoid.  There's no such thing as DMA to an FSL connection (though
sometimes I wish there was).

You can use the DMA functionality on Xilinx's OPB IPIF, but it tends to produce
massive cores.  Look for example at the size difference between the ethernet MAC
with and without SGDMA.

Also, there's the standalone opb_dma controller, but it's not as efficient as an
IPIF-integrated controller.  Choices and tradeoffs, as always.

More below:

Christian Schleiffer wrote:

> The hardware interface is no problem at all and my bus connection will
> have a system synchronous part as well. Maybe I even don't have to worry
> about IRQs: the controller will be running uCLinux and I just read about
> an official FSL driver doing the polling job. I have to get deeper into
> that uCLinux stuff first, I think.

I'm familiar with the uClinux driver you mention, since I wrote it.  And, once
again the biggest problem there is throughput because all data over the channels
must be handled by the CPU.

It is possible to trigger interrupts on FSL status, but you have to do some
crafty stuff in the MHS file.  Basically co-opt the FSL's has_data or is_full
signals and bring them into the interrupt controller.

>>As far as data rate, The read and write FIFO is synschrounous to your
>>microblaze clock.  I think it is a single cycle instruction to to a
>>non-blocking write to a FSL.  Could take 2 or more but I can't remember.
> 
> Yes, non-blocking write and read operations take 2 instruction cycles.

Multithreaded operating systems or apps *must not* use blocking FSL operations,
since they'll lock you up hard if you do a blocking read/write on an empty/full
channel.

Instead, you have to simulate it by doing a nonblocking read, testing the
status, and repeating if required.  This slows things down a lot.

If you know exactly how many items should be in the channel, you might get away
with a blocking op.

Regards,

John

Article: 105207
Subject: Re: 2048 input or gate ?
From: John_H <johnhandwork@mail.com>
Date: Tue, 18 Jul 2006 04:39:42 GMT
Links: << >>  << T >>  << A >>
rickman wrote:
> It makes some sense, but I think the fastest approach is to use
> combinations in layers.  With the large discrepancy in speed, it makes
> sense to use a lot of input in a single carry chain.  But the carry
> chain is by nature serial and the delays keep adding.  The delays with
> LUTs can be done in parallel using a pyramid structure.  I think the
> fastest approach would be to combine the two in a pyramid of LUTs and
> carry chains like they have been discussing above.
> 
> One way to compare the two is to consider building up from a single
> LUT.  With four inputs to a LUT, you can combine four single LUTs to
> another LUT for 16 inputs with two LUT delays.  Using the 12:1
> approximation for the ratio of delays in the two, you can combine 12
> LUTs for 48 inputs and get two LUT delays using the carry chain.
> Clearly this is faster on the first level.
> 
> So let's consider increasing the size by a factor of four by combining
> four, 48-input carry chains using a LUT.  This will give 192 inputs
> with three LUT delays.  To do that in a longer carry chain, you would
> get 5 LUT delays.  So clearly it is better at some point to break the
> carry chains and combine their outputs with a LUT.  I am assuming that
> you can not run one carry chain into another without using a LUT.  In
> fact, I seem to recall that to get an output from a carry chain you
> need to use a LUT.  So maybe my delay calculations are flawed since the
> 12:1 ration does not account for the required end of chain LUT.  In
> fact, I am pretty sure that makes the carry chain slower than a pyramid
> of LUTs.
> 
> Anyone know the details of connecting the output of the carry chain in
> V4 parts?

In the Spartan3E parts (things may vary for the Virtex4) the exit from a 
MUXCY (as opposed to an XORCY used in an adder) can be directly onto 
routing.  The timing report will go straight from a Tbyp delay to the net.

For 4^n inputs ORed in a LUT tree (or pyramid) the additive delay will 
be n*Tilo+(n-1)*Tnet.  For one carry chain, the additive delay will be 
Topcyf+((4^n)/8-1)*Tbyp.  For my Spartan3E, -5 speed grade, the carry 
chain is better at n=2-4; I'm surprised the numbers work for n=2 but 
that comes from a history where carry chains were tough to get on and 
off (here we only have to sweat getting on the carry chain, off is free).

If the problem were a 256-wide OR or a 16k-wide OR, an extra level of 
LUTs would work out well with one or two carry chain stages, 
respectively.  The numbers may skew slightly for other families but the 
timing reports will show what the makeup is for the various paths - 
including routing - to make a better determination of what's "best."

Article: 105208
Subject: Re: Fastest platform to run ISE?
From: Philip Freidin <philip@fliptronics.com>
Date: Tue, 18 Jul 2006 04:44:09 GMT
Links: << >>  << T >>  << A >>
On Sat, 8 Jul 2006 13:12:43 +0200, "Jan Hansen" <someone@microsoft.com> wrote:
>I have switched from an Intel Pentium 4 1.4 Ghz  0.5 GB RAM to an AMD Athlon
>64 dual core 2 GHz 2GB RAM, and processing  time for my project vent down
>from about 17 min  to about 4 min.....! And it lookes like ISE utillises
>both cores, according to task manager the load are about 50% on each core
>during processing...that leaves enough proc. power to read the news without
>degrading XST performance. Multiple cores is the future  !

While it is true that both CPUs show about 50% utilization, this is not
ISE running multi-threaded. What you are seeing is the load sharing that the
MS operating system does with systems with 2 CPUs. Basically, at every
system call (disk, screen, mouse, clock, network, or other interrupt) the
OS will chose which CPU the task runs on after the return from call/interrupt.

It tends to try and even things out. The graph that you see in task manager is
based on the average load of the CPU over a period of time that tends to be
longer that the rate at which calls to the OS occur, and so what you see looks
like 50%. If the display used faster sampling, what you would see is it
bouncing between 100% and 0%, and alternating between the 2 CPUs.

The net affect is that you get approximately the MIPs of 1 CPU at 100%.

The other 100% is available for important things such as reading news and
posting articles.

If ISE was multi-threaded, you would see both processors at close to 100%.

Note that this switching back and forth is slightly less efficient due to
the cache contents of each CPU. You can force the OS to only run a specific
task on 1 CPU as follows:

Once the task is running, open task manager on the processes tab. Select
the task (i.e. ISE or XST or P&R) then click the right mouse button to get
the context menu. Select "Set Affinity", and you will see a list of available
CPUs, with a tick against all of them. Turn one of them off. Your task will
now only run on that CPU. If you now look at the graphs, you will see one CPU
at 100% and the other is running pretty much everything else.

Cheers,
Philip


Philip Freidin
Fliptronics

Article: 105209
Subject: Reuse a Speed Grade -8 Stratix image in Speed Grade -6 ...?
From: Jesper.Kristensen@tellabs.com
Date: 17 Jul 2006 22:02:58 -0700
Links: << >>  << T >>  << A >>
Hello Group.

Quite simple question... but I cannot seem to be able to find the
answer:

Given a Code Image initially targeted for a Stratix EP1S40F780C8 - i.e.
Speed Grade "-8" - would it then be without troubles to load and run
that Image on the corresponding "-6" device...?

The need for the question arises in the crossfire of device
availability and the wish of having only one Coding Image to update.

Thanks in advance & best regards,

  Jesper.


Article: 105210
Subject: Opencore ddr_controller
From: "subint" <subin.82@gmail.com>
Date: 17 Jul 2006 22:26:21 -0700
Links: << >>  << T >>  << A >>
Hi,
         I am trying to do the post_par simulation of the opercore ddr
controller(from opencore.org)
There is feedback clk in this design which is said to be routed
externally to the ddr_clk. Since i cannot do this in the board i am
trying to route it througth the fpga for the maximum delay possible. My
problem is whenever i try to route the clock i am getting the error
message

"Pack 1569: the dual data rate register i_ddr_sdr/fddrd/u1 failed to
join a OLOGIC component as required"

i didnt understand the meaning of this error. I tried to generate extra
clk(similar to ddr_clk using the fddrrse) but the getting the same
error.
regards
subin


Article: 105211
Subject: noob question: reset problem
From: "=?iso-8859-1?B?RmRvLkxl824=?=" <fndoleon@gmail.com>
Date: 18 Jul 2006 01:42:29 -0700
Links: << >>  << T >>  << A >>
Hello all

I have implemented the typicall "hello world" in a spartan3 with:

- 1 MBlaze.
- 2 LMB buses (instructions and data)
- 1 BRAM
- 1 OPB bus with an UARTLITE.

Basically i have followed this tutorial step by step :

http://www.eece.unm.edu/xup/spartan2emicroblaze.htm
(using an spartan-3)


The system sends the "hello world" string continuously trought the
UARTLITE. But i have any problem with my reset signal, because when i
push the reset button, sometimes the system gets block completely.

somebody can help me?


Article: 105212
Subject: Re: Virtex 4, LVDS I/O: Sanity check please
From: "John Adair" <removethisthenleavejea@replacewithcompanyname.co.uk>
Date: Tue, 18 Jul 2006 09:52:05 +0100
Links: << >>  << T >>  << A >>
Standards like SSTL are good for this due to the low signal swing. The 
biggest decision is if to use DCI which burns more power in the V4 or to use 
external resistors which take board area and make routing more difficult.

The other decision is weither you use source synchronous clocking or a 
common clock approach. At 150 Mhz the common clock is slightly marginal 
depending on how long tracks are, speed grade, etc. unless you use some DCM 
based techniques. You can generate a clock that is offset from the common 
clock a little by using a DCM and use that as clock for register input to 
gain more time. Alternatively you can use a DCM to null out the clock to 
output time and get more margin from that.

John Adair
Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development 
Board.
http://www.enterpoint.co.uk


"Marc Reinig" <Marco@newsgroups.nospam> wrote in message 
news:44bc1fed@darkstar...
>I have a project where I will have a large array of V4 FPGAs.  Each chip is 
>intended to connect to its four orthogonal neighbors with no intervening 
>logic.  I would like the number of bus connections between chips in any 
>direction in the array to be 150 (600 total I/O per chip).  The connections 
>will be bi-directional.  The distance between chips will be the minimum I 
>can have with sockets, heat sinks (with individual fans), good layout and 
>noise control.  Some of the lines, what ever is necessary, will be used for 
>clock and framing for the bus data signals.  I would like to use DDR. 
>During bus transfers, all the lines on opposite sides of the chip will be 
>operating and the other two sides will be quiescent.  I'm hoping for a bus 
>clock of 150 MHz.
>
>
> Comments? ;=)
>
> Marco
> ________________________
> Marc Reinig
> UCO/Lick Observatory
> Laboratory for Adaptive Optics
>
> 



Article: 105213
Subject: Re: Development Boards -Your chance to suggest features
From: Martin Thompson <martin.j.thompson@trw.com>
Date: 18 Jul 2006 09:55:03 +0100
Links: << >>  << T >>  << A >>
"John Adair" <g1@enterpoint.co.uk> writes:

> The older names Broaddown, Raggedstone, Swinyard, Hollybush are hills
> in the local Malvern Hills chain and if you search around you can even
> see pictures of them on other websites. Moel-Bryn is the ancient celtic
> name for Malvern or "Bald Hill" as far as I understand. We even have
> remains on the hills of iron age fortifications to go with all that.
> 
> The newer names we are now taking from the Galloway hills in southern
> Scotland. So far we are using Tarfessock and as of a couple of days ago
> Darnaw. We might even give some prizes for correct pronounciation when
> we get the more difficult one. Tarfessock is a bit of a mouthful
> already but there is much interesting to come yet. I'm sure were going
> to have lots of fun.
> 

I knew geography had to be in there somewhere :-)

Thanks!
Martin

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt  
   

Article: 105214
Subject: Re: 2048 input or gate ?
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Tue, 18 Jul 2006 10:05:53 +0100
Links: << >>  << T >>  << A >>

"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:1153186786.804902.220530@h48g2000cwc.googlegroups.com...

> Anyone know the details of connecting the output of the carry chain in
> V4 parts?

The quickest way off the carry chain, believe it or not, is to use the XORCY
element (with a 0 input from the fabric, or a 1 if you want inversion). This
is faster than going up to the next LUT and using the dedicated output. This
still takes a few hundred picoseconds though (check the timing files for the
exact number).

<plug> In Virtex 5, the carry chain structure has got *much* faster relative
to the rest of the fabric, both in terms of propagation delay and time to
get on/off the chain... :-) </plug>

Cheers,

        -Ben-



Article: 105215
Subject: Re: Opencore ddr_controller
From: =?ISO-8859-1?Q?Michael_Sch=F6berl?= <MSchoeberl@mailtonne.de>
Date: Tue, 18 Jul 2006 12:28:44 +0200
Links: << >>  << T >>  << A >>
> There is feedback clk in this design which is said to be routed
> externally to the ddr_clk. Since i cannot do this in the board i am
> trying to route it througth the fpga for the maximum delay possible.

well - the idea is to compensate the IOB delay for the clock with your 
DCM. This gives you an internal clock that is phase aligned to your 
external clock ...

just delaying by "the maximum possible" will lead you nowhere ...

you could try to use one DCM to phase shift your internal clock by an 
adjustable amount and route this clock to you RAM ... you would then 
have to manually set the delay to phase align internal/external clock


bye,
Michael

Article: 105216
Subject: Re: 2048 input or gate ?
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 18 Jul 2006 23:02:52 +1200
Links: << >>  << T >>  << A >>
Ben Jones wrote:
> 
> <plug> In Virtex 5, the carry chain structure has got *much* faster relative
> to the rest of the fabric, both in terms of propagation delay and time to
> get on/off the chain... :-) </plug>

Hi Ben,
  Great, so does that mean Webpack will (soon?) allow designers to 
actually use the Virtex 5 family ?

-jg


Article: 105217
Subject: Re: Opencore ddr_controller
From: "KJ" <kkjennings@sbcglobal.net>
Date: Tue, 18 Jul 2006 11:16:56 GMT
Links: << >>  << T >>  << A >>

"subint" <subin.82@gmail.com> wrote in message 
news:1153200381.707271.324810@p79g2000cwp.googlegroups.com...
> Hi,
>         I am trying to do the post_par simulation of the opercore ddr
> controller(from opencore.org)
> There is feedback clk in this design which is said to be routed
> externally to the ddr_clk. Since i cannot do this in the board

That statement right there says that you need to stop and re-read how to use 
the core and DDR.  The whole point of the feedback clock in any DDR design 
is to compensate for PCB delays.  Trying to emulate these delays in some 
manner is exactly the wrong approach.

KJ



Article: 105218
Subject: Re: problem in simulating FFT core on ISE 7.1
From: bijoy <pbijoy@rediffmail.com>
Date: Tue, 18 Jul 2006 04:28:20 -0700
Links: << >>  << T >>  << A >>
Hi am using FFT core (VHDL model) and simulated using modelsim-xilinx edition without any problem. Did you update your model sim simulator with latest updates ?

rgds bijoy

Article: 105219
Subject: Re: 2048 input or gate ?
From: "Symon" <symon_brewer@hotmail.com>
Date: 18 Jul 2006 14:24:39 +0200
Links: << >>  << T >>  << A >>
"Ben Jones" <ben.jones@xilinx.com> wrote in message 
news:e9i89j$63f1@cliff.xsj.xilinx.com...
>
> <plug> In Virtex 5, the carry chain structure has got *much* faster 
> relative
> to the rest of the fabric, both in terms of propagation delay and time to
> get on/off the chain... :-) </plug>
>
Hi Ben,
C'mon, dish the numbers! :-) Is it looking ahead further, or has the chain 
itself got faster?
Cheers, Syms. 



Article: 105220
Subject: JED file translator
From: "sjulhes" <t@aol.fr>
Date: Tue, 18 Jul 2006 14:26:33 +0200
Links: << >>  << T >>  << A >>
Hi all,

I have a JED file for an old PAL device  and I have to put this design in an 
EPLD.
Is there a tool that can read the JED file and translate it to any usable 
language (vhdl, verilog or other ) ???

Have you any tip for this handling JED files ??

Thanks.

Stéphane. 



Article: 105221
Subject: Re: Opencore ddr_controller
From: "subint" <subin.82@gmail.com>
Date: 18 Jul 2006 06:07:11 -0700
Links: << >>  << T >>  << A >>
hi,
          ok. so i need to delay the clock using the dcm. fine .but
anyone can tell me what is the error message means ""Pack 1569: the
dual data rate register i_ddr_sdr/fddrd/u1 failed to
join a OLOGIC component as required"
This error is showing when i try to touch (route) the ddr_clk for
delaying it.
regards
subin

KJ wrote:
> "subint" <subin.82@gmail.com> wrote in message
> news:1153200381.707271.324810@p79g2000cwp.googlegroups.com...
> > Hi,
> >         I am trying to do the post_par simulation of the opercore ddr
> > controller(from opencore.org)
> > There is feedback clk in this design which is said to be routed
> > externally to the ddr_clk. Since i cannot do this in the board
>
> That statement right there says that you need to stop and re-read how to use
> the core and DDR.  The whole point of the feedback clock in any DDR design
> is to compensate for PCB delays.  Trying to emulate these delays in some
> manner is exactly the wrong approach.
> 
> KJ


Article: 105222
Subject: Burnig flash image with Xilinx EDK flashwriter tool
From: sgfallows@gmail.com
Date: 18 Jul 2006 06:42:48 -0700
Links: << >>  << T >>  << A >>
I am using EDK 7.1 and trying to determine if the built in capabilties
of the flashwriter tool will suffice for our board. On pg 153 of the
Embedded tools manual there is a table with this entry: "Paired x16
only capable devices in x16 mode, forming a 32-bit data bus"

Our config is Paired x16 devices, but they are also 8 bit capable. We
have them connected for 16 bit mode only. The parts are Spansion
S29AL032D (Model 03).

Can anyone tell me if this will work? (The wording from the EST Manual
is vague to me. I'm currently plowing through the flashwriter source to
try to understand.)


Article: 105223
Subject: Re: 2048 input or gate ?
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Tue, 18 Jul 2006 15:45:47 +0100
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message
news:44bcd307$1_1@x-privat.org...
> "Ben Jones" <ben.jones@xilinx.com> wrote in message
> news:e9i89j$63f1@cliff.xsj.xilinx.com...
> >
> > <plug> In Virtex 5, the carry chain structure has got *much* faster
> > relative
> > to the rest of the fabric, both in terms of propagation delay and time
to
> > get on/off the chain... :-) </plug>
> >
> C'mon, dish the numbers! :-) Is it looking ahead further, or has the chain
> itself got faster?

So, each slice now has four LUTs and four FFs. Consequently, there are four
MUXCY/XORCY pairs in each slice's subchain. The Tbyp (i.e. cin-to-cout
delay) for the slice is on the order of 80ps. So that works out to around
20ps per LUT, or twice as fast as in Virtex-4.

I am not a sub-micron designer, so I don't really know how they achieved it
:) but I'll bet it's a combination of the two factors you mentioned.

Cheers,

    -Ben-




Article: 105224
Subject: Re: 2048 input or gate ?
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Tue, 18 Jul 2006 15:49:17 +0100
Links: << >>  << T >>  << A >>

"Jim Granville" <no.spam@designtools.co.nz> wrote in message
news:44bcbff9$1@clear.net.nz...
> Ben Jones wrote:
> >
> > <plug> In Virtex 5, the carry chain structure has got *much* faster
relative
> > to the rest of the fabric, both in terms of propagation delay and time
to
> > get on/off the chain... :-) </plug>
>
> Hi Ben,
>   Great, so does that mean Webpack will (soon?) allow designers to
> actually use the Virtex 5 family ?

I, like you, am surprised that it doesn't (even in the 8.2i release).
Doubtless there is a justification somewhere in terms of reduced burden on
the technical support hotline or some-such... bah!

Then again, the full ISE suite isn't all that expensive... <ducks> :)

Cheers,

    -Ben-






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