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 99400

Article: 99400
Subject: Re: Virtex-4 RocketIO and G.709 OTU-2
From: Allan Herriman <allanherriman@hotmail.com>
Date: Fri, 24 Mar 2006 10:16:41 +1100
Links: << >>  << T >>  << A >>
On 23 Mar 2006 06:22:37 -0800, "GaLaKtIkUs™" <taileb.mehdi@gmail.com>
wrote:

>Can you indicate me such a SERDES. It's perfect if its output is
>64bits. Also it shoulden't do FEC stuff. FEC is planned to be done on
>FPGA.

Most 10Gb/s SERDES parts seem to have 16 bit interfaces, probably
because there's common interface definition called SFI-4 that has 16
LVDS pairs clocked at 622-670MHz.

Xilinx has an app note called XAPP 622 that describes how to implement
such an interface on an FPGA.

Did you use Google?  You would have found SERDES manufacturers such as
PMC, AMCC, Broadcom, etc.

>Thnaks in advance
>Mehdi

Thanks for the top-post!

>
>Allan Herriman wrote:
>> On 21 Mar 2006 09:08:21 -0800, "Alain" <no_spa2005@yahoo.fr> wrote:
>>
>> >Unfortunately, even OC-192 is excluded form Virtex- 4 (ug076.pdf :
>> >"Payload compatible only"), so no hope for OTU-2 I think.
>> >We have to wait Virtex-5 family ?
>>
>> No.  That is unlikely to have sufficient jitter performance, due to
>> certain compromises that must be made when putting an MGT on an FPGA.
>> In particular, it's likely to use a ring oscillator rather than an LC
>> oscillator which would have better perfomance.
>>
>> Use an external SERDES designed for G.707 / G.709 work.
>>
>> Note that (before they discontinued it) Xilinx's standalone SERDES
>> didn't meet the SONET jitter requirements either, so getting these
>> things to work is clearly not a trivial task.
>> 
>> Regards,
>> Allan

Article: 99401
Subject: Re: Xilinx hi-speed interconnect/routing question
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 23 Mar 2006 23:20:37 -0000
Links: << >>  << T >>  << A >>
Hi John,
If you don't trust the timing constraints, you can use FPGA editor's 
'Directed Routing' feature to tie down your net. Either pick a routed 
configuration that meets your spec., or hand route the net in FPGA editor. 
Select the net, then go to
Tools -> Directed Routing Constraints. You can use the dialogue box to save 
some text to paste into your UCF file which will route the net you selected 
the same way every time. You can even have it make relative constraints.
It turns out that Xilinx use this themselves in some of their IP products, 
so it has a fair chance of continuing to work with new software releases!
HTH, and good luck! Syms. 



Article: 99402
Subject: Pacman update
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 23 Mar 2006 23:22:47 GMT
Links: << >>  << T >>  << A >>
At long last I have updated the Pacman release on
www.fpgaarcade.com

All ROMs are now internal, and RAMB16s are supported by the binary to VHDL 
program RomGen. General tidyup and simplified clocking scheme. Files 
generated by RomGen will also now simulate with the Xilinx Unisim simulation 
library.

Download, unzip, then from a DOS command prompt run

build_roms.bat

and then

buils_xst.bat

If you are using a different O.S. you are probably capable of writing your 
own scripts ...

Note, no original ROMs are included in this distributions, the included 
binaries are from a Pong game written by David Widel which runs on Pacman 
hardware.

/MikeJ




Article: 99403
Subject: Re: this JTAG thing is a joke
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Thu, 23 Mar 2006 23:33:15 GMT
Links: << >>  << T >>  << A >>
Austin,

I thought AC termination only worked with 50/50 duty cycle clocks? you got 
it going with TMS ?

I have always used an up/down resistor terminator and lived with the static 
power dissipation that implies.

One thing we did do a while ago was replace the JTAG chain (18 VirtexE 
devices per board) with a cpu bus interface CPLD which wired directly to the 
din / cclk pins of each device - programmed 18 different designs in 
parallel, much faster ...

/MikeJ

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:dvuncg$as422@xco-news.xilinx.com...
> One more thing,
>
> We also AC terminate at the endpoints of TMS and TCK.
>
> This was also shown to be necessary in the simulations.
>
> But don't just assume this is the "solution", you must simulate your pcb, 
> and decide what to do.
>
> Austin
>



Article: 99404
Subject: Re: this JTAG thing is a joke
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 15:42:35 -0800
Links: << >>  << T >>  << A >>
Mikej,

What I am referring to here, is a cap in series with a 50 ohm resistor 
to ground across the input at the end of the line.

signal ------------input
             |
            cap
             |
           50ohms
             |
           ground

This is less static power than a 100 ohm split from power to ground, and 
is equivalent (if you really are 50/50) to a 50 ohm resistor to Vcco/2 
(also another perfectly accptable termination).

Austin

MikeJ wrote:

> Austin,
> 
> I thought AC termination only worked with 50/50 duty cycle clocks? you got 
> it going with TMS ?
> 
> I have always used an up/down resistor terminator and lived with the static 
> power dissipation that implies.
> 
> One thing we did do a while ago was replace the JTAG chain (18 VirtexE 
> devices per board) with a cpu bus interface CPLD which wired directly to the 
> din / cclk pins of each device - programmed 18 different designs in 
> parallel, much faster ...
> 
> /MikeJ
> 
> "Austin Lesea" <austin@xilinx.com> wrote in message 
> news:dvuncg$as422@xco-news.xilinx.com...
> 
>>One more thing,
>>
>>We also AC terminate at the endpoints of TMS and TCK.
>>
>>This was also shown to be necessary in the simulations.
>>
>>But don't just assume this is the "solution", you must simulate your pcb, 
>>and decide what to do.
>>
>>Austin
>>
> 
> 
> 

Article: 99405
Subject: Re: for all those who believe in (structured) ASICs....
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 11:50:19 +1200
Links: << >>  << T >>  << A >>
Austin Lesea wrote:
<snip>
> 
> AMIS:
> 
> FY 2001  2002  2003  2004  2005
> $$ 326M  345M  454M  517M  504M
> SA   0     0   96.7M 119M  110.4M

Hmmm....

<paste> Austin's earlier claims...
> 155M$ is the whole MARKET (IN 2005, ISuppli).  That was spread over as many as 12 companies in that year.  
 >LSI had the largest share of that, at 35M$.  Everyone one else had a 
smaller chunk than 35M$.

  If I read your table above correctly, you have AMIS at $110.4M SA in 
2005, but just a few "Austin-Arm-Waves" ago, you had LSI as the Largest 
player, at $35M ?!

  Still, I guess it makes for rather less dramatic arm-waving, if it is 
not _actually_ the largest player that has just exited... ?

  Shame to let the numbers get in the way of a good spin :)

-jg


Article: 99406
Subject: Re: Xilinx hi-speed interconnect/routing question
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 12:04:08 +1200
Links: << >>  << T >>  << A >>
johnp wrote:
> Austin -
> 
> Thanks for the comments.  I'm just frustrated because if I run
> multi-pass P&R, the tools can find a solution that meets timing,
> but I don't see any hints as to how to use RLOCs to force the
> critical cells into magical alignments that produce the smaller
> interconnect delay.

  Since Austin has revealed these are real numbers, could you
somehow fine tune the costraints, so the longer paths
do not (quite) make the cut ?
-jg


Article: 99407
Subject: Re: JTAG programing specs for XC18V01 PROM
From: "David Colson" <dscolson@rcn.com>
Date: Thu, 23 Mar 2006 19:12:11 -0500
Links: << >>  << T >>  << A >>
Chris,

I have run into a similar problem with the Platform Flash.
What you can do is look at a file located in the Xilinx tools directory
called

C:\Xilinx81\xc18v00\data\xc18v01_pc20_1532.bsd

This is the ieee1532 bsdl file that describes the programming algorithm.
for the xc18v00. Using this file and an understanding of the JTAG interface,
you maybe able to decipher how to program your device.

Also it would be usefill to observe the JTAG signals of one of the Xilinx 
programmers
while it is programming a device,. That is if you have access to one.

Between the bsdl file, the Xilinx softwaer you spoke of below and observing 
the JTAG bins
I was able to impliment my onw program for the Platform Flash.

Good luck

Dave


"barnhart" <ceb.dideas@gmail.com> wrote in message 
news:1143031828.217216.43960@i40g2000cwc.googlegroups.com...
> Would anyone know where to get the JTAG programming specs (and
> programming times, page sizes, etc) for the XC18V01?   I'd like to
> create an application for re-programming a 18V01 that takes as input
> the Intel Hex (MCS) and outputs JTAG bit banging.  Xilinx recommends
> (app note 58 and 500) generating SVF or XSVF and using the XSVF player
> for the JTAG bit-bang.  Unfortunately the memory requirements of this
> player are excessive.
>
> So far most of my knowledge has been from studding the SVF file for the
> 18V01 that is generated by Impact - however - this isn't a good way to
> generate solid foundation for this project - and Xilinx has thus far
> been unwilling to provide these specifications.
>
> TIA,
> Chris
>
>
> Section of SVF file that program's a page:
>
> RUNTEST 1 TCK;
> RUNTEST 1 TCK;
> // Loading device with a 'faddr' instruction.
> SIR 8 TDI (eb) ;
> SDR 16 TDI (0060) SMASK (ffff) ;
> RUNTEST 1 TCK;
> RUNTEST 1 TCK;
> // Loading device with a 'fpgm' instruction.
> ENDIR IRPAUSE;
> SIR 8 TDI (ea) ;
> RUNTEST 1 TCK;
> RUNTEST 14000 TCK;
> // Loading device with a 'fdata0' instruction.
> SIR 8 TDI (ed) ;
> SDR 2048 TDI
> (0100401004010000000000000000000000000004010040100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000) SMASK
> (ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff) ;
> ENDIR IDLE;
>
>
>
> XC18V01 BSD documents the following JTAG opcodes:
>
> Attribute INSTRUCTION_OPCODE of XC1801 : entity is
> "BYPASS ( 11111111)," &
> "SAMPLE ( 00000001)," &
> "EXTEST ( 00000000)," &
> "IDCODE ( 11111110)," &
> "USERCODE ( 11111101)," &
> "HIGHZ ( 11111100)," &
> "CLAMP ( 11111010)," &
> "ISPEN ( 11101000)," &
> "ISPENC ( 11101001)," &
> "FPGM ( 11101010)," &
> "FADDR ( 11101011)," &
> "FVFY0 ( 11101111)," &
> "FVFY1 ( 11111000)," &
> "FVFY3 ( 11100010)," &
> "FVFY6 ( 11100110)," &
> "FERASE ( 11101100)," &
> "SERASE ( 00001010)," &
> "FDATA0 ( 11101101)," &
> "FDATA3 ( 11110011)," &
> "FBLANK0 ( 11100101)," &
> "FBLANK3 ( 11100001)," &
> "FBLANK6 ( 11100100)," &
> "NORMRST ( 11110000)," &
> "CONFIG ( 11101110)," &
> 



Article: 99408
Subject: Re: Xilinx hi-speed interconnect/routing question
From: Ray Andraka <ray@andraka.com>
Date: Thu, 23 Mar 2006 19:12:23 -0500
Links: << >>  << T >>  << A >>
johnp wrote:

> Austin -
> 
> Thanks for the comments.  I'm just frustrated because if I run
> multi-pass P&R, the tools can find a solution that meets timing,
> but I don't see any hints as to how to use RLOCs to force the
> critical cells into magical alignments that produce the smaller
> interconnect delay.
> 
> John Providenza
> 

Ideal placement no longer guarantees an ideal route, sorry to say.  In 
releases before the 5.1 "escape", there used to be a delay based 
clean-up so that if you gave it a perfect placement, the router did a 
darned good job of getting the routing correct.  Since then however, the 
router only works as hard as it has to for the whole design to meet 
timing.  The thing is, it no longer picks the low hanging fruit (ie the 
direct connects) consistently, which in turn congests the other routing 
resources.  As a result, the router winds up stepping all over itself 
trying to get something that meets timing; if you are pushing the 
performance hard, the router will often not be able to find a solution 
that meets timing in a dense design unless you happened to have the 
right cost table (MPPR iterates using different cost tables to affect 
the routing order).  In those cases, about your only option, assuming 
you've already tried setting the router to maximum effort continue on 
impossible, is to use directed routing...basically hand routing it with 
the FPGA editor and then exporting the routing info into a ucf.  I don't 
wish that on my worst enemy, as it is a gruelling task if more than a 
small design or macro.

Article: 99409
Subject: Memory leaks with ISE 8.1
From: "David Colson" <dscolson@rcn.com>
Date: Thu, 23 Mar 2006 19:15:25 -0500
Links: << >>  << T >>  << A >>
I have experenced memory leaks with the 8.1 release of the Xilinx tools on 
two
different machines. I mean on the order of 1 gigabyte of lost memory.
 Has anyone else seen this?

Dave 



Article: 99410
Subject: Re: this JTAG thing is a joke
From: "MikeJ" <mikej@fpgaarcade.nospam.com>
Date: Fri, 24 Mar 2006 00:16:29 GMT
Links: << >>  << T >>  << A >>
Hi Austin,

I understand what you mean, the reason I used a 100 ohm split (what I 
refered to as an up/down terminator) is that it always looks like 50 ohms to 
ground even to non-50/50 signals like TMS.

Surely with your cap/resistor terminator (which I use for most of my clocks) 
it is a 50 ohm to some odd voltage depeding what TMS has been doing recently 
? I guess it still functions when TMS changes state, but has the advantage 
of consuming no power when TMS is stuck high, which of course is almost 
always.

/MikeJ

"Austin Lesea" <austin@xilinx.com> wrote in message 
news:dvvbpb$om31@xco-news.xilinx.com...
> Mikej,
>
> What I am referring to here, is a cap in series with a 50 ohm resistor to 
> ground across the input at the end of the line.
>
> signal ------------input
>             |
>            cap
>             |
>           50ohms
>             |
>           ground
>
> This is less static power than a 100 ohm split from power to ground, and 
> is equivalent (if you really are 50/50) to a 50 ohm resistor to Vcco/2 
> (also another perfectly accptable termination).
>
> Austin
>
> MikeJ wrote:
>
>> Austin,
>>
>> I thought AC termination only worked with 50/50 duty cycle clocks? you 
>> got it going with TMS ?
>>
>> I have always used an up/down resistor terminator and lived with the 
>> static power dissipation that implies.
>>
>> One thing we did do a while ago was replace the JTAG chain (18 VirtexE 
>> devices per board) with a cpu bus interface CPLD which wired directly to 
>> the din / cclk pins of each device - programmed 18 different designs in 
>> parallel, much faster ...
>>
>> /MikeJ
>>
>> "Austin Lesea" <austin@xilinx.com> wrote in message 
>> news:dvuncg$as422@xco-news.xilinx.com...
>>
>>>One more thing,
>>>
>>>We also AC terminate at the endpoints of TMS and TCK.
>>>
>>>This was also shown to be necessary in the simulations.
>>>
>>>But don't just assume this is the "solution", you must simulate your pcb, 
>>>and decide what to do.
>>>
>>>Austin
>>>
>>
>> 


Article: 99411
Subject: Data Muxing on Spartan3 using the embedded carry chain
From: Sudhir.Singh@email.com
Date: 23 Mar 2006 16:53:49 -0800
Links: << >>  << T >>  << A >>
Hi All,
Does anyone know how to use the embedded carry chain for data muxing.
The Picoblaze docs state that it can use the MUXCY for this. I am not
sure how to use it for data muxing, if anyone knows, your help will be
greatly appreciated.
Thanks in advance
Sudhir


Article: 99412
Subject: Re: Data Muxing on Spartan3 using the embedded carry chain
From: Ray Andraka <ray@andraka.com>
Date: Thu, 23 Mar 2006 20:59:37 -0500
Links: << >>  << T >>  << A >>
Sudhir.Singh@email.com wrote:

> Hi All,
> Does anyone know how to use the embedded carry chain for data muxing.
> The Picoblaze docs state that it can use the MUXCY for this. I am not
> sure how to use it for data muxing, if anyone knows, your help will be
> greatly appreciated.
> Thanks in advance
> Sudhir
> 

You use the carry chain as a wide OR gate and place an AND in the LUT at 
each bit.  The AND at each bit has to be fed the decoded select on one 
input and the input bit on the other input.  The muxcys get wired with a 
'1' tied to the DI input and the CI input of the first one in the chain 
is connected to '0'.  One carry chain per bit in your mux, one LUT per 
carry chain for each mux input.  If there are 3 or fewer bits in the 
select, you can do the decoding right in the LUT.  If more than 3 select 
bits, then you need an external decode or partial decode, which can be 
shared between mux bits (ie shared among several carry chains).

Article: 99413
Subject: Re: Going from CLK1X to CLK2X.. really safe?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 18:02:02 -0800
Links: << >>  << T >>  << A >>
Ray,

Well, the PMCD is just some custom layout flip flops.  Nothing more.

So jitter on the input side of a FF jitters the Q output in a pretty 
linear through fashion.

Austin

Ray Andraka wrote:

> Austin Lesea wrote:
> 
>> Bob,
>>
>> We designed the PMCD so that the outputs all all matched within tens 
>> of picoseconds across P-V-T.  From there, you get onto the BUFGs, and 
>> you end up with the usual +/-100ps rule for match between BUFgs.
>>
>>
> 
> Austin,  That is basically what I was told when Virtex I came out too, 
> but it turned out that jitter on the DLL input could cause a spread 
> between the 1x and 2x clocks (IIRC, I had specifically asked both here 
> on the NG and through the hotline about the alignment of the 1x and 2x 
> clocks and whether it was safe to cross clock bounds without extra logic 
> and was told it was fine.  I don't think anyone realized then what 
> effect jitter would have on the relative phases of the 1x and 2x outputs.
> 
> So my question is, I realize you've designed the PMCDs for tight 
> tolerances, but how well does that stand up to jitter on the clock input?

Article: 99414
Subject: Re: PCI Configuration access and Target State Machine...
From: Ben Jackson <ben@ben.com>
Date: Thu, 23 Mar 2006 20:06:04 -0600
Links: << >>  << T >>  << A >>
On 2006-03-19, adventleaf@gmail.com <adventleaf@gmail.com> wrote:
>
> when FRAME# is asserted target is expected to latch the Address/Command
> respectively.
> because after that FRAME# will be de-asserted and DATA/Byte_Enable
> follows.

For a config cycle you have to look at IDSEL instead.  The config
read/write commands are different from mem read/write.  IDSEL will
often be the same as one of the address lines, so you must ignore it
when the command is not a config cycle.

For an example try:

	http://www.ben.com/minipci/

Specifically you can see on:

	http://www.ben.com/minipci/verilog.php

the difference between cfg_hit and addr_hit.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Article: 99415
Subject: Re: for all those who believe in (structured) ASICs....
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 18:08:44 -0800
Links: << >>  << T >>  << A >>
JG,

Who ya going to believe?

AMIS finacial post on their webpage (to the federal governement)?

Or some silly market research company that they try get people to buy?

I noticed this too.

So, is AMIS overstating their Structured ASIC wins to their stockholders 
and the governement?  Shades of Enron?

Or is Isuppli using a different definition?  Or just doesn't know anything?

If this is about < 35M$ vs ~104M$, then I rest my case:  structured ASIC 
is dying...or already dead.

What the investors thought they would be seeing is another multi billion 
dollar market by now.  And growth.

These numbers (pick any) are just pitiful.

Austin

Article: 99416
Subject: Re: this JTAG thing is a joke
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 15:22:12 +1200
Links: << >>  << T >>  << A >>
MikeJ wrote:
> Hi Austin,
> 
> I understand what you mean, the reason I used a 100 ohm split (what I 
> refered to as an up/down terminator) is that it always looks like 50 ohms to 
> ground even to non-50/50 signals like TMS.
> 
> Surely with your cap/resistor terminator (which I use for most of my clocks) 
> it is a 50 ohm to some odd voltage depeding what TMS has been doing recently 
> ? I guess it still functions when TMS changes state, but has the advantage 
> of consuming no power when TMS is stuck high, which of course is almost 
> always.

  You are correct, in so far that it could (in theory) degrade the eye 
pattern, but adding some history loading on the line - but from
a simple reflection/ringing viewpoint, it will work.
  At 5MHz you are probably not pushing the eye patterns much :)
-jg


Article: 99417
Subject: Re: FPGA : Spartan-3e configuration failure
From: bijoy <pbijoy@rediffmail.com>
Date: Thu, 23 Mar 2006 19:25:04 -0800
Links: << >>  << T >>  << A >>
Hi I use the following command to generate the .hex file to be programmed

promgen -spi -p hex -o promdata.hex -s 2048 -u 0 gl.bit

gl.bit is made from the ISE 7.1

This .hex file i program into the SPI flash using the xspi utility downloaded from xilinx.

My device is 250e-100VQFP

I have got another board with 250e-144TQFP with same SPI interface and that works fine using the same procedure i follow.

Any idea ! what is happening ?

Is there any Bug in 100-pin package FPGA ?

rgds bijoy

Article: 99418
Subject: Re: Xilinx hi-speed interconnect/routing question
From: Jim Granville <no.spam@designtools.co.nz>
Date: Fri, 24 Mar 2006 15:27:56 +1200
Links: << >>  << T >>  << A >>
Ray Andraka wrote:

> johnp wrote:
> 
>> Austin -
>>
>> Thanks for the comments.  I'm just frustrated because if I run
>> multi-pass P&R, the tools can find a solution that meets timing,
>> but I don't see any hints as to how to use RLOCs to force the
>> critical cells into magical alignments that produce the smaller
>> interconnect delay.
>>
>> John Providenza
>>
> 
> Ideal placement no longer guarantees an ideal route, sorry to say.  In 
> releases before the 5.1 "escape", there used to be a delay based 
> clean-up so that if you gave it a perfect placement, the router did a 
> darned good job of getting the routing correct.  Since then however, the 
> router only works as hard as it has to for the whole design to meet 
> timing.  The thing is, it no longer picks the low hanging fruit (ie the 
> direct connects) consistently, which in turn congests the other routing 
> resources.  

If a PCB router did this, it would be laughed out of the market...

-jg


Article: 99419
Subject: Xilinx - was Lattice FPGA
From: "Tim" <tim@rockylogiccom.noooospam.com>
Date: Fri, 24 Mar 2006 03:45:00 -0000
Links: << >>  << T >>  << A >>

Austin Lesea wrote

> If you order them, they will arrive.  I think that is how it is supposed 
> to work?
>
> Sometimes sooner, sometimes on time (and the objective is to never be 
> late).
>
> So don't blame us that we delivered an order, please!


Yes, I do blame Xilinx. Because the line you give out is that a delivery 
date cannot be quoted until an order is placed. And if we want to discover 
the date at which volume will be available, we have to place a large order 
for delivery ASAP. Are you familiar with Catch-22?

I am puzzled by the tone of your response. What I posted was more than 
amiable, considering the treatment dished out by your distributors (for whom 
I know you take no responsibility) and you use a public forum to dump your 
sarcasm on me. That was inappropriate.




Article: 99420
Subject: TNM propagation: I seem to be having trouble
From: "JustJohn" <john.l.smith@titan.com>
Date: 23 Mar 2006 22:16:29 -0800
Links: << >>  << T >>  << A >>
Hi Folks,
 It's been a while since I've needed to do anything fancy with Xilinx
timegroups, but I've inherited a design that requires multi-cycle
timing constraints. It's a typical scenario, an 80MHz global clock, w/
a 10MHz clock enable active on the 8th phase of a three-bit divide
counter. Quoting from the cgd:

"You can place TNM on any net in the design. The constraint indicates
that the TNM value should be attached to all valid elements fed by
_all_paths_that_fan_forward_ from the tagged net. Forward tracing stops
at FFS, RAMS, LATCHES, PADS, CPUS, HSIOS, and MULTS." (emphasis mine)

After inserting the proper grouping constraint:

NET "CE_10MHz" TNM = "TG_10MHz"; # FFs, RAMs, etc that operate w/ 100ns
period

what I see in Timing Analyzer is that the group TG_10MHz appears to be
limited to only elements that are directly on the CE_10MHz net, and
combinatorial derivatives ( specifically, conjunctive derivatives, ie.
through an "and" function ) seem to be omitted from the group. To me,
the phrase "fan forward" in the doc means through combinatorial logic,
not just through routing fabric, and my poor old memory recalls that
TNM used to work that way. Consequently, when I apply:

TIMESPEC "TS_10MHz" = FROM "TG_10MHz" TO "TG_10MHz" "TS_Clk80MHz" * 8;

many of the paths that should prioritize into this constraint do not,
and are being held hostage to the 12.5 ns master clock period instead
of the desired 100ns. Anyone seen anything like this recently?

Regards All,
Just John


Article: 99421
Subject: Accessing ModelSim Environment variables in Verilog code
From: "Nju Njoroge" <njoroge@stanford.edu>
Date: 23 Mar 2006 22:59:10 -0800
Links: << >>  << T >>  << A >>
Hello,

I would like to access environment variables defined in ModelSim (6.0d)
in my Verilog code so that I can use them with the `ifdef construct.
For instance, ModelSim allows you to access the "MODEL_TECH"
environment variable, which is useful for employing `ifdef's on code
you want that you want to be compiled for simulation, but ignored for
hardware synthesis.

In a similar vein, I tried creating and setting my own environment
variable using "setenv MY_VARIABLE 1" in my .do compile tcl script
right before the script compiles my modules. Unfortunately, the Verilog
code is not able to access this env variable. I'm avoiding using an
include file, but if there is not way around this, then that's what
I'll have to do.

Thanks,

NN


Article: 99422
Subject: Re: Lattice FPGA
From: "Antti" <Antti.Lukats@xilant.com>
Date: 23 Mar 2006 23:07:26 -0800
Links: << >>  << T >>  << A >>
Austin,

Tim is right to be p******
1) sometimes placement of an order depends on the known deliver date
2) if ordered items arrive way too early than you have to pay earlier

so speed delivery (before delivery date) may give quite a bit financial
problems if money is being used wise.
example you know XC3S100E will be delivered W27 so you plan all your
actions for the product that uses
it in such timeline that money to buy them out will be 'free' for use
when the parts arrive, and that the product
other components are also purchased at about the same time and
production is targetted as well.

now if these parts arrive W14 and not W27 then,
1) you will have to pay immediatly
2) the parts will still be laying around til W27 because that when you
get PCB

this is exactly a story I heard from manufacturer of Xilinx based
boards.

Antti


Article: 99423
Subject: Re: FPGA : Spartan-3e configuration failure
From: "Antti" <Antti.Lukats@xilant.com>
Date: 23 Mar 2006 23:14:00 -0800
Links: << >>  << T >>  << A >>
the 100pin package has 2 different pinouts depending if you have early
ES part or production part! check the datasheet and documentation. but
the different pins are some Mode pins so if wrong the config would not
start I guess, so it might be different issue.

Antti


Article: 99424
Subject: Re: this JTAG thing is a joke
From: Kolja Sulimma <news@sulimma.de>
Date: Fri, 24 Mar 2006 08:19:31 +0100
Links: << >>  << T >>  << A >>
Brannon schrieb:
> 4. Standard driver interface. Need I say more? How many of you write
> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
> you all enjoy it too. How about something like this:

There are existing JTAG APIs. Which one becomes a standard is the choice
of the developers that use them. Maybe there never will be a widely
accepted standard, but that does not matter as mutliple APIs can coexist.

- Openwince has a nice iAPI with drivers for quite a lot of interfaces.
It is relatively easy to add new drivers.
http://openwince.sourceforge.net/jtag/

- Xilinx provides a TCL API.

- There is an extremely primitive Java JTAG API from SUN and Xilinx.

- Any SVF player can be used to send JTAG commands from an application
to the chips. (Openwince also contains an SVF player)


Unfortunately the openwince project is rather inactive for a few years
now, but maybe we can change that.


As far as your other suggestion are concerned:
It is important that JTAG stays extremely simple to implement. An FPGA
can justify a complex JTAG replacement. But for board testing it can be
very important to have bus buffers that have JTAG-ports. I do not want
to pay for an IP layer in each of my buffer ics.

There exist simple controller ICs that split a JTAG chain in parts that
can be individually shifted. That solves virtually all of your other
concerns.

Kolja Sulimma



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