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
2019JanFebMar2019

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 128025

Article: 128025
Subject: Re: Virtex4 burn-in failure
From: msn444@gmail.com
Date: Sun, 13 Jan 2008 22:38:04 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 12, 6:43 pm, "BobW" <nimby_NEEDS...@roadrunner.com> wrote:
> <msn...@gmail.com> wrote in message
>
> news:c7463bc7-1443-4ee1-9de6-5b602825bb8e@m77g2000hsc.googlegroups.com...
>
>
>
> > Hello,
>
> > I've observed a failure of one of our Virtex4-based products that is a
> > bit puzzling. The device had been in operation for several weeks
> > before failing, and is among a run of a couple hundred. I've dissected
> > the specimen, and the Virtex4 appears to draw a large amount of
> > current and gets hot immediately upon power-up. It does not configure
> > or show any signs of life.
>
> > Aside from the possibility of this being induced by a manufacturing
> > defect that took its time to show up, can anyone think of any design-
> > related causes of a failure like this?
>
> > Thanks in advance,
>
> > Mike.
>
> Do any of the power supplies EVER exceed the maximum allowed? You should
> carefully check power-on, operating, and power-off conditions with a high
> speed scope. This is the only thing that I've ever done that truly damaged
> an FPG
>
> Another (less likely) possiblility is overcurrent on inputs due to driving
> them above and/or below the supplies.
>
> What about over-temperature? However, it would have to get effing hot (>125C
> ?).
>
> I can't think of anything that would bother the thing.
>
> Bob

I haven't seen any sign of the power supply voltages going over the
maximum, but I'll take a closer look. Pretty sure the device isn't
going over 60C in normal operation, let alone 125C, so I don't think
that's it...

Thanks for the suggestions...
Mike.

Article: 128026
Subject: Read/Write SRAM on Spartan3 Starter kit
From: Nick <tklau@cuhk.edu.hk>
Date: Mon, 14 Jan 2008 15:17:15 +0800
Links: << >>  << T >>  << A >>
Hi all,

I am sorry if this problem has been answered but I cannot find much help 
from the archive.

I am trying to test the SRAM on the S3 starter kit board with the 
following code:

if ToWrite then
	data_buffer <= "00000000000000001111"; --A
	sram_io <= data_buffer;
	data_buffer <= "00000000000000000101"; --B
else
	sram_io <= (others=>'Z');
	led_out(0) <= sram_io(0);
	led_out(1) <= sram_io(1);
	led_out(2) <= sram_io(2);
	led_out(3) <= sram_io(3);
end if;


The output on the leds keep showing the result B (ie "0101") instead of 
"1111".

Please help!~

Article: 128027
Subject: Re: Place-and-Route : Intel vs AMD
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Jan 2008 23:24:13 -0800
Links: << >>  << T >>  << A >>
Eric Smith wrote:

(snip)

> Historically, having two banks of interleaved memory meant that if bank 0
> was busy reading or writing an even word address, bank 1 could start an
> access to ANY odd word address, not just n+1.  It is my understanding
> that that was the reason for inventing interleave rather than simply
> making the memory word longer.

I first learned about interleaving reading about the IBM 360/91, which
has 16 way interleaved 750ns memory, and a 60ns processor cycle time.
I believe it is 64 bits wide.  The design goal was one instruction
per clock cycle, which tended to require one 64 bit doubleword
per cycle (for 64 bit floating point operations).

That was before cache (on the 360/85).

-- glen


Article: 128028
Subject: Re: Real examples of metastability causing bugs
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Sun, 13 Jan 2008 23:29:01 -0800
Links: << >>  << T >>  << A >>
-jg wrote:

(snip)

> There are also two error types, the average one, and the peak one.
> Sometimes in engineering, we like to think about worst case, as
> well as averages.

> Someone else mentioned a locked metastable generation system,
> ie one that deliberately tries to be metastable.

> Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock,
> -or- a 100MHz(+ErrM), and assume a 'nominally' real system with
> nice round numbers of a 0.1fs window, and 0.1ps jitter

I had originally thought of it based on a PLL, which would have
jitter.  That would be part of the measurement.

There is a web site in another post that uses one clock with a
variable delay.  That may help as far as jitter.

> Q1: Can these widely variant clocks ever give the same peak error
> rates ?
> Q2: Can the error rate ever go above one per microsecond  ?

That is still a lot faster than without a lock system.

-- glen


Article: 128029
Subject: Re: Read/Write SRAM on Spartan3 Starter kit
From: Ben Jackson <ben@ben.com>
Date: Mon, 14 Jan 2008 01:41:08 -0600
Links: << >>  << T >>  << A >>
On 2008-01-14, Nick <tklau@cuhk.edu.hk> wrote:
> 	data_buffer <= "00000000000000001111"; --A
> 	sram_io <= data_buffer;
> 	data_buffer <= "00000000000000000101"; --B

I don't speak VHDL, but in Verilog if you wrote something like that
in a process that happened on every clock, the first assignment of
data_buffer would be overridden by the second.  If you want a series
of steps (outside of simulation) you're going to have to do it with
some kind of counter or state machine.

Eg:

	data_buffer <= phase_a ? 20'b1111 : 20'b0101;

(in Verilog, but you get the idea)

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

Article: 128030
Subject: Re: Real examples of metastability causing bugs
From: -jg <Jim.Granville@gmail.com>
Date: Mon, 14 Jan 2008 00:18:21 -0800 (PST)
Links: << >>  << T >>  << A >>


glen herrmannsfeldt wrote:
> -jg wrote:
>
> (snip)
>
> > There are also two error types, the average one, and the peak one.
> > Sometimes in engineering, we like to think about worst case, as
> > well as averages.
>
> > Someone else mentioned a locked metastable generation system,
> > ie one that deliberately tries to be metastable.
>
> > Suppose I have a 1MHz data rate, and choose a 1MHz (+ErrN) Clock,
> > -or- a 100MHz(+ErrM), and assume a 'nominally' real system with
> > nice round numbers of a 0.1fs window, and 0.1ps jitter
>
> I had originally thought of it based on a PLL, which would have
> jitter.  That would be part of the measurement.
>
> There is a web site in another post that uses one clock with a
> variable delay.  That may help as far as jitter.

Simplest delays can be either RC, or Variable Vcc on Buffers,
or you could use a LC system for a phase
shifter, which should have less phase jitter than RC.

-jg

Article: 128031
Subject: Re: Is it possible to define an Integer so it could be incremented
From: Pablo <pbantunez@gmail.com>
Date: Mon, 14 Jan 2008 00:30:40 -0800 (PST)
Links: << >>  << T >>  << A >>
Thanks to everyone for your advices. It has been very usefull for me.

Pablo

Article: 128032
Subject: Re: Virtex4 burn-in failure
From: mk <kal*@dspia.*comdelete>
Date: Mon, 14 Jan 2008 01:35:43 -0800
Links: << >>  << T >>  << A >>
On Sun, 13 Jan 2008 20:48:16 -0800 (PST), Dave Pollum
<vze24h5m@verizon.net> wrote:
>Just out of curiousity, what is "NBTI" ?

google is your friend: http://www.google.com/search?hl=en&q=nbti top 4
items.

Article: 128033
Subject: Re: setup ETHERNET UDP link suing spartan-3E starter kit
From: bart.hommels@gmail.com
Date: Mon, 14 Jan 2008 01:52:58 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 11, 2:12 pm, Dilan <dilan2...@gmail.com> wrote:
> hi,
> i need to 100BASET connection with a PC using xilinx spatan-3E board
> and lan83c185 chip.i need a bare system just to send some predefined
> UDP packets without using a Soft processor . if any one have some app
> notes on lan83c185 is helpful.
>
> thanks
> dilan

2nd Google hit on 'smsc lan83c185':

http://www.smsc.com/main/datasheets/83c185.pdf

have fun

Article: 128034
Subject: Where has Xilnet gone?
From: ratemonotonic <niladri1979@gmail.com>
Date: Mon, 14 Jan 2008 03:53:59 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi all ,

I am new to xilinx tool and currently I am working with a project
constructed using EDK 7.1. I am using EDK 9.2.

In this old project Xilnet is used for a webserver demo talking to an
external MAC/PHY chip (SMSC 91C111).

Where can I get this library ?

BR
rate

Article: 128035
Subject: Re: Resource utilization broken down by hierarchy?
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Mon, 14 Jan 2008 12:29:26 +0000
Links: << >>  << T >>  << A >>
paragon.john@gmail.com writes:

> Hello,
>
> I am interested in looking at the resource utilization of a design I
> am working on broken down based on the RTL hierarchy of the design.  

You could try FPGAOptim http://www.conekt.net/fpgaoptim.html - it's
designed for just such a job (Full disclosure - I wrote it :-)

Please mail me if you want a copy.  It allows me to keep track of who
needs updates (a V5 updates is in the offing...)

Cheers,
Martin

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

Article: 128036
Subject: Re: Virtex4 burn-in failure
From: Allan Herriman <allanherriman@hotmail.com>
Date: Tue, 15 Jan 2008 01:06:54 +1100
Links: << >>  << T >>  << A >>
On Sun, 13 Jan 2008 12:54:17 -0800, austin <austin@xilinx.com> wrote:

>Ben,
>
>No mystery:  NBTI.  Unused MGT front end pmos devices in the 
>differential amplifier circuits could see a significant Vt shift if they 
>were not transitioning.  One input high, and one low, and NBTI occurs in 
>the pmos devices, made even worse if the temperature is also high (e.g. 
>like 70 to 85C or hotter).  The DCM delay line was also susceptible to 
>NBTI shift, hence the "auto-cal" block being added by the software (to 
>keep delay lines busy switching at a low frequency).
>
>Later devices perform these functions by hardware, or design techniques 
>to mitigate the shift are used (no longer an issue after V4).
>
>Although the NBTI shift may be demonstrated in a lab, there has never 
>been a case of a field failure for either the MGT, or dCM, due to NBTI. 
>  It seems the condition is created by such a specific sequence of 
>temperatures, and static voltages, that unless you are unlucky enough to 
>duplicate, all the pmos shift together, and everything is just fine.
>
>NBTI starts out quick, then slows down.  A bake without power restores 
>the levels a lot.  Just turning things on and off, can mitigate any 
>issues.  Very tricky stuff, but once understood, can be dealt with easily.
>
>NBTI is over thirty years old, and has been understood and dealt with by 
>the IO designers for a long time.  What was a surprise is that MGT front 
>end design (and the DCM delay line) used thinner oxide devices in V4, 
>and didn't expect to see the shift.  Foundry practices also helped tune 
>down the effects.
>
>This particular "melt-down" scenario is unrelated to NBTI.
>
>Common causes: shorts in the package/pcb/solder balls, over-temp of the 
>die (caused by inadequate heatsinking), large over voltage (on core, io, 
>or aux -- causes junction or gate breakdown, this may be power supply, 
>or ESD).
>
>Xilinx will issue a RMA (return mechandise authorization) and try to 
>find the cause of failure.  However, this is not taken lightly, we 
>request that the customer removes the device using very specific 
>methods, so that we can establish what caused the failure (often 
>customers remove the device, destroying it in the process).
>
>A RMA is also something that takes time, and just one failure is not 
>considered a reason to go to all the trouble.
>
>Any device returned without authorization is not accepted.

Hi Austin,

Do Xilinx publish overall figures for RMA devices, e.g. what fraction
are caused by ESD, no fault found, overvoltage, etc?

Thanks,
Allan.

Article: 128037
Subject: Debbuging a RISC processor on an FPGA
From: pg4100 <pg4100@yahoo.co.uk>
Date: Mon, 14 Jan 2008 14:11:02 +0000
Links: << >>  << T >>  << A >>
Hi

I have implemented a RISC architecure and RTL simulation in Modelsim 
works fine. So the next step would be to run this architecture on an
FPGA and see if it still outputs the correct results. So far my only 
idea is go use Chipscope to connect to the core and then try to read out
the register contents as soon as the computation of the program has 
finished. Until now I just used Chipscope to debug simple design where
I just had debugg one output value and not a set of registers.

Are their maybe other approaches that I could use to see if the 
sythesized core does the same as the simulated one?

Would be thankful for other ideas

Thanks!

Article: 128038
Subject: Re: Debbuging a RISC processor on an FPGA
From: "HT-Lab" <hans64@ht-lab.com>
Date: Mon, 14 Jan 2008 14:38:40 GMT
Links: << >>  << T >>  << A >>

"pg4100" <pg4100@yahoo.co.uk> wrote in message news:fmfqhm$a86$1@aioe.org...
> Hi
>
> I have implemented a RISC architecure and RTL simulation in Modelsim works 
> fine. So the next step would be to run this architecture on an
> FPGA and see if it still outputs the correct results. So far my only idea 
> is go use Chipscope to connect to the core and then try to read out
> the register contents as soon as the computation of the program has 
> finished. Until now I just used Chipscope to debug simple design where
> I just had debugg one output value and not a set of registers.
>
> Are their maybe other approaches that I could use to see if the sythesized 
> core does the same as the simulated one?

What about adding a simple UART or low-cost HD44780 (or compatible) LCD 
displays to your processor.

Hans
www.ht-lab.com


>
> Would be thankful for other ideas
>
> Thanks! 



Article: 128039
Subject: Re: BRAM Readback
From: Jochen <JFrensch@harmanbecker.com>
Date: Mon, 14 Jan 2008 07:04:40 -0800 (PST)
Links: << >>  << T >>  << A >>
On 12 Jan., 11:28, bi...@wavenet.at wrote:
> Hi all,
>
> Is there a simple way to read back data from Virtex5 BRAMs
> preferable over JTAG by XSFV/SVF commands?
>
> Best regards
> Ed

Hi Ed,
 there used to be a TechXclusive from Kris Chaplin called
"Reconfiguring Block RAMs"
and a "PicoBlaze JTAG Program Loader", but unfortunately this seems to
have disappeared frrom Xilinx' website....

maybe sb. from Xilinx can give an updated link..

Jochen

Article: 128040
Subject: Re: Debbuging a RISC processor on an FPGA
From: Kris Vorwerk <kris.vorwerk@gmail.com>
Date: Mon, 14 Jan 2008 07:34:21 -0800 (PST)
Links: << >>  << T >>  << A >>
> Are their maybe other approaches that I could use to see if the
> sythesized core does the same as the simulated one?


For a CPU that I designed once, I setup an automated testing platform
where I ...

- ran a small, simple test case on the CPU, and recorded changes in
the program counter (PC)
- fed the recorded PCs back into my desktop computer ... (for this
particular design, I was able to use an existing serial connection)
- I wrote a small C program to gather the results coming in the serial
port and analyze the PCs that were output by the CPU (to compare it to
expected results)

I had a suite of several test cases which tested various ADD, MULT,
etc. instructions, and these were often used to JMP to different
locations (thereby changing the PC).  Any differences in the program
counter were automatically picked up by the C software when it
analyzed the "trace" of PCs.

This took a bit of time to get working perfectly (i.e., you have to
design the test cases and the C program correctly :), but as a real
believer in automated testing, I feel that it saved me a fair bit of
time down the road.

K.

Article: 128041
Subject: Re: BRAM Readback
From: John McCaskill <jhmccaskill@gmail.com>
Date: Mon, 14 Jan 2008 07:35:11 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 14, 9:04 am, Jochen <JFren...@harmanbecker.com> wrote:
> On 12 Jan., 11:28, bi...@wavenet.at wrote:
>
> > Hi all,
>
> > Is there a simple way to read back data from Virtex5 BRAMs
> > preferable over JTAG by XSFV/SVF commands?
>
> > Best regards
> > Ed
>
> Hi Ed,
>  there used to be a TechXclusive from Kris Chaplin called
> "Reconfiguring Block RAMs"
> and a "PicoBlaze JTAG Program Loader", but unfortunately this seems to
> have disappeared frrom Xilinx' website....
>
> maybe sb. from Xilinx can give an updated link..
>
> Jochen


The PicoBlaze loader is now part of the PicoBlaze distribution. Here
is link to the Xilinx Forum message about it:

We have done a lot of neat stuff with the PicoBlaze, it is a great
little processor.

http://forums.xilinx.com/xlnx/board/message?board.id=PicoBlaze&thread.id=3

Regards,

John McCaskill
www.FasterTechnology.com

Article: 128042
Subject: Re: Virtex4 burn-in failure
From: austin <austin@xilinx.com>
Date: Mon, 14 Jan 2008 07:35:22 -0800
Links: << >>  << T >>  << A >>


Dave,

http://en.wikipedia.org/wiki/NBTI

Austin

Article: 128043
Subject: sine and cosine wave generation
From: FPGA <FPGA.unknown@gmail.com>
Date: Mon, 14 Jan 2008 07:36:11 -0800 (PST)
Links: << >>  << T >>  << A >>
Can anyone give guidelines on how to generate sine and cosine wave in
VHDL?

Article: 128044
Subject: Re: Virtex4 burn-in failure
From: austin <austin@xilinx.com>
Date: Mon, 14 Jan 2008 07:39:37 -0800
Links: << >>  << T >>  << A >>


Allan,

There is the quarterly quality report which lists the hard fail rates
for each family.  This is all causes.

http://www.xilinx.com/products/quality/index.htm
and
http://www.xilinx.com/bvdocs/userguides/ug116.pdf

There are separate sections for process, and ESD and Latch-Up.

Austin

Article: 128045
Subject: Re: sine and cosine wave generation
From: Jon Beniston <jon@beniston.com>
Date: Mon, 14 Jan 2008 07:42:12 -0800 (PST)
Links: << >>  << T >>  << A >>
On 14 Jan, 15:36, FPGA <FPGA.unkn...@gmail.com> wrote:
> Can anyone give guidelines on how to generate sine and cosine wave in
> VHDL?

Use a look-up table.

Cheers,
Jon

Article: 128046
Subject: Re: sine and cosine wave generation
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Mon, 14 Jan 2008 16:43:48 +0100
Links: << >>  << T >>  << A >>
FPGA schrieb:
> Can anyone give guidelines on how to generate sine and cosine wave in
> VHDL?

A very common technique is a look-up table.

Ralf

Article: 128047
Subject: Re: sine and cosine wave generation
From: FPGA <FPGA.unknown@gmail.com>
Date: Mon, 14 Jan 2008 07:47:19 -0800 (PST)
Links: << >>  << T >>  << A >>
On Jan 14, 10:43=A0am, Ralf Hildebrandt <Ralf-Hildebra...@gmx.de> wrote:
> FPGA schrieb:
>
> > Can anyone give guidelines on how to generate sine and cosine wave in
> > VHDL?
>
> A very common technique is a look-up table.
>
> Ralf

Could you please explain in more detail

Article: 128048
Subject: fpga pin to pin conecting
From: Zorjak <Zorjak@gmail.com>
Date: Mon, 14 Jan 2008 07:48:19 -0800 (PST)
Links: << >>  << T >>  << A >>
Hi everyone

Can someone please help me. If I have to connect two FPGA circuits on
the same board and their pins are not compatible waht should I do?
If someone knows some good link about this, anything that you think
that will be useful, please tell me.

Thanks
Zoran

Article: 128049
Subject: Help! Micriblase + plbv46_pci in Virtex5
From: axalay <axalay@gmail.com>
Date: Mon, 14 Jan 2008 07:59:37 -0800 (PST)
Links: << >>  << T >>  << A >>
I am connect plbv46_pci(in slavemode) to Micriblase. =F7ut in
Plase&Route ISE give warning:

WARNING:Route:436 - The router has detected an unroutable situation
for one or more connections. The router will finish
   the rest of the design and leave them as unrouted, The cause of
this behavior is either an issue with the placement
   or unroutable placement constraints. To allow you to use FPGA
editor to isolate the problems, the following is a list
   of (up to 10) such unroutable connections:
	 Unroutable 	 signal: GLOBAL_LOGIC0 	 pin:
system_i/PCI_Bridge/PCI_Bridge/PCI_CORE_V5_generate.pci_core/
IDELAYCTRL_4.XPCI_IDC3_MapLib_replicate11/REFCLK
	 Unroutable 	 signal: GLOBAL_LOGIC0 	 pin:
system_i/PCI_Bridge/PCI_Bridge/PCI_CORE_V5_generate.pci_core/
IDELAYCTRL_4.XPCI_IDC0/REFCLK
	 Unroutable 	 signal: GLOBAL_LOGIC0 	 pin:
system_i/PCI_Bridge/PCI_Bridge/PCI_CORE_V5_generate.pci_core/
IDELAYCTRL_4.XPCI_IDC1/REFCLK
	 Unroutable 	 signal: GLOBAL_LOGIC0 	 pin:
system_i/PCI_Bridge/PCI_Bridge/PCI_CORE_V5_generate.pci_core/
IDELAYCTRL_4.XPCI_IDC2/REFCLK

And write:


Process "Place & Route" completed successfully

Started : "Generate Post-Place & Route Static Timing".
Loading device for application Rf_Device from file '5vlx50t.nph' in
environment
D:\Xilinx92i.
   "system_stub" is an NCD, version 3.1, device xc5vlx50t, package
ff665, speed
-1

Analysis completed Mon Jan 14 18:43:01 2008
----------------------------------------------------------------------------=
----

Generating Report ...

Number of warnings: 0
Total time: 27 secs

Process "Generate Post-Place & Route Static Timing" completed
successfully

But in Generate Programming File I have Error:

Started : "Generate Programming File".
WARNING:PhysDesignRules:372 - Gated clock. Clock net
   system_i/PCI_Bridge/PCI_Bridge/I_plb2pci_bridge/I_slv_ipifv3_bridge/
I_slv_ipi
   f2pci_fifo/I_slv_ipif2pci_fifo_cntrl/Wr_Addr_All_zeros_strobe is
sourced by a
   combinatorial pin. This is not good design practice. Use the CE pin
to
   control the loading of data into the flip-flop.
INFO:PhysDesignRules:1505 - Dangling pins on
   block:<system_i/microblaze_0/microblaze_0/Performance.Data_Flow_I/
MUL_Unit_I/
   Use_HW_MUL.Using_DSP48_Architectures.No_MUL64.dsp_module_I3/
Using_Virtex5.DSP
   48E_I1/system_i/microblaze_0/microblaze_0/Performance.Data_Flow_I/
MUL_Unit_I/
   Use_HW_MUL.Using_DSP48_Architectures.No_MUL64.dsp_module_I3/
Using_Virtex5.DSP
   48E_I1>:<DSP48E_DSP48E>.  When the DSP48E AREG attribute is set to
1 the CEA1
   input pin should be tied GND to save power.
INFO:PhysDesignRules:1509 - Dangling pins on
   block:<system_i/microblaze_0/microblaze_0/Performance.Data_Flow_I/
MUL_Unit_I/
   Use_HW_MUL.Using_DSP48_Architectures.No_MUL64.dsp_module_I3/
Using_Virtex5.DSP
   48E_I1/system_i/microblaze_0/microblaze_0/Performance.Data_Flow_I/
MUL_Unit_I/
   Use_HW_MUL.Using_DSP48_Architectures.No_MUL64.dsp_module_I3/
Using_Virtex5.DSP
   48E_I1>:<DSP48E_DSP48E>.  When the DSP48E BREG attribute is set to
1 the CEB1
   input pin should be tied GND to save power.
ERROR:PhysDesignRules:9 - The network <GLOBAL_LOGIC0> is only
partially routed.
ERROR:Bitgen:25 - DRC detected 1 errors and 1 warnings.

Process "Generate Programming File" failed

My ucf file: (use XC5VLX50T-1ff665)

NET "iClock77"  LOC =3D "E13" ;
NET "iClock125"  LOC =3D "D14" ;

NET "PCI_AD[0]"  LOC =3D "E5"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[1]"  LOC =3D "E6"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[2]"  LOC =3D "B4"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[3]"  LOC =3D "E8"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[4]"  LOC =3D "E7"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[5]"  LOC =3D "D9"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[6]"  LOC =3D "B5"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[7]"  LOC =3D "D11"   |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[8]"  LOC =3D "E11"   |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[9]"  LOC =3D "B6"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[10]"  LOC =3D "F13"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[11]"  LOC =3D "E12"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[12]"  LOC =3D "E15"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[13]"  LOC =3D "B7"   |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[14]"  LOC =3D "E17"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[15]"  LOC =3D "F15"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[16]"  LOC =3D "E21"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[17]"  LOC =3D "D13"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[18]"  LOC =3D "D21"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[19]"  LOC =3D "D15"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[20]"  LOC =3D "D24"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[21]"  LOC =3D "D16"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[22]"  LOC =3D "C24"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[23]"  LOC =3D "B14"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[24]"  LOC =3D "D25"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[25]"  LOC =3D "B17"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[26]"  LOC =3D "D23"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[27]"  LOC =3D "C18"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[28]"  LOC =3D "D26"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[29]"  LOC =3D "B19"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[30]"  LOC =3D "C26"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_AD[31]"  LOC =3D "B20"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_CBE[0]"  LOC =3D "D10"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_CBE[1]"  LOC =3D "E18"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_CBE[2]"  LOC =3D "B12"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_CBE[3]"  LOC =3D "B16"  |  IOSTANDARD =3D LVCMOS25 ;
NET "fpga_0_PCI_CLK_FB"  LOC =3D "E20"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_DEVSEL"  LOC =3D "B10"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_FRAME"  LOC =3D "C22"   |  IOSTANDARD =3D LVCMOS25 ;
#NET "PCI_GNT_A"  LOC =3D "C23"  |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_IDSEL"  LOC =3D "B15"   |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_IRDY"  LOC =3D "B11"    |  IOSTANDARD =3D LVCMOS25 ;
#NET "PCI_IRQ"  LOC =3D "B26"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_PAR"  LOC =3D "D8"      |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_PERR"  LOC =3D "B9"     |  IOSTANDARD =3D LVCMOS25 ;
#NET "PCI_REQ_A"  LOC =3D "B21"  |  IOSTANDARD =3D LVCMOS25 ;
#NET "PCI_RST"  LOC =3D "B25"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_SERR"  LOC =3D "F18"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_STOP"  LOC =3D "F19"    |  IOSTANDARD =3D LVCMOS25 ;
NET "PCI_TRDY"  LOC =3D "F20"    |  IOSTANDARD =3D LVCMOS25 ;

NET "LedGreen"  LOC =3D "H21"  ;
NET "LedRed"  LOC =3D "G21"  ;
NET "LedYellow"  LOC =3D "G20"  ;
NET "LedBlue"  LOC =3D "H19"  ;

INST "*XPCI_IDC0" LOC =3D "IDELAYCTRL_X0Y4";
INST "*XPCI_IDC1" LOC =3D "IDELAYCTRL_X1Y4";
INST "*XPCI_IDC2" LOC =3D "IDELAYCTRL_X1Y3";
INST "*XPCI_IDC3" LOC =3D "IDELAYCTRL_X1Y5";



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
2019JanFebMar2019

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