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 82600

Article: 82600
Subject: Re: Connecting Virtex2pro to Virtex4 via RocketIO MGT's
From: Ed McGettigan <ed.mcgettigan@xilinx.com>
Date: Thu, 14 Apr 2005 11:19:02 -0700
Links: << >>  << T >>  << A >>
Ed McGettigan wrote:
> jason.stubbs wrote:
> 
>> Ed,
>>
>> So, if I send data from a V2Pro to a V4 the MSB is sent first.  when
>> the V4 receives and deserializes the data, the MSB of the V2pro becomes
>> the LSB of the V4?
>>
>> And if I send data from a V4 to a V2Pro the LSB is sent first.  when
>> the V2Pro receives and deserializes the data, the LSB of the V4 becomes
>> the MSB of the V2Pro?
>>
>> If the bus order is inverted at one end of the link, everything should
>> be OK?
>>
>> Jason
>>
> 
> No, it's a byte ordering issue, not a bit ordering issue, so
> the order that the bytes are sent or received are different.
> 
>         V-II Pro                    V-II Pro X/V-4
> 1 Byte: [7:0]                     = [7:0]
> 2 Byte: [15:8][7:0]               = [7:0][15:8]
> 4 Byte: [31:24][23:16][15:8][7:0] = [7:0][15:8][23:16][31:24]
> 
> For example if you want to send the following bytes in the
> following order:
> 
>   Byte 1 = 0xDE
>   Byte 2 = 0xAD
>   Byte 3 = 0xBE
>   Byte 4 = 0xEF
> 
> In Virtex-II Pro   TX/RXDATA[31:0] would be 0xDE_AD_BE_EF
> In Virtex-II Pro X TX/RXDATA[31:0] would be 0xEF_BE_AD_BE
> In Virtex-4        TX/RXDATA[31:0] would be 0xEF_BE_AD_BE
> 
> Ed
> 

One caveat with the above is that this is true for the encoded modes.

In the case of non encoded (aka raw) bit ordering would be a complete
LSB to MSB swap.

Ed

Article: 82601
Subject: Re: 5V PCI interface
From: "gja" <geeja@hotmail.com>
Date: Thu, 14 Apr 2005 14:35:52 -0400
Links: << >>  << T >>  << A >>
 I investigated further and was able to get 3v across the switch by
isolating the TTL side of the switch from the rest of the bus and driving
the switch with a signal generator.
And for some reason now,  with everything as it was, I do see 3v on the
virtex2 side of the switch, even though I know at one point I did not. So I
will continue investigating based on the assumption that something on the
TTL bus is loading the bus down when performing a read from the virtex2
device.
Austin, thanks again for letting me know that what I was seeing was
abnormal, and that I should relook at it.

gja

"gja" <geeja@hotmail.com> wrote in message
news:F2j7e.211$V02.115@fe08.lga...
> Austin, thank you for your responses.  My replies are below:
>
> "Austin Lesea" <austin@xilinx.com> wrote in message
> news:d3k3jm$mav1@cliff.xsj.xilinx.com...
> > gja,
> >
> > See below,
> >
> > Austin
> >
> > gja wrote:
> >> Austin, are you saying that you've actually seen the circuit actually
> >> pass 3v across the switch ?
> > Yes, I have.
>
> OK, I will have to investigate further now that I know that it should.
>
>
> >  Or are you saying that the output SHOULD be clamped
> >> around 2.3v ?
> > No, I am not.
> >>
> >> Perhaps I should've been more clear, but I am currently testing a new
ckt
> >> board built with the circuit in xapp646 and a virtex2 part.
> >> With the IDT  vcc at 3.3v, the maximum voltage I am seeing with a scope
> >> is about 2.3v on the output side of the switch. IE., when the virtex2
> >> part is driving (lvttl) one side of the switch at 3.3v, the other side
of
> >> the switch is about 2.3v.
> > Into what load?  On a "real" PCI bus is where I made the measurements.
> > Perhaps if you use the resistor "standard termionation" (which is
anything
> > but a standard) you will get some other result?
>
> My application uses the switch to connect a Virtex2 to a slow (1us access
> times) 5v TTL databus, not PCI. The virtex2 pins are configured as
lvcmos33
> iobuf and is the only device on one side of the quickswitch, so I don't
> think it is a loading problem. When the 5v FCT chip is driving the virtex2
> (thru the switch), I see 4v on the ttl side but only 2.3v on the virtex2
> side.
>
> >  When the 5v ttl part 74FCT645 is writing to the virtex2 part,
> >> I see 4v on that side of the switch and 2.3v on the virtex2 side.
> > OK.  I will admit that the TI part has some advantages, but it is also
an
> > active device, and adds delay, doesn't it?
>
> No, the TI devices SN74CB3T3384  and SN74CBTD3384C are also FET switches
> with the same delay spec as the IDT part.  The SN74CB3T3384 device uses a
> vcc of 3.3v while the SN74CBTD3384C uses 5v. Both devices claim to do 5v
to
> 3.3 v level translation.
>
> >  When I
> >> originally looked at xapp646, it stated that it would clamp to less
than
> >> ~3v outputs, I didn't think it would be closer to 2.3v.  If I had used
> >> the implementation in IDT's  or TI's appnote where they drive the vcc
pin
> >> at 4.3v using a diode from 5v, I wonder if that would have worked
better.
> > Except that then you do not limit the voltages to less than what we
> > require.
>
> They do because the QS3861 clamps to VCC-1, so 4.3 - 1 = 3.3v
>
>
>



Article: 82602
Subject: Re: Xilinx VIIPro power supplies
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 14 Apr 2005 11:45:06 -0700
Links: << >>  << T >>  << A >>
Ed,
No offence taken Ed! Especially as you agree that switching regulators can
work later on in your post. I did write "as long as you provide for adequate
filtering on the supplies". I realise that you guys write your App. notes to
protect your customers from when designs go bad, and you err on the side of
safety, but all I'm trying to say is that it can work. I accept it may be a
more risky route. Some ways to reduce the risk are:-
1) Defeat any burst mode the switcher may have. The bursts can give bad LF
noise.
2) Provide for resistive low frequency filtering.
3) Switch as fast as possible, some modern switchers switch at several MHz,
easier to filter.
4) Don't skimp on the layout effort and bypassing.
5) Don't use a board wide supply plane.

I wonder if you see mostly bad switcher designs because no-one rings Xilinx
to complain when the switcher design works!
Cheers, Syms.

"Ed McGettigan" <ed.mcgettigan@xilinx.com> wrote in message
news:425EAEE6.3020708@xilinx.com...
> Symon please don't take any offense at this, but this information
> is wrong and would like lead a designer into a serious issue with
> their high speed serial links if they were to take your advice.
>
> For the record, Xilinx design requirements for the RocketIO supplies
> are that the supply is sourced from a linear regulator with capacitive
> filtering as noted in the RocketIO user guides.  In addition each
> RocketIO voltage is to be isolated from the supply with a ferrite bead.
>
> Depending upon the family and package type you may also need another
> cap on the FPGA side of the ferrite bead as noted in the RocketIO user
> guides.
>
> Yes, you can have one supply to be the source for all RocketIO and you
> do not need to have individual regulators for each RocketIO or for
> each supply type.
>
> We make these requirements for your benefit and link quality across all
> possible conditions.
>
> In the real world, I have seen a few cases where switching power
> supplies have worked.  I have also seen far more cases where they
> are the root of the problem in a totally dead link or have produced
> a marginal link.
>
> Ed
>




Article: 82603
Subject: Re: ISE 7.1 for 64 bit Linux ???
From: Eric Smith <eric@brouhaha.com>
Date: 14 Apr 2005 12:25:29 -0700
Links: << >>  << T >>  << A >>
Rudolf Usselmann <russelmann@hotmail.com> writes:
> I read your post and did try the things you suggest, but like
> you, I too was NOT successful, installing the 64 bit version of
> ISE 7.1.

Sorry, I didn't read your post carefully enough so I didn't realize
that you were trying to use the 64 bit version.  I've been happy with
the 32 bit version.

If I had the full ISE rather than BaseX, and wanted to run the 64-bit
version, I'd probably install Centos Linux 3.4 (community-maintained
derivative of RHEL 3):
        http://www.centos.org/

Eric

Article: 82604
Subject: Re: Xilinx VIIPro power supplies
From: Eric Smith <eric@brouhaha.com>
Date: 14 Apr 2005 12:29:07 -0700
Links: << >>  << T >>  << A >>
Ed McGettigan <ed.mcgettigan@xilinx.com> writes:
> For the record, Xilinx design requirements for the RocketIO supplies
> are that the supply is sourced from a linear regulator with capacitive
> filtering as noted in the RocketIO user guides.  In addition each
> RocketIO voltage is to be isolated from the supply with a ferrite bead.
[...]
> In the real world, I have seen a few cases where switching power
> supplies have worked.  I have also seen far more cases where they
> are the root of the problem in a totally dead link or have produced
> a marginal link.

If I used a linear regulator, it would be fed from a higher voltage from
a switcher.  I've observed that linear regulators provide almost no
filtering of the switching noise, because their frequency response
doesn't extend that high, so apparently the recommended capacitive
filtering takes care of that?  If so, why doesn't the capacitive
filtering work adequately when using just a switcher?

Thanks,
Eric

Article: 82605
Subject: Re: 5V PCI interface
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 14 Apr 2005 13:28:14 -0700
Links: << >>  << T >>  << A >>
gja,

No problem.  Good luck with your troubleshooting.

Austin

Article: 82606
Subject: Re: Fitting functionality in an XC2VP30 FPGA.
From: Ray Andraka <ray@andraka.com>
Date: Thu, 14 Apr 2005 16:44:44 -0400
Links: << >>  << T >>  << A >>
:
You will probably be OK.  The mapper tends to put one lut/ff per slice 
when there is lots of room in the device.  Note that your total slice 
count for the individual designs is a bit less than the slice count in 
the device, so even without sharing slices you'll fit.  A better 
indicator is the LUT and FF counts, but with the caution that depending 
on the design you may not be able to pack some of them in the same 
slice.  In your case, I don't see a problem.

-- 
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com  
http://www.andraka.com  

 "They that give up essential liberty to obtain a little 
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 82607
Subject: Re: free-ip
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 14 Apr 2005 22:48:55 +0200
Links: << >>  << T >>  << A >>
ok I wasnt lazy the freelib1 is now downloadable
http://gforge.openchip.org/projects/wwwfreeipcom/

antti

"Daniel Florin" <florin@primelec.ch> schrieb im Newsbeitrag
news:d3ma49$pm4$1@news.hispeed.ch...
> Over the last couple of weeks I have tried accessing the web site
> www.free-ip.com and gotten an error message. Is it mirrored someplace else
> on the web?
>
> I am looking for Free-LIB1, a library of NCO, DAC and PWM parameterized
> cores in VHDL, which was available at www.free-ip.com.
>
> Any information is very appreciated.
>
>



Article: 82608
Subject: Re: Flowcharts and diagrams
From: Reinier <usenet@NO_SPAM.nl>
Date: Thu, 14 Apr 2005 23:01:16 +0200
Links: << >>  << T >>  << A >>
On Thu, 14 Apr 2005 13:25:20 +0200, Engineering Guy
<whataloginsfor@os.pl> wrote:

>Reinier wrote:
>
>> Hi,
>> 
>> I'm looking for a freeware or low cost program do document and
>> illustrate the signal processing flow in my FPGA design.  I'd like to
>> use building blocks like adders, multipliers, memory, busses etc. What
>> do you guys use to make some nice looking pictures? I don't want to
>> spend days learning Corel Draw or something huge like that.
>> 
>> Thanks,
>> Reinier
>
>Never used, but heard of Dia:
>	http://www.gnome.org/projects/dia/
>It is claimed to be a Visio replacement. Its multi-platform and free.
>Give it a try.
>
>EG

Thanks, I'll give it a try.

BTW, I found an ancient Win95/NT program (Flow!) in the office that
was just collecting dust.

Thanks for your input!
Reinier

Article: 82609
Subject: Re: Xilinx VIIPro power supplies
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 14 Apr 2005 14:11:17 -0700
Links: << >>  << T >>  << A >>
Eric,
I wonder if it's because of low frequency noise generated from switchers
that are working in burst mode? The subsequent linear regulator can deal
with that.
Cheers, Syms.
"Eric Smith" <eric@brouhaha.com> wrote in message
news:qh1x9d17jw.fsf@ruckus.brouhaha.com...
> If I used a linear regulator, it would be fed from a higher voltage from
> a switcher.  I've observed that linear regulators provide almost no
> filtering of the switching noise, because their frequency response
> doesn't extend that high, so apparently the recommended capacitive
> filtering takes care of that?  If so, why doesn't the capacitive
> filtering work adequately when using just a switcher?
>
> Thanks,
> Eric



Article: 82610
Subject: Re: LVDS PCI card is needed
From: "soos" <marcsok@yahoo.com>
Date: 14 Apr 2005 15:29:13 -0700
Links: << >>  << T >>  << A >>
Austin, hello

Thank you for your reply. I have visited the site you mentioned but
failed to find
an LVDS card with a pci interface.

I have noticed that you are a Xlinx member, could you point other
companies that implement LVDS on your FPGAS?

Thanks in advance, and sorry to bother you,
Marc.


Article: 82611
Subject: Help OPB <> Wishbone wrapper
From: "Marco" <marcotoschi_no_spam@email.it>
Date: Fri, 15 Apr 2005 00:51:43 +0200
Links: << >>  << T >>  << A >>
Hallo,
I should connect the wishbone can core with opb bus.

I have downloaded from asics.ws the wrapper.

There is someone who could explain how to use it?

I have also made some search for a tutorial or documentation, but I don't
have found nothing.

Where I could find the documentation?


Many Thans
Marco

Thanks
Marco Toschi



Article: 82612
Subject: Re: CCD and Graphics - which FPGA?
From: christopher.saunter@durham.ac.uk (c d saunter)
Date: Thu, 14 Apr 2005 23:31:41 +0000 (UTC)
Links: << >>  << T >>  << A >>
Greetings,
	Comments inline below...

C. Peter (die_les_ich_nicht@gmx.net) wrote:
: Hi all,

: some years have gone since I did something with FPGAs and I am aware that 
: technology has moved forward significantly since the end of the last 
: century ...

: We now think about reading out some CCD sensors and doing image processing 
: with an FPGA. My questions to you:

When you say "reading out some CCD..." does this include generating the 
various readout waveforms for the CCD?  FPGAs make excelent waveform 
generators for controling a CCD, and can be much better suited to 
this task than a CPU, although care is needed with the timings.

So yes an FPGA is good for readout control, but whether it is good for 
image processing depends on the nature of the processing.  If you ask 
yourself "are my processing algorithms highly deterministic?" and the 
answer is "yes", then the FPGA is likely a good choice.  If the answer is 
"actually no, our reference C code is full of conditional branches and 
uses different algorithms bassed on the image content etc." then more 
consideraton is needed.

Cheers,
      Chris

: - do you think this is feasable?
: - which FPGA would you recommend?
: - Which language would you recommend?

: We have used Xilinx and Handel-C so far and hence would prefer to stick to 
: them. But if there are good arguments against it we would certainly follow 
: them.


: Thanks a lot for your advice,

: Christian


Article: 82613
Subject: Re: Reading old F2.1i schematics
From: John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com>
Date: Thu, 14 Apr 2005 16:42:40 -0700
Links: << >>  << T >>  << A >>
On 13 Apr 2005 09:12:51 -0700, "Andy Peters" <Bassman59a@yahoo.com>
wrote:

>I'm sure others have this problem ...
>
>Is there a tool that'll let one view and hopefully print a schematic
>done in the old Xilinx F2.1i schematic tool?  The new stuff doesn't
>want to know about the old stuff, and worse is that you can't even
>install 2.1i on an XP machine. (Yeah, that'll teach me to upgrade.)
>
>I don't want to do anything with this schematic other than view it.
>I'm doing a new board sorta based on an old design, and the new design
>will of course be in VHDL rather than as a schematic.
>
>Ideas?
>
>-a


What the world needs is a standard schematic file format.

Our policy now is to release PDFs of all schematics with the designs,
so at least it's easy to see what's there.

John


Article: 82614
Subject: Re: Altera DSP dev board stratix II
From: "Jerry" <nospam@nowhere.com>
Date: Thu, 14 Apr 2005 21:12:31 -0400
Links: << >>  << T >>  << A >>

"Jerry" <nospam@nowhere.com> wrote in message
news:n9l7e.9709$_63.1095@fe03.lga...
> I download my design via byteblaster USB. The  leds wink and blink as if
the
> fpga is taking the data.
> At the end of downloading, the original configuration is still running
with
> the 4 leds down counting and the
> nco running the two sine waves. I did change the default configuration of
> the unused pins to inputs tri state.
> I also downloaded all of the supplied configurations that came along with
> the board. No effect.
>
> Anyone have any suggestions?
>
> Tks
> Jer
>
>
To answer my own post in case some one else has a similiar problem. You got
to turn sw4 off on the dip switch.



Article: 82615
Subject: Re: Global buffer feeding non clock pins in VIRTEX II
From: "gja" <geeja@hotmail.com>
Date: Thu, 14 Apr 2005 21:59:40 -0400
Links: << >>  << T >>  << A >>
It's not on a global clock line if it's the output of a LUT, that's why he 
said send the output of the LUT to a global clock buf.

"g. giachella" <giachella.g@laben.it> wrote in message 
news:caea16ca.0504122217.8f4a11c@posting.google.com...
> "Marc Randolph" <mrand@my-deja.com> wrote in message 
> news:<1113311589.903268.83150@z14g2000cwz.googlegroups.com>...
>> Howdy,
>>
>> Depending on how you are getting signals between blocks A/B and C,
>> there is the potential for trouble - but the MUCH bigger problem is
>> that you will have unacceptable skew *within* block C.  Unless you
>> floorplan the flops within block C (and do so VERY intelligently),
>> you're asking for trouble.  Even if you do the muxing with LUTs, send
>> the output of the LUT to a global clock.
>>
>> And yes, the skew within blocks A and B should be fine.
>>
>>    Marc
>
> Could you clarify this point ? Why shouldn't the skew inside block C
> be low, assuming it is also an a global clock line ?
>
> Thanks 



Article: 82616
Subject: Re: LVDS PCI card is needed
From: austin <austin@xilinx.com>
Date: Thu, 14 Apr 2005 19:13:03 -0700
Links: << >>  << T >>  << A >>
soos,

Was it: http://www.dyneng.com/pci_lvds.html
or,
another one of the 907 hits on google for:

LVDS Xilinx PCI card

I was just using google to find the card.  A lot of links to wade through.

Good luck,

Austin



soos wrote:

> Austin, hello
> 
> Thank you for your reply. I have visited the site you mentioned but
> failed to find
> an LVDS card with a pci interface.
> 
> I have noticed that you are a Xlinx member, could you point other
> companies that implement LVDS on your FPGAS?
> 
> Thanks in advance, and sorry to bother you,
> Marc.
> 

Article: 82617
Subject: Re: virtex4 reconfiguration time
From: "Marc Randolph" <mrand@my-deja.com>
Date: 14 Apr 2005 21:23:59 -0700
Links: << >>  << T >>  << A >>
Stephane wrote:
>
> Thank you guys for your feedback!
>
> I am to understand that a 32b selectMap is reserved for future use,
when
>   7.1i will be stable, and xilinx engineers more available...
>
> Ok, but how can the internal conf logic detect what is the kind of
> incoming bistream? As soon as the syncro words? In that case, one can

> not place any garbage on D[31..8], as they might be badly
interpreted!

Howdy Stephane,

I have no idea how they really do it, but one simple way would be to
ignore the contents of D[31..8] until after you decide it should switch
to 32 bit mode:

32 bit mode          8 bit mode
 D32   D0             D32   D0
 XXXXXX32             XXXXXX08
[START 32 BIT MODE]   XXXXXXXX
 5678ABCD             XXXXXXXX
                      XXXXXXXX (or 08 could be here)
                      [START 8 BIT MODE CONFIGUATION]
                      XXXXXXCD
                      XXXXXXAB
                       ...etc

X's are obviously don't cares.

BTW, I neglected to mention something on my original reply about the
configuration time: it is only that low (10 msec) if you can really
feed a byte to the part on every clock cycle.  If you are driving the
selectMAP from a microprocessor, that may not be possible since it can
take them many cycles for each bus access.

   Marc


Article: 82618
Subject: Re: Fitting functionality in an XC2VP30 FPGA.
From: "Marc Randolph" <mrand@my-deja.com>
Date: 14 Apr 2005 21:38:43 -0700
Links: << >>  << T >>  << A >>
Howdy Simon,

   I forgot to explain why I mentioned 99% slice usage... doing so
should help confirm your (correct) understanding of unrelated logic.
The tools actually output a message that explains unrelated logic:

NOTES:
  Related logic is defined as being logic that shares connectivity -
  e.g. two LUTs are "related" if they share common inputs.
  When assembling slices, Map gives priority to combine logic that
  is related. Doing so results in the best timing performance.
  Unrelated logic shares no connectivity. Map will only begin
  packing unrelated logic into a slice once 99% of the slices are
  occupied through related logic packing.
  Note that once logic distribution reaches the 99% level through
  related logic packing, this does not mean the device is completely
  utilized. Unrelated logic packing will then begin, continuing until
  all usable LUTs and FFs are occupied. Depending on your timing
  budget, increased levels of unrelated logic packing may adversely
  affect the overall timing performance of your design.

(taken from
http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/sim/sim0020_5.html)

So as you can see from the output message, until it reaches 99%, the
tools almost go out of their way to use up slices before starting to
work a bit harder and put things that don't share inputs together.  If
your unrelated logic is 0%, there is still considerable headroom above
99%.  It's only when unrelated logic packing auto-activates that you
need to be concerned about being over 99%, and even then, it varies
drasticly by design.  Here is the output of one design I helped with a
few years ago in ISE 5.3.3i:

Logic Utilization:
  Total Number Slice Registers:    10,129 out of  18,560   54%
  Number of 4 input LUTs:          13,491 out of  18,560   72%
Logic Distribution:
    Number of occupied Slices:                        9,278 out of
9,280   99%
    Number of Slices containing only related logic:   5,259 out of
9,278   56%
    Number of Slices containing unrelated logic:      4,019 out of
9,278   43%

[note that it is ONLY saying that 43% of the used slices contain
unrelated logic... it isn't saying that utilization is 99% + 43%, or
anything like that]

BTW, this whole discussion about unrelated logic usage only applies if
you leave the -timing option for MAP turned off (at least in ISE 6.x or
7.x).  If -timing is turned on, I believe that slice packing is done
differently such that you won't get an unrelated packing number... in
theend, with -timing you should get better results, but it keeps the
designer a little more in the dark about how full the design really is.


None of this changes the fact that since your total slice usage is less
than your target device, so it should fit with no problems.

Here is another explaination of unrelated logic:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=12191

Summary: in some instances, it can adversely affect routability or
routing delays.  In short, it varies by design. :-)

Good luck,

   Marc


Article: 82619
Subject: Re: PPC405 Performance Monitoring
From: "Nju Njoroge" <njoroge@stanford.edu>
Date: 14 Apr 2005 21:48:14 -0700
Links: << >>  << T >>  << A >>
Anthony Mahar wrote:
> As they state in their paper
> http://cag.csail.mit.edu/warfp2005/submissions/29-suh.pdf
>
> "In our initial study, we deploy a monitoring capsule in Dcaches to
mon-
> itor the memory behavior between a CPU and L1 Dcache."
>
> It is not possible to monitor signals between the CPU and L1 cache (I
or
> D).  Was the monitoring of CPU/L1 inferred by the cache misses seen
> coming from L1?
They had two versions of their monitor--one for the MicroBlaze core and
one for the PPC. For the PPC, they inferred the cache missess as seen
from the L1. With the uBlaze, since they have access to the L1 cache
signals, they could wedge their monitor in it.
>Even so, a lot of memory behavior is missed when only
> observing cache misses.
>
> Regards,
> Tony
>
> Nju Njoroge wrote:
> > Anthony Mahar wrote:
> >
> >>Nju Njoroge wrote:
> >>
> >>Interesting question for the "Monitoring Capsule Design" paper...
> >
> > they
> >
> >>state they monitor behavior "between the CPU and L1 Dcache."  Did
> >
> > they
> >
> >>explain how they were able to do this, since the PPC405 and L1 are
> >
> > part
> >
> >>of the same hard core?
> >>
> >
> > You are right--the CPU and the L1 cache are in the same hard core,
so
> > we don't have access to the interface inside the CPU core and the
> > cache. As I described in my previous post, they placed their
monitor at
> > the interface of the L1 cache port that are usually connected to
the
> > PLB. Thus, instead of connecting their CPU to the PLB bus, they
> > connected the PPC core to their monitor, which is then connected to
the
> > PLB.
> > 
> > NN
> >


Article: 82620
Subject: clock input over an I/O pin
From: arthur@ieee-dot-org.no-spam.invalid (downunder)
Date: Thu, 14 Apr 2005 23:50:55 -0500
Links: << >>  << T >>  << A >>
Hi,

I was wondering if anyone has any advice or experience on the
following:

I need to clock some logic with a clock signal that is connected to an
I/O pin (PCB design constraint!). What are the consequences of
connecting this signal to a DCM input? I'm assuming it's possible...

Does anyone have any recommendations? I'm using Virtex II Pro and the
clock signal is in the 100MHz range.

thanks.


Article: 82621
Subject: Re: re:implement the JTAG MASTER --ACT8990 by using FPGA
From: strayblue2003@yahoo.com-dot-cn.no-spam.invalid (strayblue)
Date: Thu, 14 Apr 2005 23:50:56 -0500
Links: << >>  << T >>  << A >>
I think your conclusion about three kinds of people is very
classical.I hope that we will have more intercommunion.

> Antti Lukatswrote:
"strayblue" <strayblue2003@yahoo.com-dot-cn.no-spam.invalid>
schrieb im
> Newsbeitrag news:lt6dnd2PNq8vYcbfRVn_vg@giganews.com...
> Thank you very much,I will learn to do it,and will do it better.
> 
thats better attitude, I belive that if you do, you can do it.
better.

The links I provided do not give anything quite ready to use, just
those
starting points known to me. Hopefully there was some usefulness in
it. And
hope you didnt mind my writing style, I am very open, so I say what I
think.
So get a Smile and start doing. And try keep smiling :)

Antti
BTW I am at the moment quite engaged with JTAG from different aspects,
both
from master and slave side and also in supporting software, so if you
make
something better, please keep me posted, or better would be if there
would
be some result from your work that could be used by others.



[[/quote:a8cad9cfa2]


Article: 82622
Subject: Re: clock input over an I/O pin
From: "Marc Randolph" <mrand@my-deja.com>
Date: 14 Apr 2005 22:10:34 -0700
Links: << >>  << T >>  << A >>

downunder wrote:
> Hi,
>
> I was wondering if anyone has any advice or experience on the
> following:
>
> I need to clock some logic with a clock signal that is connected to
an
> I/O pin (PCB design constraint!). What are the consequences of
> connecting this signal to a DCM input? I'm assuming it's possible...
>
> Does anyone have any recommendations? I'm using Virtex II Pro and the
> clock signal is in the 100MHz range.

Howdy,

Yes, it should be possible.  You'll probably pick up a little jitter,
and definitely will have a phase offset due to prop delay, but probably
nothing that is a show stopper.

You didn't say if you need to clock I/O signals into the part with this
clock.  Or out of the part.  For the out direction, is there a
requirement that the I/O's toggle with a particular phase relationship
to the input clock?  If you do have I/O requirements, I believe you can
work around it by using the fixed phase offset of the DCM to dial in a
compensation for the prop delay of the input buffer, internal routing
to the DCM, GBUF, and global clock delay - may take a few experiments
to get it right.  I/O requirements are the toughest thing to meet with
a situation like yours, but at 100 MHz, it should be doable by locking
down the routing from the input IOB to the DCM(s).

If you have lax or no I/O timing requirements, most of the above
doesn't apply and your job will be even easier.

Good luck,

   Marc


Article: 82623
Subject: Re: Xilinx TMRTool price
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 15 Apr 2005 15:23:56 +1000
Links: << >>  << T >>  << A >>
Amora wrote:

> I couldn't find any information regarding the price of Xilinx's new
> TMRTool. Does anybody happen to be interested in knowing the price of
> this tool?

The Xilinx webpage says contact your local sales office for pricing:

http://www.xilinx.com/products/milaero/tmr/index.htm

However I'd be surprised if this is not subject to export control. 
Rad-hard electronics systems (and design tools) come under US Govt. ITAR 
(International Traffic in Arms Regulations) restrictions.  It would be 
interesting to hear what your local Xilinx sales office has to say on 
the matter.

Regards,

John


Article: 82624
Subject: Re: tools used for ASIC synthesis
From: "teen" <nkishorebabu123@yahoo.com>
Date: 14 Apr 2005 22:29:17 -0700
Links: << >>  << T >>  << A >>
Thank you Jon

Kishore




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