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 117325

Article: 117325
Subject: Re: Minimal pins for JTAG configuration
From: jidan1@hotmail.com
Date: 28 Mar 2007 09:15:47 -0700
Links: << >>  << T >>  << A >>
On 27 Mrz., 17:41, Austin Lesea <aus...@xilinx.com> wrote:
> JJ,
>
> If the part is connected properly, you will see the proper signal on INIT_B.
>
> INIT_B will go high while the devices cleans out, and gets ready to try
> to configure, and then it will go low when cleanout is done before it
> starts to configure.  If there is no configuration device present, then
> this sequence of INIT_B lets you know that the device is ready and waiting.
>
> Also, if a master mode is selected, the CCLK pin should be running.
>
> See page 56 of 280:
>
> http://direct.xilinx.com/bvdocs/userguides/ug332.pdf
>
> Austin

Thank you Austin for your help. I finally got to program the FPGA. The
problem was on the programmer I used: Xilinx Parallel Cable 3. The
strange problem with this cable has haunted me since I built it. I
described the problem here:
http://groups.google.at/group/comp.arch.fpga/browse_thread/thread/931f54aee8faca51/6a97e6e07f67e1b4?hl=de#6a97e6e07f67e1b4

JJ


Article: 117326
Subject: Re: Problems with Xilinx Parallel III Cable
From: "zcsizmadia@gmail.com" <zcsizmadia@gmail.com>
Date: 28 Mar 2007 09:25:27 -0700
Links: << >>  << T >>  << A >>
On Mar 28, 11:12 am, jid...@hotmail.com wrote:
> Hi,
>
> To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3
> XCS400) at the same time, I decided as a programmer to use the Xilinx
> Parallel Cable III. I implemented the programmer 100% the same as
> found in Xilinx's website (http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html).
> The programmer worked, but not without problems. For programming the
> Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable
> from the LPT port to Programmer was 20cm long and from the programmer
> to the uC/FPGA board was not more than 10 cm.
> The problem related with this programmer were verification errors, i.e
> the PC can't program or read properly from the board. The interesting
> thing is how these verification problem came up.
> In the morning when I turn the PC and Board on, these verification
> errors are a lot. When the code that I want to download is big, its
> impossible to program the FPGA/uC, for small codes it works but after
> many tries. After 10 tries or so, the programming works  correct and
> no verification errors no matter how many times I try to download the
> code or how big the code is, and this without even touching a thing on
> the hardware!!!
>
> Since this problem applies to more than one board, I assume the
> problem must lay on the programmer itself. My explanation is that
> maybe the buffer IC's get hot or something...I really don't know.
> I want to know if there is anyone who has had problems with this
> programmer cable.
>
> Thank You,
> JJ

I'm doing exactly the same, but I'm using the Digilent Parallel JTAG3
cable ($12 http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Cables&Cat=Cable)
Impact 6.3 to program my Spartan3-1000, and avrdude to program my
ATmega64.
I had problems in the past when I had some noisy power supplies in the
lab and got mysterious errors, sometimes I had to turn off the noisy
power supply to make my JTAG work :)

Zoltan


Article: 117327
Subject: Re: Where is Open Source for FPGA development?
From: "Daniel S." <digitalmastrmind_no_spam@hotmail.com>
Date: Wed, 28 Mar 2007 12:35:13 -0400
Links: << >>  << T >>  << A >>
Martin Thompson wrote:
> "Daniel S." <digitalmastrmind_no_spam@hotmail.com> writes:
> 
>> Until my larger designs are sufficiently advanced to start producing
>> meaningful simulation results (I call this the approximation phase), I
>> am more interested in tracking resource utilization and static timing
>> evolution than correctness: achieving absolute correctness in the
>> first pass (the one most susceptible to typos and syntax errors) is
>> useless if the implementation fails to meet target timings or exceeds
>> the logic budget. It is during these passes that XST&all die on me the
>> most and Modelsim as a simulation tool is irrelevant - that's why it
>> took me so long to think of using it as a syntax checker.
> 
> But if you make a trivial error in your design, won't the optimiser
> chuck lots of stuff out and make it look much better than it is?
> You'll never know until you simulate...

When the optimizer chucks out lots of stuff, it usually spits out 
truckloads of warnings about unconnected signals being trimmed, never 
changing ("replaced by logic") or equivalent to some other net. Some of 
these trimmed signals are expected (is there a simple and inexpensive way 
to quietly drop multiplier LSBs when doing fixed-point maths?) but the rest 
are good indicators of missing stuff.

Since I do not wish to spend much time on control logic during the 
approximation phase, I simply connect the N control signals to an N-bits 
PRNG with a few IOBs blended in to prevent synthesis from simplifying the 
dummy control logic and everything else thereafter. Once the 
data/processing pipeline is in place and looks good, I can start 
implementing and optimizing the real control logic using simulations - I 
usually try to save as much of the control logic as possible for last since 
relatively minor data path refinements can have a major impact on the 
control logic and optimization opportunities... I am lazy so I try to avoid 
moving targets whenever possible.

Article: 117328
Subject: Re: Minimal pins for JTAG configuration
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 28 Mar 2007 09:42:08 -0700
Links: << >>  << T >>  << A >>
JJ,

Sounds like you have a signal integrity problem with the cable and the
interface.

I suggest using Hyperlynx from Mentor to troubleshoot, or read up on SI.

http://www.xilinx.com/products/design_resources/signal_integrity/


Austin

Article: 117329
Subject: Re: Problems with Xilinx Parallel III Cable
From: jidan1@hotmail.com
Date: 28 Mar 2007 09:47:29 -0700
Links: << >>  << T >>  << A >>
On 28 Mrz., 18:25, "zcsizma...@gmail.com" <zcsizma...@gmail.com>
wrote:
> On Mar 28, 11:12 am, jid...@hotmail.com wrote:
>
>
>
> > Hi,
>
> > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3
> > XCS400) at the same time, I decided as a programmer to use the Xilinx
> > Parallel Cable III. I implemented the programmer 100% the same as
> > found in Xilinx's website (http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html).
> > The programmer worked, but not without problems. For programming the
> > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable
> > from the LPT port to Programmer was 20cm long and from the programmer
> > to the uC/FPGA board was not more than 10 cm.
> > The problem related with this programmer were verification errors, i.e
> > the PC can't program or read properly from the board. The interesting
> > thing is how these verification problem came up.
> > In the morning when I turn the PC and Board on, these verification
> > errors are a lot. When the code that I want to download is big, its
> > impossible to program the FPGA/uC, for small codes it works but after
> > many tries. After 10 tries or so, the programming works  correct and
> > no verification errors no matter how many times I try to download the
> > code or how big the code is, and this without even touching a thing on
> > the hardware!!!
>
> > Since this problem applies to more than one board, I assume the
> > problem must lay on the programmer itself. My explanation is that
> > maybe the buffer IC's get hot or something...I really don't know.
> > I want to know if there is anyone who has had problems with this
> > programmer cable.
>
> > Thank You,
> > JJ
>
> I'm doing exactly the same, but I'm using the Digilent Parallel JTAG3
> cable ($12http://www.digilentinc.com/Products/Catalog.cfm?Nav1=Products&Nav2=Ca...)
> Impact 6.3 to program my Spartan3-1000, and avrdude to program my
> ATmega64.
> I had problems in the past when I had some noisy power supplies in the
> lab and got mysterious errors, sometimes I had to turn off the noisy
> power supply to make my JTAG work :)
>
> Zoltan

Glad to hear that I am not the only one who has a problem with this
programmer!! I thought at the beginning also it has to be some kind of
interference from somewhere, but as I said, I usually change nothing,
just click many times until it works, and when it does, it works
without any problems for hours.But before i reach this phase, it
really gives me headach :(

JJ

JJ


Article: 117330
Subject: Re: Problems with Xilinx Parallel III Cable
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 28 Mar 2007 09:55:50 -0700
Links: << >>  << T >>  << A >>
<jidan1@hotmail.com> wrote in message 
news:1175098335.158323.203250@n59g2000hsh.googlegroups.com...
> Hi,
>
> To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3
> XCS400) at the same time, I decided as a programmer to use the Xilinx
> Parallel Cable III. I implemented the programmer 100% the same as
> found in Xilinx's website (
> http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html).
> The programmer worked, but not without problems. For programming the
> Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable
> from the LPT port to Programmer was 20cm long and from the programmer
> to the uC/FPGA board was not more than 10 cm.
> The problem related with this programmer were verification errors, i.e
> the PC can't program or read properly from the board. The interesting
> thing is how these verification problem came up.
> In the morning when I turn the PC and Board on, these verification
> errors are a lot. When the code that I want to download is big, its
> impossible to program the FPGA/uC, for small codes it works but after
> many tries. After 10 tries or so, the programming works  correct and
> no verification errors no matter how many times I try to download the
> code or how big the code is, and this without even touching a thing on
> the hardware!!!
>
> Since this problem applies to more than one board, I assume the
> problem must lay on the programmer itself. My explanation is that
> maybe the buffer IC's get hot or something...I really don't know.
> I want to know if there is anyone who has had problems with this
> programmer cable.
>
>
> Thank You,
> JJ

The newer Xilinx programming cables (Parallel Cable IV, Platform Cable USB) 
use comparators rather than simple buffers to establish proper voltage 
levels from the VREF pin connected to the programmer and VCC supplied 
eternally (keyboard passthrough or USB).  The VCC supplied to the Parallel 
Cable III powers the buffers; the result is poor signal levels on low 
voltage interfaces.

I had a 2.5V JTAG interface I could not get working when using the Parallel 
Cable III powered by 2.5V.  Just by increasing the VCC to 3.3V, I was able 
to keep decent logic levels and get the interface working.  But I never 
trusted it; if I got a good result I was happy.  The convenience and 
(decent) reliability of the Platform Cable USB is well worth the price in my 
mind.

- John_H 



Article: 117331
Subject: Need help with sequential fault simulation in Tetramax!!!
From: "spectrallypure" <jorgelagos@gmail.com>
Date: 28 Mar 2007 10:10:34 -0700
Links: << >>  << T >>  << A >>
Hi all. I am experiencing a very annoying problem while trying to run
a sequential fault simulation with Tetramax, using external patterns
saved (via a VCD dump) from a back-annotated simulation done in
ModelSim. The problem is that when I load the VCD dump file in
Tetramax and simulate it, the tool produces wrong simulation results,
exhibiting an akward behavior. The  caption in the following link
explains the whole situation:
h**p://images.elektroda.net/37_1175093373.jpg

****[Upper part of image: Modelsim 5.8b simulation - Results: OK, as
expected]****
Notice the timing of the clocks PAD_EMTCK and PAD_CLK. At the
beginning they have periods of 40 and 20 ns, respectively. Then, @
27,240ns, signal PAD_SCAN_EN goes up and PAD_CLK assumes also a 40 ns
period (the other clock remains unaffected). Notice also the 40ns-wide
pulses appearing on signals PAD_SCAN_IN1...3.

****[Lower part of image: Tetramax Z-2007.03 simulation - Results:
WRONG]****
This is Tetramax's simulation as obtained through the reading of
modelsim's vcd dump through the following command:"set patterns
external my_dump.vcd -sensitive -strobe period 40 ns -strobe offset 37
ns" (note that this command implies the sampling of the test patterns
at periodic intervals of 40ns, with a suitable offset of 37ns that
should allow for an appropriate sampling of stable values in all
waveforms).
Notice now the awful part: at the beginning Tetramax seems to get it
right, and defines the test patterns at regular intervals 40ns apart.
But then misfortune happens: after the edge of PAD_SCAN_EN, Tetramax
incredibily does two wrong things:
1. Contrary of what was specified in the "set patterns" command, it
starts to sample the test patterns EVERY 20ns!!!!
2. It starts mis-simulating everything: the periods of both clocks
switch to 20ns, the pulses appearing in PAD_SCAN_IN1...3 are 20ns-
wide ,etc.

Therefore, since the dumped file is not appropiately simulated by
Tetramax, I cannot perform the desired fault simulation, which I
desperately need.
I would be the most grateful if anybody could please give a clue to
what is going wrong here. Why doesn't Tmax respect the 40ns-period
samping? Am I missing something in the "set patterns" command? I have
struggled for 2 weeks with this problem without success. I have even
tried using other versions of Tmax, and also giving different values
to the "offset" parameter, without any luck. I have also verified the
vcd dump file's correctness with a third tool, with positive results.
Any suggestions are really, really welcome!!!

Thanks in advance!!!
Regards, JL.


Article: 117332
Subject: Re: Problems with Xilinx Parallel III Cable
From: jidan1@hotmail.com
Date: 28 Mar 2007 10:47:26 -0700
Links: << >>  << T >>  << A >>
On 28 Mrz., 18:55, "John_H" <newsgr...@johnhandwork.com> wrote:
> <jid...@hotmail.com> wrote in message
>
> news:1175098335.158323.203250@n59g2000hsh.googlegroups.com...
>
>
>
> > Hi,
>
> > To program my Atmel(ATmega128L) controller and Xilinx FPGA (sparta-3
> > XCS400) at the same time, I decided as a programmer to use the Xilinx
> > Parallel Cable III. I implemented the programmer 100% the same as
> > found in Xilinx's website (
> >http://toolbox.xilinx.com/docsan/xilinx4/data/docs/pac/appendixb.html).
> > The programmer worked, but not without problems. For programming the
> > Atmel uC I used AVRdude, and for the FPGA, ISE9.1i. The ribbon-cable
> > from the LPT port to Programmer was 20cm long and from the programmer
> > to the uC/FPGA board was not more than 10 cm.
> > The problem related with this programmer were verification errors, i.e
> > the PC can't program or read properly from the board. The interesting
> > thing is how these verification problem came up.
> > In the morning when I turn the PC and Board on, these verification
> > errors are a lot. When the code that I want to download is big, its
> > impossible to program the FPGA/uC, for small codes it works but after
> > many tries. After 10 tries or so, the programming works  correct and
> > no verification errors no matter how many times I try to download the
> > code or how big the code is, and this without even touching a thing on
> > the hardware!!!
>
> > Since this problem applies to more than one board, I assume the
> > problem must lay on the programmer itself. My explanation is that
> > maybe the buffer IC's get hot or something...I really don't know.
> > I want to know if there is anyone who has had problems with this
> > programmer cable.
>
> > Thank You,
> > JJ
>
> The newer Xilinx programming cables (Parallel Cable IV, Platform Cable USB)
> use comparators rather than simple buffers to establish proper voltage
> levels from the VREF pin connected to the programmer and VCC supplied
> eternally (keyboard passthrough or USB).  The VCC supplied to the Parallel
> Cable III powers the buffers; the result is poor signal levels on low
> voltage interfaces.
>
> I had a 2.5V JTAG interface I could not get working when using the Parallel
> Cable III powered by 2.5V.  Just by increasing the VCC to 3.3V, I was able
> to keep decent logic levels and get the interface working.  But I never
> trusted it; if I got a good result I was happy.  The convenience and
> (decent) reliability of the Platform Cable USB is well worth the price in my
> mind.
>
> - John_H

I used 3.3V JTAG interface since the beginning, and also since the
beginning I had problems with it. I think part of the problem might be
in the buffer itself. The input voltage at the buffer(74HC125) used
there, according to the data sheet, should be max. VCC+1.5. And if you
are using VCC=3.3V or 2.5V, the high level voltage coming from the
LPT(5V) will be exceeding the max. input voltage. A series resistor
was used to limit the current going through the clamp didoe, however
the signal might have got distorted because of that.I have also
thought about using Schmitt-triggers instead of buffers. At the end I
built the exact circuit posted in xilinx website, because I thought
the Xilinx team knows better than me. But that circuit has caused me a
lot of problems and it seems I am not the only one!

JJ


Article: 117333
Subject: Re: Post PAR simulation for RAM Block implementations
From: "Duth" <premduth@gmail.com>
Date: 28 Mar 2007 11:34:48 -0700
Links: << >>  << T >>  << A >>
On Mar 26, 10:54 pm, "veeresh" <veeresh8...@yahoo.co.in> wrote:
> Hello Sir,
>
>        I'm trying to simulate a design involving Block RAM implemented
> using core generator.
> Please consider the example "Dual Port Block RAM v6.1" at
Hi Vereesh,

The problem you are running into is because the version of the MXE
libraries are not matching with your ISE version. Please ensure that
the two match. Ideally you want to use ISE 7.1i SP3 and the MXE
libraries for SP3  and the IPUpdate and then try this again. It will
work correctly.

Also note that when you download the libraries it says that the files
have to be installed in order. What this means is that always download
the latest library for that ISE version based on the time stamp on the
download page.

Thanks
Duth


>  http://www.xilinx.com/support/software/coregen/71i_coregen_examples.htm
>
> I generated an empty test bench for this design. I'm able to do PARSimulationon virtex 2. When I tried same on virtex 4, Modelsim XE
> simulator is giving error message saying two generics"en_ecc_read",
> and "en_ecc_write" are not defined.
>
> My tool set is:
> Tool : ISE 7.1
> Simulator : Modelsim XE III/Starter 6.0a
>
> Can you please help me to find the reason?
>
> Thanks and Regards,
> Veeresh



Article: 117334
Subject: Re: Problems with Xilinx Parallel III Cable
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 28 Mar 2007 19:16:48 GMT
Links: << >>  << T >>  << A >>
jidan1@hotmail.com wrote:
> 
> I used 3.3V JTAG interface since the beginning, and also since the
> beginning I had problems with it. I think part of the problem might be
> in the buffer itself. The input voltage at the buffer(74HC125) used
> there, according to the data sheet, should be max. VCC+1.5. And if you
> are using VCC=3.3V or 2.5V, the high level voltage coming from the
> LPT(5V) will be exceeding the max. input voltage. A series resistor
> was used to limit the current going through the clamp didoe, however
> the signal might have got distorted because of that.I have also
> thought about using Schmitt-triggers instead of buffers. At the end I
> built the exact circuit posted in xilinx website, because I thought
> the Xilinx team knows better than me. But that circuit has caused me a
> lot of problems and it seems I am not the only one!

I've always stuck two (because they are inverting) 74HCT14 Schmidt 
triggers in there, and have no problems with long parallel cables on a 
number of different boards and computers.

Article: 117335
Subject: suggestion for choosing the right FPGA for gigabit transciever
From: "vasile" <piclist9@gmail.com>
Date: 28 Mar 2007 12:33:54 -0700
Links: << >>  << T >>  << A >>
Hi,

I need to chose between the Altera Stratix II GX or Stratix III GX and
some Xilinx Virtex5 FPGA for an implementation of gigabit interface
into a multi DSP system.

Could you suggest pro and cons between Altera and Xilinx (or maybe
others) for such design ?
If I'm trying to compare Altera with Xilinx FPGA based on those
websites, both are telling is better than the other.
Maybe you know and independent comparison table between those two ?

thank you,
Vasile


Article: 117336
Subject: Re: suggestion for choosing the right FPGA for gigabit transciever
From: Austin Lesea <austin@xilinx.com>
Date: Wed, 28 Mar 2007 13:28:06 -0700
Links: << >>  << T >>  << A >>
Vasile,

Virtex 5 LX and LXT, SXT, is in production on almost all devices, and
available now.

What isn't in production is sampling right now (and available).

http://www.xilinx.com/onlinestore/silicon/online_store_v5.htm

The serial transceivers are the lowest power of any (if that is
important to you).

We also have at least 30 serial transceiver standards tested and their
characterization reports available (XAUI, PCI express, gigabit ethernet,
fibrechannel, PCIe, HDSDI, etc. etc...).  The last ten or so standards
characterization reports are being finished as we speak.

For the serial transceivers, we have over 400 FAEs worldwide, with about
11 RocketChips(tm) Labs spread around the world where we provide all the
necessary equipment for our customers to work with our MGTs, or to learn
about the signal integrity challenges on these interfaces.

Product+Features+Characterization+Support=Success.

Austin

Article: 117337
Subject: Re: Problems with Xilinx Parallel III Cable
From: jidan1@hotmail.com
Date: 28 Mar 2007 13:30:17 -0700
Links: << >>  << T >>  << A >>
On 28 Mrz., 21:16, Duane Clark <junkm...@junkmail.com> wrote:
> jid...@hotmail.com wrote:
>
> > I used 3.3V JTAG interface since the beginning, and also since the
> > beginning I had problems with it. I think part of the problem might be
> > in the buffer itself. The input voltage at the buffer(74HC125) used
> > there, according to the data sheet, should be max. VCC+1.5. And if you
> > are using VCC=3.3V or 2.5V, the high level voltage coming from the
> > LPT(5V) will be exceeding the max. input voltage. A series resistor
> > was used to limit the current going through the clamp didoe, however
> > the signal might have got distorted because of that.I have also
> > thought about using Schmitt-triggers instead of buffers. At the end I
> > built the exact circuit posted in xilinx website, because I thought
> > the Xilinx team knows better than me. But that circuit has caused me a
> > lot of problems and it seems I am not the only one!
>
> I've always stuck two (because they are inverting) 74HCT14 Schmidt
> triggers in there, and have no problems with long parallel cables on a
> number of different boards and computers.

May I ask why you used inverting and not non-inverting schmitt-
triggers? I assume if you used inverting schmitt-triggers you would
have to change the programmer software to allow these inverted signals
to be understandable.

JJ


Article: 117338
Subject: Re: Problems with Xilinx Parallel III Cable
From: jidan1@hotmail.com
Date: 28 Mar 2007 13:38:55 -0700
Links: << >>  << T >>  << A >>
On 28 Mrz., 22:30, jid...@hotmail.com wrote:
> On 28 Mrz., 21:16, Duane Clark <junkm...@junkmail.com> wrote:
>
>
>
> > jid...@hotmail.com wrote:
>
> > > I used 3.3V JTAG interface since the beginning, and also since the
> > > beginning I had problems with it. I think part of the problem might be
> > > in the buffer itself. The input voltage at the buffer(74HC125) used
> > > there, according to the data sheet, should be max. VCC+1.5. And if you
> > > are using VCC=3.3V or 2.5V, the high level voltage coming from the
> > > LPT(5V) will be exceeding the max. input voltage. A series resistor
> > > was used to limit the current going through the clamp didoe, however
> > > the signal might have got distorted because of that.I have also
> > > thought about using Schmitt-triggers instead of buffers. At the end I
> > > built the exact circuit posted in xilinx website, because I thought
> > > the Xilinx team knows better than me. But that circuit has caused me a
> > > lot of problems and it seems I am not the only one!
>
> > I've always stuck two (because they are inverting) 74HCT14 Schmidt
> > triggers in there, and have no problems with long parallel cables on a
> > number of different boards and computers.
>
> May I ask why you used inverting and not non-inverting schmitt-
> triggers? I assume if you used inverting schmitt-triggers you would
> have to change the programmer software to allow these inverted signals
> to be understandable.
>
> JJ

...or did you actually mean you used two inverted schitt-triggers
becuase you didn't have one non-inverted schmitt-trigger :)


Article: 117339
Subject: Re: A suggestion for a new input interface for functions in VHDL:
From: Jim Lewis <jim@synthworks.com>
Date: Wed, 28 Mar 2007 12:46:36 -0800
Links: << >>  << T >>  << A >>
Ben
> "Jim Lewis" <jim@synthworks.com> wrote in message 
> news:130it10cdc7ocbf@corp.supernews.com...
> 
>> Please also read my paper on Accellera VHDL standard 3.0.  Read up
>> on the unary usage of operators such as XOR.
>> Unfortunately due to overloading it will need a type qualifier, but
>> you will be able to use it as:
>>
>>>>    y_xor(0) <= XOR std_logic_vector'( x(1), x(2), x(3), x(5), x(8), 
>>>> x(9), x(11), x(14),
>>>>                      x(17), x(18), x(19), x(21), x(24), x(25), x(27), 
>>>> x(30), x(32), x(36),
>>>>                      x(38), x(39), x(42), x(44), x(45), x(47), x(48), 
>>>> x(52), x(54), x(55),
>>>>                      x(58), x(60), x(61), x(63) );
> 
> Or I think I'd prefer:
> 
>   y_xor(0) <= xor (x and X"B4D1B4D14B2E4B2E");
> 
> Because it's much less typing.
> 

I like it.  Just if it was more readable.

Jim

Article: 117340
Subject: Re: Where is Open Source for FPGA development?
From: Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>
Date: 28 Mar 2007 20:47:59 GMT
Links: << >>  << T >>  << A >>
In news:1175034224.021941.188430@o5g2000hsb.googlegroups.com
timestamped 27 Mar 2007 15:23:44 -0700, "Andy Peters"
<google@latke.net> posted:
"[..]

> An extra semicolumn at the wrong place can crash XST but these are often
> hard to spot since any other programming language would silently accept
> them.

I take it that you don't simulate much, if at all ...

> Over the last two or three years, I wasted over a month hunting down
> syntax-induced crashes, about a week of it last summer because XST got
> confused while processing BRAM inferences... it took me a few days to
> figure out the link between crashes and memory inferences and many more
> tweaking the inference until I got what I wanted without crashing XST or MAP.
>
> The last time I ran into simple syntax errors I was unable to spot within
> 2-3 minutes, I simply ran the thing through ModelSim's compiler... both a
> fair bit faster and much more reliable.

you should have used ModelSim FIRST !"


That is not a good enough excuse.

Article: 117341
Subject: Re: Problems with Xilinx Parallel III Cable
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 28 Mar 2007 20:49:29 GMT
Links: << >>  << T >>  << A >>
jidan1@hotmail.com wrote:
> 
> ...or did you actually mean you used two inverted schitt-triggers
> becuase you didn't have one non-inverted schmitt-trigger :)
> 

Yep, thats what I meant ;)

Article: 117342
Subject: Re: Problems with Xilinx Parallel III Cable
From: jidan1@hotmail.com
Date: 28 Mar 2007 14:10:49 -0700
Links: << >>  << T >>  << A >>
On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote:
> jid...@hotmail.com wrote:
>
> > ...or did you actually mean you used two inverted schitt-triggers
> > becuase you didn't have one non-inverted schmitt-trigger :)
>
> Yep, thats what I meant ;)

LOL...you might have not known this, but by using two schmitt-triggers
(rather than one) you have made the programmer more noise immune! Do
you still have the schematic for this circuit?


Article: 117343
Subject: Re: suggestion for choosing the right FPGA for gigabit transciever
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 28 Mar 2007 14:16:15 -0700
Links: << >>  << T >>  << A >>
"vasile" <piclist9@gmail.com> wrote in message 
news:1175110434.467891.112950@n59g2000hsh.googlegroups.com...
> Hi,
>
> I need to chose between the Altera Stratix II GX or Stratix III GX and
> some Xilinx Virtex5 FPGA for an implementation of gigabit interface
> into a multi DSP system.
>
> Could you suggest pro and cons between Altera and Xilinx (or maybe
> others) for such design ?
> If I'm trying to compare Altera with Xilinx FPGA based on those
> websites, both are telling is better than the other.
> Maybe you know and independent comparison table between those two ?
>
> thank you,
> Vasile

Do you need the raw power and size of those devices or do you long for 
something more cost effective do do generic workhorse processing at decent 
speeds and sizes?  If so, consider the Lattice ECP2M series as well.  They 
may also have the lowest power transceivers in the industry:

  Lattice:
    3.125Gbps Embedded SERDES (ECP2M only)
    Low 100mW power per channel

  Xilinx:
    Flexible SERDES with 100 Mbps-to-3.2 Gbps operating range supports all 
popular protocols
    Lowest power consumption in the industry: less than 100 mW per channel 
at 3.2 Gbps
      (shall we say 99.99 mW?)

The Lattice devices may not be fancy.  They are used in quads rather than 
trying to divide the functionality into smaller increments.  But if what you 
need is the raw bandwidth without super-extreme processing in between, 
consider the outsider.

In my opinion, the ECP2M product has given Lattice a strong leg up on the 
competition for a strong range of price/performance devices.

The points that are imprtant to some may not be important to others.  Are 
you concerned with:

  Power? (Is >100 mW a problem?)
  Speed? (Is 3.125Gb/s enough?)
  Cost?  (Whoa)
  Flexibility?  (How much granularity?  # of independent channels?  Channel 
width?)
  Device size?  (How many LEs/LUTs will you need?  RAM?)
  Multiplier/DSPblock functionality?  (Are there features that tip the 
balance)
  Logic speed?  (Do you need 200 MHz or 500 MHz?  Simple or complex paths?)
  Clocking?  (Do the devices support your clock source cleanly?)

I haven't seen a good apples-to-apples comparison becasue these choices and 
concerns tend to make analysis less obvious.

- John_H



Article: 117344
Subject: Re: How is it possible to design a convolutional interleaver with sequential memory writes?
From: "Gabor" <gabor@alacron.com>
Date: 28 Mar 2007 14:21:11 -0700
Links: << >>  << T >>  << A >>
On Mar 28, 11:21 am, "Oli Charlesworth" <c...@olifilth.co.uk> wrote:
> On Mar 28, 3:36 pm, "news reader" <newsrea...@google.com> wrote:
>
>
>
> > In my interleaver design for FPGA, I am using an external SDRAM for data
> > storage.
>
> > The clock cycles required to write a frame into the RAM and read a frame
> > back to error correction unit ain't enough.
>
> > The interleaver has 40 rows, which contain 200 * 0, 1, ...39 pieces of data.
> > And one row of the RAM contains 256 data. The write/read pointers are
> > increased by 200*i or decreased by 200*i (0<i<39) for each write/read
> > operation.
>
> > As a result, nearly everytime I write one data or read one data, I have to
> > go
> > through a "open a new row, write or read 1 data, close the row" cycle. To
> > open
> > a row and close it, the memory requires some 10 clock cycles.
>
> > How is it possible to design it in such a way that memory write is in
> > sequential
> > order? That is, when a new frame arrives, I write into the RAM column by
> > until current row is filled, then open the next row.
>
> > I may have to read in a random access, but I can save a lot of clock cycles
> > in
> > the memory write.
>
> > FYI, my resources is some RTL logic and an SDRAM. The design can be made
> > with the FPGA's LUTs, but i don't own the resource.
>
> If you write out by hand the order in which data comes out of a depth-
> N interleaver, you should be able to spot the pattern (it's really not
> a very complicated pattern...).
>
> You can then just apply this pattern to the read pointer, letting you
> store your data in the original (sequential) order.  In other words,
> the interleaving is done during the read operation.
>
> However, the read access pattern will be just as "random" as the write
> access pattern was in your original design.  So unless your SDRAM's
> read cycle is shorter than its write cycle, this won't save you any
> time.
>
> --
> Oli


I'm not sure how much it would help in your application unless your
interleave factor is constant, but using the 4 banks of the SDRAM is
generally a faster way to deal with high-speed data than attempting to
locate all data in a single row.  SDRAM was designed such that the
row activate and precharge can be "buried" behind other operations
when multiple banks are used.  So in essence if you can order your
storage such that each new data comes from a different bank in the
SDRAM you can cut your cycle time down significantly.  Using the
minimum burst size (assuming you don't need more than one word
of data at a time) and read with autoprecharge (to avoid the
additional
command to "close" the row) you can get down to 2 cycles per read if
you rotate through all four banks.  A control sequence for a regular
rotation through 4 banks might look like:
--- Startup section with some wasted cycles ---
Activate Row in Bank 0
NOP
Activate Row in Bank 1
NOP
Activate Row in Bank 2
--- Continuous high-bandwidth section
Read Col in Bank 0 with autoprecharge
Activate Row in Bank 3
Read Col in Bank 1 with autoprecharge
Activate Row in Bank 0
Read Col in Bank 2 with autoprecharge
Activate Row in Bank 1
Read Col in Bank 3 with autoprecharge
Activate Row in Bank 2
Read Col in Bank 0 with autoprecharge
Activate Row in Bank 3
Read Col in Bank 1 with autoprecharge
Activate Row in Bank 0
Read Col in Bank 2 with autoprecharge
Activate Row in Bank 1
Read Col in Bank 3 with autoprecharge
Activate Row in Bank 2
Read Col in Bank 0 with autoprecharge
Activate Row in Bank 3
Read Col in Bank 1 with autoprecharge
--- Closing section with some wasted cycles
NOP
Read Col in Bank 2 with autoprecharge
NOP
Read Col in Bank 3 with autoprecharge

Note that the mid-section can be repeated ad-naseum allowing
unlimited access length at this bandwidth.  Also note that
each access includes its own Row and Column so other than
the bank restriction the order can be truly random.

HTH,
Gabor


Article: 117345
Subject: Re: Problems with Xilinx Parallel III Cable
From: Duane Clark <junkmail@junkmail.com>
Date: Wed, 28 Mar 2007 21:44:37 GMT
Links: << >>  << T >>  << A >>
jidan1@hotmail.com wrote:
> On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote:
>> jid...@hotmail.com wrote:
>>
>>> ...or did you actually mean you used two inverted schitt-triggers
>>> becuase you didn't have one non-inverted schmitt-trigger :)
>> Yep, thats what I meant ;)
> 
> LOL...you might have not known this, but by using two schmitt-triggers
> (rather than one) you have made the programmer more noise immune! Do
> you still have the schematic for this circuit?
> 

I originally got the circuit from someone here in this group (sorry, I 
forgot who). Anyway, here is a 60KB pdf:

http://www.leewardfpga.com/par_jtag.pdf

As you can see, if I have room on my circuit board, I simply stick this 
circuit and a connector on the board, and run a plain parallel cable 
between the computer and the board.

Article: 117346
Subject: Re: Problems with Xilinx Parallel III Cable
From: jidan1@hotmail.com
Date: 28 Mar 2007 14:59:46 -0700
Links: << >>  << T >>  << A >>
On 28 Mrz., 23:44, Duane Clark <junkm...@junkmail.com> wrote:
> jid...@hotmail.com wrote:
> > On 28 Mrz., 22:49, Duane Clark <junkm...@junkmail.com> wrote:
> >> jid...@hotmail.com wrote:
>
> >>> ...or did you actually mean you used two inverted schitt-triggers
> >>> becuase you didn't have one non-inverted schmitt-trigger :)
> >> Yep, thats what I meant ;)
>
> > LOL...you might have not known this, but by using two schmitt-triggers
> > (rather than one) you have made the programmer more noise immune! Do
> > you still have the schematic for this circuit?
>
> I originally got the circuit from someone here in this group (sorry, I
> forgot who). Anyway, here is a 60KB pdf:
>
> http://www.leewardfpga.com/par_jtag.pdf
>
> As you can see, if I have room on my circuit board, I simply stick this
> circuit and a connector on the board, and run a plain parallel cable
> between the computer and the board.

Thanks for sharing the schematics!

Hmm...the TDO and voltage sense line are the exactly the same as
orginally posted by Xilinix. For the other JTAG lines (TMS, TCK, TDI),
two schmitt-triggers and a buffer were used to increase noise
immunity. Thats a little bit too many components for my taste, but
seems to be reliable.


Article: 117347
Subject: Re: Problems with Xilinx Parallel III Cable
From: "John_H" <newsgroup@johnhandwork.com>
Date: Wed, 28 Mar 2007 15:10:17 -0700
Links: << >>  << T >>  << A >>
<jidan1@hotmail.com> wrote in message 
news:1175119186.275874.78300@e65g2000hsc.googlegroups.com...
>
> Thanks for sharing the schematics!
>
> Hmm...the TDO and voltage sense line are the exactly the same as
> orginally posted by Xilinix. For the other JTAG lines (TMS, TCK, TDI),
> two schmitt-triggers and a buffer were used to increase noise
> immunity. Thats a little bit too many components for my taste, but
> seems to be reliable.

Seems to be reliable as in... you've already tried it and seen your troubles 
go away?

Your problem may not be on the Schmidt trigger side of your buffers but in 
the interface between the PC and the programmer chips.

Have you tried your existing programmer on a different PC to see if the 
behavior is identical or vastly different?

You could modify the Parallel-III style design with comparators and a 
low-voltage DC-DC boost converter with fixed 5V output to power the 
LPT-compatible circuit with a variable logic level I/O to get closer to 
Parallel-IV performance with a Parallel-III interface. 



Article: 117348
Subject: Re: Problems with Xilinx Parallel III Cable
From: "comp.arch.fpga" <ksulimma@googlemail.com>
Date: 28 Mar 2007 16:04:06 -0700
Links: << >>  << T >>  << A >>

jidan1@hotmail.com schrieb:

> Since this problem applies to more than one board, I assume the
> problem must lay on the programmer itself. My explanation is that
> maybe the buffer IC's get hot or something...I really don't know.
> I want to know if there is anyone who has had problems with this
> programmer cable.

As I posted before, there are many issues with parallel cable 3,
especially
in conjunction with old versions of impact. (The old software versions
simultaneously turn of
the output enable and change the data output value resulting in a race
condition)

The main issue is, that the parallel port has TTL logic levels that
only have a guaranteed V_OH of
 2V. But a 5V powered 74HC125 has a threshold voltage of 2.5V which
might never be reached.
A 3.3V powered 75HC125 still has a threshold of 1.65V. In that range
the slope of a parallel port output
can be very slow, but the 74HC is quite fast. As a result noise on the
parallel port will amplify to
many clock edges to TCK.

You can solder 2k resistors between each buffers input and output pin.
(0402 SMT fits perfectly)
This creates a schmitt trigger with a large hysteresis which helps a
lot.

For building your own cable there are CMOS families that have
thresholds of 1/3 VCC instead of
1/2 VCC.
A 50mV hysteresis is not enough, so you need the positive feedback
from output to input in all cases.

Kolja Sulimma


Article: 117349
Subject: Re: Confuse on Spartan speed
From: "Ace" <yasirmm@gmail.com>
Date: 28 Mar 2007 17:49:18 -0700
Links: << >>  << T >>  << A >>
Thank you to both Andreas and Paul. After reading your feedback, can I
make this conclusion "Spartan FPGA has it's own clock which can fit
most design".





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