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 80825

Article: 80825
Subject: Re: Xilinx eagle package (PQ208)
From: google@gornall.net
Date: 11 Mar 2005 14:56:18 -0800
Links: << >>  << T >>  << A >>
Definitely a Doh! moment :-(

Cheers,
  Simon.


Article: 80826
Subject: Re: To estimate the maximum frequency?
From: Ray Andraka <ray@andraka.com>
Date: Fri, 11 Mar 2005 18:00:39 -0500
Links: << >>  << T >>  << A >>
xing1234@yahoo.com wrote:

>I already have the RTL code available which is designed for ASIC and
>targeted to work at 200Mhz. Now if I want to implement the logic into
>FPGA, how can get the idea in advance that how fast my logic can work
>on the FPGA? What the best way to calculate this number? Is this
>something you have to think about first before you do FPGA design?
>BTW, I am going to use the Xilinx VirtexII 6000.
>
>Thanks!
>
>  
>
It really depends on how the design is done.  If it is implemented to 
minimize the logic between flip-flops to four input functions and 
arithmetic, you can reach the 200 Mhz target.  If on the other hand it 
has layers and layers of logic between flip-flops you may only get a few 
tens of MHz.  As a first cut, try synthesizing the design with the 
Xilinx as a target using synplify or XST and look at the post synthesis 
speed estimates.

-- 
--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: 80827
Subject: Re: XC3000 non-recoverable lockup problem
From: Jon Elson <jmelson@artsci.wustl.edu>
Date: Fri, 11 Mar 2005 17:04:13 -0600
Links: << >>  << T >>  << A >>


lecroy7200@chek.com wrote:

>I am looking at a design that was done several years back which uses
>several  XC3000 devices.  All devices are programmed with the same core
>from a computer on power up.  What I am seeing is that once or twice a
>year, one of the devices will enter a non-recoverable mode.  In this
>mode, the device appears to be in power down or reset.  Once in this
>mode I am no longer able to program the device.  Pulling the XC3000's
>reset low for 10us has no effect.  The problem appears random.  The
>only way to reprogram the part is to power down the IC.  I have tried
>running tests where I just reprogram the device, over heat the device,
>change the supply voltages, etc. and can't reproduce the problem.  When
>the Xilinx device is in this mode, it draws little power.  It can be
>held in this mode for what appears an infinite amount of time and
>causes no damage to the device.
>
>Was there some kind of an undocumented test mode built into the XC3000
>that I may be seeing?  Does anyone else ever remember seeing a problem
>like this?
>
>  
>
I haven't used the XC3000, only 95xx and Spartan.  But, I'm assuming it has
jtag or something to download the config.  Is the download controlled by an
onboard CPU, or is it a pin header that you plug a programming cable 
into?  If
it is a header, do you jumper the pins to prevent stray fields from 
producing
clocks on the download pins?

Well, presumably, it isn't a classic CMOS latchup event, or it would 
either fry
the device or overload the power supply on the whole board.

Jon


Article: 80828
Subject: Re: Xilinx ISE7.1
From: Eric Smith <eric@brouhaha.com>
Date: 11 Mar 2005 17:04:20 -0800
Links: << >>  << T >>  << A >>
Ray Andraka <ray@andraka.com> writes:
> FWIW, I don't even load a mjor release anymore until service pack 1 is
> out.  Better to let someone else find the easy bugs!

I just load it in a different directory.  If I have trouble with it, I
can easily switch back to the previous release.

Article: 80829
Subject: Re: Over-Sampling
From: "jtw" <wrightjt @hotmail.invalid>
Date: Sat, 12 Mar 2005 03:49:08 GMT
Links: << >>  << T >>  << A >>
Or, you may be able to use both edges of the clock to produce a de-facto 180 
MHz.  Use with care.

Jason

"Peter Hermansson" <peter.hermansson@sts.saab.se> wrote in message 
news:4fc631bb.0503110703.43ef50ad@posting.google.com...
> ALuPin@web.de (ALuPin) wrote in message 
> news:<b8a9a7b0.0503110036.1b73c25c@posting.google.com>...
>> Hello @ VHDL people out there,
>>
>> I have the following problem. Maybe someone of you has experienced the 
>> same:
>>
>> The signal "input_data" comes from a 12MHz clock domain.
>> Now I want to sample that signal that way that I generate one 
>> sample-enable
>> which is close to the center position of the bits.
>> One possibility to do so is to use a over-sampling clock, let us assume
>> 48MHz.
>>
>>
>> The problem: 90 is not a multiple of 12.
>> Is there a possibility to sample the 12MHz signal right in the center ?
>>
>
> Hi,
>
> 90/12 = 7.5 and fractional division may be performed by dividing by 7
> one cycle and 8 the next. If the jitter is acceptable, the resulting
> divisor is 7.5.
>
> /Peter 



Article: 80830
Subject: Re: RocketIO and Gigabit Ethernet
From: "Marc Randolph" <mrand@my-deja.com>
Date: 11 Mar 2005 20:50:50 -0800
Links: << >>  << T >>  << A >>
MM wrote:
> "Marc Randolph" <mrand@my-deja.com> wrote in message
> news:1110509935.634028.77710@g14g2000cwa.googlegroups.com...
> >
> > xGMII (RGMII is what we
> > use) is another, possibly easier way (or at least, slower speed
that
> > doesn't require MGT's).  Physical layer chips for 1000Base-T cost
> > something over ~$10/port.  1000Base-T SFP's cost something
approaching
> > 10x that (depending on volume).
>
> If you don't mind telling, which PHY chip are you using?

Howdy Mikhail,

   I'm not sure if you are asking because I put a ballpark price in my
response, or if you're just wondering my experience with the parts.

I happen to be using a quad-port Broadcom part, although not in
1000Base-T mode (I use 1000Base-X mode).  Support isn't the fastest,
and you have to put up with their never-ending paranoia, but the parts
work well.

As for pricing, I don't remember the details.  Seems like it was mid or
high-teen's until you get to real high volume, which is when it falls
closer to $10/port.

I would expect parts from Vitesse or Marvell to be in the same price
range, and with the same features.  Agere has some parts as well, as
might Intel, NEC, and others.  For fiber only, there are even more
choices.

Have fun,

   Marc


Article: 80831
Subject: Re: Hierarchical Synchronous Design (corrected)
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 11 Mar 2005 21:47:52 -0800
Links: << >>  << T >>  << A >>
morpheus wrote:

 > To extend your suggestion, suppose i have 5 levels of hierarchy.

I'd rather suppose one or two.
I don't use hierarchy for it's own sake.
However, when reusing a substantial module
already having a testbench, it is probably
smarter to instance it than risk combining
designs directly.

 > My question is if I use your advice, I would be registering 'OUT' at
 > each level, is that what I should do?

I don't really know what your are doing other
than drawing boxes inside boxes. The fact that
you are counting up output registers leads me to
think that you might need fewer boxes with
more logic in them.

    -- Mike Treseler

Article: 80832
Subject: Re: State Machine Coding?
From: Mike Treseler <mike_treseler@comcast.net>
Date: Fri, 11 Mar 2005 21:57:37 -0800
Links: << >>  << T >>  << A >>
Johnson Lee wrote:

>  My simulation is ok!
>  But the result is not as what I planned to have.

Consider a synchronous design.

          -- Mike Treseler

Article: 80833
Subject: Re: XC3000 non-recoverable lockup problem
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 12 Mar 2005 01:56:46 -0600
Links: << >>  << T >>  << A >>
In article <1110556640.014510.68500@g14g2000cwa.googlegroups.com>,
 lecroy7200@chek.com writes:
>I am looking at a design that was done several years back which uses
>several  XC3000 devices.  All devices are programmed with the same core
>from a computer on power up.  What I am seeing is that once or twice a
>year, one of the devices will enter a non-recoverable mode.  In this
>mode, the device appears to be in power down or reset.  Once in this
>mode I am no longer able to program the device.  Pulling the XC3000's
>reset low for 10us has no effect.  The problem appears random.  The
>only way to reprogram the part is to power down the IC.  I have tried
>running tests where I just reprogram the device, over heat the device,
>change the supply voltages, etc. and can't reproduce the problem.  When
>the Xilinx device is in this mode, it draws little power.  It can be
>held in this mode for what appears an infinite amount of time and
>causes no damage to the device.

It's been a long long time...

I can't find the data sheet on their web page and my memory is
(more than) a bit rusty...

I forget the details of how configuration works.  I think reset is
just a global reset of the FFs.  It doesn't have anything (much?) to
do with configuration.

I think there is a combined ~prog and done pin.  It's pulled low
(open drain) by the 3000 until it gets configured.  Power up starts
needing configutation.  A high-to-low transition on ~prog asks for
another configuration cycle.  If your attempted configuration gets
confused, there is no way to start over until you finish configuration
since ~done is held low so you can't make it go high-to-low.

Configuration starts with a 24 bit bit-count value.  After that many
configuration clocks, all the devices in the the chain release
their done pulldown.  If one of the devices in the chain gets
(somehow) a low value in that counter you have to cycle through
2**24 cycles to wrap around and finish the current cycle.

How clean is your configuration clock?  Try cold rather than hot
on your lab setup.

The description of configuration in the data book is pretty good,
but maybe only after you know the answer because you have read it
many times.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 80834
Subject: (Stupid/Newbie) Question on UART
From: imanpreet@gmail.com
Date: 12 Mar 2005 00:49:54 -0800
Links: << >>  << T >>  << A >>
Hello,

	I am wondering if someone could clear this doubt for me, in case of
UART, the clock speed is 1.8432 MHZ, however it is able to transmit
maximum of 115,200 bps, however even if we are able to transmit at 1
bit per cycle we should be able to transmit at 1,843,200 bps. What is
the rationale for making something go slowly, when it can go much
faster.


PS, I really could not find any suitable group for this question,
follow-ups to a more suitable group are welcome.

TIA
-- 
Imanpreet Singh Arora


Article: 80835
Subject: Re: Spontaneous Board Reset
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 12 Mar 2005 08:54:06 GMT
Links: << >>  << T >>  << A >>
On Fri, 11 Mar 2005 09:15:30 -0800, "Ulf Ochsenfahrt" <ulfjack@gmx.de> wrote:
>Just for the fun of it. Here's my solution:
>
> <http://server1.conquer-space.net/~ulf/fan-shot.jpg>
>
>The picture won't be there forever, if you'd like to keep it, you may want to mirror it.
>
>Cheers,
>
>-- Ulf

Do you run the fan in oscillating mode, or stationary?

Here are some things to think about:

The regulators on the board may be current limiting at 1000mA

The regulators may be going into thermal shut down,
  (add a heat sink and maybe a smaller (muffin) fan?)

You are measuring current by looking at the front panel
of your power supply (or maybe a multimeter in the power
line to your board). This current measurement is an average
measurement. If for instance it shows 1200 mA, and your system
causes a 10uS transient of 2000 mA, the meter will probably
still show 1200 mA.

You need to look at the VCC rail, close to the FPGA with a
fast scope, at least 100 MHz bandwidth. What you are looking
for is transient drop in the VCC voltage that the FPGA sees,
not what the bench power supply says it is supplying.


>My thought then was that maybe the FPGA pulls down that pin
>for whatever reason. So I specified a pull-up in the
>constraints file. This helps. But not much. The board still
>resets itself, just after a slightly longer amount of time.

This suggest a power supply problem.

>Then, a colleague also said that it's most likely a problem
>with the power supply.

I agree.

>So I got a fancy electronic power supply, where you can set
>the voltage to a certain level and it shows the current.

Both voltage and current reading are average, at the power
supply. What you need to know is what the FPGA is seeing.
With your design running, the current consumption varies
depending on what is happening. Depending on how the voltage
regulation and decoupling is done on the board, this variable
current consumption will cause variation in the voltage. None
of the high speed behaviour will be shown on your bench power
supply meters.

You may need to add more decoupling capacitors, as well as
heat sinks and fans to the on-board regulators.

>The current tops at 1300 mA, which is more than the previous
>power supply could handle (it says 1200 mA max). The improved
>power supply helps. But, the board _still_ resets itself.

The problem is likely the on-board regulator cant handle the
current you design needs (although only at transient events).

>Now here's something interesting: My old (working) design only
>draws 1000 mA.

This supports all previous conclusions.


Philip Freidin



===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM

Article: 80836
Subject: Re: (Stupid/Newbie) Question on UART
From: hmurray@suespammers.org (Hal Murray)
Date: Sat, 12 Mar 2005 03:11:57 -0600
Links: << >>  << T >>  << A >>
>	I am wondering if someone could clear this doubt for me, in case of
>UART, the clock speed is 1.8432 MHZ, however it is able to transmit
>maximum of 115,200 bps, however even if we are able to transmit at 1
>bit per cycle we should be able to transmit at 1,843,200 bps. What is
>the rationale for making something go slowly, when it can go much
>faster.

The traditional implementation uses a 16x clock on the receiver.

It looks for the transition on the leading edge of the start bit,
then starts counting. After 1.5 baud times, it samples the first bit
in the byte.  That's the middle of the bit cell.

16*115200 is 1843200

You can use slower clocks, say 8x, but they you will (sometimes) be
farther from the center of the bit cell and errors will be more likely.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 80837
Subject: Re: low speed FIR filter in FPGA
From: "Ulf Samuelsson" <ulf@a-t-m-e-l.com>
Date: Sat, 12 Mar 2005 10:51:31 +0100
Links: << >>  << T >>  << A >>
Mook Johnson wrote:
> I'm looking to implement four, 150 tap FIR filters in an Actel MX
> series FPGA.  The filters I'm designing are 16 data bit input, 16 bit
> coeffienencs and
> 1khz sample rate.  FPGA will be clocked with a 10MHz clock and will
> have a state machine to retrieve the samples from the A2D following a
> 1khz
> HW interrupt.
>
> How do I estimate the resource requirements to implement the filter
> section? Any
> special hurdles in implelenting FIR filters in a Actel MX series FPGA?
>
> MX series is a fixed quantity and cannot be changed.
>
> thanks

Have you heard about the FPSLIC?
This combines an FPGA + an AVR microcontroller.
The smallest part have 20 kB of SRAM and 5 k gates.
There ar 36kb + 10kg or 36 kB + 40kg available as well.
The SRAM is by 8 only.

You have 150 coefficients and 150 samples
Each are 16 bit so you need (150 + 150) * 2 = 600 bytes per filter.
Total of 2400 bytes needed for the  coefficient and the samples.

You can allocate 4 KB of the SRAM for the FPGA portion
16 or 32 kB allocated for the

You have to do 150 multiply and add per millisecond per filter,
so 600 multiply in 10000 clock cycles.
This means 16 clocks are available per multiply.

For the smallest FPSLIC part  you get 12 x (32 x 4 DPRAMs).
There are 4 more, but they are ROM only.
You use 10 of them to implement an 40 bit dual port register file.

Implement an 8 bit multiplier in the FPGA and run 4 cycles.per multiply.

R0 := LowCoeff1     (Cl);    temp  =  40'b0;                           Acc =
0;                        -- init
R1 := LowSample1  (Sl) ;   temp   = {24'b0,Cl * Sl};            Acc = Acc +
temp;        -- add 0 the first time
R2 :=  HiSample1    (Sh) ;   temp   = {16'b0,Cl * Sh,8'b0};   Acc = Acc +
temp;
R3 :=  HiCoeff1       (Ch);   temp   =  {16'b0,Ch * Sl,8'b0};  Acc = Acc +
temp;
R0 := LowCoeff2     (Cl);    temp   = {8'b0Ch * Sh,16'b0};   Acc = Acc + tem
p;
R1 := LowSample2  (Sl) ;   temp   = {24'b0,Cl * Sl};            Acc = Acc
+temp;
...

The AVR will handle the interrupt and the ADC.
Can probably read the ADC using bitbanging to save FPGA real estate.
The AVR can write to the FPGA RAM without any problems.
The FPGA never writes to the RAM so it will only use the read port.

Think this should be a real nice application for the FPSLIC.

-- 
Best Regards,
Ulf Samuelsson
ulf@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB



Article: 80838
Subject: Xilinx ISE and IP cores
From: Nemesis <nemesis@nowhere.invalid>
Date: Sat, 12 Mar 2005 09:54:35 GMT
Links: << >>  << T >>  << A >>
Hi everyone,
I'm going to buy Xilinx ISE Foundation, I'd like to know if this package
contains also IP cores like DDC, FFT and so on.
It seems that the "LogiCore" IPs should be shipped within ISE
Foundations, am I right?

-- 
I do whatever the voices tell me to do.
 
 |\ |       |HomePage   : http://nem01.altervista.org
 | \|emesis |XPN (my nr): http://xpn.altervista.org


Article: 80839
Subject: Re: XC3000 non-recoverable lockup problem
From: Philip Freidin <philip@fliptronics.com>
Date: Sat, 12 Mar 2005 09:58:26 GMT
Links: << >>  << T >>  << A >>
On 11 Mar 2005 07:57:20 -0800, lecroy7200@chek.com wrote:
>I am looking at a design that was done several years back which uses
>several  XC3000 devices.  All devices are programmed with the same core
>from a computer on power up.  What I am seeing is that once or twice a
>year, one of the devices will enter a non-recoverable mode.  In this
>mode, the device appears to be in power down or reset.  Once in this
>mode I am no longer able to program the device.  Pulling the XC3000's
>reset low for 10us has no effect.  The problem appears random.  The
>only way to reprogram the part is to power down the IC.  I have tried
>running tests where I just reprogram the device, over heat the device,
>change the supply voltages, etc. and can't reproduce the problem.  When
>the Xilinx device is in this mode, it draws little power.  It can be
>held in this mode for what appears an infinite amount of time and
>causes no damage to the device.
>
>Was there some kind of an undocumented test mode built into the XC3000
>that I may be seeing?  Does anyone else ever remember seeing a problem
>like this?

This sounds like something that used to be called the "brownout" problem.
I did a xilinx search, but found nothing. Must have been purged.

I seem to remember that the problem occurs if there is a low going
transient that drops below some level (like 3.0 V) which causes
the chip to do house cleaning (wiping the config memory), but doesn't
go low enough to trigger the re-configuration logic.

Maybe Peter Alfke can remember better than me? This problem was fixed
around 1989 I think.

The solution may involve changes to your power supply, such that if
the voltage ever dips below say 4.5V, you make sure it goes all the
way down to 0V, for maybe 100 mS, before it comes back up.

A google search found this:
    http://www.sltf.com/articles/pein/pein9507.htm

which sort of confirms the fault mode.

Philip Freidin



Philip Freidin
Fliptronics

Article: 80840
Subject: Re: (Stupid/Newbie) Question on UART
From: "Alexei A. Frounze" <alexfru@chat.ru>
Date: Sat, 12 Mar 2005 13:18:30 +0300
Links: << >>  << T >>  << A >>
"Hal Murray" <hmurray@suespammers.org> wrote in message
news:tdednf4NTuXAL6_fRVn-vg@megapath.net...
> > I am wondering if someone could clear this doubt for me, in case of
> >UART, the clock speed is 1.8432 MHZ, however it is able to transmit
> >maximum of 115,200 bps, however even if we are able to transmit at 1
> >bit per cycle we should be able to transmit at 1,843,200 bps. What is
> >the rationale for making something go slowly, when it can go much
> >faster.
>
> The traditional implementation uses a 16x clock on the receiver.
>
> It looks for the transition on the leading edge of the start bit,
> then starts counting. After 1.5 baud times, it samples the first bit
> in the byte.  That's the middle of the bit cell.

The oversampling not only makes it possible to determine the position of the
start bit, but also it combats the noise and errors. The 16 consecutive
sampled values (each being 0 or 1) are used to decide on the actual bit
value. If most of these 16 samples are 1, it's 1. Otherwise, it's 0. A
better (in terms of error immunity) UART is one that works with a current
loop instead of the regular that works with voltage.

> 16*115200 is 1843200
>
> You can use slower clocks, say 8x, but they you will (sometimes) be
> farther from the center of the bit cell and errors will be more likely.

The start bits help to resynchronize. If the data flow isn't continuous but
often have all ones, the receiver and xmitter clocks may not match each
other well, provided all bits in a byte are decoded correctly. Good hardware
implementations may adjust themselves to the clock offset.

Alex



Article: 80841
Subject: Re: Hierarchical Synchronous Design (corrected)
From: "valentin tihomirov" <spam@abelectron.com>
Date: Sat, 12 Mar 2005 13:16:01 +0200
Links: << >>  << T >>  << A >>

> I don't really know what your are doing other
> than drawing boxes inside boxes. The fact that
> you are counting up output registers leads me to
> think that you might need fewer boxes with
> more logic in them.

I think the OP asked for a proper design demo on the single signal path
example.



Article: 80842
Subject: Re: Lattice's XP (flash + sram) fpga
From: Luc <lb.edc@pandora.be>
Date: Sat, 12 Mar 2005 13:31:56 +0100
Links: << >>  << T >>  << A >>
Hi,

The part looks promising, but I don't believe that someone in the
newsgroup will have experience with it. The device is only announced
last week.
But if indeed soneone has experience, please let me know too.

Luc

On 9 Mar 2005 07:48:30 -0800, "Teo" <themarenas@comcast.net> wrote:

>Does anyone have experience with Lattice's XP (flash + sram) fpga?
>This technology looks great, instant on, reconfigurable & total
>security.
>I've been impressed with the progress of their sw, althogh it is not up
>to ISE, it seem more than adequate.


Article: 80843
Subject: Re: Free Stencil For SMD Soldering
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Sat, 12 Mar 2005 20:17:54 +0700
Links: << >>  << T >>  << A >>
ezpcb.com wrote:
> 
> sorry for spamming, but good to everybody:
> 
> There's a way to get $200 laser-cut SMD soldering stencils for free!
> see http://www.ezpcb.com for details
> 
> mike

Yes, spamming this is indeed ...

Just looked at ezpcbs.com to compare prices with www.pcbexpress.com,
a company we have used in the past and are *very* satisfied with.

A few weeks ago we had pcbexpress make 25 proto boards for us.
4 layers, 8.5 cm x 13 cm, 7 mil t/s, silk screen on both sides,
fr4 ... Total cost was $650, including international UPS shipping.

According to ezpcb.com web site, just the boards would cost
us $1028,75 USD using some unknown outlet in Beijing .... that
likes to spam this newsgroup ...

pcbexpress offers a stencil *kit* for some $150 USD as well, so
even if you buy the stencil, you still save money ...

I don't know ... what do you mean with "good to everybody"
anyway ?   Check out http://www.pcbexpress.com

Just a happy customer ....

rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Article: 80844
Subject: Re: Free Stencil For SMD Soldering
From: jedi <me@aol.com>
Date: Sat, 12 Mar 2005 13:35:43 GMT
Links: << >>  << T >>  << A >>
Rudolf Usselmann wrote:
> ezpcb.com wrote:
> 
>>sorry for spamming, but good to everybody:
>>
>>There's a way to get $200 laser-cut SMD soldering stencils for free!
>>see http://www.ezpcb.com for details
>>
>>mike
> 
> 
> Yes, spamming this is indeed ...
> 
> Just looked at ezpcbs.com to compare prices with www.pcbexpress.com,
> a company we have used in the past and are *very* satisfied with.
> 
> A few weeks ago we had pcbexpress make 25 proto boards for us.
> 4 layers, 8.5 cm x 13 cm, 7 mil t/s, silk screen on both sides,
> fr4 ... Total cost was $650, including international UPS shipping.
> 
> According to ezpcb.com web site, just the boards would cost
> us $1028,75 USD using some unknown outlet in Beijing .... that
> likes to spam this newsgroup ...
> 
> pcbexpress offers a stencil *kit* for some $150 USD as well, so
> even if you buy the stencil, you still save money ...
> 
> I don't know ... what do you mean with "good to everybody"
> anyway ?   Check out http://www.pcbexpress.com
> 
> Just a happy customer ....
> 

ANd what the hell has SMD stencil to do with FPGA newsgroup?
Apparently this spammer has only posted here...

I would never order any prototype boards from China...or
generally outside Europe..even have problem with certain
countries in Europe as well...


And besides...I'm still the kinda person which also looks
at the first impression...and this website looks like in those
good ole days when I used netscape 1.x/2.x (o;


rick


Article: 80845
Subject: Re: (Stupid/Newbie) Question on UART
From: "Maxim S. Shatskih" <maxim@storagecraft.com>
Date: Sat, 12 Mar 2005 16:36:31 +0300
Links: << >>  << T >>  << A >>
> The start bits help to resynchronize. If the data flow isn't continuous but

Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the
pauses between bytes can be of arbitrary time. Only the timings between bits in
a byte are established.

Serial line has no notion of the "packet".

-- 
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com



Article: 80846
Subject: Re: Free Stencil For SMD Soldering
From: Jedi <me@aol.com>
Date: Sat, 12 Mar 2005 14:05:21 GMT
Links: << >>  << T >>  << A >>
Rudolf Usselmann wrote:
> ezpcb.com wrote:
> 
> A few weeks ago we had pcbexpress make 25 proto boards for us.
> 4 layers, 8.5 cm x 13 cm, 7 mil t/s, silk screen on both sides,
> fr4 ... Total cost was $650, including international UPS shipping.
> 

25 pieces of 4-layer boards this size incl. 2nd silkscreen
costs around 600 US$ at eurocircuits.

And that is including VAT and shipping costs...


rick


Article: 80847
Subject: vhdl netlist synthesized
From: kubik <jackgroups@interfree.it>
Date: Sat, 12 Mar 2005 14:59:51 +0000
Links: << >>  << T >>  << A >>
Sorry for the basic question!
I' d like to know if with the ISE Webpack of Xilinx i can obtain the .vhd
file of the synthesized netlist.
I can view the RTL schematic double-clicking on the "View RTL schematic"
option of the Synthesize tag and i can view the .vhd report of the
traslate tag. The latter ( as is specified in the file ) is only for
simulation purpose and haven't a one to one correspondence with the
primitives and the hardware really used. 
Is the VHDL netlist voluntarily hidden? If not, where i can find the file? 
If yes, is there something that i can do to obviate it?

I'm asking that because i' d like to obtain a netlist synthesized in VHDL
and try a place and route with another tool, with a standard cell library
mapped on the basic gates of a XC9500 architecture.


Thanks in Advance!


Article: 80848
Subject: Re: (Stupid/Newbie) Question on UART
From: "Alexei A. Frounze" <alexfru@chat.ru>
Date: Sat, 12 Mar 2005 18:07:02 +0300
Links: << >>  << T >>  << A >>
"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:d0ur3u$1vn9$1@gavrilo.mtu.ru...
> > The start bits help to resynchronize. If the data flow isn't continuous
but
>
> Exactly. Also note that, with serial line (unlike Ethernet, USB etc), the
> pauses between bytes can be of arbitrary time. Only the timings between
bits in
> a byte are established.
>
> Serial line has no notion of the "packet".


Packetization is an artificial thing. Normally, the physical data channels
are continuous and bear no idea of any data packetization. Packets are just
a way to transfer data in portions, which is most useful in the channels,
where the data can be lost or corrupted. Chunks of data are numbered and
redundancy is appended to make sure anything lost or corrupted can be
requested for retransmission. Another way to combat data corruption is to
add the redundancy into the data itself, by some forward error correction
(FEC) mechanism. The receiving party can recover some errorneus bits in the
data from the data with added redundancy. Although FECs can help a lot,
they're not always practical because they require bigger bandwith and of
course not every error can be corrected with them (the Hamming distance of
the FEC determines the correcting performance).

Alex



Article: 80849
Subject: Re: RocketIO and Gigabit Ethernet
From: "MM" <mbmsv@yahoo.com>
Date: Sat, 12 Mar 2005 11:35:03 -0500
Links: << >>  << T >>  << A >>
"Marc Randolph" <mrand@my-deja.com> wrote in message
news:1110603050.126155.280760@o13g2000cwo.googlegroups.com...
>
>    I'm not sure if you are asking because I put a ballpark price in my
> response, or if you're just wondering my experience with the parts.
>
> I happen to be using a quad-port Broadcom part, although not in
> 1000Base-T mode (I use 1000Base-X mode).  Support isn't the fastest,
> and you have to put up with their never-ending paranoia, but the parts
> work well.

Thanks Marc. I was interested in your experience...


/Mikhail





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