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 107525

Article: 107525
Subject: Re: September training?
From: "linnix" <me@linnix.info-for.us>
Date: 29 Aug 2006 13:38:55 -0700
Links: << >>  << T >>  << A >>

yusufil...@gmail.com wrote:
> linnix wrote:
> > We can book a 7 days cruise from LA to Mexico and do hand-on
> > training/experiments with FPGA.  How many are coming?
>
> Can you post more information about place, price, dates,concept etc..

7 days cruise would be:

Los Angeles, Cabo San Lucas, Mazatlan, Puerto Vallarta, Los Angeles

But we probably would not leave the ship anyway, since rooms and foods
are excellent on-board.

We can look into interfacing portable instruments with Micro/Avr
(always on) to FPGA/Xilinx (on and off), including issues such as power
regulations and monitorings, battery chargings, programmings and
debuggings.  If time permitted, board layouts and mountings (Micro-lead
frames and Ball Grid Arrays).


Article: 107526
Subject: Re: Question on Virtex-4 CLB
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 29 Aug 2006 13:58:01 -0700
Links: << >>  << T >>  << A >>

> Of course, we are not interested in helping anyone design an ASIC, so
> you are unlikely to get much in the way of support there.

Hmm. I thought that most fpga manufacturers provide a path from fpga to 
ASIC. Is this not true of Xilinx?

> On the other hand, since what we do we consider proprietary, we are not
> going to share schematics with you.

I understand the importance of proprietary intellectual property, as a 
patent owner, better than most. However, it seems that keeping your 
customers in the dark about what they are programming is counterproductive. 
What are Xilinx's real risks? And have they been ripped off in the past?

Brad Smallridge
aivision

> Austin
>
> Brad Smallridge wrote:
>> I wrote down a similar question about
>> some skinny rectangles on the perimeter
>> of a SX35.  These seem to connect to
>> the connecting wires and have the funny
>> names OMUX, DOUBLE, and HUNIHEX. Any
>> idea about what these are?
>>
>> If the editor does not show us the reality
>> of the physical spaces in the silicon as
>> Austin has suggested that's fine with me.
>> I can speculate on how some features
>> might be too small to show graphically.
>>
>> However, where can one find out about the
>> real sizes of the fabric? Curious minds
>> will want to know if they are planning future
>> ASIC designs or might want to suggest to Xilinx
>> some future designs.
>>
>> Brad Smallridge
>> aivision
>> dot com
>>
>> "Andreas Ehliar" <ehliar@lysator.liu.se> wrote in message
>> news:ecv54t$6jr$1@news.lysator.liu.se...
>>> If I look in the FPGA editor there seems to be one element
>>> in the CLB of a Virtex-4 that is odd as compared to previous
>>> FPGA generations that I have looked at in the FPGA editor.
>>>
>>> The CLB looks something like this in ASCII art:
>>>
>>>    +-------------+
>>>    |             |           +--+
>>>    |             |           |  |
>>>    |             |           |  |    +-----+
>>>    |             |           |  |    |SLICE|
>>>    |             |           |  |    |     |
>>>    |             |           |  |    +-----+
>>>    |             |           |  |
>>>    |             |           |  |    +-----+
>>>    |             |           |  |    |SLICE|
>>>    |             |           |  |    |     |
>>>    |             |           |??|    +-----+
>>>    |  Switchbox  |           |??|
>>>    |             |           |  | +-----+
>>>    |             |           |  | |SLICE|
>>>    |             |           |  | |     |
>>>    |             |           |  | +-----+
>>>    |             |           |  |
>>>    |             |           |  | +-----+
>>>    |             |           |  | |SLICE|
>>>    |             |           |  | |     |
>>>    |             |           |  | +-----+
>>>    |             |           |  |
>>>    |             |           +--+
>>>    +-------------+
>>>
>>>
>>> The box with question marks just seems to rearrange the wires so that
>>> they are grouped according to function at the switchbox.
>>> Is that all there is to it?
>>>
>>> /Andreas
>>
>> 



Article: 107527
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 30 Aug 2006 09:17:20 +1200
Links: << >>  << T >>  << A >>
John_H wrote:
> KJ wrote:
> 
>> Austin Lesea wrote:
>>
>>> Rick,
>>>
>>> Via in pad (basically no trace) is best.  Placement is not critical, as
>>> long as you have via in pad, and planes.
>>>
>> My memory is fuzzy on this (and other topics for that matter) but I
>> think via in pad creates an assembly issue because the pad of the part
>> is physically blocking the via (by design).  Unfortunately I don't
>> recall the specifics, maybe someone else recalls.
>>
>> Unless you already understand the issue (that I've conveniently
>> forgotten) I would suggest that whoever is going to be building your
>> boards be consulted to understand if there are appropriate tradeoffs
>> that can be made prior to planning to use 'via in pad' since
>> manufacturability is also generally a concern that at least must be
>> taken into consideration and evalutated.
>>
>> KJ
> 
> 
> Via in pad is a bad thing if you don't have filled vias since they would 
> otherwise wick the solder away from the component.  This "solder thief" 
> can present a reliability problem beyond initial build because of 
> trapped gasses even if the connection started out as good.
> 
> Filled vias are an extra process that will cost a little money but most 
> PC vendors can do it.  The benefits in lower inductance can be great.

Filled vias have an additional cost/risk, and BGAs are already a yield 
hot spot.

What I have seen, is what I'd call tangent vias : these overlap the 
pads, so that the hole is just under the solder mask. There is no trace.

Some CAD tools can also enable/disable Via sharing.
Sharing is good for packing more tracks in, but poor for lowest 
impedance. ( fewer parallel paths result )

In extreme cases, more than one via could be beneficial, but that would 
impact routing channels.

-jg



Article: 107528
Subject: Re: placing addiional caps across existing caps to reduce noise
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 30 Aug 2006 09:21:06 +1200
Links: << >>  << T >>  << A >>
rickman wrote:

> John_H wrote:
>>I've seen good information on Cadence tools based on Sun Microsystems work
>>that tracks what you've described with Ritchey.  A recent Howard Johnson /
>>Xilinx talk also covered many of these items well without contradiction.
> 
> 
> The contradiction part I don't agree with.  Many still argue that the
> distance between the IC and the cap is critical and some still say
> quantity is more important than variety of SRF.  

It depends on the PCB topology:

For BGA, that is not true, as you (should) go the the plane first.

For 2 layer PCBs, with QFP packages, then the distance between cap and 
IC is certainly critical :)

-jg


Article: 107529
Subject: Re: Style of coding complex logic (particularly state machines)
From: "rickman" <gnuarm@gmail.com>
Date: 29 Aug 2006 14:26:06 -0700
Links: << >>  << T >>  << A >>
mikegurche@yahoo.com wrote:
> rickman wrote:
> > mikegurche@yahoo.com wrote:
> > > In synthesis, the problem is normally the abuse of sequential
> > > statements, rather than the use of variable.  I have seen people trying
> > > to convert C segment into a VHDL process (you can have variables, for
> > > loop, while loop, if, case, and even break inside a process) and
> > > expecting synthesis software to figure out everything.
> >
> > Personally I think most problems in using HDLs in this way come not
> > directly from the way signals or variables are used, but rather from
> > the use of an HDL to describe the solution in an abstract way.  I
> > nearly always design in terms of registers and "clouds" for the logic.
> > I get a feel for how large the design is and if I need to optimize at
> > this block diagram level.  I can even get an idea of how complex the
> > logic part is by looking at the equations that describe it.  Then I use
> > an HDL to "describe" the hardware rather than describing the
> > functionality and letting the tool decide what hardware to invoke.
> >
>
> I agreed with you completely.  What I am trying to say is that variable
> may not be synthesizable if you write the code with a "C
> mentality."

I'm not sure I agree that variables are the problem at all.  There are
many ways to write code that is not synthesizable.  This can be done
with signals as well as variables.  The difference between signals and
variables is just that the value of a variable is updated immediately
just like a 'C' variable.  Signals are only updated at the end of the
process.  So if you make an assignment to a variable and then use that
value in a calculation in the same process, the new value will be used.
 If you do the same thing with a signal, the old value of the signal
will be used.  I don't know of a way that this can be unsynthesizable.
Variables can not exist outside of a process, IIRC.  So the variable
must be assigned to a signal in order for it to affect anything outside
the process.  So in reality, it can only be used as an intermediate
value in an assignment to a signal.

Do you have an example of unsynthesizable code using a variable that
would be synthesizable with a signal?


Article: 107530
Subject: Re: CPU design
From: Jim Granville <no.spam@designtools.maps.co.nz>
Date: Wed, 30 Aug 2006 09:49:36 +1200
Links: << >>  << T >>  << A >>
Walter Banks wrote:
> Jim,
> 
> We have certainly thought about it. Byte Craft has done quite a bit of
> instruction design work on embedded commercial processors. Internally
> for every C compiler we create an instruction set simulator  with a lot of
> performance instrumentation.
> 
> I expect the next round of processors will move towards multiple processor
> solutions to applications. Compilers and other HLL tools will be focused on
> application work division.
> 
> w..

Sounds promising. What about debug pathways ?

-jg


Article: 107531
Subject: Re: September training?
From: Jim Stewart <jstewart@jkmicro.com>
Date: Tue, 29 Aug 2006 14:49:49 -0700
Links: << >>  << T >>  << A >>
Richard Henry wrote:

> We have been encouraged to spend some of our remaining training budget
> by taking a week-long seminar in September.  I am looking for something
> concerning FPGA design, wireless networks, or just general engineering.
>  My preference would be somewhere in southern California, but other
> places may be negotiable.
> 
> Any suggestions?

If it were me, I'd save it for the Paris airshow (:



Article: 107532
Subject: Re: September training?
From: "Richard Henry" <pomerado@hotmail.com>
Date: 29 Aug 2006 14:56:12 -0700
Links: << >>  << T >>  << A >>

Jim Stewart wrote:
> Richard Henry wrote:
>
> > We have been encouraged to spend some of our remaining training budget
> > by taking a week-long seminar in September.  I am looking for something
> > concerning FPGA design, wireless networks, or just general engineering.
> >  My preference would be somewhere in southern California, but other
> > places may be negotiable.
> >
> > Any suggestions?
>
> If it were me, I'd save it for the Paris airshow (:

Fiscal year ends Sept 30.


Article: 107533
Subject: Re: Question on Virtex-4 CLB
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 29 Aug 2006 15:09:58 -0700
Links: << >>  << T >>  << A >>
Brad,

Good questions.

I will attempt answering them,

-snip-

>> Of course, we are not interested in helping anyone design an ASIC, so
>> you are unlikely to get much in the way of support there.
> 
> Hmm. I thought that most fpga manufacturers provide a path from fpga to 
> ASIC. Is this not true of Xilinx?

There are companies who use our parts to verify the logic prior to its
placement in an ASIC.  Good business, as they buy our largest parts, and
lots and lots of them.

We make no further effort to help them create ASICs.  We appreciate
their use of our parts, even if that use leads eventually to less business.

>> On the other hand, since what we do we consider proprietary, we are not
>> going to share schematics with you.
> 
> I understand the importance of proprietary intellectual property, as a 
> patent owner, better than most. However, it seems that keeping your 
> customers in the dark about what they are programming is counterproductive. 
> What are Xilinx's real risks? And have they been ripped off in the past?

Then you can appreciate that customers have trust in Xilinx not to do
anything to make it trivial, or easy, for their clever IP to be ripped off.

As for being ripped off in the past, we have not been harmed per se, but
customers have been harmed by a company cloning an entire pcb, and then
copying the eproms, and selling that product for less money.  I won't
say who did this, as it is all litigated and settled now, and Xilinx
derives benefit because both companies bought our FPGAs (the cloning
company had to, as they had no means to modify or change the design, or
even to fix any bugs).

This is why today we offer the bitstream decryption features in V2,
V2Pro, V2Pro-X, V4, and now V5.  We will do whatever we can to help
protect the customer's investment.

What you refer to as "Keeping our customer's in the dark" is in no way a
hindrance, or a handicap, as reverse engineering is perfectly legal to
fix a problem, or discover how something works.  We do not keep our
customer's in the dark for a legitimate reason.

If someone has to reverse engineer something (for example: a soft error
broke their design, which line of VHDL did that bit affect?) we are
happy to work with them to resolve the issue by telling them exactly
what they need to know (in fact, we will parse their design, and use our
tools to discover what they require).


Austin

Article: 107534
Subject: Re: Spartan-4 ?
From: Ben Twijnstra <btwijnstra@gmail.com>
Date: Wed, 30 Aug 2006 00:11:33 +0200
Links: << >>  << T >>  << A >>
Jim Granville wrote:

> Any info out yet on what MAX3 looks like ?
> Does it improve Static Icc, and lack of memory of MAX II, for example ?
> Smallest devices / largest devices  ?

Nope - Altera's silicon design team is quite busy with Cyclix III. If you
have any good suggestions on specs outside the hobby sphere, now might be a
good time to post them...

Ben


Article: 107535
Subject: Re: FSL read/write problems
From: "David" <simianfever@gmail.com>
Date: 29 Aug 2006 15:41:12 -0700
Links: << >>  << T >>  << A >>
Thanks for your help guys, that fixed it.  Interesting that the EDK
system assembly GUI doesn't hook up clock and reset by default...

Cheers,

David


G=F6ran Bilski wrote:
> David wrote:
> > G=F6ran Bilski wrote:
> >
> >
> >>David wrote:
> >>
> >>>Hi all,
> >>>
> >>>I'm trying to implement a correlator as a coprocessor on the FSL bus.
> >>>The first thing I've done is generate the FSL example using the create
> >>>peripheral wizard in EDK 8.1 and hooked it up to the MicroBlaze.  When
> >>>I do a blocking write or read the MB stalls - my understanding is that
> >>>this will happen if the FSL FIFO is full or empty respectively, but it
> >>>happens the first time I write to it, so the FIFO should not be full.
> >>>
> >>>If I use non-blocking reads and writes and check the error and invalid
> >>>flags after each one using fsl_isinvalid() and fsl_iserror() - see code
> >>>below - everything seems normal but the output is always zero.  Am I
> >>>implementing the error checking macros correctly?
> >>>
> >>>
> >>>#define write_into_fsl(val, id)  nputfsl(val, id)
> >>>#define read_from_fsl(val, id)  ngetfsl(val, id)
> >>>
> >>>#define WRITE_FSL_TEST_0(val)  write_into_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_INPUT_SLOT_ID)
> >>>#define READ_FSL_TEST_0(val)  read_from_fsl(val,
> >>>XPAR_FSL_FSL_TEST_0_OUTPUT_SLOT_ID)
> >>>
> >>>
> >>>void fsl_test_app(
> >>>      unsigned int* input_0,      /* Array size =3D 2 */
> >>>      unsigned int* output_0       /* Array size =3D 2 */
> >>>      )
> >>>{
> >>>  int i;
> >>>   Xuint8 is_error =3D 0;
> >>>   Xuint8 is_valid =3D 0;
> >>>
> >>>   print("Entering fsl_test_app \r\n");
> >>>
> >>>  //Start writing into the FSL bus
> >>>  for (i=3D0; i<2; i++)
> >>>  {
> >>>
> >>>     WRITE_FSL_TEST_0(input_0[i]);
> >>>       fsl_iserror(is_error);
> >>>       xil_printf("error post: %d \r\n", is_error);
> >>>       fsl_isinvalid(is_valid);
> >>>       xil_printf("valid post: %d \r\n", is_valid);
> >>>  }
> >>>   print("Finished Write \r\n");
> >>>
> >>>   is_error =3D 0;
> >>>   is_valid =3D 0;
> >>>
> >>>  //Start reading from the FSL bus
> >>>  for (i=3D0; i<2; i++)
> >>>  {
> >>>     READ_FSL_TEST_0(output_0[i]);
> >>>       fsl_iserror(is_error);
> >>>       xil_printf("error post: %d \r\n", is_error);
> >>>       fsl_isinvalid(is_valid);
> >>>       xil_printf("valid post: %d \r\n", is_valid);
> >>>  }
> >>>}
> >>>
> >>>I added external ports to the FSL core to check the reset polarity and
> >>>monitor the state machine - the core is not being held at reset, but
> >>>always sits in the Idle state.  This, coupled with the blocking
> >>>instruction problems seems to indicate an issue with the FSL FIFO
> >>>perhaps (I have tried both BRAM and non-BRAM FIFO implementations)?
> >>>If anyone has any ideas on what might be going wrong your help would be
> >>>much appreciated...
> >>>
> >>>
> >>>Cheers,
> >>>
> >>>David
> >>>
> >>
> >>Hi,
> >>
> >>Can you show the .mhs where you have connected your FSL core with
> >>Microblaze?
> >>
> >>G=F6ran Bilski
> >
> >
> >
> > Hi G=F6ran,
> >
> > Thanks for your reply, here are the relevant parts of the .mhs file:
> >
> > BEGIN microblaze
> >  PARAMETER INSTANCE =3D microblaze_0
> >  PARAMETER HW_VER =3D 4.00.a
> >  PARAMETER C_USE_FPU =3D 0
> >  PARAMETER C_DEBUG_ENABLED =3D 1
> >  PARAMETER C_NUMBER_OF_PC_BRK =3D 2
> >  PARAMETER C_FSL_LINKS =3D 1
> >  BUS_INTERFACE DLMB =3D dlmb
> >  BUS_INTERFACE ILMB =3D ilmb
> >  BUS_INTERFACE DOPB =3D mb_opb
> >  BUS_INTERFACE IOPB =3D mb_opb
> >  BUS_INTERFACE SFSL0 =3D fsl_v20_0
> >  BUS_INTERFACE MFSL0 =3D fsl_v20_1
> >  PORT CLK =3D sys_clk_s
> >  PORT DBG_CAPTURE =3D DBG_CAPTURE_s
> >  PORT DBG_CLK =3D DBG_CLK_s
> >  PORT DBG_REG_EN =3D DBG_REG_EN_s
> >  PORT DBG_TDI =3D DBG_TDI_s
> >  PORT DBG_TDO =3D DBG_TDO_s
> >  PORT DBG_UPDATE =3D DBG_UPDATE_s
> > END
> >
> >
> > BEGIN fsl_v20
> >  PARAMETER INSTANCE =3D fsl_v20_0
> >  PARAMETER HW_VER =3D 2.00.a
> >  PARAMETER C_EXT_RESET_HIGH =3D 0
> >  PARAMETER C_IMPL_STYLE =3D 1
> > END
> >
> > BEGIN fsl_v20
> >  PARAMETER INSTANCE =3D fsl_v20_1
> >  PARAMETER HW_VER =3D 2.00.a
> >  PARAMETER C_EXT_RESET_HIGH =3D 0
> >  PARAMETER C_IMPL_STYLE =3D 1
> > END
> >
> > BEGIN fsl_test
> >  PARAMETER INSTANCE =3D fsl_test_0
> >  PARAMETER HW_VER =3D 1.00.c
> >  BUS_INTERFACE MFSL =3D fsl_v20_0
> >  BUS_INTERFACE SFSL =3D fsl_v20_1
> >  PORT reset_out =3D fsl_test_0_reset_out
> >  PORT state_debug =3D fsl_test_0_state_debug
> > END
> >
> > Cheers,
> >
> > David
> >
>
> Hi,
>
> You need to connect the system clock to the fsl_v20 modules.
> They are non clocked right now.
>
> One good trick is always to look at the top level vhdl file in the hdl
> directory. It's called system.vhd
>
> In that file you will see what signals are connected to what and it this
> case you should be able to see that the fsl bus doesn't have any clock
> connected.
>=20
> G=F6ran Bilski


Article: 107536
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 00:54:03 +0200
Links: << >>  << T >>  << A >>
"rickman" <gnuarm@gmail.com> wrote in message
news:1156880090.634821.118390@i3g2000cwc.googlegroups.com...
>
> I'm not sure what you are asking.  A different capacitance will not
> change the inductive part of the impedance curve and a different
> inductance will not change the capacitive part of the curve.  What
> changes in both cases is the SRF.  So you put a few 0.1 uF caps on the
> board and a number more of 0.01 uF caps and even more of the 0.001 uF
> caps.  Each capacitance value needs to have sufficient quantity to
> bring the impedance near the SRF low enough to be effective.  Then the
> capacitive effect of the smaller caps keep the overall impedance low in
> spite of the larger caps being inductive.  Finally the impedance of the
> ground planes keep the impedance low for the highest frequency.  Doing
> a simulation is always a good thing to be able to see how the parallel
> resonances affect the impedance.
>
>
> The contradiction part I don't agree with.  Many still argue that the
> distance between the IC and the cap is critical and some still say
> quantity is more important than variety of SRF.  In one of these
> threads there was a link to a post by HJ.  There were some things in
> the HJ post that were not supported by any sort of measurement or even
> simulation.  I don't recall the details.
>
>
> Not inductance, impedance.  I don't care about inductance if I can keep
> the impedance low over the frequency range that matters to my design.
> The small deltas in inductance only move the SRF, they don't have a
> large impact on the impedance after you mix the capacitor values.
>

So, here's my thoughts.

If we have two caps of different values, but the same package/inductance,
there's a frequency between the SRF of the caps that has a parallel
resonance which leads to a peak in the impedance. For example, C1, a 1uF
0402 has a SRF of 10MHz. C2, a 0.1uF 0402 has a SRF of 25MHz. Between 10 MHz
and 25MHz, C1 looks inductive and C2 capacitive. This means there's a peak
in the impedance. So, the stragegy of using different values to 'even out'
the impedance gives us peaks (bad) and troughs (good) in the impedance
across the frequency spectrum.

However, for a 0.1uF 0402 cap, at resonance the ESR is 0.014R, so the Q of
the tuned circuit is about 5. For a 0402 1uF cap, the ESR at resonance is
0.01R, giving a Q of 2. These values of Q are so low as to make the self
resonance problem/advantage make bugger all difference. Note that a 10nF
0402 cap has a Q of about 3 at its SRF of 70MHz.

BTW, I got the cap data from here http://www.murata.com/designlib/mcsil.html

(Also, note that the vias/traces to connect these caps probably double the
inductance, reducing the SRF by 30%)

As for the 'plane capacitance', it starts to have an effect at frequencies >
1GHz which is a fat lot of good when our vias and BGA balls have inductances
in the nH region. Remember, we're not trying to bypass the power plane,
we're trying to bypass the IC.

In conclusion, mixing different values of ceramic caps in the same packages
might help a little but might hurt a little in a real system with FPGAs. I
maintain that using the biggest value in the size you choose is the best, if
nothing else because they have the crappest Q and this avoids BOM bloat. If
we do use a range, bully for us, we probably won't notice any difference,
but we have more chances for resonance and EMI failures.

Finally, I agree that the positioning of the cap is of lesser importance.
However, some of us prefer not to waste layers in our stacks on power
planes, we prefer to have decent grounds and route our FPGA power on layers
used for signals in other places. The HF plane capacitance is pissed away by
the chip mounting interconnect anyway, and its high Q might lead to evil
resonances. (As you mention in your posts, Rick.) In this case, with little
mini-planes for power routing, capacitor placement is crucial. (Note. With
FPGAs needing at least 3 supplies, and maybe a lot more, the PCBs are
getting very expensive with planes for every supply.)

In conclusion, for FPGA PCBs,
Lots of ground layers, one for every two signal layers.
One value of cap per size.
Use lots of caps. It means less impedance.
Power planes only need extend as far as the bypass caps. So, closer the caps
to the target device, the less plane needed.

IMHO, YMMV, HTH, Syms.

p.s. It's easy to simulate this stuff, try the excellent and free LTSpice
from
http://www.linear.com/company/software.jsp
(as recommended by Bob, thanks!)
p.p.s. Let me underline, _other_ways_work_too_ , but I'm happy with this
methodology, and I don't think other solutions work noticeable better.



Article: 107537
Subject: Re: September training?
From: martin griffith <mart_in_medina@yahoo.esXXX>
Date: Wed, 30 Aug 2006 00:58:46 +0200
Links: << >>  << T >>  << A >>
On 29 Aug 2006 14:56:12 -0700, in comp.arch.embedded "Richard Henry"
<pomerado@hotmail.com> wrote:

>
>Jim Stewart wrote:
>> Richard Henry wrote:
>>
>> > We have been encouraged to spend some of our remaining training budget
>> > by taking a week-long seminar in September.  I am looking for something
>> > concerning FPGA design, wireless networks, or just general engineering.
>> >  My preference would be somewhere in southern California, but other
>> > places may be negotiable.
>> >
>> > Any suggestions?
>>
>> If it were me, I'd save it for the Paris airshow (:
>
>Fiscal year ends Sept 30.

Change your OS.........


martin

Article: 107538
Subject: Re: I2C on Xilinx Virtex-4/ML403
From: "Suzie" <eckardts@saic.com>
Date: 29 Aug 2006 16:04:35 -0700
Links: << >>  << T >>  << A >>
Brad Smallridge wrote:
> The bit-banging is probably slower.
>
> How are you handling your IOs?
>
> You may wish to use tristate outputs
> with your signals going to the T input:
>
>  scl_iobuf : IOBUF
>  port map (
>  O  => open,
>  IO => scl_pin,
>  I  => '0',
>  T  => scl_master );
>
>  sda_iobuf : IOBUF
>  port map (
>  O  => sda_slave,
>  IO => sda_pin,
>  I  => '0',
>  T  => sda_master );
>
> Brad Smallridge
> aivision
> dot com

Even after applying the IP core and driver patches described in Xilinx
Answer 23866, I still have the same problem.  What could cause the core
to skip a bit/clock within a transfer that is atomic at the user-level?


Article: 107539
Subject: Re: Do I need to adjust sdram clk shift when i lower my system clock?
From: "Tony" <ihankuo@gmail.com>
Date: 29 Aug 2006 16:05:19 -0700
Links: << >>  << T >>  << A >>
Hi Gabor,
Thank you for your prompt reply.
I am using Altera Stratix development board (pro edition 1s40) for this
project. The board provide around 40k of LEs, and my whole design is
only taking 15k of all.
Do you think it's likely there is a power supply drop ? (by the way I
am not sure how to check if there is power drop or not. :P )

> Also when reducing the SDRAM clock, make sure you don't violate
> the refresh period requirements.  Normally refresh timing is done by
> counting clock cycles,
I looked up the default timing setting for my sdram controller (I build
my design based on the example design provided by Altera) in SOPC
builder and all timing are specified in seconds except the
"initialisation refresh cycles". Since cycle period increase when the
frequency is lowered, the timing setting in seconds will end up the
same no matter how I change the clock frequency?. 

Thank you 
Tony


Article: 107540
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 01:18:20 +0200
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message
news:44f4c58b$1_1@x-privat.org...
>
> p.s. It's easy to simulate this stuff, try the excellent and free LTSpice
> from
> http://www.linear.com/company/software.jsp
> (as recommended by Bob, thanks!)
>
Here's a simple LTSpice file with a swept frequency across two caps. It's
interesting to experiment and see where the resonances occur.

Version 4
SHEET 1 1316 756
WIRE 0 464 -208 464
WIRE 208 496 144 496
WIRE 336 496 288 496
WIRE 384 496 336 496
WIRE 448 496 384 496
WIRE 464 496 448 496
WIRE -208 512 -208 464
WIRE 336 560 336 496
WIRE 448 560 448 496
WIRE 0 592 0 560
WIRE -208 624 -208 592
WIRE 336 736 336 624
WIRE 448 736 448 624
FLAG 0 592 0
FLAG -208 624 0
FLAG 336 736 0
FLAG 384 496 Vcap
FLAG 448 736 0
SYMBOL SpecialFunctions\\modulate 0 464 R0
WINDOW 3 0 0 Invisible 0
SYMATTR InstName A1
SYMATTR Value MARK=40000000 SPACE= 5000000
SYMBOL voltage -208 496 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value PULSE(0 1 100ns 1us 1us 1us 4us)
SYMBOL res 304 480 R90
WINDOW 0 0 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName R2
SYMATTR Value 0.1
SYMBOL cap 320 560 R0
SYMATTR InstName C2
SYMATTR Value 0.1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1
SYMBOL cap 432 560 R0
SYMATTR InstName C5
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
TEXT 144 344 Left 0 !.tran 20us



Article: 107541
Subject: Re: placing addiional caps across existing caps to reduce noise
From: fpga_toys@yahoo.com
Date: 29 Aug 2006 16:22:38 -0700
Links: << >>  << T >>  << A >>

rickman wrote:
> If nothing else you can check out the
> Ritchey book, "Right The First Time, A Practical Handbook on High Speed
> PCB and System Design, Volume 1".  He is promising a Volume 2,
> "Included in this text will be a thorough treatment of EMI; a
> comprehensive description of the PCB fabrication process and PCB
> materials; a detailed examination of simulation tools and their use and
> a complete discussion of Gigabit and higher signaling protocols."

awesome ... thanks for the pointer ... ought to make some interesting
bed time reading ;)


Article: 107542
Subject: Re: September training?
From: Rich Grise <rich@example.net>
Date: Tue, 29 Aug 2006 23:23:11 GMT
Links: << >>  << T >>  << A >>
On Tue, 29 Aug 2006 14:56:12 -0700, Richard Henry wrote:
> Jim Stewart wrote:
>> Richard Henry wrote:
>>
>> > We have been encouraged to spend some of our remaining training budget
>> > by taking a week-long seminar in September.  I am looking for something
>> > concerning FPGA design, wireless networks, or just general engineering.
>> >  My preference would be somewhere in southern California, but other
>> > places may be negotiable.
>> >
>> > Any suggestions?
>>
>> If it were me, I'd save it for the Paris airshow (:
> 
> Fiscal year ends Sept 30.

Oh, hell, then: They've _GOT_ to spend the money - just make something
up!

For a price, I can give you a week-long seminar in just about anything
you want to study!

Good Luck!
Rich


Article: 107543
Subject: Re: September training?
From: "Rich Grise, Plainclothes Hippie" <eatmyshorts@doubleclick.net>
Date: Tue, 29 Aug 2006 23:26:03 GMT
Links: << >>  << T >>  << A >>
On Tue, 29 Aug 2006 13:38:55 -0700, linnix wrote:
> yusufil...@gmail.com wrote:
>> linnix wrote:
>> > We can book a 7 days cruise from LA to Mexico and do hand-on
>> > training/experiments with FPGA.  How many are coming?
>>
>> Can you post more information about place, price, dates,concept etc..
> 
> 7 days cruise would be:
> 
> Los Angeles, Cabo San Lucas, Mazatlan, Puerto Vallarta, Los Angeles
> 
> But we probably would not leave the ship anyway, since rooms and foods
> are excellent on-board.
> 
> We can look into interfacing portable instruments with Micro/Avr
> (always on) to FPGA/Xilinx (on and off), including issues such as power
> regulations and monitorings, battery chargings, programmings and
> debuggings.  If time permitted, board layouts and mountings (Micro-lead
> frames and Ball Grid Arrays).

How hard would it be to carry a couple of ozs of Acapulco Gold back from
the cruise? Like, does Customs pat you down or use dogs or anything? Or do
they just assume that anyone who can afford a week-long cruise has better
things to smuggle than pot? ;-)

Thanks!
Rich


Article: 107544
Subject: Re: How to load the data off the FPGA to the PC?
From: "EEngineer" <maricic@gmail.com>
Date: 29 Aug 2006 16:31:05 -0700
Links: << >>  << T >>  << A >>
Symon,
I am using 2002 laptop PC. I am trying to use Matlab to input data from
the parallel port. Sending data using Matlab works fine.
Thanks,
Dan

Symon wrote:
> Dan,
> Which parallel port signals are you trying to read? On old parallel ports,
> the data pins can only be outputs from the PC.
> Cheers, Syms.
>
> "EEngineer" <maricic@gmail.com> wrote in message
> news:1156804493.078190.57560@74g2000cwt.googlegroups.com...
> > PC, the voltage is 3.3V which seems OK. But why I can not read anything
> > on my PC from the parallel port?
> >
> > Thanks,
> > Dan
> >


Article: 107545
Subject: Re: September training?
From: "linnix" <me@linnix.info-for.us>
Date: 29 Aug 2006 16:34:17 -0700
Links: << >>  << T >>  << A >>

Rich Grise, Plainclothes Hippie wrote:
> On Tue, 29 Aug 2006 13:38:55 -0700, linnix wrote:
> > yusufil...@gmail.com wrote:
> >> linnix wrote:
> >> > We can book a 7 days cruise from LA to Mexico and do hand-on
> >> > training/experiments with FPGA.  How many are coming?
> >>
> >> Can you post more information about place, price, dates,concept etc..
> >
> > 7 days cruise would be:
> >
> > Los Angeles, Cabo San Lucas, Mazatlan, Puerto Vallarta, Los Angeles
> >
> > But we probably would not leave the ship anyway, since rooms and foods
> > are excellent on-board.
> >
> > We can look into interfacing portable instruments with Micro/Avr
> > (always on) to FPGA/Xilinx (on and off), including issues such as power
> > regulations and monitorings, battery chargings, programmings and
> > debuggings.  If time permitted, board layouts and mountings (Micro-lead
> > frames and Ball Grid Arrays).
>
> How hard would it be to carry a couple of ozs of Acapulco Gold back from
> the cruise? Like, does Customs pat you down or use dogs or anything? Or do
> they just assume that anyone who can afford a week-long cruise has better
> things to smuggle than pot? ;-)

You do have to go through airport like security.  They don't want you
to sink the ship or bring in foreign plants (fruits and pot included)
to the state.

> 
> Thanks!
> Rich


Article: 107546
Subject: Re: FPGA -> SATA?
From: fpga_toys@yahoo.com
Date: 29 Aug 2006 16:34:46 -0700
Links: << >>  << T >>  << A >>

Phil James-Roxby wrote:
> That said, its understandable that people see SATA and immediately think
>   hard drives.  We tried in the documentation to explain the difficulty
> of connecting to drives, for example, on page 67 of the user guide, we
> stated

Hi Phil,

People have a right to get upset when you advertise/describe one thing,
and deliver something completely different.

Consider selling 74LS02 chips and calling them PLD's or FPGA's.

Sure, you have a fine bit serial prototype bench, SATA shouldn't be
anywhere in ANY document unless it's standard conforming product.


Article: 107547
Subject: Re: high level languages for synthesis
From: fpga_toys@yahoo.com
Date: 29 Aug 2006 16:42:05 -0700
Links: << >>  << T >>  << A >>

Martin Thompson wrote:
> Can I suggest you stick the docs up on the actualy web somewhere, last
> time I looked, they were all in SVN.  I checked them out and there was
> some very interesting stuff in there, but I imagine most people would
> like to have a read of what you have more easily than that...

The doc's are available under the Doc page, which are Beta-2 docs.
Current work in progress will be always SVN. I try update the doc's as
we check things in, so it's not a frenzy at the next beta freeze.

> Are you going to start making use of the carry chain... last time I
> tried a counter, it didn't go anywhere near it, just a big lump of
> LUT4s - took me right back to uni, doing next-state logic
> minimisations for a counter!

There isn't really any technology specific generation at the moment, so
it doesn't use the LUT carry resources. In fact, the current internal
technology makes it nearly impossible. That is something that we are
addressing soon ... probably Beta-4

> Have you considered doing a higher-level technology independent
> VHDL/Verilog backend, which could then be thrown into a normal
> synthesizer and let it ifugre out the best adders and such like -
> they've been practising that for a number of years now :-)

There is a VHDL output, fully functional I believe in Beta-1 ... it got
broke in Beta-2, and will be fixed at Beta-3 again (which should be
very soon).


Article: 107548
Subject: Re: placing addiional caps across existing caps to reduce noise
From: "Symon" <symon_brewer@hotmail.com>
Date: 30 Aug 2006 02:30:44 +0200
Links: << >>  << T >>  << A >>
OK, here's a LTSpice file that shows a resonance between disimilar cap
values. The circuit sweeps from 5MHz to 45MHz back and forth. The first
three sweeps are done with two 1uF caps, the second three with a 1uF and a
0.1uF cap. Notice the big resonance at about 10MHz for the second set of
sweeps. The performance of the second circuit is slightly better at 45MHz,
worse at 5MHz, MUCH worse at 10MHz.
HTH, Syms.

Version 4
SHEET 1 1516 904
WIRE 1040 432 800 432
WIRE 0 464 -208 464
WIRE 208 496 144 496
WIRE 384 496 288 496
WIRE 448 496 384 496
WIRE 656 496 448 496
WIRE 896 496 656 496
WIRE -208 512 -208 464
WIRE 656 512 656 496
WIRE 896 512 896 496
WIRE 736 528 704 528
WIRE 1040 528 1040 432
WIRE 1040 528 944 528
WIRE 448 560 448 496
WIRE 800 576 800 432
WIRE 800 576 704 576
WIRE 976 576 944 576
WIRE 0 592 0 560
WIRE -208 624 -208 592
WIRE 656 624 656 592
WIRE 896 624 896 592
WIRE 1040 624 1040 528
WIRE 656 720 656 688
WIRE 736 720 736 528
WIRE 736 720 656 720
WIRE 896 720 896 688
WIRE 976 720 976 576
WIRE 976 720 896 720
WIRE 448 736 448 624
WIRE 656 736 656 720
WIRE 896 736 896 720
WIRE 1040 736 1040 704
FLAG 0 592 0
FLAG -208 624 0
FLAG 384 496 Vcap
FLAG 448 736 0
FLAG 656 736 0
FLAG 896 736 0
FLAG 1040 736 0
SYMBOL SpecialFunctions\\modulate 0 464 R0
WINDOW 3 0 0 Invisible 0
SYMATTR InstName A1
SYMATTR Value MARK=45000000 SPACE= 5000000
SYMBOL voltage -208 496 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V1
SYMATTR Value PULSE(0 1 100ns 1us 1us 1us 4us)
SYMBOL res 304 480 R90
WINDOW 0 0 56 VBottom 0
WINDOW 3 32 56 VTop 0
SYMATTR InstName R2
SYMATTR Value 0.1
SYMBOL cap 432 560 R0
SYMATTR InstName C5
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL sw 656 608 R180
SYMATTR InstName S1
SYMATTR Value MYSW
SYMBOL cap 640 624 R0
SYMATTR InstName C1
SYMATTR Value 0.1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.014 MTBF=0 Lser=0.45nH ppPkg=1
SYMBOL cap 880 624 R0
SYMATTR InstName C3
SYMATTR Value 1µ
SYMATTR SpiceLine V=10 Irms=10.541 Rser=0.01 MTBF=0 Lser=0.4nH ppPkg=1
SYMBOL sw 896 608 R180
SYMATTR InstName S2
SYMATTR Value MYSW
SYMBOL voltage 1040 608 R0
WINDOW 123 0 0 Left 0
WINDOW 39 0 0 Left 0
SYMATTR InstName V3
SYMATTR Value PULSE(1 -1 12us 1ns 1ns 12us 24us)
TEXT 144 344 Left 0 !.tran 24us
TEXT 296 888 Left 0 !.model MYSW SW(Ron=0.0001 Roff=10Meg Vt=.5 Vh=-.4)



Article: 107549
Subject: Re: Quartus software and dual-purpose pins
From: "Marc Guardiani" <news.guardiani@gmail.com>
Date: 29 Aug 2006 17:47:39 -0700
Links: << >>  << T >>  << A >>
Nevo wrote:
> I'm designing a Cyclone device and am having problems with one pin.
>
> I want to use the configuration pin ASDO as an I/O pin after my device
> finishes active serial configuration. I assigned my I/O to that pin but the
> fitter barks at me that it "Can't place node ~ASDO~ in location 37 because
> location already occupied by Q[0]"
>
> I went to Assignments... Device... Device & Pin Options... Dual-Purpose
> Pins, but the setting for ASDO is greyed out.
>
> How do I tell Quartus to let me use that pin as an I/O pin after AS
> configuration?
>
> Thanks,
>
> -Nevo

Cyclone does not support the use of the ASDO pin as an I/O after Active
Serial configuration. See:
http://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
Go to page 48 and look for ASDO "User Mode" in the table.

Marc




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