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 99350

Article: 99350
Subject: FPGA : Spartan-3e configuration failure
From: bijoy <pbijoy@rediffmail.com>
Date: Thu, 23 Mar 2006 06:34:42 -0800
Links: << >>  << T >>  << A >>
Hi

I have a board with Spartan-3e-100VQFP FPGA mounted on it.

I am using SPI flash (M25p20 ) from ST, to store the configuration bit map.

After power-on, the FPGA's starts configuring (INIT-B goes high), then it comes to low. and DONE pin does not go high.

All power suplly is correct.

CCLK is coming but about 1.3 MHz and other signals like CSO_B,DIN some data is coming.

But i am not able to trace why the configuration fails.

May I get any help from you guys..

Thanks in advance...

bijoy

Article: 99351
Subject: Re: Problem with LwIP and MicroBlaze
From: "Marco T." <marc@blabla.com>
Date: Thu, 23 Mar 2006 15:52:59 +0100
Links: << >>  << T >>  << A >>

"Raymond" <raybakk@yahoo.no> wrote in message 
news:1143116151.447290.42460@t31g2000cwb.googlegroups.com...
> Hi Marco.
>
> And thanks for answering :)
>
> I can't find any path options here? (It maybe that I overlook
> something).
> What should I look for in the configuration settings?
>
> Is it possible to download a new version of LwIP (like a custom LwIP)
> and use that in stead?
> By the way, I use lwip 2.00.a
>
> Raymond
>

There aren't newer version of lwip.
I use a custom version because ll_temac is not supported by xilinx official 
version 1.00.a and 2.00.a.

Which ethernet core are you using? Ethernet and ethernet lite cores are 
fully supported.

In any case it seems a configuration trouble. Check if you have configured 
every parameter into: Software Platform Setting -> OS and Libraries -> lwip 
tree (expand it)
You can compare all parameters into oslib_rm.pdf

If you environment varaible Xilinx_EDK is set to C:\EDK try changing it to 
C:\EDK\

Marco



Article: 99352
Subject: Re: Going from CLK1X to CLK2X.. really safe?
From: "radarman" <jshamlet@gmail.com>
Date: 23 Mar 2006 07:03:33 -0800
Links: << >>  << T >>  << A >>

Sylvain Munaut wrote:
> Morten Leikvoll wrote:
> > Got a DCM (spartan3),
> > CLK1X coming CLK90 pin, thru a BUFG (to get 90deg out of phase from the
> > incoming clk)
> > CLK2X coming from CLK2X180 pin, thru a BUFG (to get rising edge in phase
> > with CLK1X)
> >
> > How safe is it to sample a signal coming from the CLK1X domain, into the
> > CLK2X domain (and maybe back)?
> > Does this create a race condition or will this always be safe? (I know it
> > isnt when using modelsim, but when implementing?)
> > I have problems matching simulation result with real life.
>
> I did this recently and it worked fine for me, both in real life and in
> the simulation (note that in simulation, i generated the clock myself, I
> didn't simulate the DCM). I'm working on Virtex4 with ISE7.1 & 8.1
>
> When looking at the timing analyzing, I clearly see the path between 1x
> and 2x being analyzed, taking the skew and clock uncertainty into account.
>
> Note that I still tried to minimize the logic between the 1x reg and the
> 2x reg, basically I just have a mux so this part can run way faster than
> the 200 MHz I ask for ;) To be sure, you can add a maxdelay constraint
> in your vhdl file I think and constraint it to be < x% of your clock
> period for e.g. that should give you some margin.
>
>
>
> Sylvain

Maybe I've gotten overly conservative, but I always treat clock
boundaries as asynchronous, no matter how closely they may appear to
line up on a scope. For example, I worked on a board where the FPGA had
control of a off-chip digital signal generator, which produced the
clock for the 4th clock domain. (that clock also fed downstream A/D
converters, and the controls to the converters had to be synchronous to
that clock)

Even though the system requirements indicated that the logic should
only operate when the external PLL clock was locked to the primary
clock, and accuracy could be maintained to within +/-500 ps, I still
took all the usual precautions for clock boundaries.

Even if I were using to derivative clocks from the same oscillator, I
would *STILL* treat them as asynchronous - because they are. Don't
count on DCM's to make them "close enough".

There are plenty of tricks for crossing clock domains, but you need to
know the relative phase relationship of the clocks, the frequency
delta, and the latency tolerance of your application.


Article: 99353
Subject: help on RISC controller developed mikej
From: "sel" <selva991@gmail.com>
Date: 23 Mar 2006 07:36:57 -0800
Links: << >>  << T >>  << A >>
now i have the complete correct code ( i got that from open cores.org)
and i could pin point the errors im uploading the whole code
  fist let me tell the errors when i compiled the code
 1.in mux8 file im getting
 Warning: ELAB1_0026: mux8.vhd : (87, 0): There is no default binding
for component "lut4".(No entity named "lut4" was found).
Error: COMP96_0078: mux8.vhd : (84, 22): Unknown identifier
"mux8_lut4".
Error: COMP96_0133: mux8.vhd : (84, 22): Cannot find object
declaration.
Error: COMP96_0078: mux8.vhd : (83, 22): Unknown identifier
"mux8_lut3".
Error: COMP96_0133: mux8.vhd : (83, 22): Cannot find object
declaration.
Error: COMP96_0078: mux8.vhd : (82, 22): Unknown identifier
"mux8_lut2".
Error: COMP96_0133: mux8.vhd : (82, 22): Cannot find object
declaration.

2.in mux4 file im geting
Warning: ELAB1_0026: mux4.vhd : (75, 0): There is no default binding
for component "lut4".(No entity named "lut4" was found).
Error: COMP96_0078: mux4.vhd : (72, 22): Unknown identifier
"mux8_lut2".
Error: COMP96_0133: mux4.vhd : (72, 22): Cannot find object
declaration.
Compile Architecture "RTL" of Entity "MUX4"
Compile failure 2 Errors 1 Warnings  Analysis time :  0.1 [s]

3.in risc5x_xil as
warning: ELAB1_0026: risc5x_xil.vhd : (189, 0): There is no default
binding for component "ramb4_s2_s2".(No entity named "ramb4_s2_s2" was
found).

4.in add_sub
Warning: ELAB1_0026: add_sub.vhd : (76, 0): There is no default binding
for component "lut4".(No entity named "lut4" was found).
Warning: ELAB1_0026: add_sub.vhd : (90, 0): There is no default binding
for component "mult_and".(No entity named "mult_and" was found).
Warning: ELAB1_0026: add_sub.vhd : (97, 0): There is no default binding
for component "muxcy".(No entity named "muxcy" was found).
Warning: ELAB1_0026: add_sub.vhd : (105, 0): There is no default
binding for component "xorcy".(No entity named "xorcy" was found).
better the whole proram is here u ca run urself and u could debug the
errors
"  http://www.opencores.net/cvsweb.shtml/risc5x/"

pls pls pls pls reply


Article: 99354
Subject: Re: Those yellow markers .... (ISE8.1)
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 23 Mar 2006 10:41:48 -0500
Links: << >>  << T >>  << A >>
I wish this was my biggest problem with the ISE :) I would in fact trade
each problem I am having for an extra yellow marker.

/Mikhail


"Dave" <dave.garnett@metapurple.co.uk> wrote in message
news:1143044520_1225@sp6iad.superfeed.net...
> OK,
>
> I surrender ! Any idea how I can clear those yellow markers that result
from
> clicking on an error message, apart from saving and reopening ?
>
> Dave
>
>



Article: 99355
Subject: Re: Going from CLK1X to CLK2X.. really safe?
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 23 Mar 2006 07:41:59 -0800
Links: << >>  << T >>  << A >>
Hi - 

The original poster was concerned with Spartan 3, so this is slightly
OT, but does anyone have experience with the V4 phase-matched clock
dividers (PCMDs)?  Is is safe to transfer data between domains clocked
by two outputs of a PCMD without resorting to resynchronization?

Bob Perlman
Cambrian Design Works
  

Article: 99356
Subject: Re: for all those who believe in ASICs....
From: fpga_toys@yahoo.com
Date: 23 Mar 2006 07:54:35 -0800
Links: << >>  << T >>  << A >>
http://www.fpgajournal.com/articles_2006/20060321_bell.htm


Article: 99357
Subject: Re: Going from CLK1X to CLK2X.. really safe?
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 08:11:46 -0800
Links: << >>  << T >>  << A >>
Bob,

We designed the PMCD so that the outputs all all matched within tens of 
picoseconds across P-V-T.  From there, you get onto the BUFGs, and you 
end up with the usual +/-100ps rule for match between BUFgs.

Austin

Bob Perlman wrote:

> Hi - 
> 
> The original poster was concerned with Spartan 3, so this is slightly
> OT, but does anyone have experience with the V4 phase-matched clock
> dividers (PCMDs)?  Is is safe to transfer data between domains clocked
> by two outputs of a PCMD without resorting to resynchronization?
> 
> Bob Perlman
> Cambrian Design Works
>   

Article: 99358
Subject: Re: this JTAG thing is a joke
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 08:15:55 -0800
Links: << >>  << T >>  << A >>
Brannon,

The most common problem with JTAG is people expect it to work, without 
simulating the signal integrity of their implementation.

Bad choice.

Our Rosetta boards have ten devices per board, and ten boards (100 
devices).  They are arranged in a chain.

We simulated the single card, and the chain, and found we needed to 
buffer the clock, but everything else was fine.  The first card in the 
chain has a wide buffer, that splits out the clock, to drive the ones on 
that card, and nine more outputs, one for each additional card.

We do have to make sure we do not do something stupid, and mismatch the 
signal lines.

Simulate it first, and then your problems will go away.

Austin

Brannon wrote:

> This post is a bit of a flame, but seriously, JTAG has got to go. The
> signals are weak. The various drivers and controllers for it are weak.
> It causes nonstop headaches for hardware developers and FPGA developers
> alike. It's slow, hardly customizable, hard to use, ultra extremely
> fantastically flaky on every piece of FPGA hardware I've ever used
> (which includes at least a dozen vendors), and ancient technology.
> 
> Here is what I want:
> 
> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
> three or four. The 200KHz signal dies after eight or nine. This will
> require some strong signals with error correction, but, heck, if a
> basic ethernet layer can do it....
> 
> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
> both flaky and redundant. We need some nice protocols, maybe even
> packets with headers, etc.
> 
> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
> And put some standard, accessible plugs on there while you're at it.
> 
> 4. Standard driver interface. Need I say more? How many of you write
> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
> you all enjoy it too. How about something like this:
> 
> mycard = code to locate the right driver and device and open it....
> ioctl(mycard, HOW_MANY_DEVICES, &devices)
> id_struct = new ID_STRUCT[devices]
> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
> for each d in devices {
>   if( id_struct[d].devId == Virtex4Id ) {
>      targetlist = { d }
>      ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
>      command_struct.mode = programming
>      ioctl(mycard, SEND_COMMAND, &command_struct)
>      write(mycard, "c:\my programming file.bit")
>      ioctl(mycard, READ_STATUS, &status_struct)
>      if( status_struct.mode & programmed) break
>      else return failed
>   }
> }
> Then we go into a loop for reading and writing debug data, etc.
> 
> We could have drivers for a dozen different interfaces including
> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
> 
> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
> hat on the "platform" driver and make the thing useful for the parallel
> port as well.
> 
> Maybe I'm taking this too far. I just want something that works
> reliably and is not a pain in the ars to use programmatically. Is that
> too much to ask?
> 

Article: 99359
Subject: Re: XST takes unusually long
From: Ralf Hildebrandt <Ralf-Hildebrandt@gmx.de>
Date: Thu, 23 Mar 2006 17:18:10 +0100
Links: << >>  << T >>  << A >>
dotnetters@gmail.com wrote:


> We're working with a Xilinx Virtex II Pro board. As a part of our
> project, we had to write a hardware stack. After having made it work,
> we thought of optimizing the design and hence removed a few states and
> reduced the no. of states from 8 to 4. The older code was getting
> synthesized in around 20 mins, but the new code takes hours together to
> get synthesized, and so does the PAR.

But it finally gets synthesized?

Break your design into smaller components, synthesize them alone. Try to 
locate the real source for that problem.

Ralf

Article: 99360
Subject: Re: Lattice FPGA
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 08:19:59 -0800
Links: << >>  << T >>  << A >>
Looks nice, but...

If you could only get them (ST2GX or SC).

At least we have shipped all our backlog on xc4vFX devices.

Austin

John_H wrote:

> maxascent wrote:
> 
>> Hi
>>
>> I was hoping to get some opinions on Lattice FPGAs compared to Xilinx and
>> Altera. I see they have a SC device out. How does this compare to similar
>> devices from the other two?
>>
>> Cheers
>>
>> Jon
> 
> 
> The SC series is brand new so you might not find anyone with a socket on 
> their board just yet.  It *looks* like a nice family.  3+ Gbit 
> transsceivers.  90 nm.  Many 18kb mems.  Oh - no "DSP" units in the SC 
> family if I recall correctly - they put those in the "volume" parts 
> instead: the ECP2 family.  I like what I see.
> 
> If you have high volume needs and want some hard IP on your board, you 
> can get their MACO blocks wired up as a teeny asic in your FPGA.

Article: 99361
Subject: Re: OpenSPARC released
From: "J o h n _ E a t o n (at) hp . com (no spaces)" <"J o h n _ E a t o n (at) hp . com (no spaces)">
Date: Thu, 23 Mar 2006 08:29:11 -0800
Links: << >>  << T >>  << A >>
Michael wrote:
> Weng Tianxiang wrote:
> 
>>Hi Pablo,
>>Thank you for your useful information.
>>
>>Weng
> 
> 
> The problem is "System Requirements": "SPARC CPU based system"
> 

Is that for the software development environment?. Seems like the
verilog rtl code should be pretty generic. From the description it
sounds more like a big compute farm engine rather than something
you would put in a fpga for an embedded system.



John Eaton

Article: 99362
Subject: Re: ACE Formatter for Linux (was Re: Parallel Cable IV...)
From: Duane Clark <junkmail@junkmail.com>
Date: Thu, 23 Mar 2006 16:30:57 GMT
Links: << >>  << T >>  << A >>
Stephen Williams wrote:
> Andreas Ehliar wrote:
>> To be honest, at this point I prefer to use XC3SProg
>> http://www.rogerstech.force9.co.uk/xc3sprog/index.html
>> in Linux. Sure, it is rather slow since it uses the parallel cable IV
>> in cable III mode, but it feels much more stable in Linux than impact does.
>>
> 
> What I would really like something that can write Xilinx .ACE files.
> The impact from Foundation 6.2 is terribly slow, and from Webpack8.1
> is pretty flakey. (It wrote ace files everywhere but where I wanted
> them.)
> 

I'll agree that the interface is not particularly intuitive, but the 
main limitation I see is that the ace files must always be placed two 
directories deep. I've used Impact from ISE7.1 on Linux regularly, and 
had no problems at all. I haven't used the 8.1 version much, but a quick 
test seems to indicate that it works the same.

Arrgg... I just noticed that the ipf project files have switched from 
plain text in version 7.1 to binary in version 8.1.

Hey Xilinx, please take a poll of your paying customers. We don't want 
binary project files!

Article: 99363
Subject: Re: Are Quad-processors advantageous?
From: Bob Myers <rjmyers@raytheon.com>
Date: Thu, 23 Mar 2006 10:43:28 -0600
Links: << >>  << T >>  << A >>
Look at the -m option for par.  The 7.x documentation states that it
is not available under windows, so it may be of use when running
under Sun Solaris and Linux(? not sure about Linux; check with your
local Xilinx FAE and/or their hotline support).

-bob

p.s.  as side note:  there are two versions of this -- MPPR (multi-pass
place and route) and MNPR (multi-nodal place and route).  I believe
the latter was "inherited" when Xilinx absorbed NeoCad a number of
years ago.

fpga_toys@yahoo.com wrote:

> Ron wrote:
> > I was considering purchasing an AMD64 quad-processor system, but have no
> > idea whether any of the FPGA development tool software would take
> > advantage of multi-processors (Synplicity for Lattice, Actel, Xilinx,
> > etc). Any ideas or recommendations?
>
> the primary cpu bound process for Xilinx, par, can be run in a
> multiprocessor and cluster configuration for converging the best
> routing solution sooner. Do a serch for MPPR in your par documentation
> or the Xilinx answer base. At least on older ISE 6.x releases under
> linux this is VERY useful.


Article: 99364
Subject: Changes on xapp765 for ISE/EDK7.1 and 8.1?
From: "Jorge" <jeparra@gmail.com>
Date: 23 Mar 2006 08:56:37 -0800
Links: << >>  << T >>  << A >>
Hello everyone!

Any one knows if there are any (even minor) changes that have to be
done to xapp765 to make it suitable to be used with ISE/EDK 7.1 and
8.1?

Thank you!!!!!

Jorge


Article: 99365
Subject: Re: XST takes unusually long
From: dotnetters@gmail.com
Date: 23 Mar 2006 09:03:43 -0800
Links: << >>  << T >>  << A >>
Ralf,
First of all, thanks a lot.

yeah, it finall does get synthesized. But the time differnce is too
large.

And how do I synthesize the components seperately and then finally
"merger" them together? We work in XPS. Is it possible to do it in XPS
itself directly?

Thanks once again.

-- DotNetters


Article: 99366
Subject: Re: this JTAG thing is a joke
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 23 Mar 2006 17:07:31 -0000
Links: << >>  << T >>  << A >>
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message 
news:48fmbiFhpnieU1@individual.net...
> Symon schrieb:
>
>
> HMMMM??? SOURCE-Termination for a multidrop CLOCK signal? It may work, but 
> more due to murphys law than by design .  . .
>
Falk,
I thought Murphy's Law describes why things _don't_ work, not why they _do_ 
work?! :-) The reason you often get some improvement is that the connections 
at the destination end are close together and, particularly for big BGAs 
like FPGAs, are at the end of stubs. The source is far away at the end of a 
cable.
>
> AC-termination at the end of a clock line is most probably the better way 
> to go. And don't forget, those parallel port often enough spit out really 
> ugly signals. So a buffer for the clock line with a schmitt trigger input 
> and a RC-filter in front pays off.
>
> Regards
> Falk
>
Of course, but that's a fat lot of help when you're stuck with a board which 
wasn't designed by someone like you who thought about the SI! The bodge I 
suggested, together with a bit of simulation experimentation,  might just 
get a board going un-modded.
Cheers, Syms. 



Article: 99367
Subject: Number of taps for a FIR
From: "Roger Bourne" <rover8898@hotmail.com>
Date: 23 Mar 2006 09:48:21 -0800
Links: << >>  << T >>  << A >>
Hello all,

I am planning to introduce a decimation filter in my FPGA design in
order to reduce the sample frequency by 8. This has resulted in a 61
tap FIR filter. -It seems awfully large. Basically, I am asking , for
an FPGA implementation, what is a REASONNABLE number of taps for a FIR
filter?

(I am planning to again filter the decimation filter's output with a
cascaded structure of 4 2nd order IIR filters. In my opinion it is that
cascaded structure which is doing the REAL filtering and it happens to
be smaller and more potent. It seems a shame to ruin the compactness of
the filter modules with a huge decimation filter. P.S I have yet to
implement anything; I am just doing the planning of the required
modules for the moment so I may be completly off base in my previous
statement)

-Roger



(Filter parameters, in case they are of interest  :
Normalized Passband=0.015
Normalized StopBAnd=0.062
60dB stopband attenuation
0.1dB passband ripple
Sample frequency=1MHz
10 bits or 16 bits databus, don't know yet


Article: 99368
Subject: Re: OpenSPARC released
From: Jason Zheng <jxzheng@gmail.com>
Date: Thu, 23 Mar 2006 09:53:02 -0800
Links: << >>  << T >>  << A >>
J o h n _ E a t o n (at) hp . com (no spaces) wrote:
> Michael wrote:
> 
>> Weng Tianxiang wrote:
>>
>>> Hi Pablo,
>>> Thank you for your useful information.
>>>
>>> Weng
>>
>>
>>
>> The problem is "System Requirements": "SPARC CPU based system"
>>
> 
> Is that for the software development environment?. Seems like the
> verilog rtl code should be pretty generic. From the description it
> sounds more like a big compute farm engine rather than something
> you would put in a fpga for an embedded system.
> 
> 
> 
> John Eaton

Why not? This would be a great teaching tool for fpga design and/or 
computer system design courses at college level.

~jz

Article: 99369
Subject: Re: this JTAG thing is a joke
From: Falk Brunner <Falk.Brunner@gmx.de>
Date: Thu, 23 Mar 2006 18:53:35 +0100
Links: << >>  << T >>  << A >>
Symon schrieb:

> Falk,
> I thought Murphy's Law describes why things _don't_ work, not why they _do_ 
> work?! :-) The reason you often get some improvement is that the connections 

Theory: Nothing works but everone knows why.
Practice: Everything works but nobody knows why.
Theory + Practice : Nothing works and nobody knows why.

;-)

> at the destination end are close together and, particularly for big BGAs 
> like FPGAs, are at the end of stubs. The source is far away at the end of a 
> cable.

Si.

> Of course, but that's a fat lot of help when you're stuck with a board which 
> wasn't designed by someone like you who thought about the SI! The bodge I 
> suggested, together with a bit of simulation experimentation,  might just 
> get a board going un-modded.

Ok, for a work around this might be a way to go (If all you got is a 
hammer, everything looks like a nail). But the original 
complaint/cry/whatever was about a implementation of JTAG from scratch.

Regards
Falk

P.S. One of the problems with JTAG is/was, that people underestimate 
problems due to the low frequencies involved. And as far as I remember, 
the are/were some nasty problems with FPGAs for brand . . . because the 
JTAG inputs (especially the clock) was sensitive to non-perfect 
transitions, which means you have to treat the almost DC like JTAG like 
a GBit transmission line. Not nice at all. The suggestion of Austin to 
do a simulation is in general right, but sounds a little bit strange to 
me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition 
time that matters, not frequency). So why is the JTAG (clock) not 
INTENTINALLY made slower (+ schmitt trigger) to avoid this problems? 
Nobody needs a 100MHz++ capable JTAG port (today).

Article: 99370
Subject: Re: this JTAG thing is a joke
From: Austin Lesea <austin@xilinx.com>
Date: Thu, 23 Mar 2006 09:54:24 -0800
Links: << >>  << T >>  << A >>
One more thing,

We also AC terminate at the endpoints of TMS and TCK.

This was also shown to be necessary in the simulations.

But don't just assume this is the "solution", you must simulate your 
pcb, and decide what to do.

Austin

Austin Lesea wrote:

> Brannon,
> 
> The most common problem with JTAG is people expect it to work, without 
> simulating the signal integrity of their implementation.
> 
> Bad choice.
> 
> Our Rosetta boards have ten devices per board, and ten boards (100 
> devices).  They are arranged in a chain.
> 
> We simulated the single card, and the chain, and found we needed to 
> buffer the clock, but everything else was fine.  The first card in the 
> chain has a wide buffer, that splits out the clock, to drive the ones on 
> that card, and nine more outputs, one for each additional card.
> 
> We do have to make sure we do not do something stupid, and mismatch the 
> signal lines.
> 
> Simulate it first, and then your problems will go away.
> 
> Austin
> 
> Brannon wrote:
> 
>> This post is a bit of a flame, but seriously, JTAG has got to go. The
>> signals are weak. The various drivers and controllers for it are weak.
>> It causes nonstop headaches for hardware developers and FPGA developers
>> alike. It's slow, hardly customizable, hard to use, ultra extremely
>> fantastically flaky on every piece of FPGA hardware I've ever used
>> (which includes at least a dozen vendors), and ancient technology.
>>
>> Here is what I want:
>>
>> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
>> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
>> three or four. The 200KHz signal dies after eight or nine. This will
>> require some strong signals with error correction, but, heck, if a
>> basic ethernet layer can do it....
>>
>> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
>> both flaky and redundant. We need some nice protocols, maybe even
>> packets with headers, etc.
>>
>> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
>> And put some standard, accessible plugs on there while you're at it.
>>
>> 4. Standard driver interface. Need I say more? How many of you write
>> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
>> you all enjoy it too. How about something like this:
>>
>> mycard = code to locate the right driver and device and open it....
>> ioctl(mycard, HOW_MANY_DEVICES, &devices)
>> id_struct = new ID_STRUCT[devices]
>> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
>> for each d in devices {
>>   if( id_struct[d].devId == Virtex4Id ) {
>>      targetlist = { d }
>>      ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
>>      command_struct.mode = programming
>>      ioctl(mycard, SEND_COMMAND, &command_struct)
>>      write(mycard, "c:\my programming file.bit")
>>      ioctl(mycard, READ_STATUS, &status_struct)
>>      if( status_struct.mode & programmed) break
>>      else return failed
>>   }
>> }
>> Then we go into a loop for reading and writing debug data, etc.
>>
>> We could have drivers for a dozen different interfaces including
>> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
>>
>> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
>> hat on the "platform" driver and make the thing useful for the parallel
>> port as well.
>>
>> Maybe I'm taking this too far. I just want something that works
>> reliably and is not a pain in the ars to use programmatically. Is that
>> too much to ask?
>>

Article: 99371
Subject: Re: Number of taps for a FIR
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 23 Mar 2006 17:54:54 -0000
Links: << >>  << T >>  << A >>
"Roger Bourne" <rover8898@hotmail.com> wrote in message 
news:1143136101.823610.180860@u72g2000cwu.googlegroups.com...
> Hello all,
>
> I am planning to introduce a decimation filter in my FPGA design in
> order to reduce the sample frequency by 8. This has resulted in a 61
> tap FIR filter. -It seems awfully large. Basically, I am asking , for
> an FPGA implementation, what is a REASONNABLE number of taps for a FIR
> filter?
>
Roger,
Look at making your filter as a series of half-band FIR filters. These are 
efficient in that every other tap is zero. (Nice and easy to multiply by 
zero!) Use three, decimating by two at each stage. Your implementation 
should be a lot more compact. The later stages will probably have more taps, 
but the sample rate will be reduced, possibly allowing you to use 
distributed arithmetic.
Cheers, Syms. 



Article: 99372
Subject: Re: Number of taps for a FIR
From: "Symon" <symon_brewer@hotmail.com>
Date: Thu, 23 Mar 2006 18:02:10 -0000
Links: << >>  << T >>  << A >>

"Symon" <symon_brewer@hotmail.com> wrote in message 
news:4422e0f2$0$15787$14726298@news.sunsite.dk...
> "Roger Bourne" <rover8898@hotmail.com> wrote in message 
> news:1143136101.823610.180860@u72g2000cwu.googlegroups.com...
>> Hello all,
>>
>> I am planning to introduce a decimation filter in my FPGA design in
>> order to reduce the sample frequency by 8. This has resulted in a 61
>> tap FIR filter. -It seems awfully large. Basically, I am asking , for
>> an FPGA implementation, what is a REASONNABLE number of taps for a FIR
>> filter?
>>
> Roger,
> Look at making your filter as a series of half-band FIR filters. These are 
> efficient in that every other tap is zero. (Nice and easy to multiply by 
> zero!) Use three, decimating by two at each stage. Your implementation 
> should be a lot more compact. The later stages will probably have more 
> taps, but the sample rate will be reduced, possibly allowing you to use 
> distributed arithmetic.
> Cheers, Syms.
>
Also, check out CIC (cascaded integrator comb) filters? Although 8 may not 
be a high enough decimation factor to make this method worthwhile.
Cheers, Syms 



Article: 99373
Subject: Re: Lattice FPGA
From: "Antti" <Antti.Lukats@xilant.com>
Date: 23 Mar 2006 10:02:53 -0800
Links: << >>  << T >>  << A >>
wau! does it mean all FX MGT issues are solved !?

that would be good news !!

Antti


Article: 99374
Subject: Re: this JTAG thing is a joke
From: "dp" <dp@tgi-sci.com>
Date: 23 Mar 2006 10:03:16 -0800
Links: << >>  << T >>  << A >>
> Nobody needs a 100MHz++ capable JTAG port (today).

I could use one... When driving the address and data lines of
a processor in order to program a flash memory (because the
data on how to do this using the processor internal utilities for
that are secret or the processor has none), this can make some
reasonable difference in programming times (mainly during prototype
testing/bringing up, during production you typically can program
some tiny initial boot flash code which will do the rest).
But well, I do not argue I could not live without it, it would
just be nice to have it.

Dimiter

------------------------------------------------------
Dimiter Popoff               Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------


Falk Brunner wrote:
> Symon schrieb:
>
> > Falk,
> > I thought Murphy's Law describes why things _don't_ work, not why they _do_
> > work?! :-) The reason you often get some improvement is that the connections
>
> Theory: Nothing works but everone knows why.
> Practice: Everything works but nobody knows why.
> Theory + Practice : Nothing works and nobody knows why.
>
> ;-)
>
> > at the destination end are close together and, particularly for big BGAs
> > like FPGAs, are at the end of stubs. The source is far away at the end of a
> > cable.
>
> Si.
>
> > Of course, but that's a fat lot of help when you're stuck with a board which
> > wasn't designed by someone like you who thought about the SI! The bodge I
> > suggested, together with a bit of simulation experimentation,  might just
> > get a board going un-modded.
>
> Ok, for a work around this might be a way to go (If all you got is a
> hammer, everything looks like a nail). But the original
> complaint/cry/whatever was about a implementation of JTAG from scratch.
>
> Regards
> Falk
>
> P.S. One of the problems with JTAG is/was, that people underestimate
> problems due to the low frequencies involved. And as far as I remember,
> the are/were some nasty problems with FPGAs for brand . . . because the
> JTAG inputs (especially the clock) was sensitive to non-perfect
> transitions, which means you have to treat the almost DC like JTAG like
> a GBit transmission line. Not nice at all. The suggestion of Austin to
> do a simulation is in general right, but sounds a little bit strange to
> me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition
> time that matters, not frequency). So why is the JTAG (clock) not
> INTENTINALLY made slower (+ schmitt trigger) to avoid this problems?
> Nobody needs a 100MHz++ capable JTAG port (today).




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