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 51325

Article: 51325
Subject: Re: shift register implementation
From: jetmarc@hotmail.com (jetmarc)
Date: 10 Jan 2003 12:13:12 -0800
Links: << >>  << T >>  << A >>
> I would like to design a module which will enable me to input 12-bit
> samples and output 16-bit samples.

This requirement can be satisfied by concatenation of the 12 bit input
bits (MSB) with 4 '0'-bits (LSB).

Marc

Article: 51326
Subject: Re: Virtex-II Pro misfire?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 11 Jan 2003 09:18:41 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Thanks to all the people that have defended my statement.  :-)
> Let me make it even clearer:
> 
> If you compare the XC2VP7 against the well-known XC2V1000:
> The P7 has 40 rows by 34 columns, the 2V1000 has 40 rows by 32
> columns.
> The P7 has 4928 slices, and the 2V1000 has 5120 slices, so the
> difference is 4% in favor of 2V1000
> The P7 has 44 BlockRAMs, and the 2V1000 has 40, so the difference is
> 10% in favor of P7.
> The 2V1000 has slightly more I/O.
> That means, the comparison is very close, but the P7 is cheaper than
> the 2V1000.
> That means the  PowerPC and the eight 3 gigabit transceivers are
> really FOR FREE !
> 
> This is the proverbial progress:
> smaller geometries due to more advanced processing (130 nm vs 150 nm)
> make a smaller die and lower cost.


 An accountant would agree, and engineer might want to qualify that :)

The same die, without the PPC or SerDes test flows could be cheaper.

Xilinx's own web info has a good indication of these Test/Yield costs :

http://www.xilinx.com/prs_rls/silicon_vir/0302easy_path.htm

# Xilinx Virtex-II Pro EasyPath devices
#provide production cost savings from 30 percent for low-density 
# devices up to 80 percent for the largest Virtex-II Pro FPGAs 

How does EasyPath work ? - they slash the test coverage, to hike the
yields.

# isolate and test all resources required of a specific design..
# .. creates a set of configuration patterns and test vectors 
# specific to that design and combines them into a custom test 
# program to validate the functionality of all required
# FPGA resources. 
# The result is an application specific device that functions and
# performs identically to a Virtex-II Pro

Is this significant ? - 30% to 80% saving ( their numbers )

Conclusion : I'm sure if you are large enough, you can get Xilinx
to skip the SerDes and Pro testing/yields, and negotiate a cheaper
price.

- jg

Article: 51327
Subject: Re: Virtex-II Pro misfire?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 11 Jan 2003 09:25:23 +1300
Links: << >>  << T >>  << A >>
tbiggs wrote:
> 
> "Steve Casselman" <sc@vcc.com> wrote in message news:<OCqT9.900$CZ6.635@newssvr16.news.prodigy.com>...
> > It all has to do with volume. If the Pro gets in more designs than the V2
> > then a larger Pro die will cost less than a smaller V2 die.
> 
> Here are the cost issues the way that I see them:
> 1. The Virtex II Pro is .13um, the Virtex II is 0.15um so the Virtex
> II Pro is a smaller die and will therefore be cheaper, gate-for-gate.
> 2. FPGA logic is much easier and faster to test than processor logic.
> You can create test patterns to test every gate pretty quickly in an
> FPGA. Testing processor logic is more difficult and time consuming. So
> testing costs will be a bit higher for the Pro.
> 3. Testing a SerDes at 3.125GHZ costs more than testing a generic
> LVPECL IO. So, again, testing costs are a bit higher.
> 
> Will the Virtex II Pro be cheaper? Only Xilinx can say.
> 
> Our designs use lots of logic and lots of IO. A small amount of logic
> and IO was sacrificed in the Virtex II Pro to make room for the SerDes
> and processors. Yes, Peter, we don't have to use the Pro, but the
> salesman was really pushing it on us, telling us that it is the future
> of the Virtex line.
<snip>

 Then just push-back :) ( see my other post ).

 Explain to the salesman, that you are an engineer, not an accountant
or purchasing officer, and you would like a quote on 0.13u device minus
the
testing/yield costs of the Processor and SerDes.

 the rest is politics ...

 If enough customers do this, voila.

 -jg

Article: 51328
Subject: Generating a 4x Clock using DLLs with Spartan-II
From: rsg@payload.com (Robert S. Grimes)
Date: 10 Jan 2003 13:25:46 -0800
Links: << >>  << T >>  << A >>
I am trying to generate three clocks from my 25 MHz clock input.  I
want SysClock (25 MHz), SysClockX2 (50 MHz), and SysClockX4 (100 MHz)
in my XC2S200 Spartan-II design.  From the data sheet (Functional
Description, page 24) there is an example using two DLL circuits to
generate 2x and 4x clocks, but I also need 1x.  Implementing the
example as-is (i.e. no 1x) is no problem, but when I attempt to take
the CLK0 signal from the first DLL and buffer it via a BUFG, I run
into problems during PAR.  Specifically, I get errors about the DLLs
and the three BUFGs not being placed (see PAR Errors below).

This is not too surprising, as the data sheet says "If other clock
output is needed, the clock could access a BUFG only if the DLLs are
constrained to exist on opposite edges (Top or Bottom) of the device."
 Also, the Solution Record for the first error (1726) says the same
thing (see http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=9469)

The problem is, I can't seem to figure out how to get the constraints
to work!  Here is my attempt:

  NET "p_sysclock" LOC = "P185";	# GCLk3 input clock
  INST "sysclockdll2" LOC=DLL3;         # First DLL
  INST "sysclockdll4" LOC=DLL1;         # Second DLL
  INST "sysclockbuffer" LOC=GCLKBUF3;   # 1x clock buffer
  INST "sysclockx2buffer" LOC=GCLKBUF2; # 2x clock buffer
  INST "sysclockx4buffer" LOC=GCLKBUF1; # 4x clock buffer

When I run these, PAR seems to totally ignore these constraints, and I
get the exact same errors!

Help please!

Thanks!
-Bob

---------
PAR Errors

ERROR:Place:1726 - Could not find an automatic placement for the
following
   components:
    p_sysclock of type GCLK IOB is placed at P185.
    clocksgenerator_hsclocksgenerator_sysclockdll2 of type DLL is
unplaced.
    clocksgenerator_hsclocksgenerator_sysclockbuffer of type GCLK
BUFFER is
unplaced.
    clocksgenerator_hsclocksgenerator_sysclockx2buffer of type GCLK
BUFFER is
unplaced.
    clocksgenerator_hsclocksgenerator_sysclockdll4 of type DLL is
unplaced.
    clocksgenerator_hsclocksgenerator_sysclockx4buffer of type GCLK
BUFFER is
unplaced.
ERROR:Place:1727 - Xilinx requires using locate constraints to
preplace such
   connected GCLK/GCLKIO/DLL components.

Article: 51329
Subject: Re: VLSI training and prospects?
From: ptkwt@shell1.aracnet.com (Phil Tomson)
Date: 10 Jan 2003 21:30:34 GMT
Links: << >>  << T >>  << A >>
In article <18a34598.0212301510.1262dc40@posting.google.com>,
TI <anglomont@yahoo.com> wrote:
>Hi group,
>-is a course like the one at www.naics.ca
>enough to qualify an engineer to find work with vlsi, or masters is needed?
>-how risky is a ASIC design career anyway ie
>what is the chance Berkeley's 'chip in a day' Simulink to silicon aproach
>succeeds completely?
>(www.mathworks.com/mason/tag/ proxy.html?dataid=1248&fileid=4207)

Doubt it...

>- Do you think Asian vlsi engineers are going to be dumped completely or
>just partly as soon as they become too expensive compared to people in
>some other underdeveloped country?
>(http://www.eetimes.com/story/OEG20020627S0032)

Well, it's happening to US engineers right now.  In the global marketplace 
that (for better or worse) now exists if employers can find cheaper 
qaulified labor somewhere else they're going to do it.  If a wage 
differential exists and you're on the high-side then it's only a matter of 
time before your job is outsourced.  Think about it, manufacturing jobs 
were 'outsourced' (exported) from the US starting in the late 80's and 
into the 90's.  Now engineering jobs are being outsourced and with the 
internet it's much easier to move these jobs overseas than it was to move 
manufacturing jobs - we're just talking about moving bits over the 
internet as opposed to moving materials and factories; it's trivial to 
move engineering jobs to another locale. 

Since US engineers would have to be making something close to minimum wage 
in order to compete with their counterparts in India, China or Russia it's 
not likely that engineering will remain a viable profession going forward 
in the US since it's quite difficult to live on minimum wage here - and 
nobody wants to work for minimum wage in a job that takes the kind of 
training that vlsi engineering does.  
This is a catastrophic change for US engineers - most of us don't have a 
fall-back position and it's not likely that we'll be able to migrate to 
places where one can survive on these lower wages since most of these 
countries (like India, China, Russia) make it much harder for us to get a 
work visa than it is for their people coming to work in the US (via H1B 
visas).  Until the relative costs of living equalize between the US and some of 
these other countries (and that could take decades) the wage differential 
will be a problem.

...but I hope this is an overly pessimistic analysis... who knows, there 
could be unforseen, unaccounted-for market forces, new technologies or 
political changes that keep this scenario from happening.

Phil
-- 
"Or perhaps the truth is less interesting than the facts?" 
Amy Weiss (accusing theregister.co.uk of engaging in 'tabloid journalism')
Senior VP, Communications
Recording Industry Association of America  

Article: 51330
Subject: Re: shift register implementation
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 10 Jan 2003 13:38:37 -0800
Links: << >>  << T >>  << A >>
Obviously you can fatten each 12-bit input up with four extra zeros.
But I suppose you want to compact the data, do you?
That requires a very shallow FIFO-like structure and a lower read clock
frequency. What do you want and what do you have?

Peter Alfke
==========================
jetmarc wrote:

> > I would like to design a module which will enable me to input 12-bit
> > samples and output 16-bit samples.
>
> This requirement can be satisfied by concatenation of the 12 bit input
> bits (MSB) with 4 '0'-bits (LSB).
>
> Marc


Article: 51331
Subject: Re: Virtex-II Pro misfire?
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 10 Jan 2003 14:01:01 -0800
Links: << >>  << T >>  << A >>
Jim, miscommunication again.

Easypath is cheaper
1. because of less testing
2. because of higher yield
3. because marketing wants it to be cheaper for tactical reasons.

I think #1 is the least relevant.
Testing is a significant cost, but not the dominant one.
Silicon and packages are usually much higher contributors.
At least that is my educated guess...

Peter Alfke



Article: 51332
Subject: Re: Virtex-II Pro misfire?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 11 Jan 2003 11:14:31 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Jim, miscommunication again.
> 
> Easypath is cheaper
> 1. because of less testing
> 2. because of higher yield
> 3. because marketing wants it to be cheaper for tactical reasons.

Miscommunication ? Wasn't that what I was saying ?

Cheaper(@same die) = less testing/higher Yields * Politics [tactical
marketing reasons] .. ?

-jg

Article: 51333
Subject: Re: Power usage of CLOCK in FPGA
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Fri, 10 Jan 2003 22:36:29 -0000
Links: << >>  << T >>  << A >>
Peter Alfke wrote

> We always distribute the global clock(s) on one or two horizontal "backbones"
> across the chip, but we gate off any vertical "rib" or "branch" that is not
> used. This is done automatically without any user intervention. It means that
> vertically oriented clocked logic draws less power than horizontally oriented
> one. And the carry structure always groups counters and accumulators
> vertically.  :-)

This is probably a nomenclature confusion, but if I go into
fpga_editor, it looks as if the backbones are vertical, with
horizontal distribution spines feeding all the flops in a quarter
of a row.  I always assumed that it is these horizontal lines
which are turned off to minimize power.  This is with Virtex/E.




Article: 51334
Subject: Re: Virtex-II Pro misfire?
From: Peter Alfke <peter@xilinx.com>
Date: Fri, 10 Jan 2003 15:02:53 -0800
Links: << >>  << T >>  << A >>


Jim, I was responding to the dangerous and misleading statement:

"Explain to the salesman, that you are an engineer, not an accountant
or purchasing officer, and you would like a quote on 0.13u device minus
the testing/yield costs of the Processor and SerDes."

That creates completely false expectations of a drastic cost ( and thus
price) reduction. when not testing certain things.  Not true!

Greetings
Peter Alfke


Jim Granville wrote:

> Peter Alfke wrote:
> >
> > Jim, miscommunication again.
> >
> > Easypath is cheaper
> > 1. because of less testing
> > 2. because of higher yield
> > 3. because marketing wants it to be cheaper for tactical reasons.
>
> Miscommunication ? Wasn't that what I was saying ?
>
> Cheaper(@same die) = less testing/higher Yields * Politics [tactical
> marketing reasons] .. ?
>
> -jg



Article: 51335
Subject: Re: Virtex-II Pro misfire?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Sat, 11 Jan 2003 12:47:46 +1300
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Jim, I was responding to the dangerous and misleading statement:
> 
> "Explain to the salesman, that you are an engineer, not an accountant
> or purchasing officer, and you would like a quote on 0.13u device
> minus the testing/yield costs of the Processor and SerDes."
> 
> That creates completely false expectations of a drastic cost ( and
> thus price) reduction. when not testing certain things.  Not true!

 It was a tad tongue in cheek (see smiley in OP ), but it was 
also meant to be read with my other posting stub, which quotes the
Xilinx Easypath stats.

 I do not see the word 'drastic' in what I wrote, and most
engineers would appreciate the price could not exceed 
( or come close to ) those referenced by Xilinx in EasyPath
claims of 30% to 80%.

 They would also appreciate that any special flows have a negative
cost benefit until the volumes get above a certain level.
 IIRC, easypath had a 6 figure NRE ....

 To summarise, I think Tom Biggs is correct in his thrust, and 
Xilinx COULD, given the will, [==customer demand], offer 
a lower cost 0.13u flow where the PPC core and SerDes are 
non qualified.

-jg

Article: 51336
Subject: ESD question on Spartan2e series inputs?
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Fri, 10 Jan 2003 20:00:42 -0500
Links: << >>  << T >>  << A >>
Hi,
    I am experiencing what I suspect are ESD failures in a Spartan2E design.
In particular the failures are shorted inputs (to ground).  The inputs are
configured as LVTTL once configured.  However, during configuration the
input is pulled up to 3.3v via a 10K resistor.  Is this a problem?  What do
the inputs look like electrically?  (For example are there the traditional
CMOS input protection diodes?)



Article: 51337
Subject: Re: Bug in Quartus2 Web 2.2
From: Russell <rjshaw@iprimus.com.au>
Date: Sat, 11 Jan 2003 12:06:40 +1100
Links: << >>  << T >>  << A >>
Rene Tschaggelar wrote:
> I really appreciate to have the major vendors here.
> Hoping to have now at least one reader in charge :
> 
> As much as like to use the web based support, I am discouraged.
> 
> I do have to log in, giving name adress and so on plus a password.
> The next time, I lost the password, then I enter the name =
> street = whatever = aaaaa. The only correct entry is my email.
> Then I get a mail back : company does not match or alike, after
> a day or two.
> There are error description forms to be filled out (forgot
> which company) but the message is truncated after 160 characters.
> 
> Common, this is not useable at all.
> There is not even an email adress as alternative means.
> 
> I don't want yet another entry in a postal mailing list...

Some email/web browsers (like mozilla) can remember what you
enter into these name/password pages so that the fields are
automatically filled next time you go to that page. The other
way is to record all your passwords in a file locally.


Article: 51338
Subject: Re: In-Rush current in Stratix device
From: gregs@altera.com (Greg Steinke)
Date: 10 Jan 2003 17:12:39 -0800
Links: << >>  << T >>  << A >>
Alon,

The EP1S25 ES devices have a higher power-up current than the
production devices. The typical power-up current for the ES device is
2.5 A (on the 1.5-V VCCINT supply), as shown in the Stratix Errata
Sheet version 2.2. This value is typical, and individual devices use
more or less current during power up. Also it is important to note
that charging the decoupling capacitors on the board will consume some
amount of current during the power up, so not all of the current
coming from the supply is consumed by the Stratix device.

We have improved the EP1S25 production devices, which are available
now. These devices are tested for a maximum power-up current of 1.2 A
on the VCCINT supply. We are now characterizing the entire Stratix
family for power-up current and will update the data sheet with
power-up specifications for all Stratix devices.

Power-up current in general is quite low for the production Stratix
devices. In fact, the EP1S80 is over 3x larger than the EP1S25 and we
are seeing typical power-up current that is under 1A. We are still
working on what the maximum power-up current will be for the EP1S80,
but it should be below 2A or so.

Many customers have purchased the EP1S25ES devices and we have not
heard any examples of customers seeing the current consumption that
you have seen. I would like to suggest that you contact me at Altera
and we can try to see why your board shows this characteristic.

Regards, 
Greg Steinke
gregs@altera.com


Rene Tschaggelar <tschaggelar@dplanet.ch> wrote in message news:<3E1DC550.3060907@dplanet.ch>...
> Alon Z wrote:
> > Hi All
> > 
> > The problem: The Stratix devices are not functioning after power-up.
> > Symptom: 15A power-up current in the 1.5V power supply.
> > 
> > Details:
> > We just assembeled a board with three EP1S25F1020C6ES. During
> > power-up, the Stratix device consume about 15A current for 20ms. It
> > causes the power supply to raise its voltage to 2.8V.
> > We had the Stratix device for about 2 month in our stock, so I belive
> > they are engineering samples (ES suffix).
> > The Stratix devices are the only ones that are connected to the 1.5V
> > power supply.
> > The power comes from external LAB power-supply with 10mm diameter
> > cables.
> > 
> > If the power supply is tuned to 1.8V then the stratix devices are
> > waking correctly, then we set it to 1.5V.
> > 
> > Did anyone encounter this problem?. Any suggetions ?
> > 
> 
> 
> I'm in the process of doing it.
> I was told the engineering samples are known for these
> high starting currents. I was told the smallest, the S10 takes
> 2.5Amps, and assume the bigger one take more.
> 
> Rene

Article: 51339
Subject: Interfacing to a PC using EPP parallel port
From: rfischer5@cfl.rr.com (Bob Fischer)
Date: 10 Jan 2003 17:55:31 -0800
Links: << >>  << T >>  << A >>
I will be testing an FPGA design that is intended to drive a PC for
initial checkout and later to an embedded computer using parallel
port.  I selected the EPP protocol as it looks like it can support
what I need to do.

The FPGA will output 10 bytes of data to the PC each cycle of
operation.  The data consists of five 14 bit values output in two
bytes each.  The FPGA will be performing about 40,000 cycles per
second.  Think of each cycle as a 25 us frame.  Data collection (about
4 us), processing (about 7-8 us) occurs for the first 11-12 us of each
frame.  When the data is ready the parallel port Interrupt line is
asserted.

The burst rate during the available 13 us data output portion is
around 770 Khz.  The times have already been verified in the
simulations.  For the simulation I used an 800 ns byte cycle.  The
testbench emulates the PC by responding to the Interrupt, invoking the
byte cycle timing as expected from the PC by cycling the Data Strobe
line (400 ns low then 400 ns high for each byte).  The FPGA responds
with Waits and presentation of data bytes at the time defined for the
EPP port.  I used the timing found in web site
www.beyondlogic.org/epp/epp.htm

The output of the FPGA is configured for TTL levels, slow transitions.
 I intend to pipe the FPGA directly to the DB connector and through a
3 ft parallel cable to the PC parallel port.

In the PC we will DMA the data to memory and accumulate it for several
seconds.  A display program will access that memory and generate
graphs, etc for visual analysis of the performance and results.

Does this approach to PC interfaceing sound feasible?  Has anyone out
there any prior experience they would like to share?  Some Do's and
Don'ts?

Bob Fischer
FPGA independent designer

Article: 51340
Subject: Re: Stratix IOE "Input Pin to Input Register Delay"
From: gregs@altera.com (Greg Steinke)
Date: 10 Jan 2003 18:05:15 -0800
Links: << >>  << T >>  << A >>
Mr. Gustad,

You can use the "Decrease Input Delay to Input Register" logic option
in Quartus II to decrease the delay from the input pin to the DDR
input registers.  This logic option can be applied to any signal going
into the input registers in the IO Element, including when the input
registers act as DDR input registers. It is not set as part of the
MegaWizard, but is set just like any other assignment. Figure 64 of
the Stratix FPGA Family Data Sheet shows that the Input pin to Input
register delay is before the two IOE input registers.

This option is set during design and is compiled into the programming
file. To change this option you would reconfigure the device with a
different programming file.

However, there is another way that you could consider -
Instead of changing the delay of the data pin to the register, you
could change the delay of the clock to the register. This has a
similar effect of adjusting the TSU/TH window. The Stratix Enhanced
PLL has feature called "PLL Reconfiguration" where certain PLL
attributes can be modified by system logic, without loading a new
programming file. One of these attributes is a programmable delay on
the PLL output. So you would have the ability to change this delay
without device configuration, which would have much the same effect as
changing the data delay.

We are now working on a design example which will show the details of
how to implement the reconfiguration.

Sincerely,
Greg Steinke
gregs@altera.com

Petter Gustad <newsmailcomp4@gustad.com> wrote in message news:<m3r8bpqowv.fsf@scimul.dolphinics.no>...
> The Stratix Data Sheet¹ shows in figure 64 (page 114) Stratix IOE in
> DDR Input I/O Configuration. Between the Pad (On-Chip Termination) and
> the input register there is a box titled "Input Pin to Input Register
> Delay".
> 
> I found the following rather terse description in the data sheet "The
> Quartus II Compiler can program these delay to automatically minimize
> setup time while providing a zero hold time."
> 
> There seem to be no options to set these delays while using the
> Quartus II MegaWizard to create a DDR input register. There appears to
> be a compile time "De/Increase Input Delay to Input Register logic
> option" in Quartus II. However, there is no input to the generated DDR
> input register to set the input delay.
> 
> Is there a way to program these delays during run time (i.e. after the
> device has been configured)? Is any detailed documentation available?
> 
> TIA
> Petter
> 
> ¹) Digital Library CD October 2002 - DS-STXFAMILY-2.1

Article: 51341
Subject: Re: Virtex-II Pro misfire?
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Sat, 11 Jan 2003 05:53:39 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3E1F2AA1.739F@designtools.co.nz>,
Jim Granville  <jim.granville@designtools.co.nz> wrote:
>How does EasyPath work ? - they slash the test coverage, to hike the
>yields.

However, the win, BIG win, on easypath is the savings on the test
coverage on the rest of the interconnect.  You have a gazillion wires,
but only a small percentage of the interconnnect points and only a
reasonable fraction of wires are used on any given design.

>Conclusion : I'm sure if you are large enough, you can get Xilinx
>to skip the SerDes and Pro testing/yields, and negotiate a cheaper
>price.

Except they will point out, quite rightly, that the number of dies in
question is fairly low in terms of failures, although they will
happily save the tester-time if your easy-path part doesn't use these.

That, and the PowerPC can probably make the rest of the testing
faster, although I'm not sure if Xilinx does that.
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 51342
Subject: MicroBlaze MDK2.2 opb_timer
From: duy_do@angelfire.com (Duy K Do)
Date: 10 Jan 2003 21:55:55 -0800
Links: << >>  << T >>  << A >>
Hi all,

I got trouble with MicroBlaze MDK2.2 with service pack 2 installed.
Development tools is Xilinx ISE Foundation 4.2i.

when I used MDK 2.2 without service pack 2, I compile a simple
MicroBlaze configuration with UART and timer, the timer interrupt work
fine. However, after installed MDK service pack 2 to overcome the
problem with xmd of ISE 4.2 service pack 3. The same configuration
won't work anymore. The timer interrupt won't work as usual anymore.
After debuging, I found out that the interrupt controller in
MicroBlaze won't accept the Acknowledge write to IAR register,
therefore, interrupt status still set and once timer generated
interrupt, the interrupt handler just keeps go on and on.

Is there anyone having the same problem before and how to fix it? Will
it help if i upgrade to EDK version of MicroBlaze?

Thanks
Duy K Do

Article: 51343
Subject: Re: Virtex-II Pro misfire?
From: johnjakson@yahoo.com (john jakson)
Date: 10 Jan 2003 22:59:41 -0800
Links: << >>  << T >>  << A >>
I only wish Xilinx could have made an ARM deal too. I know, I know,
next person will want MIPS and so on.

I am pretty sure too that embedded PPC cores are a low priority for
most FPGA guys right now but the path to PPC leads to certain markets
(higher performance, high value). The path to ARM leads to lower cost
and smaller designs I hazard & I bet much larger consumer markets as
well as perhaps ASIC conversions. Perhaps Spartan.. pro whatever could
have ARM offering instead. If I were a gadget guy counting all the
embedded cpus in my toys I'm sure I would find lots of ARMs and few
PPCs (although my 3com cable box has one).

My last project was needlessly more complex by an order of magnitude
because the ARM was external and way too slow. If we had known that
Xilinx was heading to PPC and Altera was with ARM back when we started
the design many years ago, I probably would have gone the A route for
that reason alone but then we also needed them multipliers too.
Perhaps a mixed X+A solution?

I can certainly understand the IBM technology partnerships though that
Xilinx & AMD are following but when you are committed to a cpu
architecture and you get something else for free in your lap, doesn't
mean we can switch.

Enuf of wishing

Article: 51344
Subject: Re: VLSI training and prospects?
From: johnjakson@yahoo.com (john jakson)
Date: 10 Jan 2003 23:28:47 -0800
Links: << >>  << T >>  << A >>
ptkwt@shell1.aracnet.com (Phil Tomson) wrote in message news:<avne1q01um3@enews1.newsguy.com>...
> In article <18a34598.0212301510.1262dc40@posting.google.com>,
> TI <anglomont@yahoo.com> wrote:
> >Hi group,
> >-is a course like the one at www.naics.ca
> >enough to qualify an engineer to find work with vlsi, or masters is needed?
> >-how risky is a ASIC design career anyway ie
> >what is the chance Berkeley's 'chip in a day' Simulink to silicon aproach
> >succeeds completely?
> >(www.mathworks.com/mason/tag/ proxy.html?dataid=1248&fileid=4207)
> 
> Doubt it...
> 
> >- Do you think Asian vlsi engineers are going to be dumped completely or
> >just partly as soon as they become too expensive compared to people in
> >some other underdeveloped country?
> >(http://www.eetimes.com/story/OEG20020627S0032)
> 
> Well, it's happening to US engineers right now.  In the global marketplace 
> that (for better or worse) now exists if employers can find cheaper 
> qaulified labor somewhere else they're going to do it.  If a wage 
> differential exists and you're on the high-side then it's only a matter of 
> time before your job is outsourced.  Think about it, manufacturing jobs 
> were 'outsourced' (exported) from the US starting in the late 80's and 
> into the 90's.  Now engineering jobs are being outsourced and with the 
> internet it's much easier to move these jobs overseas than it was to move 
> manufacturing jobs - we're just talking about moving bits over the 
> internet as opposed to moving materials and factories; it's trivial to 
> move engineering jobs to another locale. 
> 
> Since US engineers would have to be making something close to minimum wage 
> in order to compete with their counterparts in India, China or Russia it's 
> not likely that engineering will remain a viable profession going forward 
> in the US since it's quite difficult to live on minimum wage here - and 
> nobody wants to work for minimum wage in a job that takes the kind of 
> training that vlsi engineering does.  
> This is a catastrophic change for US engineers - most of us don't have a 
> fall-back position and it's not likely that we'll be able to migrate to 
> places where one can survive on these lower wages since most of these 
> countries (like India, China, Russia) make it much harder for us to get a 
> work visa than it is for their people coming to work in the US (via H1B 
> visas).  Until the relative costs of living equalize between the US and some of 
> these other countries (and that could take decades) the wage differential 
> will be a problem.
> 
> ...but I hope this is an overly pessimistic analysis... who knows, there 
> could be unforseen, unaccounted-for market forces, new technologies or 
> political changes that keep this scenario from happening.
> 
> Phil


I would have to agree with this assesment atleast right now.

From where I am sitting, union blue collar jobs that can't be exported
like say painters, plumbers, toll collectors, auto mechanics, seem to
be able to easily make maybe half as much as veteran EEs. The pressure
on EEs though is getting rediculous, more & more education required
for jobs in order to stay only a little further ahead than many
tradesmen.

However, the HW & SW jobs that seem to have been exported to India &
China so far seem to be at the bottom end of the skill spectrum and at
the end of the day as long as the US is the leading consumer of
technology, I thinks the better jobs will remain here. And English
language & culture remains a huge barrier to these countries too esp
China/Russia.

In the end, most of us do it because we are interested in it, not for
the huge $, if you aren't driven by 1s & 0s or whatever, I'd look
elsewhere.

my 2c

Article: 51345
Subject: Re: USB OPENCORE IP usage
From: "Frederic Bastenaire" <frederic.bastenaire@wanadoo.fr>
Date: Sat, 11 Jan 2003 12:21:10 +0100
Links: << >>  << T >>  << A >>
> I used the USB1.1 core in a project last fall. We only used 2 bulk
endpoints
> so I can't say we tried it out thoroughly. I packaged it as an OPB
peripheral
> for a Microblaze system, and as such it used about 10% of a XCV800 chip.
>
Interesting, could you tell a bit more about your application...the type of
transceiver, how the model was
connected with actual hardware, etc...

Yours,

FB




Article: 51346
Subject: Re: Generating a 4x Clock using DLLs with Spartan-II
From: Brian Drummond <brian@shapes.demon.co.uk>
Date: Sat, 11 Jan 2003 11:52:59 +0000
Links: << >>  << T >>  << A >>
On 10 Jan 2003 13:25:46 -0800, rsg@payload.com (Robert S. Grimes) wrote:

>I am trying to generate three clocks from my 25 MHz clock input.  I
>want SysClock (25 MHz), SysClockX2 (50 MHz), and SysClockX4 (100 MHz)
>in my XC2S200 Spartan-II design. 

>The problem is, I can't seem to figure out how to get the constraints
>to work!  Here is my attempt:
>
>  NET "p_sysclock" LOC = "P185";	# GCLk3 input clock
>  INST "sysclockdll2" LOC=DLL3;         # First DLL

>When I run these, PAR seems to totally ignore these constraints, and I
>get the exact same errors!
>
>Help please!
The error messages are a pretty good guide to what's wrong.

>PAR Errors
>    p_sysclock of type GCLK IOB is placed at P185.
This constraint worked.

>    clocksgenerator_hsclocksgenerator_sysclockdll2 of type DLL is
>unplaced.

This constraint won't work because the name on the constraint 
("sysclockdll2") does not match the instance name
("clocksgenerator_hsclocksgenerator_sysclockdll2")

And so on.

Edit the constraints file to match the actual instance names.
(Be aware that if you change the design hierarchy or the synthesis
settings, the instance names subsequently generated might change again)

- Brian

Article: 51347
Subject: Re: USB OPENCORE IP usage
From: "Frederic Bastenaire" <fba@free.fr>
Date: Sat, 11 Jan 2003 13:27:26 +0100
Links: << >>  << T >>  << A >>
> I assume Frederic is using the USB 1.1 core.
Yes
>
> Several issues here:
>
> 1) The mode pin on the PDIUSBP11A applies to the input to the
> transceiver only. The receive side does not change it's
> behavior regardless of the mode pin setting.
>
> 2) The USB 1.1 PHY I provide, allows you to select the mode
> as well. Regardless of the mode setting on the "Trenz" board,
> you can change the behavior of the RTL by assigning a 1 or 0
> to the "phy_tx_mode" input of the phy. I imitate the behavior
> of the mode pin on the PDIUSBP11A with the "phy_tx_mode" input.
> You should set the "phy_tx_mode" to the same value as the
> mode input on the PDIUSBP11A.
>
> 3) On the receive side you need at least the "vp" and "vm"
> signals, you should be able to use "vp" as the "rcv" signal
> as well.
>
> Hope this helps !
>
> Cheers,
> rudi

Thank you for this information. I will use it to implement USB on my Trenz
board and make it available as soon as it works. This might lead me to ask
more
questions, sorry to annoy you. I read most of the OPENCORE mailing list but
some points are not yet 100% clear in my mind as I am just a newbie.

Yours,

FB

PS: happy new year to all FPGA afficionados in this newsgroup!



Article: 51348
Subject: Help for Generating Video Clock synchronous to Hsync of the Video..........
From: arvindstomar@india.com (arvind)
Date: 11 Jan 2003 06:22:03 -0800
Links: << >>  << T >>  << A >>
Hi,
   I want a 16mhz clock synchronous to Hsync of the video.I want my 16mhz
clock should lock on the rising edge of the Hsync.
I want a pixel clock for Xilinx Spartan 2 Fpga for Video frame
storage Application.
I am using oscillator for generating the 16mhz Clock but my video out
is not stable it have some color problem on the top of the frame
manse on the first 100 lines of the video and it vary on changing
of source, first I thought it is a clock stability problem so that I
changed the oscillator to 5ppm but the problem is still there so I
want a clock synchronous to video Hsync.        
Can u help me, How can I get the clock synchronous to the video
because it is affecting the performance of video.
If u have some idea how we can generate in Fpga so pl'z help me out.I
Need your urgent Help.
Thanks For any suggestion.

Regards
Arvind.

Article: 51349
Subject: Has anyone used the SerDes on the VirtexIIP?
From: "B. Joshua Rosen" <bjrosen@polybus.com>
Date: Sat, 11 Jan 2003 10:36:41 -0500
Links: << >>  << T >>  << A >>
Has anyone used the SerDes on the VirtexIIP, if so have they been reliable?
An on board SerDes make's life a lot simpler if it works but it's also
something that can be very hard to get right, so I'm interested in
hearing if anyone has used it and if it works well.



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